Migración de plataforma tecnológica basada en redes definidas por software para gestión de subestaciones eléctricas a una arquitectura 

basada en microservicios  

   

  

NILTON STEVEEN VÉLEZ GARCÍA    

  

 Informe final bajo la modalidad práctica empresarial presentado para 

optar al título de: Ingeniero de Sistemas 

   

   

Asesor interno: Ph.D. Juan Felipe Botero 

  

Asesor Externo: Andrés Felipe Castaño Mazo 

         

 Departamento de Ingeniería de Sistemas 

Facultad de Ingeniería Universidad de Antioquia 

Medellín, Colombia 2019 

 TABLA DE CONTENIDO

Resumen 3

Introducción 4

Objetivos 10 Objetivo General 10 Objetivos específicos 10

Marco Teórico 10 Arquitectura de software 10 Arquitectura monolítica 12 Arquitectura cliente - servidor 14 Arquitectura de n-capas 17 Arquitectura orientada a servicios 18 Microservicios 19 Aspectos de calidad del software (ISO/IEC 25010) 21

Adecuación funcional: 22 Eficiencia de desempeño: 22 Compatibilidad: 22 Usabilidad: 23 Fiabilidad: 23 Seguridad: 23 Mantenibilidad: 24 Portabilidad: 24

Subestaciones eléctricas 25 IEC 61850 25 Redes definidas por software 26

Metodología 26 Fase de análisis 26

Necesidades y/o problemas encontrados: 27 Alcance del proyecto: 28 Funcionamiento inicial de la aplicación: 28

Fase de diseño 29 Exploración de tecnologías: 29 Diseño de arquitectura: 31 Diseño de base de datos 33 Diagramas de flujo: 34 Mockups: 34

Fase de implementación 35 Fase de pruebas 36

1

Resultados y análisis 36 Interfaz gráfica mostrada en el evento 61850: 36 Proyecto realizado con microservicios y ONOS: 42 Pruebas de aceptación: 45 Resultados y opiniones en el evento 61850: 46

Conclusiones 47

Referencias Bibliográficas 49    

                       

2

Resumen La automatización de tareas y procesos ha madurado gracias a                   innovaciones tecnológicas por ejemplo en los campos de la robótica y                     la inteligencia artificial logrando en la mayoría casos más eficiencia o                     mayor precisión. En el campo del desarrollo de software nace un                     concepto nuevo denominado DevOps donde los equipos de desarrollo                 y operaciones ya no están "aislados" y donde los ingenieros desarrollan                     un rango de habilidades que no están limitadas a una sola función.                       Ahora bien para el caso del campo de las redes de datos en los últimos                             20 años no han sido muchos los avances y éstos se han limitado sólo a                             innovaciones en el hardware, por lo que el enrutamiento o envío de                       paquetes sigue siendo igual que antes, lo que ha generado un gran                       problema en su administración, debido a que las redes han crecido                     gracias a que más personas siguen teniendo acceso a la red.                     Afortunadamente en los últimos años surgió un nuevo paradigma                 denominado redes definidas por software que gracias a que separa el                     plano de datos del plano de control (éste se le da a una aplicación de                             software llamado controlador), es posible cumplir con el objetivo de                   centralizar y automatizar una red dando un paso firme hacia la                     creación de redes inteligentes. Una gran diversidad de redes de                   comunicaciones se pueden diferenciar en la actualidad, sin embargo                 una aplicación interesante bajo el marco de las redes definidas por                     software y que ha sido abordada durante los últimos años gracias al                       trabajo conjunto de compañías e instituciones como la Universidad de                   Antioquia, Colciencias, Ruta N o Kinnesis S.A.S, son las redes en las                       subestaciones eléctricas, dando como resultado una plataforma web               para la gestión de dichas subestaciones.  La aplicación desarrollada contaba entonces con un controlador               capaz de comunicarse con un concentrador comercial de subestación,                 para alcanzar ciertas funciones de automatización, e incluía una                 interfaz web donde el personal de la subestación podía realizar tareas                     de configuración y gestión sobre la red; sin embargo después de                     múltiples pruebas y ser mostrado en diferentes empresas del sector                   eléctrico a nivel nacional e internacional se determinó que una buena                     opción para este tipo de aplicación que podía seguir escalando y                     además ofrecía funcionalidades específicas, era desarrollarla bajo una               arquitectura basada en microservicios, debido a que el fallo en algún                     componente estaba afectando la disponibilidad de toda la aplicación                 en general, al tratarse de una aplicación monolítica. De esta manera                     nació este proyecto con el objetivo de migrar las funcionalidades a                     pequeños módulos y separar el front-end del back-end. Por el lado del                       

3

front-end se logró cambiar la interfaz gráfica añadiendo ese aspecto de                     calidad correspondiente a la usabilidad y del lado del back-end se                     desarrollaron microservicios para topología, usuarios y dispositivos             utilizando ONOS como controlador para revisar su correcto               funcionamiento. La plataforma fue presentada en un evento a nivel                   internacional que reunió a más de 150 expertos en la norma IEC 61850                         acaparando el interés de grandes compañías del sector eléctrico para                   posibles alianzas y ventas.  Introducción El crecimiento de las redes informáticas o redes de computadores                   desde su origen ha estado estrechamente relacionado con 2 factores                   fundamentales como lo son la necesidad de comunicación o                 transmisión de la información, y el desarrollo de nuevas y avanzadas                     tecnologías para dicho propósito. Esos avances no se detienen y van                     aumentando a medida que pasa el tiempo como un efecto de “bola                       de nieve” y es por eso que la población mundial ha podido percibir                         como se ha pasado rápidamente del invento de las                 supercomputadoras y transistores, a tener en la actualidad               computadoras personales y dispositivos inteligentes que a través de las                   redes interconectadas cumplen con el propósito de comunicar o                 intercambiar información. Ahora bien, todos los tipos de redes (campus,                   data center, etc) están creciendo a grandes velocidades a medida                   que más personas con más dispositivos se están conectando y                   accediendo a una creciente cantidad de datos, y como se menciona                     en [1], ésto no está del todo mal con el usuario final o los desarrolladores                             de software, en primer lugar debido a que el que hace uso de la                           información solo cumple el rol de consumidor y por el otro lado para el                           desarrollador de software de la actualidad nace un nuevo concepto                   denominado DevOps que según [3], es un conjunto de prácticas que                     automatiza los procesos entre el desarrollo y los equipos de TI logrando                       de esta manera poder construir, probar y desplegar de una forma más                       rápida y segura, y que gracias a los servicios basados en la nube ([4]                           PaaS, SaaS, Iaas) no se necesita ser un experto en infraestructura para                       configurar las aplicaciones y finalmente el desarrollador sería un                 consumidor más de los proveedores de servicios de la nube (Google,                     AWS, Azure, etc).  Según lo mencionado anteriormente tanto el usuario final como los                   desarrolladores no tienen mucho de qué preocuparse sobre dónde y                   cómo se están administrando los datos ya que estos procesos tienden a                       automatizarse y ser transparentes para ellos. Ahora bien surge la duda                     entonces sobre quién o quiénes son los que hacen que la información                       esté disponible en todo momento y lugar y también como lo hacen.                       Para conocer o dar respuesta a esta inquietud hay que entender cómo                       funcionan las redes de comunicaciones en la actualidad; por ejemplo                   en la figura 1 tomada de [2], se puede ver una red básica y donde se                               

4

pueden identificar diversos equipos como switches, routers, firewall o                 host, con el propósito de transmitir información entre los equipos                   terminales o con motivos de seguridad para la red, y, según la                       configuración de éstas redes, propósito y ubicación hoy en día se                     pueden ver diversos tipos: LAN, WAN, PAN, CAN, VLAN, etc [5].  

 figura 1. Componentes de una red ethernet [2]. 

 Como se puede ver en [6] el avance en el campo de las redes se debe                               al avance de grandes tecnologías como el internet, los enrutadores,                   ethernet, firewall, vlan y el wifi, sin embargo, puede verse que todos                       estos cambios se fueron dando hasta el fin de siglo, es decir que en 20                             años no han sido muchos los avances en redes y como se mencionó                         anteriormente cada vez hay más personas conectadas y con más                   dispositivos, lo que ha generado un crecimiento a gran escala de las                       redes, y por ende ha crecido la complejidad de mantenerlas. Como                     puede verse en la figura 2, los grandes proveedores de servicios en la                         nube tienen instalaciones ‘gigantescas’ las cuales están distribuidas en                 todo el planeta, lo que nos hace preguntar cuánto más pueden crecer                       y hasta qué punto va a ser posible continuar administrando las redes de                         la misma manera sin llegar al extremo de continuos colapsos en la red o                           que ésta se convierta en un cuello de botella.  

5

 figura 2. Centro de datos de Google en Los Ángeles [8]. 

 Los grandes proveedores han entendido éste gran problema y es por                     ello que se han generado nuevas alternativas o tecnologías, entre ellas                     las redes definidas por software (SDN por sus siglas en inglés) que es una                           tecnología que busca centralizar, automatizar y depurar una red.                 Empresas como Google o AWS como se menciona en [9], están                     utilizando SDN para crear de manera eficiente nubes privadas, públicas                   e híbridas para aumentar la agilidad de implementación de                 aplicaciones y responder mejor a las necesidades comerciales; sin                 embargo durante los últimos 20 años los grandes proveedores de                   equipos (enrutadores, conmutadores) han diseñado equipos con la               misma filosofía (para enrutamiento, tráfico de red, seguridad) por lo que                     el software sigue siendo propiedad intelectual de dichas empresas. Ésta                   fue bien percibida por Nick McKeown científico informático de Stanford                   quien junto a sus colegas desarrollaron un estándar denominado                 OpenFlow con el cual es posible definir los flujos de datos mediante                       software, brindando de esta manera acceso a las tablas de flujo y                       reglas que le indican a los conmutadores y enrutadores como dirigir el                       tráfico de red [31].   Básicamente las redes definidas por software consisten entonces en                 separar el hardware encargado de reenviar los paquetes de las                   decisiones de control, o lo que se conoce comúnmente como el plano                       de datos y plano de control. En la figura 3 que se muestra a                           continuación, es posible ver que en SDN todo el plano de control es                         centralizado en un solo componente el cual de ahora en adelante es                       denominado el controlador, el cual es quien lleva la ‘inteligencia’ de la                       red y se encarga de proporcionar esas reglas a los switches o routers,                         que ahora sólo se convierten en simples emisores del controlador y                     hacen el trabajo habitual de reenvío de paquetes solo que bajo las                       órdenes o lógica implementada en dicho controlador [11].  

6

 

 figura 3. Red tradicional vs Red definida por software [10]. 

  Por otro lado el controlador de SDN no sólo cumple con la función de                           gestionar un amplio rango de recursos del plano de datos o de hacer                         que la red sea mucho más abierta, flexible, escalable y reprogramable,                     si no que también ofrece una serie de API que permite a los servicios y                             aplicaciones simplificar y automatizar las tareas de configuración,               provisión y gestionar nuevos servicios en la red, ofreciendo a los                     operadores nuevas vías de ingresos, diferenciación e innovación [12].                 De acuerdo a ésto y gracias a nuevas versiones del protocolo                     OpenFlow, que ha permitido nuevas funcionalidades como tunelización,               NAT, medición, etc, es posible hoy en día generar nuevas y novedosas                       aplicaciones para la gestión de redes. Según [11,13] esas aplicaciones                   se pueden categorizar dependiendo de la función que realizan como                   aplicaciones de seguridad, calidad de servicio (QoS), ingeniería de                 tráfico (TE), gestión de las listas de control de acceso (ACL), balanceo                       de carga, servicios en ambientes específicos como la computación en                   la nube, las redes móviles, la virtualización de la red y la virtualización de                           las funciones de red (NFV).   Ahora bien un enfoque diferente el cual puede ser abordado usando                     SDN son las redes de las subestaciones eléctricas, o como se menciona                       de aquí en adelante subestación definida por software (SDS por sus                     siglas en inglés), el cual nació y se ha venido implementado en el Grupo                           de Investigación de Telecomunicaciones Aplicadas (GITA) de la               Universidad de Antioquia [32]; en la figura 4 mostrada a continuación se                       puede observar que SDS inicialmente fue concebido como una                 investigación y un prototipo, y no fue sino hasta el año 2015 donde se                           

7

concibe un proyecto denominado “Redes definidas por software (SDN)                 como habilitador de tecnologías de redes inteligentes para el sector                   energía eléctrica” desarrollado gracias al aval de la Universidad de                   Antioquia y los recursos otorgados por Colciencias, donde se pudo                   construir un aplicativo de software básico, compuesto por un                 controlador SDN y una interfaz de usuario con funcionalidades mínimas,                   que permitió corroborar la utilidad de SDN en las redes de datos de las                           subestaciones eléctricas.  Posteriormente, al verificar la adaptabilidad de SDN con las                 subestaciones eléctricas se ejecuta un nuevo proyecto nombrado               “Plataforma tecnológica de redes inteligentes para el sector energía,                 habilitada por redes definidas por software (SDN)” donde participaron                 RutaN como promotor del proyecto e igualmente el Grupo de                   Investigación de Telecomunicaciones Aplicadas GITA, a través de la                 Universidad de Antioquia, y la empresa Kinnesis Solutions como                 principales proponentes [15], el cual tiene como principal objetivo la                   mejora del aplicativo del proyecto anterior, con un controlador más                   robusto, que pueda comunicarse con un concentrador comercial de                 subestación para alcanzar ciertas funciones de automatización, y que                 incluya una interfaz web desde donde el personal de la subestación                     pueda realizar tareas de configuración y gestión sobre la red.    

 figura 4. Línea de tiempo de SDS. 

 Finalmente nace un nuevo proyecto denominado “Desarrollo de               plataforma web para gestión de subestaciones eléctricas, basadas en                 redes definidas por software” cuyo principal propósito era el desarrollo                   de una plataforma web construída sobre un entorno SDN, que                   obedeció a la idea de administrar la red de datos de las subestaciones                         a través de una interfaz a alto nivel. En dicho proyecto se incluyó la visita                             a cuatro empresas del sector energético ‒ tres del exterior y una                       regional‒, en donde se desplegó el sistema y se recogieron nuevas                     necesidades y requisitos específicos para retroalimentación en general               de toda la plataforma. Precisamente de dicha retroalimentación se da                   origen a la propuesta de práctica empresarial para el presente informe                     el cual consiste primordialmente en mejorar en los aspectos de calidad                     

8

de software, puesto que se evidenciaron falencias en algunas                 funcionalidades cuando fueron puestas a prueba en ambientes reales.                 El objetivo principal de esta manera es proporcionar del mismo modo                     una aplicación web que reúna los requisitos del proyecto                 inmediatamente anterior y que tenga consigo los más importantes                 aspectos de calidad del software como lo son la eficiencia, usabilidad                     fiabilidad y mantenibilidad.    Con este objetivo trazado se decide cambiar la arquitectura del                   sistema, que en el momento es monolítica por una basada en                     microservicios, ya que cada función dentro del sistema (descubrimiento                 de topología, dispositivos, usuarios, slices, estadísticas, seguridad, flujos               ,etc), pueden ser tratados como servicios individuales con el propósito                   de proporcionar al sistema modularidad, escalabilidad o contenedores               para un despliegue más rápido. Del mismo modo se opta por cambiar                       la interfaz gráfica por una en la que se use una tecnología más reciente                           para el front-end aprovechando las ventajas de las aplicaciones de una                     sola página añadiendo al usuario una mejor percepción visual y un                     mejor manejo de la plataforma en general. Por último se opta por                       cambiar también el controlador de SDN por uno que presente menos                     fallas en algunas de las funcionalidades del sistema y que del mismo                       modo posea las mismas ventajas que se tenían con el anterior                     controlador.  Cabe destacar que el proyecto actual tiene como objetivo principal                   mejorar en aspectos de calidad, por lo que el desarrollo no se basa en                           crear nuevas funcionalidades hasta no tener una versión estable y                   debidamente probada que incluya todas aquellas con las que contaba                   el anterior proyecto, sin embargo es importante destacar el hecho de                     que la plataforma igualmente se seguirá mostrando en diferentes                 eventos por lo que objetivos como el de mejorar la interfaz gráfica                       deben estar incluidos en el antiguo proyecto mientras se va haciendo la                       migración del mismo. Por ejemplo, el evento se mostró en el evento                       61850 Global llevado a cabo en Berlín Alemania, que reúne a más de                         150 especialistas en IEC 61850 y líderes de implementación de todo el                       mundo, razón por la cual el desarrollo por el lado lado del backend se                           vió afectado para prestar mayor atención en el front-end.  Para la correcta elaboración de este proyecto no se consideraron                   nuevos requisitos funcionales ya que como se dijo anteriormente la                   prioridad en el momento es mejorar en los aspectos o falencias que se                         pudieron evidenciar en las visitas que se realizaron en las 4 compañías                       eléctricas, sin embargo se hizo necesario redefinir la arquitectura                 general del sistema para que sea modular e incluir el nuevo controlador                       SDN. Para la interfaz gráfica se diseñaron mockups con la finalidad de                       tener resultados mucho más rápidos y acordes a las necesidades                   encontradas. Ahora bien, para llevar a cabo el diseño e                   implementación de la aplicación se va a continuar bajo el marco de                       trabajo de las metodologías ágiles ya que como se menciona en [16]                       

9

esta metodología ha sido aceptada por la industria como una mejor                     solución para el desarrollo de proyectos. De este modo se utiliza la                       metodología ágil denominada “programación extrema” (XP por sus               siglas en inglés) debido a que se enfoca en potenciar las relaciones                       interpersonales, promoviendo el trabajo en equipo y además es iterativa                   e incremental, por lo que se tiene retroalimentación continua entre el                     cliente y el equipo de desarrollo; además, se adecua perfectamente al                     proyecto debido a que los requisitos pueden ser muy cambiantes o                     imprecisos en el tiempo. Por otro lado, es oportuna para la idea de                         negocio debido a que el cliente decide lo que quiere y el trabajo es                           dividido en acciones pequeñas y se le asigna un tiempo a cada una.                         Éstas acciones son priorizadas por el cliente y el equipo de desarrollo                       realiza lo que el cliente ha decidido   Objetivos  Objetivo General Desarrollar una plataforma web que optimice la gestión y configuración                   de la red de las subestaciones eléctricas bajo una arquitectura modular.  Objetivos específicos  Realizar una fase de diseño en la cual se incluya el diseño de la                           arquitectura, el modelo de datos y mockups de la aplicación.  Implementar una aplicación web de acuerdo a las especificaciones                 obtenidas en el objetivo específico 1.  Verificación y validación de la correcta integración y operación de                   todo el sistema, mediante la realización de diferentes pruebas de                   funcionalidad y comunicación entre sus componentes, tanto en               ambientes simulados como reales.   Marco Teórico  Arquitectura de software En la etapa de diseño de software, definir una arquitectura para el                       sistema al igual que en los planos de obras en construcción, es de vital                           importancia, debido a que del mismo modo, ayuda a estructurar, definir                     el funcionamiento e interacción de los componentes del sistema y crea                     una base sólida para el proyecto de software para garantizar que sea                       escalable y poderoso.  

10

A través de la historia se han dado grandes avances tecnológicos que                       han hecho evolucionar la forma de estructurar las aplicaciones en la                     actualidad. A continuación en la figura 5 es posible ver una línea de                         tiempo resumida del avance en el campo de la arquitectura de                     software que se remonta desde la aparición de la programación no                     estructurada hasta los proyectos basados en microservicios.  

figura 5. Línea de tiempo de la arquitectura de software [Fuente propia].  

11

 Arquitectura monolítica Este tipo de arquitectura como lo dice su nombre consta o se compone                         de una sola pieza, por lo que está diseñada para ser autónoma, por                         consiguiente los componentes del programa están interconectados e               interdependientes en lugar de estar débilmente acoplados, como es el                   caso de los programas de software modulares. Del mismo modo cada                     componente y sus componentes asociados deben estar presentes para                 que el código sea ejecutado o compilado, por consiguiente para cada                     cambio o actualización del sistema es necesario compilar e                 implementar una versión actualizada del sistema.   Ahora bien, una aplicación puede estar dividida por muchos                 componentes, entre los principales encontramos la base de datos,                 front-end o back-end por lo que este tipo de arquitectura obedece a                       los servicios que dichos componentes ofrecen y no depende de otros                     servicios fuera de este sistema aparte de la integración con otras                     aplicaciones como por ejemplo a través de REST. En la figura 6 tomada                         de [17] se puede evidenciar de una mejor manera como los principales                       componentes están acoplados en la aplicación y entre ellos se pueden                     comunicar para el correcto funcionamiento del sistema.  

   figura 6. Componentes de una arquitectura monolítica [17]. 

 Las ventajas de acuerdo a lo mencionado anteriormente de este tipo                     de arquitectura serían las siguientes [18,19]: 

12

 - Fácil de desarrollar: Al comienzo de un proyecto, es mucho más                     

fácil ir con la arquitectura monolítica. - Sencillo de probar - Simple de implementar: Hay que copiar la aplicación               

empaquetada a un servidor. - Simple para desplegar - Menos costosas: Debido a la simpleza de su estructura, el                   

desarrollo de aplicaciones monolíticas suele ser menos costoso               que otras. 

 Por otro lado también se tienen desventajas: 

- Mantenimiento: Se presenta en el momento en que la aplicación                   ya es demasiado grande y compleja de comprender por                 completo, debido a que realizar nuevos cambios de manera                 rapida y correcta suele ser un desafío. 

- El tamaño de la aplicación puede ralentizar el tiempo de inicio. - Debe volver a implementar la aplicación completa en cada                 

actualización. - Las aplicaciones monolíticas también pueden ser difíciles de               

escalar cuando diferentes módulos tienen requisitos de recursos               en conflicto. 

- Confiabilidad: Un error en cualquier módulo (por ejemplo, pérdida                 de memoria) puede potencialmente desbaratar todo el proceso.               Además, dado que todas las instancias de la aplicación son                   idénticas, ese error afecta la disponibilidad de toda la aplicación                   independientemente de lo fáciles que puedan parecer las etapas                 iniciales, las aplicaciones monolíticas tienen dificultades para             adoptar tecnologías nuevas y avanzadas. Dado que los cambios                 en los lenguajes o marcos afectan a una aplicación completa,                   requiere esfuerzos para trabajar a fondo con los detalles de la                     aplicación, por lo tanto, es costoso considerando tanto el tiempo                   como los esfuerzos. 

         

13

Arquitectura cliente - servidor   

 figura 7. Arquitectura cliente-servidor [20]. 

 Según IBM la arquitectura cliente-servidor es la tecnología que                 proporciona al usuario final el acceso transparente a las aplicaciones,                   datos, servicios de cómputo o cualquier otro recurso del grupo de                     trabajo y/o, a través de la organización, en múltiples plataformas. El                     modelo soporta un medio ambiente distribuido en el cual los                   requerimientos de servicio hechos por estaciones de trabajo inteligentes                 o "clientes, resultan en un trabajo realizado por otros computadores                   llamados servidores.  En la figura 7 tomada de [20] se puede observar una pequeña                       representación de este tipo de arquitectura, donde se pueden                 identificar diversos elementos que la componen y que nos ayudan a                     entender de una mejor manera el funcionamiento en general de las                     aplicaciones cliente-servidor. Como se puede observar se tiene un                 elemento denominado servidor que como su nombre lo dice viene de la                       palabra servir, es decir que puede ser una máquina para la función de                         alojar archivos o también un software instalado en un máquina que sirve                       a las páginas web (denominado servidor web). Un servidor tiene que ser                       una máquina con especificaciones considerables que atiende a               requerimientos específicos de clientes, por lo que puede manejar un                   número considerable de peticiones de acuerdo al número de clientes                   que solicitan algún servicio. Comúnmente al servidor también se le llama                     back-end y la interfaz para interactuar con el usuario no debe ser muy                         sofisticada dentro del mismo, debido a que la comunicación se hace a                       través de la interfaz gráfica del cliente. 

14

Por otro lado se tiene el componente cliente, en la actualidad                     denominado front-end, que normalmente reside en el computador del                 usuario (generalmente un navegador web), es decir que puede ser                   cualquier dispositivo que esté conectado a la red (computador, móvil,                   etc) y es quien solicita algún servicio del servidor comúnmente desde                     una interfaz gráfica [20].   Ahora bien de acuerdo a la figura 7 faltaría darle significado a las                         solicitudes o respuestas que existen entre los clientes y el servidor y es                         que en la actualidad esta comunicación es posible gracias al protocolo                     HTTP que sirve para transferir archivos a través de la world wide web y                           que se ejecuta sobre el conjunto de protocolos TCP/IP. A lo largo de los                           años se han desarrollado algunos protocolos y tecnologías para el                   intercambio de datos o archivos. En un principio el protocolo más usado                       fue el protocolo simple de acceso a objetos (SOAP por sus siglas en                         inglés), el cual puede funcionar con cualquier protocolo de la capa de                       aplicación (HTTP, SMTP, TCP, UDP) y devuelve los datos al receptor o                       cliente en un formato XML, éste protocolo es el más usado en entornos                         empresariales distribuidos debido a que la seguridad, la autorización y el                     manejo de errores están incorporados en el protocolo y no asume una                       comunicación directa de punto a punto. Por otro lado en los últimos                       años ha cogido una gran fuerza el uso de un estilo arquitectónico                       denominado “Transferencia de estado representacional” (REST por sus               siglas en inglés), que define un conjunto de recomendaciones para el                     diseño de aplicaciones de acoplamiento flexible que utilizan el                 protocolo HTTP para la transmisión de datos. REST no prescribe cómo                     implementar los principios en un nivel inferior. En cambio, las pautas de                       REST permiten a los desarrolladores implementar los detalles de acuerdo                   con sus propias necesidades [21].  Ventajas de un sistema cliente/servidor [22]: 

- Centralización del control: El servidor dedicado controla el               acceso, los recursos y la integridad de los datos para que un                       programa o cliente no autorizado no pueda dañar el sistema. 

- Escalabilidad : puede aumentar la capacidad de los clientes y                   servidores por separado. 

- Fácil mantenimiento : Distribución de las funciones y               responsabilidades a varias computadoras independientes, puede           reemplazar, reparar, actualizar o incluso mover un servidor,               mientras que los clientes no se verán afectados por ese cambio (o                       afectarán de manera mínima). Esta independencia de los               cambios también se conoce como encapsulación. 

15

- Existen tecnologías suficientemente desarrolladas, diseñadas para           el paradigma de C/S para garantizar la seguridad en las                   transacciones, la facilidad de uso de la interfaz y la facilidad de                       uso. 

 Desventajas de un sistema cliente/servidor [22]: 

- El tráfico de red siempre ha sido un problema en el paradigma de                         C/S. Cuando una gran cantidad de clientes simultáneos envían                 solicitudes al mismo servidor, esto puede causar muchos               problemas (directamente proporcional: a más clientes - más               problemas para el servidor). 

- El software y el hardware de un servidor son generalmente muy                     decisivos. Es posible que un personal de hardware de                 computadoras no pueda atender a un cierto número de clientes.                   Por lo general, necesita software y hardware específicos,               especialmente en el lado del servidor, para cumplir con el trabajo.                     Por supuesto, esto aumentará el costo. 

 Las arquitecturas cliente/servidor han evolucionado como se puede ver                 en la figura 8 por lo que frecuentemente se pueden ver variaciones de                         acuerdo al número de capas que incorpora. Un sistema basado en                     capas es un sistema jerárquico donde cada capa provee servicios a la                       capa superior y es servido por la capa inferior e igualmente cada                       componente corresponde a cada capa y la comunicación entre ellas                   al igual que como se explicó con el modelo cliente/servidor se da a                         través de protocolos, sin embargo esta comunicación solo se puede dar                     entre las capas adyacentes. Para comprender mejor esta afirmación                 véase la figura 8 en donde se pueden identificar tres unidades                     funcionales fundamentales: lógica de presentación o interfaz de               usuario, lógica de negocios y lógica de datos. Existen entonces 2                     variaciones, por ejemplo en las aplicaciones cliente/servidor de 2                 niveles, donde la lógica de negocios está oculta dentro de la interfaz de                         usuario en el cliente o dentro de la base de datos en el servidor en                             forma de procedimientos almacenados. Alternativamente, la lógica de               negocios puede dividirse entre el cliente y el servidor. Los servidores de                       archivos y los servidores de bases de datos con procedimientos                   almacenados son ejemplos de arquitectura de 2 niveles. Por otro lado                     en aplicaciones cliente/servidor de 3 niveles, la lógica de negocios                   reside en el nivel medio, separada de los datos y la interfaz de usuario.                           De esta manera, los procesos se pueden administrar y desplegar por                     separado desde la interfaz de usuario y la base de datos. Además, los                         sistemas de 3 niveles pueden integrar datos de múltiples fuentes. 

16

  figura 8. Arquitectura cliente-servidor de 2 y 3 capas[23]. 

  Arquitectura de n-capas En la figura 5 igualmente se puede evidenciar que en la arquitectura                       cliente/servidor también es posible extender de 1,2 ó 3 capas a ‘N’                       número de éstas, y de ésta manera es posible diferenciar entre lógica                       de presentación y de aplicación. Según [24] la arquitectura de ‘N’                     capas es también llamada arquitectura de múltiples niveles porque el                   software está diseñado para tener las funciones de procesamiento,                 gestión de datos y presentación separadas física y lógicamente. Esto                   significa que estas diferentes funciones se alojan en varias máquinas o                     clústeres, lo que garantiza que los servicios se brindan sin compartir los                       recursos y, como tales, estos servicios se entregan a la máxima                     capacidad.  Esta arquitectura al igual que en 1, 2 ó 3 capas implica dividir la                           aplicación en los 3 niveles: 

● Capa de presentación: El nivel más alto de la aplicación es la                       interfaz de usuario. La función principal de la interfaz es la                     traducción de tareas y resultados a algo que el usuario pueda                     entender.  

● Capa de lógica o negocios: Esta capa se encarga de coordinar                     la aplicación, procesa comandos, realiza decisiones lógicas y               evaluaciones y realiza cálculos como también mueve y procesa                 datos entre las 2 capas adyacentes. 

17

● Capa de datos: En esta capa es donde la información es                       almacenada y recuperada desde una fuente de datos (base de                   datos, archivos, etc) para luego ser pasada de regreso a la capa                       de negocio para su procesamiento y así ser luego devuelta al                     usuario final o cliente quien realizó dicha solicitud. 

 Ventajas de la arquitectura a ‘N’ capas: 

- Seguro: Puede asegurar cada uno de los tres niveles por separado                     utilizando diferentes métodos. 

- Fácil de administrar: Puede administrar cada nivel por separado,                 agregando o modificando cada nivel sin afectar los otros niveles. 

- Escalable: Si necesita agregar más recursos, puede hacerlo por                 nivel, sin afectar los otros niveles. 

- Flexible: Además de la escalabilidad aislada, también puede               expandir cada nivel de la manera que lo requieran sus requisitos. 

  Es decir que con la arquitectura de n niveles, es posible adoptar nuevas                         tecnologías o agregar más componentes y funcionalidades sin tener                 que volver a diseñar e implementar todo el software, facilitando de esta                       manera el escalamiento y mantenimiento del mismo y, por otro lado, en                       cuanto al tema de la seguridad se puede almacenar información                   sensible o confidencial en el nivel lógico, manteniéndola alejada del                   nivel de presentación, lo que lo hace más seguro.  Arquitectura orientada a servicios Una arquitectura orientada a servicios (SOA) es un patrón de                   arquitectura de software, cuyos componentes de aplicaciones             proporcionan servicios a otros componentes a través de un protocolo                   de comunicaciones a través de una red. La comunicación puede                   involucrar el paso simple de datos o podría involucrar dos o más                       servicios que coordinen servicios de conexión entre sí. De esta manera,                     en una SOA existen 2 roles principales: el proveedor y consumidor de                       servicios, en donde se usa un Enterprise Service Bus para la                     comunicación punto a punto. La capa de consumidor es el punto                     donde los consumidores (usuarios humanos, otros servicios o terceros)                 interactúan con la SOA y la capa de proveedor consta de todos los                         servicios definidos dentro de la SOA. La figura 9 muestra una vista rápida                         de una arquitectura SOA.    

18

 figura 9. Arquitectura SOA[25]. 

  Microservicios Cuando se habla de microservicios, más que un tipo de arquitectura es                       mejor visto como un estilo arquitectónico debido a que los                   componentes de la aplicación son aplicaciones independientes de su                 propiedad y se pueden comunicar entre sí mediante RMI (Invocación                   de método remoto), servicios web Restful o mensajería push. Además                   estas pequeñas aplicaciones independientes pueden considerar o             configurar su propia arquitectura, por ejemplo un microservicio para la                   administración de usuarios de una aplicación puede tener una                 arquitectura cliente-servidor de n capas y ser implementado con python                   y un modelo de datos no relacional, mientras que un microservicio para                       la misma aplicación para la gestión de compras podría tener un tipo de                         arquitectura totalmente diferente, codificado en JavaScript y con un                 modelo de datos relacional por ejemplo.  Teniendo en cuenta lo dicho anteriormente es fundamental que cada                   microservicio sea totalmente independiente del resto y que de esta                   manera se puedan cambiar, eliminar o actualizar fácil y rápidamente                   sin afectar a toda la aplicación como sucede en el caso del monolítico,                         

19

además la gobernanza descentralizada de los servicios permite a los                   desarrolladores utilizar diferentes lenguajes de programación o modelos               de datos por lo que la escabilidad es casi ilimitada [25]. Como los                         servicios son muy pequeños, las aplicaciones cliente por lo general                   necesitan interactuar con múltiples servicios para obtener la información                 solicitada, por tal motivo se utiliza un API Gateway, que es una capa                         abstracta que oculta todos los microservicios y al llegar una solicitud                     desde el cliente el Gateway la procesa y luego enruta hacia los servicios específicos como puede verse en la figura 10.  

 figura 10. Arquitectura basada en microservicios. [36] 

 Ventajas de los microservicios [27]: 

- Cada servicio se puede desarrollar en el lenguaje que mejor se                     adapte a los requisitos 

- El microservicio es lo más independiente y pequeño posible por lo                     que el desarrollador tendrá mejor conocimiento y entendimiento               del código 

- No hay una base de datos centralizada (esta es una de las                       grandes diferencias con SOA) 

- Cuando un servicio necesita hablar con otro servicio, pueden                 hablar mediante API, específicamente mediante un servicio REST.               Un servicio REST es el medio para comunicarse, por lo que hay                       poca transformación 

- Escabilidad 

20

  Desventajas de los microservicios [26]: 

- Los microservicios al disminuir la complejidad de la administración                 del equipo puede también disminuir la comunicación, por lo que                   la modificación de un servicio puede afectar la funcionalidad de                   muchos otros y la comunicación es un aspecto clave para la                     solución de este tipo de problemas. 

- Aplicación no uniforme: El tener libertad de escoger las                 tecnologías para cada microservicio también puede generar             problemas y puede aumentar los costos de mantenimiento a                 largo plazo. 

- Mayor uso de recursos: la inversión inicial para ejecutar estas                   aplicaciones es alta porque todos los componentes que se                 ejecutan de forma independiente necesitan sus propios             contenedores de tiempo de ejecución con más memoria y CPU. 

- Complejidad Dev-Ops: Se debe tener un equipo maduro para                 manejar la complejidad del despliegue de una aplicación               basada en microservicios. 

 Aspectos de calidad del software (ISO/IEC 25010) Cómo lo describe la norma ISO/IEC 25010 [28], la calidad de software                       puede entenderse como el grado en el que un producto satisface las                       necesidades del usuario aportando de esta manera un valor (comercial                   por ejemplo). Esos requisitos (funcionalidad, mantenibilidad, fiabilidad,             etc) son precisamente los que se encuentran representados en el                   modelo de calidad.  Según la ISO/IEC 25010 el modelo de calidad del producto de software                       se encuentra compuesta por las 8 características de calidad mostradas                   a continuación en la figura 11:  

 figura 11. Arquitectura basada en microservicios [28]. 

 

21

Adecuación funcional:  Esta característica representa la capacidad del producto de software para proporcionar funciones que satisfacen los requisitos declarados e implícitos, cuando el producto se usa en las condiciones especificadas. Como se ve en la figura 11 esta característica se subdivide a su vez en las siguientes subcaracterísticas: 

● Completitud funcional. Grado en el cual el conjunto de                 funcionalidades cubre todas las tareas y los objetivos del usuario                   especificados. 

● Corrección funcional. Capacidad del producto o sistema para               proveer resultados correctos con el nivel de precisión requerido. 

● Pertinencia funcional. Capacidad del producto software para             proporcionar un conjunto apropiado de funciones para tareas y                 objetivos de usuario especificados.  

Eficiencia de desempeño:  Esta característica representa el desempeño relativo a la cantidad de                   recursos utilizados bajo determinadas condiciones. Esta característica se               subdivide a su vez en las siguientes subcaracterísticas: 

● Comportamiento temporal. Los tiempos de respuesta y             procesamiento y los ratios de throughput de un sistema cuando                   lleva a cabo sus funciones bajo condiciones determinadas en                 relación con un banco de pruebas (benchmark) establecido. 

● Utilización de recursos. Las cantidades y tipos de recursos utilizados                   cuando el software lleva a cabo su función bajo condiciones                   determinadas. 

● Capacidad. Grado en que los límites máximos de un parámetro                   de un producto o sistema software cumplen con los requisitos. 

 Compatibilidad:  Capacidad de dos o más sistemas o componentes para intercambiar                   información y/o llevar a cabo sus funciones requeridas cuando                 comparten el mismo entorno hardware o software. Esta característica se                   subdivide a su vez en las siguientes subcaracterísticas: 

● Coexistencia. Capacidad del producto para coexistir con otro               software independiente, en un entorno común, compartiendo             recursos comunes sin detrimento. 

● Interoperabilidad. Capacidad de dos o más sistemas o               componentes para intercambiar información y utilizar la             información intercambiada. 

  

22

Usabilidad:  Capacidad del producto software para ser entendido, aprendido,               usado y resultar atractivo para el usuario, cuando se usa bajo                     determinadas condiciones. Esta característica se subdivide a su vez en                   las siguientes subcaracterísticas: 

● Capacidad para reconocer su adecuación. Capacidad del             producto que permite al usuario entender si el software es                   adecuado para sus necesidades. 

● Capacidad de aprendizaje. Capacidad del producto que             permite al usuario aprender su aplicación. 

● Capacidad para ser usado. Capacidad del producto que               permite al usuario operarlo y controlarlo con facilidad. 

● Protección contra errores de usuario. Capacidad del sistema para                 proteger a los usuarios de hacer errores. 

● Estética de la interfaz de usuario. Capacidad de la interfaz de                     usuario de agradar y satisfacer la interacción con el usuario. 

● Accesibilidad. Capacidad del producto que permite que sea               utilizado por usuarios con determinadas características y             discapacidades. 

 Fiabilidad:  Capacidad de un sistema o componente para desempeñar las                 funciones especificadas, cuando se usa bajo unas condiciones y                 periodo de tiempo determinados. Esta característica se subdivide a su                   vez en las siguientes subcaracterísticas: 

● Madurez. Capacidad del sistema para satisfacer las necesidades               de fiabilidad en condiciones normales. 

● Disponibilidad. Capacidad del sistema o componente de estar               operativo y accesible para su uso cuando se requiere. 

● Tolerancia a fallos. Capacidad del sistema o componente para                 operar según lo previsto en presencia de fallos hardware o                   software. 

● Capacidad de recuperación. Capacidad del producto software             para recuperar los datos directamente afectados y restablecer el                 estado deseado del sistema en caso de interrupción o fallo.  

Seguridad:  Capacidad de protección de la información y los datos de manera que                       personas o sistemas no autorizados no puedan leerlos o modificarlos.                   Esta característica se subdivide a su vez en las siguientes                   subcaracterísticas: 

23

● Confidencialidad. Capacidad de protección contra el acceso de               datos e información no autorizados, ya sea accidental o                 deliberadamente. 

● Integridad. Capacidad del sistema o componente para prevenir               accesos o modificaciones no autorizados a datos o programas de                   ordenador. 

● No repudio. Capacidad de demostrar las acciones o eventos que                   han tenido lugar, de manera que dichas acciones o eventos no                     puedan ser repudiados posteriormente. 

● Responsabilidad. Capacidad de rastrear de forma inequívoca las               acciones de una entidad. 

● Autenticidad. Capacidad de demostrar la identidad de un sujeto                 o un recurso. 

 Mantenibilidad:  Esta característica representa la capacidad del producto software para                 ser modificado efectiva y eficientemente, debido a necesidades               evolutivas, correctivas o perfectivas. Esta característica se subdivide a su                   vez en las siguientes subcaracterísticas: 

● Modularidad. Capacidad de un sistema o programa de               ordenador (compuesto de componentes discretos) que permite             que un cambio en un componente tenga un impacto mínimo en                     los demás. 

● Reusabilidad. Capacidad de un activo que permite que sea                 utilizado en más de un sistema software o en la construcción de                       otros activos. 

● Analizabilidad. Facilidad con la que se puede evaluar el impacto                   de un determinado cambio sobre el resto del software,                 diagnosticar las deficiencias o causas de fallos en el software, o                     identificar las partes a modificar. 

● Capacidad para ser modificado. Capacidad del producto que               permite que sea modificado de forma efectiva y eficiente sin                   introducir defectos o degradar el desempeño. 

● Capacidad para ser probado. Facilidad con la que se pueden                   establecer criterios de prueba para un sistema o componente y                   con la que se pueden llevar a cabo las pruebas para determinar                       si se cumplen dichos criterios. 

 Portabilidad:  Capacidad del producto o componente de ser transferido de forma                   efectiva y eficiente de un entorno hardware, software, operacional o de                     

24

utilización a otro. Esta característica se subdivide a su vez en las                       siguientes subcaracterísticas: 

● Adaptabilidad. Capacidad del producto que le permite ser               adaptado de forma efectiva y eficiente a diferentes entornos                 determinados de hardware, software, operacionales o de uso. 

● Capacidad para ser instalado. Facilidad con la que el producto                   se puede instalar y/o desinstalar de forma exitosa en un                   determinado entorno. 

● Capacidad para ser reemplazado. Capacidad del producto para               ser utilizado en lugar de otro producto software determinado con                   el mismo propósito y en el mismo entorno. 

 Subestaciones eléctricas Una subestación consiste de un gran número de conmutadores y                   equipos usados en la transmisión de electricidad, los cuales son                   controlados, supervisados y protegidos por un sistema de               automatización de subestaciones (SAS), el cual se encarga de proveer                   todas las funciones requeridas para la operación confiable y segura de                     toda la subestación. Estos sistemas de automatización están               conformados por un equipo de dispositivos electrónicos inteligentes               (IEDs por sus siglas en inglés) y la red de comunicaciones entre ellos.                         Estos equipos implementan tareas de control, protección y monitoreo                 sobre el sistema de potencia. Básicamente para el intercambio de                   datos, todos los IEDs son conectados a través de TCP/UDP e IP, sobre                         redes de área local (LAN) basadas en Ethernet. Gracias a esto, es                       posible desplegar cualquier tecnología avanzada de comunicaciones             en la subestación.  IEC 61850 IEC 61850 es un estándar el cual define una norma que consta de 10                           partes y aborda un conjunto de especificaciones aplicables a los                   sistemas de automatización de subestaciones por lo que define                 entonces un modelo de datos que tiene como objetivos principales                   posibilitar interoperabilidad entre IEDs de diferentes fabricantes y               deseablemente la intercambiabilidad, entendida como la capacidad             de reemplazar un dispositivo de cierto fabricante que esté en                   operación, con un dispositivo de otro proveedor sin tener que hacer                     cambios adicionales en algún otro elemento de la red. Esta norma                     especifica además un conjunto de servicios y objetos abstractos, que                   permiten que se puedan desarrollar aplicaciones de manera               independiente de un protocolo específico y que haya un intercambio                   

25

compatible de información entre los diferentes componentes de los                 sistemas de automatización [29].  Redes definidas por software Las redes definidas por software (SDN), se constituyen en un nuevo                     enfoque de redes basado en un plano de control centralizado, en                     donde la arquitectura cuenta con interfaces estandarizadas entre el                 plano de control y el plano de los datos. En este paradigma, desde el                           punto de vista de los operadores de red, el elemento clave diferencial                       es reemplazar la interfaz de la línea de comandos estándar, por la                       gestión directa de los dispositivos mediante una interfaz abierta y                   programable [12]. De manera más general, se afirma también en [12]                     que la llave básica de SDN es la separación de la lógica de control de                             la operación del hardware, y se otorga dicha lógica a una plataforma                       de software denominada controlador como se puede observar en la                   figura 3. Esto habilita la automatización de los procesos de gestión de la                         red, centraliza la lógica de control y abre los recursos de la red hacia                           estándares abiertos y hacia los usuarios finales   Metodología El proyecto fue realizado con la metodología ágil ‘programación                 extrema’ (XP por sus siglas en inglés), debido a que los requisitos pueden                         cambiar mucho en el tiempo, el uso de nuevas tecnologías es algo                       fundamental para la migración del proyecto y por ende trae consigo                     riesgos al ser un proyecto con un tiempo fijo estipulado y además el                         equipo de desarrollo es relativamente pequeño como se menciona en                   [30] la adopción de esta metodología para el proyecto es muy                     adecuada. Ahora bien, para la realización del proyecto se incluyeron                   de igual forma 4 etapas para tener una mayor claridad del alcance del                         sistema: una etapa o fase de análisis, fase de diseño, fase de desarrollo                         y finalmente una fase de pruebas. Aunque pareciera una metodología                   de desarrollo tradicional se establecieron ciertas actividades iniciales               para cada fase, sin embargo éstas fueron cambiando acorde a los                     requisitos y la respectiva retroalimentación que se fue haciendo en                   cada entrega.  Fase de análisis En ésta fase se analizaron los requisitos funcionales y no funcionales del                       sistema, la viabilidad, limitaciones y el alcance del mismo.   

26

Necesidades y/o problemas encontrados: - Requisitos funcionales: De acuerdo a las recomendaciones y               

problemas encontrados en las visitas realizadas en el anterior                 proyecto se pudo determinar que para la migración del sistema                   no es necesario realizar nuevas implementaciones para la               aplicación por lo que los requisitos funcionales se limitó solo a la                       correción de bugs en las funcionalidades existentes y los requisitos                   que surgieron según las tecnologías que se usaron. 

- Requisitos no funcionales: El sistema para automatización en               subestaciones eléctricas cuenta con un gran número de               funcionalidades entre las que se encuentran: descubrimiento de               topología, creación de slices, tabla de flujos y grupos, estadísticas,                   detalle de dispositivos, wireshark, entre otros, por lo que crear un                     sistema fácil de usar y conforme a los requisitos funcionales no es                       tarea fácil, en el anterior proyecto se pudo evidenciar que al                     sistema le hacía falta usabilidad y es por ello que se consideró el                         cambio por completo de la interfaz gráfica para darle a los                     usuario finales una mejor percepción del sistema. Por otro lado                   con la migración también se tuvieron en cuenta las otras                   características de calidad como la eficiencia, fiabilidad,             seguridad, mantenibilidad, etc. 

 - Controlador: Durante las visitas realizadas en el anterior proyecto                 

se ha evidenciado que el controlador que actualmente se está                   utilizando (ODL) ha tenido problemas de estabilidad y algunos                 bugs con funcionalidades específicas que hacía tedioso el               desarrollo. 

 - Evento 61850 Global y otros proyectos: En un principio SDS fue                     

desarrollado bajo el Grupo de Investigación de             Telecomunicaciones Aplicadas GITA de la Universidad de             Antioquia y apoyado por Ruta N, Kinnesis y Colciencias.                 Posteriormente, el papel que cumplia la universidad de Antioquia                 para con el grupo, lo empezó a tener Inorks (Industrial networks                     https://inorks.com), ahora solo con los recursos de Ruta N y                   Kinnesis. Inorks se conforma como una empresa con la visión de                     desarrollar un nuevo nivel de abstracción para las redes de datos                     industriales y virtualización, no una solución tradicional basada en                 enfoques heredados, sino una mejora sustancial para resistencia               futura. El proyecto de automatización de subestaciones eléctricas               (SDS) actualmente es uno de los productos y la empresa fue                     invitada al evento 61850 global llevado a cabo en Berlín                   

27

Alemania, el cual reúne a las más reconocidas empresas de TI,                     más de 150 especialistas en IEC 61850 y líderes de implementación                     de todo el mundo. Sin embargo inorks también está llevando a                     cabo otro producto denominado SION CORE que es una                 plataforma de comunicaciones que simplifica la administración y               operación de redes de datos. SION permite una conexión segura                   en redes privadas y públicas a través de la automatización, el                     control centralizado de la red y la gestión del tráfico en tiempo                       real. Inorks siendo un startup cuenta con los mismos recursos para                     ambos proyectos razón por la cual el alcance de la migración del                       sistema de SDS fue modificado para cumplir de manera correcta                   en el evento y avanzar igualmente en el desarrollo. 

 Alcance del proyecto:  Teniendo en cuenta las necesidades y problemas que se mencionaron                   anteriormente el alcance del proyecto se dividió en 2 frentes: uno fue el                         mejorar la interfaz gráfica de la aplicación existente y corregir sus bugs y                         por otro lado se llevó a cabo el desarrollo de algunas funcionalidades                       de la plataforma SDS con una arquitectura basada en microservicios. A                     continuación en la figura 12 se puede evidenciar el cronograma                   propuesto y las actividades que se llevaron a cabo para el desarrollo de                         la plataforma web:  

  figura 12. Cronograma del proyecto. [Fuente propia] 

 Funcionamiento inicial de la aplicación: El proyecto inicialmente estaba implementado bajo las siguientes               tecnologías: 

- AngularJS: Es un marco de aplicaciones web front-end de código                   abierto basado en javascript para abordar los desafíos               encontrados en el desarrollo de aplicaciones de una sóla página. 

28

- Materialize: Es un marco de trabajo con una amplia biblioteca de                     componentes UI basado en la filosofía de material design de                   google, el cual es utilizado para realizar aplicaciones adaptables                 en diferentes dispositivos. 

- OpenDaylight: OpenDaylight (ODL) es una plataforma abierta             modular para personalizar y automatizar redes de cualquier               tamaño y escala. El proyecto OpenDaylight surgió del movimiento                 SDN, con un claro enfoque en la capacidad de programación de                     la red. 

- Mininet: Mininet crea una red virtual realista, ejecutando el kernel                   real, el conmutador y el código de la aplicación, en una sola                       máquina (VM, nube o nativa), en segundos, con un solo                   comando 

- NodeJS: Es un entorno en tiempo de ejecución multiplataforma,                 de código abierto, para la capa del servidor (pero no limitándose                     a ello) basado en el lenguaje de programación ECMAScript,                 asíncrono, con I/O de datos en una arquitectura orientada a                   eventos y basado en el motor V8 de Google. 

De acuerdo con las tecnologías mostradas anteriormente, el proyecto y                   sus respectivos componentes funcionan de la siguiente manera: Existe un único proyecto desarrollado bajo NodeJS, en el que se                     ejecutan al mismo tiempo el back-end y front-end (donde se                   implementan las librerías de materialize y angularjs). El back-end al                   mismo tiempo y a través de peticiones http realiza solicitudes                   constantemente al servidor dispuesto por Opendaylight que contiene el                 api necesario para que funcione el sistema, y a su vez, el controlador se                           conecta con un ambiente o red simulado por mininet.   Como se menciona anteriormente, los componentes principales del               sistema tienen mucha relación entre sí, por lo que el objetivo principal es                         tener una alta cohesión y un bajo acoplamiento. En este sentido, el                       back-end y front-end se ejecutan de manera simultánea en un solo                     proceso por lo que el fallo de alguno de los componentes de la                         aplicación afecta directamente la disponibilidad de los demás               componentes o servicios que fue lo que se evidenció en las pruebas                       realizadas en el anterior proyecto.  Fase de diseño Exploración de tecnologías:  De acuerdo a los problemas mencionados en la fase de análisis con las                         tecnologías que se estaban usando, se optó entonces por trabajar con                     las siguientes tecnologías para la migración del proyecto: Angular 7,                   MoleculerJS, MDBootstrap, PostgreSQL y ONOS. Es importante señalar               

29

que para el proyecto que ya se tiene implementado se usaron las                       mismas tecnologías, sin embargo las plantillas HTML que se                 implementaron fueron reutilizables en el otro proyecto.  El uso de Angular 7 fue para cumplir con el mismo rol que Angularjs, sin                             embargo, la razón principal por la que fue cambiado es debido a que                         su tecnología está un poco obsoleta y esta nueva versión es más                       recomendada y estable. Por otro lado, el comportamiento del sistema y                     la interacción de los diferentes módulos y componentes se realizó de la                       siguiente manera:  El back-end se desarrolló de la misma manera en NodeJS, pero en vez                         de usar su lenguaje nativo, se usó MoleculerJS el cual es un moderno y                           poderoso marco de trabajo que permite desarrollar microservicios, para                 poder cumplir con el objetivo de crear una aplicación modular. Entre                     otras ventajas, este marco nos permite: 

- Soporte de arquitectura dirigida por eventos con balanceo. - Registro de servicios integrado y descubrimiento dinámico de               

servicios. - Balanceador de cargas de solicitudes y eventos. - Características de tolerancia a fallos. 

 El front-end, como se dijo anteriormente, es una aplicación realizada                   con Angular 7 y MDBootstrap para el diseño, el cual fue escogido                       debido a que tiene soporte para los marcos de trabajo más usados en                         la actualidad (Angular7, VueJS, React). Además, porque se quita la                   dependencia de usar jQuery para la manipulación de los diferentes                   componentes de la interfaz gráfica como se hacía con Materialize. Esta                     aplicación consultará el back-end através de servicios http y la                   información obtenida será mostrada en la respectiva plantilla html.  Por otra parte, el controlador SDN se cambió de OpenDaylight a ONOS,                       debido a que con ODL se tenían problemas de estabilidad y algunos                       bugs con funcionalidades específicas que hacía tedioso el desarrollo.                 Ahora bien para la información suministrada por el sistema se usará la                       base de datos relacional PostgreSQL, y del mismo modo se usará mininet                       para tener una red virtual simulada para realizar el desarrollo en un                       ambiente de pruebas. Es importante señalar que por cada microservicio                   se tendrá su respectivo modelo de base de datos (esta información se                       puede ver de manera más detallada en la figura 13 de la arquitectura                         del sistema).  

30

 Diseño de arquitectura: Esta fase del diseño consta de 3 capas como se muestra en la figura 13:  - Capa de aplicación: En esta capa es donde se despliegan los                       microservicios realizados con MoleculerJS, el cual contiene nodos que                 son un espacio donde pueden estar uno o varios servicios y se ejecuta                         en un mismo proceso, por lo que los servicios que se definieron para el                           sistema se ejecutan en nodos individuales y ellos se pueden comunicar                     entre sí a través del transportador (NATS en este caso). Cabe notar que los servicios tienen su propio modelo de datos y no uno                           para todos los servicios conjuntamente. Como se indicó en la fase de                       análisis el modelo relacional se ha realizado con PostgreSQL y para este                       caso sólo se usará la base de datos en los nodos correspondientes a los                           servicios de usuarios, dispositivos y slices, debido a que los demás                     servicios usan la información suministrada por estos nodos.  - Capa de control: Al igual que OpenDaylight, ONOS es basado en java                         y ofrece características como la alta disponibilidad y rendimiento a gran                     escala, además de un software modular con 135 extensiones que                   permiten entre otras cosas el control de tráfico, aplicaciones de                   superposición o modelos YANG precompilados  - Capa física: El controlador SDN es capaz de comunicarse con el plano                         de infraestructura de la arquitectura a través del protocolo OpenFlow, e                     instalar luego en los switches, flujos de red que obedecen a diversas                       estrategias programadas para el descubrimiento de los dispositivos y la                   topología, las cuales se basan en protocolos como ARP, LLDP y STP.  El front-end que es desarrollado con Angular 7 y MDBootstrap, que es                       una aplicación aparte y realiza solicitudes a través del protocolo http;                     una vez realizada la petición, ésta llega al api gateway del backend                       que se encarga de publicar, promocionar y supervisar el API en un                       entorno seguro y escalable, después las solicitudes son enrutadas al                   servicio correspondiente.   

31

figura 13. Arquitectura del sistema. [Fuente propia].  

32

Diseño de base de datos  Como se mencionó anteriormente la base de datos que se utilizó fue                       PostgreSQL, sin embargo para facilitar la escritura y lectura en la base                       de datos se utiliza un ORM (Object-Relational mapping) para utilizar el                     mismo lenguaje de programación para realizar las operaciones sobre la                   base de datos y evitarse el uso de SQL nativo. Para realizar dicha tarea                           se escogió la librería SequelizeJS ya que es liviana, tiene soporte para los                         dialectos SQL más usados, es faćil de configurar, usar y posee una                       buena documentación. En las figuras 14 y 15 se pueden ver los modelos                         de datos correspondientes a los microservicios de usuario y dispositivos                   respectivamente.    

  figura 14. Modelo entidad-relación microservicio de usuario [Fuente propia]. 

     

33

  

figura 15. Modelo entidad-relación microservicio de dispositivos [Fuente propia].  

 Diagramas de flujo:  Para realizar la migración hay algunos métodos o funcionalidades que                   pueden ser reutilizados, sin embargo para algunos es necesario hacer                   una refactorización, es por eso que se realizaron los siguientes                   diagramas de flujo para facilitar el desarrollo:   

- Diagrama de flujo slice GOOSE (ver anexo 4). - Diagrama de flujo slice MMS (ver anexo 3). - Diagrama de flujo slice DNP3 (ver anexo 6). - Diagrama de flujo para el descubrimiento de dispositivos (ver                 

anexo 5).  Mockups:  Para garantizar el aspecto de calidad correspondiente a la usabilidad,                   se realizaron los diseños de la interfaz gráfica con el fin de disminuir el                           número de menús, encontrar la información de una manera más rápida                     y clasificar los menús de acuerdo a su rol o funcionalidad en el sistema.                           A continuación, se pueden ver algunos de los mockups desarrollados                   comparados con la versión actual de la interfaz gráfica, para ver más,                       el lector puede dirigirse al anexo 1. 

34

  figura 16. Menú principal [Fuente propia]. 

figura 17. Vista para la topología [Fuente propia].  

 Fase de implementación Como se mencionó anteriormente en la etapa de análisis, el desarrollo                     se llevó a cabo para atender 2 frentes: uno con la versión vieja del                           proyecto y otro con la migración. Lo más importante entonces era darle                       prioridad a la interfaz gráfica puesto que la visita al evento llevado a                         cabo en Berlín, Alemania estaba muy próximo (Octubre 2018), por tal                     motivo a éste proyecto no se le hicieron modificaciones en cuanto a las                         tecnologías, y a cambio se ajustaron las plantillas html y algunas                     funcionalidades en el backend para que los cambios no tuvieran                   problemas con la funcionalidad en general de la aplicación. Una vez se                       terminó de realizar las vistas del sistema se inició la implementación del                       nuevo proyecto con la arquitectura antes mencionada basada en                 microservicios, sin embargo esas vistas realizadas en el anterior proyecto                   fueron reutilizadas y solo cambiando algunas directivas (permiten la                 manipulación y reutilización de código HTML) y componentes (permiten                 gestionar las plantillas HTML y directivas que afectan al comportamiento                   del sistema) fue posible adaptarlo de forma rápida al nuevo sistema.                     

35

Luego de realizar toda la navegación del sistema con Angular7 se                     enfatizó en implementar los servicios de usuarios, topología y dispositivos,                   además de añadir el controlador ONOS para las funciones de la red.  Fase de pruebas  Como se muestra en el cronograma en la figura 12, se estipularon 3 tipos                           de pruebas a realizar: unitarias, integración y aceptación.  Las pruebas unitarias se realizaron con Mocha que es un marco de                       prueba de JavaScript con numerosas funciones que se ejecuta en                   Node.js y en el navegador, lo que hace que las pruebas asíncronas sean                         simples de realizar. También se llevó a cabo el proceso de desarrollo de                         software con la técnica denominada TDD (Test-driven development por                 sus siglas en inglés), la cual se basa en la repetición de un ciclo de                             desarrollo muy corto: se escribe primero el caso de prueba                   automatizado (que falla inicialmente) para una funcionalidad en               específico, luego se produce la cantidad de código para pasar esa                     prueba, y finalmente se refactoriza el nuevo código a estándares                   aceptables. Esta técnica en las pruebas unitarias facilitó el desarrollo                   debido a que los diferentes escenarios o casos de prueba que se                       necesitaban fueron probados y de esta manera si una nueva                   funcionalidad afecta una de las pruebas puede verse exactamente a                   qué se debe y de esta manera tener un código más limpio, esto con el                             fin de que se pueda cumplir con uno de los objetivos principales que                         está enfocado en la calidad del software, específicamente la fiabilidad.  Por otro lado se tienen las pruebas de integración, para probar que esos                         pequeños módulos o servicios en conjunto funcionan correctamente. Se                 estipula entonces probar aquellos microservicios que se comunican               entre ellos e igualmente la funcionalidad del front-end con los servicios                     http expuestos por el back-end.  Resultados y análisis Interfaz gráfica mostrada en el evento 61850: Las figuras 18 a 27 muestran en funcionamiento y en un ambiente real la                           aplicación que se tenía en un principio luego de corregir algunos bugs                       con su funcionamiento. Se puede apreciar que los cambios se ajustan a                       los mockups presentados en la fase de análisis y lo más importante y                         como puede verse en la figura 19 es que los menús fueron reducidos a 3                             y éstos a su vez tienen submenús con las opciones del sistema. Ahora                         bien, para añadir usabilidad en la aplicación una vez seleccionada una                     opción se redirecciona a la página correspondiente y en el template en                       la parte izquierda se muestra un submenú con las opciones del menú al                         

36

cual pertenece y de ésta manera el usuario no tiene que abrir                       nuevamente el menú si quiere seleccionar otra opción del mismo menú.                     También, puede verse en la figura 28 que éste menú puede ser                       reducido sólo a sus correspondientes íconos con el fin de aprovechar el                       espacio.  

  figura 18. Página de inicio [Fuente propia]. 

 - Formulario con 2 campos de autenticación (email y contraseña). - El usuario debe estar registrado previamente. - Una vez se da en la opción ‘Login’ el usuario es redireccionado a                         

la ventana principal de la aplicación correspondiente a la                 topología de red. 

  

37

  figura 19. Menú principal [Fuente propia]. 

 

  figura 20. Topología de red [Fuente propia]. 

 - La ventana principal de la topología de red tiene un menú donde                       

se puede cambiar la etiqueta de los equipos (opción Node Tag) a                       su ip, mac, fabricante o ip. También se tiene la opción dispositivos                       donde al dar click se puede ver la lista de los dispositivos de red                           en un menú lateral como se muestra en la figura 20 y al dar click                             sobre alguno de éstos se puede ver el detalle. De igual manera la                         opción slices nos permite ver la lista de slices (figura 21) y también                         crear uno nuevo. 

- Una nueva funcionalidad es el botón de refresh, útil cuando hay                     algún cambio y no se ha visto reflejado en la topología. 

38

  figura 21. Lista de slices [Fuente propia]. 

 

  figura 22. Lista de dispositivos [Fuente propia]. 

 - Cuenta con una entrada de texto para hacer un filtro de                     

búsqueda. - Opción para hacer un ordenamiento de la lista según cierto                   

parámetro (id, tipo, etc). - Opción para exportar un documento en formato pdf con el                   

reporte de los dispositivos del sistema. - En la tabla se encuentra una opción que puede verse en la parte                         

superior derecha que sirve para añadir o quitar dinámicamente                 columnas de la tabla con el fin de mostrar solo las de especial                         interés. 

39

  figura 23. Detalle de IED [Fuente propia]. 

 

  figura 24. Detalle de switch [Fuente propia]. 

 - Se añaden nuevos chasis según el fabricante: HP, CENTEC,                 

genérico. 

40

  figura 25. Estadísticas [Fuente propia]. 

 - Para las estadísticas es importante señalar que se optó por dejar                     

de trabajar con la librería D3 debido a que se hacía muy tedioso                         el desarrollo y gráficos básicos como los diagramas de tortas, línea                     o barras pueden ser abordados mejor con otra librería más liviana                     y fácil de usar como chart.js 

 

  figura 26. Monitoreo de red (wireshark) [Fuente propia]. 

 - En esta ventana es posible escoger los dispositivos de red y poder                       

ver el tráfico de red a través de un analizador de protocolos o                         wireshark. 

41

  figura 27. Tienda de los principales módulos del sistema [Fuente propia]. 

 

  figura 28. Menú lateral izquierdo solo con los íconos. [Fuente propia]. 

  Proyecto realizado con microservicios y ONOS: Como se mencionó anteriormente lo primero que se implementó fue la                     interfaz gráfica para el anterior proyecto, sin embargo esas mismas vistas                     fueron adaptadas al nuevo y, una vez se terminó de realizar la                       navegación y rutas de éste, se procedió a realizar los principales                     servicios del backend correspondientes a usuarios, dispositivos y               topología por lo que se expusieron los servicios web mostrados en la                       tabla 1. Lo siguiente entonces fue configurar ONOS como controlador y                     crear una topología de red en mininet con las mismas propiedades que                       

42

los host o equipos terminales que son agregados por defecto en la base                         de datos de dispositivos (se hace por defecto en el ambiente simulado);                       la configuración antes mencionada puede verse en el anexo 2.             

Tabla 1. Lista de servicios web Servicio  Ruta  Token  Método  Parámetros 

Servicios web para el usuario 

Crear usuario  ip:puerto/api/users/sign_up 

No  POST  user:Object 

Obtener usuario por email  ip:puerto/api/users/user_by_id/:email 

Sí  GET  email:string 

Mostrar todos los usuarios  ip:puerto/api/users/allUsers 

Sí  GET  No aplica 

Obtener todos los roles  ip:puerto/api/users/getAllRoles 

Sí  GET  No aplica 

Obtener todas las compañías 

ip:puerto/api/users/getAllOrganizations 

Sí  GET  No aplica 

Obtener todos los tipos de documentos 

ip:puerto/api/users/getAllTypesOfDocuments 

Sí  GET  No aplica 

Servicios web para los dispositivos 

Obtener dispositivo por id  ip:puerto/api/device/getDeviceById/:deviceId 

Sí  GET  deviceId:string 

Obtener dispositivo por nombre 

ip:puerto/api/device/getDeviceByName/:deviceName 

Sí  GET  deviceName:string 

Obtener dispositivos por fabricante 

ip:puerto/api/device/getDevicesByManufacturer/:deviceManufacturer 

Sí  GET  devicemanufacturer:string 

Obtener dispositivo por dirección ip 

ip:puerto/api/device/getDeviceByIp/:deviceIp 

Sí  GET  deviceIp:string 

43

Obtener todos los dispositivos 

ip:puerto/api/device/getAllDevices 

Sí  GET  No aplica 

Agregar dispositivo  ip:puerto/api/device/insertDevice 

Sí  POST  device:Object 

Servicios web para los dispositivos 

Obtener topología de red  ip:puerto/api/topology/getCurrentTopology 

Sí  GET  No aplica 

   Las figuras 29 a 32 muestran la integración de los servivios web expuestos                         por el backend en el front-end realizado con Angular7, además del                     correcto funcionamiento de ONOS con mininet.      

  figura 29. Formulario de registro de usuario. [Fuente propia]. 

 - Puede observarse que los campos corresponden al modelo de                 

datos expuesto en la figura 14  

44

  figura 30. Inicio de sesión SDS. [Fuente propia]. 

  figura 31. Topología de red desplegada en ONOS GUI. [Fuente propia]. 

 

45

  figura 32. Topología de red con microservicios. [Fuente propia]. 

  Pruebas de aceptación: Después de realizar las respectivas pruebas de integración, el sistema                   entonces fue probado como se planeó en un principio y según lo                       establecido en el cronograma (figura 12), en un entorno real y simulado.                       Éste último fue el que se realizó durante todo la etapa o fase de                           desarrollo y contó con la aprobación y retroalimentación de todo el                     equipo de desarrollo y/o interesados. Una vez probado el correcto                   funcionamiento en un ambiente simulado se procedió a configurar un                   entorno real como puede verse en la figura 33, en el evento 61850                         global donde se pueden apreciar los equipos reales y el despliegue de                       la plataforma.  

46

  figura 33. Participación de inorks en el IEC 61850 Global 2018 en Alemania. [Fuente 

propia].  Resultados y opiniones en el evento 61850: SEL como lo dice en su portal web [33], inventa, diseña y construye                         productos y sistemas digitales que protegen las redes eléctricas en todo                     el mundo y durante más de una década, las empresas de electricidad                       de América del Norte han clasificado a SEL como el fabricante de relés                         número 1 en el Estudio mundial de Newton-Evans del mercado de relés                       de protección en servicios eléctricos [34]. SEL fue una de las compañías                       que estuvo presente en el evento 61850 y pudo evaluar a SDS llegando                         a la siguiente conclusión: “es una plataforma muy interesante, debido a                     que es un controlador estándar”. Sin embargo como a SEL les gustaría                       que sus switch se puedan trabajar con nuestro controlador, ellos                   resolverán los certificados de los switch SEL 2740 para que sea estándar.   Por otro lado, Siemens quien también tuvo presencia en el evento y que                         es una potencia global que se centra en las áreas de electrificación,                       automatización y digitalización opinó: “es una plataforma muy               interesante que genera una propuesta diferente a nuestro modelo de                   negocio que se centra en la venta de cajas”. Ellos están interesados en                         desarrollar un Switch Ruggedcom con capacidades de SDN y que                   pueda trabajar con nuestro controlador, y ser un partner estratégico.  

47

Conclusiones - Durante el proceso de desarrollo de SDS se han revisado diversos                     

controladores siendo ODL el controlador industrial escogido en las                 últimas versiones de la plataforma debido a su uso en diferentes                     tipos de industrias (empresas, gobierno, investigación, educación,             telecomunicaciones, proveedores de contenido, etc), lo cual en               un principio permitió generar confianza sobre este tipo de                 controlador y sus desarrollos; además de la modularidad, facilita                 el uso y desarrollo de nuevas herramientas para la red de                     comunicaciones (en una subestación eléctrica para este caso),               sin embargo el esquema de versionamiento hicieron que los                 procesos de actualización de la plataforma y mejora se volviera                   un proceso tedioso, además se encontró algunos bugs con                 funcionalidades específicas lo que ocasionó que se optara por un                   nuevo controlador, en este caso ONOS fue el candidato. Con                   numerosos casos de uso exitosos en la industria se adoptó este                     controlador el cual fue fácil de instalar y además también está                     desarrollado en java por lo que parte del código de ODL puede                       ser reutilizado. 

 - Por otro lado, dentro de los esquemas de arquitectura de software                     

el estilo arquitectónico de los microservicios facilita el proceso de                   automatización del software, la escabilidad que es una               característica importante en este tipo de sistemas orientados a las                   redes de comunicación y lo más importante poder separar cada                   funcionalidad de manera que se facilite los procesos de                 mantenimiento, soporte y actualización de la aplicación y que el                   cambio o solución a algún bug no afecte directamente la                   estabilidad de todo el sistema. Además, comercialmente la               separación en pequeños módulos facilita la separación de               funciones específicas de la plataforma (descubrimiento de red,               estadísticas, slices, captura de paquetes, etc), de manera que en                   las soluciones que se venden el cliente se pueden ajustar                   perfectamente a sus necesidades. 

 - El uso de la metodología ágil ‘XP’ permitió la adaptación al                     

cambio en los requisitos y alcance del proyecto, puesto que                   aunque no se migró la totalidad de las funcionalidades como se                     tenía pensado en un principio, se trabajó en 2 frentes de                     desarrollo donde el objetivo principal fue tener una buena                 participación en el evento 61850 con el proyecto que se tenía                     desarrollado sin dejar a un lado el desarrollo de este nuevo                     

48

proyecto. Además fue posible cumplir con las necesidades               debido a la interacción continua entre el responsable del                 proyecto y el equipo de desarrollo.  

- Dentro de las herramientas de desarrollo para el front-end                 MDBootstrap permitió hacer una implementación mucho más             rápida debido a la gran cantidad de componentes, estilos y                   herramientas avanzadas de diseño que provee, además todo               ésto con un soporte directo para Angular7, lo que permitió el                     desarrollo y visualización en los dispositivos. 

- La participación en el evento llevado a cabo en Berlín, Alemania                     permitió a inorks darse a conocer ante la comunidad 61850 con                     más de 16 expertos internacionales de la norma IEC 61850, donde                     se tuvo gran percepción y aceptación de las más importantes                   compañías del sector eléctrico de la plataforma de software, lo                   que abre una gran posibilidad de consolidar alianzas y/o ventas.    

                      Referencias Bibliográficas    [1] Sherwood, Rob. 2014. "SDN Is Devops For Networking" 39 (2): 34-36.                       https://www.usenix.org/system/files/login/articles/10_sherwood.pdf. 

49

 [2] "Network Architecture". 2019. Conceptdraw. Accessed January 10.               https://www.conceptdraw.com/examples/enterprise-architect-network-topology-diagram.  [3] Steinborn, Thomas. 2018. "The Future Of Devops Is Mastery Of                     Multi-Cloud Environments". Opensource.Com.     https://opensource.com/article/18/1/future-devops.  [4] Ranger, Steve. 2018. "What Is Cloud Computing? Everything You                   Need To Know About The Cloud, Explained | Zdnet". Zdnet.                   https://www.zdnet.com/article/what-is-cloud-computing-everything-you-need-to-know-from-public-and-private-cloud-to-software-as-a/.  [5] Juliá, Samuel. 2015. "Tipos De Redes Informáticas Según Su Alcance -".                       Informática Para Empresas.     http://www.gadae.com/blog/tipos-de-redes-informaticas-segun-su-alcance/.  [6] Froehlich, Andrew. 2017. "6 Key Milestones In Computer Networking                   History". Network Computing.     https://www.networkcomputing.com/networking/6-key-milestones-computer-networking-history/1438059667.  [7] Greene, Kate. 2009. "TR10: Software-Defined Networking - MIT                 Technology Review". MIT Technology Review.         http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/.  [8] Li, Abner. 2018. "Google Cloud Opening Fifth U.S. Region In LA Next                         Month, Targeting Media & Entertainment". 9To5google.           https://9to5google.com/2018/06/26/google-cloud-region-los-angeles/.  [9] Ma, Chloe. 2014. "SDN Secrets Of Amazon And Google". Infoworld.                     https://www.infoworld.com/article/2608106/sdn/sdn-secrets-of-amazon-and-google.html.  [10] Bhatia, Jitendra. 2017. "A Primer On Software Defined Networking                   (SDN) And Openflow Standard". Open Source For You.               https://opensourceforu.com/2017/10/primer-software-defined-networking-sdn-openflow-standard/.  

50

[11] Fulton, Scott. 2018. "What Is SDN? How Software-Defined Networking                   Changed Everything | Zdnet". Zdnet.         https://www.zdnet.com/article/software-defined-networking-101-what-sdn-is-and-where-its-going/.  [12] Millán, Ramón. 2016. "SDN (Software-Defined Networking)".             Ramonmillan.Com. https://www.ramonmillan.com/tutoriales/softwaredefinednetworking.php.  [13] Frómeta, Dayrene, Caridad Anías, Susana Ballester, and Sergio León.                   2016. "Desarrollo De Aplicaciones SDN". Revista Técnica De La Empresa                   De Telecomunicaciones De Cuba S.A 13: 41-47.             https://www.researchgate.net/publication/320508215_DESARROLLO_DE_APLICACIONES_SDN.  [15] Kinnesis.com. (2017). Kinnesis Solutions. [online] Available at:               http://www.kinnesis.com/ [Accessed 27 Oct. 2017]. [16] "A Beginners Guide To Understanding The Agile Method | Linchpin                     SEO". 2019. Linchpin SEO. Accessed January 10.             https://linchpinseo.com/the-agile-method/.  [17] "Arquitectura Monolítica Vs Microservicios – Emmita – Medium". 2017.                   Medium. https://medium.com/@Emmitta/arquitectura-monol%C3%ADtica-vs-microservicios-6d8b14ed6e55.  [18] "Aplicaciones Monoliticas O Microservicios | Aplyca". 2019.               Aplyca.Com. Accessed January 18.       https://www.aplyca.com/es/blog/aplicaciones-monoliticas-o-microservicios.  [19] ul Haq, Siraj. 2018. "Introduction To Monolithic Architecture And                   Microservices Architecture". Medium.     https://medium.com/koderlabs/introduction-to-monolithic-architecture-and-microservices-architecture-b211a5955c63.   [20] Anwar, Masood. 2019. "What Is Client Server Architecture?". Daily                   Web Solutions. Accessed January 10.         http://www.dailywebsolutions.com/what-is-client-server-architecture.   [21] Mitra, Shamik. 2016. "Why Microservices? - Dzone Microservices".                 Dzone.Com. https://dzone.com/articles/microservices-basics.   [22] "Advantages And Disadvantages Of Client Application Server". 2011.                 Esds.Co.In. 

51

https://www.esds.co.in/blog/advantages-and-disadvantages-of-client-application-server/#sthash.j0GZNyxf.dpbs.   [23] "Anatomy Of The Client/Server Model". 2019. Docs.Oracle.Com.               Accessed January 10.     https://docs.oracle.com/cd/E13203_01/tuxedo/tux71/html/intbas3.htm.   [24] "What Is N-Tier Architecture? How It Works, Examples, Tutorials, And                     More". 2017. Stackify. https://stackify.com/n-tier-architecture/.   [25] Arsov, Kristijan. 2017. "What Are Microservices, Actually? - Dzone                   Microservices". Dzone.Com.   https://dzone.com/articles/what-are-microservices-actually.   [26] Kumar, Mrityunjay. 2016. "Microservices Architecture: What, When,               And How - Dzone Microservices". Dzone.Com.           https://dzone.com/articles/microservices-architecture-what-when-how.   [27] Mitra, Shamik. 2016. "Why Microservices? - Dzone Microservices".                 Dzone.Com. https://dzone.com/articles/microservices-basics.   [28] "ISO 25010". 2019. Iso25000.Com. Accessed January 10.               https://iso25000.com/index.php/normas-iso-25000/iso-25010?limit=3&limitstart=0.   [29] Mackiewicz, Ralph, and Sterling Heights. 2006. "Technical Overview                 And Benefits Of The IEC 61850 Standard For Substation Automation". IEEE,                     1-8. https://library.e.abb.com/public/04519389e504d7ddc12576ff0070704d/3BUS095131_en_IEC61850_Overview_and_Benefits_Paper_General.pdf.   [30] "What Is Extreme Programming (XP)?". 2017. Agile Alliance.                 https://www.agilealliance.org/glossary/xp/.   [31] Feamster, N., Rexford, J., & Zegura, E. (2014). The road to SDN: an                           intellectual history of programmable networks. ACM SIGCOMM             Computer Communication Review, 44(2), 87-98.  [32] E. A. Leal and J. F. Botero, “Software defined power substations: an                         architecture for network communications and its control plane.”               Universidad de Antioquia. 2016.  [33] "About SEL". 2019. Selinc.Com. https://selinc.com/company/about/.  

52

 [34] "SEL Ranked #1 Again In Newton-Evans Protective Relay Study". 2019.                     Cdn.Selinc.Com. Accessed January 10.       https://cdn.selinc.com/assets/Literature/Product%20Literature/Flyers/NewtonEvans_Flyer.pdf?v=20151111-171518.   [35] "User Stories - Opendaylight". 2019. Opendaylight. Accessed January                 10. https://www.opendaylight.org/use-cases-and-users/user-stories.   [36] Del Chiaro, Jhonatan. 2018. "Microservicios".           Knowing-Microservicios.Blogspot.Com. http://knowing-microservicios.blogspot.com/.    ANEXOS: [1] https://app.moqups.com/Development@inorks.com/ipLO2LV4cg/view  [2] https://www.dropbox.com/s/5ui1ayuf203oov6/configuraci%C3%B3n%20de%20entorno%20ONOS%20%2B%20Mininet.pdf?dl=0  [3] https://www.dropbox.com/s/34hsec53cvzugfd/onNew.png?dl=0  [4] https://www.dropbox.com/s/qhvgqsw5u2i2bsf/onNew%20%282%29.png?dl=0  [5] https://www.dropbox.com/s/z7wchitcjhbz8y9/device_discoverer.png?dl=0  [6] https://www.dropbox.com/s/lock1mlb840pd0l/onNew%20%283%29.png?dl=0   

53