Sistema Embebido Industrial Autónomo de Monitoreo e ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo... · Plan de Proyecto del Trabajo Final de Carrera de Especialización

Plan de Proyecto del Trabajo Final de Carrera de Especialización de Sistemas Embebidos

Ing. Pablo M. Almada

Página 1 de 19

Sistema Embebido Industrial Autónomo de Monitoreo e Intrusión Remoto

Autor


Director del trabajo

Esp. Ing. Alvarez Nicolas

Jurado propuesto para el trabajo

- Ing. Martos Pedro

- Esp. Ing. Nombre Apellido (filiación) - Esp. Ing. Nombre Apellido (filiación)



Página 2 de 19

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre marzo – abril del 2018.



Página 3 de 19

Tabla de contenido

Registros de cambios 3

Acta de Constitución del Proyecto 4

Descripción técnica-conceptual del Proyecto a realizar 5

Identificación y análisis de los interesados 6

1. Propósito del proyecto 7

2. Alcance del proyecto 7

3. Supuestos del proyecto 7

4. Requerimientos 7

5. Entregables principales del proyecto 8

6. Desglose del trabajo en tareas 8

7. Diagrama de Activity On Node 9

8. Diagrama de Gantt 9

9. Matriz de uso de recursos de materiales 10

10. Presupuesto detallado del proyecto 10

11. Matriz de asignación de responsabilidades 11

12. Gestión de riesgos 11

13. Gestión de la calidad 13

14. Comunicación del proyecto 13

15. Seguimiento y control 14

16. Procesos de cierre 14



Página 4 de 19

Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 01/03/2018

1.1 Ampliación de información 14/04/2018

1.2 Ampliación de información 28/04/2018



Página 5 de 19

Acta de Constitución del Proyecto

Buenos Aires, 1 de marzo de 2018

Por medio de la presente se acuerda con el Sr. Ing. Pablo Almada que su Proyecto Final de la Carrera de Especialización en Sistemas Embebidos se titulará “Sistema Industrial Autónomo Remoto de Intrusión”, consistirá esencialmente en el prototipo preliminar de un sistema de aprendizaje autónomo de comunicaciones en una red industrial permitiendo la manipulación remota de la misma, y tendrá un presupuesto preliminar estimado de 600 hs de trabajo, con fecha de inicio jueves 1 de marzo de 2018 y fecha de presentación pública lunes 31 de julio de 2018.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Walter Risi Director de la CESE-FIUBA KPMG

Nicolas Alvarez

Director del Trabajo Final

Ing. Pedro Martos

Jurado del Trabajo Final



Página 6 de 19

Descripción técnica-conceptual del Proyecto a realizar El trabajo pretende ser un prototipo de un hardware autónomo, sin medios externos de alimentación eléctrica, que permita ser conectado dentro de una red industrial aprendiendo el comportamiento de la misma a través de las comunicaciones entre los componentes del sistema. Es decir, tener la capacidad de mapear las conversiones entre los componentes, frecuencias de comunicación, comandos de lectura/escritura, entre otros. Así mismo, permitirá la acción remota, a través de un módulo de comunicación inalámbrico, hacia la red industrial, donde se encuentra conectado el dispositivo a desarrollar, por medio del protocolo Modbus TCP. Sumado a lo anterior, se diseñará una arquitectura embebida escalable que permita, en un futuro, agregar nuevos protocolos como ser: DNP3, 104, 101, ICCP, entre otros. Dichos protocolos han sido seleccionados ya que son los más utilizados en el ambiente de la generación, distribución y transporte de Energía Eléctrica en donde este sector, es de vital importancia para cualquier nación.

El sistema poseerá 5 módulos encargados de gestionar cada uno de los requerimientos definidos en el punto 4. A continuación se realiza una descripción funcional de los mismos:

• Módulo de eficiencia energética: Será el encargado de la gestión del consumo del sistema embebido en búsqueda de maximizar la fuente de energía autónoma.

• Módulo de comunicaciones: Será el encargado de gestionar el puerto de escucha que estará conectado sobre la red industrial. Capturará el tráfico que por este pasa, lo analizará y extraerá la carga (payload) de información que el protocolo industrial posee (comandos/lecturas/escrituras/datos). Por otro lado, se encargará de la gestión de las comunicaciones de la interfaz inalámbrica e intercomunicará cada comando recibido al módulo de comandos.

• Módulo de Protocolos Industriales: Será la fuente de conocimientos que utilizará el módulo de comunicaciones para interpretar los datos capturados por su interfaz de escucha. Este módulo inicialmente contendrá la definición del protocolo industrial Modbus. Sumado a lo anterior, el mismo será capaz de almacenar múltiples protocolos. En futuras versiones se considera ampliar al mismo con los protocolos industriales ETHERNET/IP y CIP.

• Módulo de Comandos: Analizará y gestionará los comandos recibidos y responderá a través de un protocolo de capa 7 OSI.

• Módulo de Baseline: Será el encargado de armar un baseline de comportamiento en base a la información recibida del módulo de comunicaciones por cada uno de los componentes de la red industrial (comandos/lecturas/escrituras/datos).



Página 7 de 19

Figura 1 – Esquema Modular del Software Embebido

Identificación y análisis de los interesados

Rol Nombre y Apellido Puesto

Auspiciante Walter Risi Socio

Colaboradores Charles Sigmar Consultor Senior

Usuario Final KPMG

El auspiciante desea que el prototipo sea parte de los laboratorios de Ciberseguridad Industrial de la Compañía.



Página 8 de 19

1. Propósito del proyecto El propósito del presente trabajo es que su resultado sea utilizado en los proyectos de concientización en Ciberseguridad de la compañía auspiciante. De esta forma, personal técnico de campo en industrias como ser: Eléctrica u oil & gas puedan observar como un dispositivo pequeño permite paralizar o afectar las operaciones en un campo. Otros elementos importantes son sus pequeñas dimensiones y su independencia de suministro eléctrico, permitiendo que el dispositivo pueda ser desplegado en un campo de la industria de Upstream o en un punto de tele-medición eléctrica en la vía pública.

2. Alcance del proyecto El trabajo incluye la elección de un hardware con un módulo de comunicación inalámbrica y un sistema de alimentación externa recargable. Sumado a lo anterior, se diseñará un sistema embebido escalable que permita la inclusión de nuevos protocolos no incluidos en el presente trabajo.

El software se montará sobre un sistema operativo embebido open source especialmente diseñado para lograr una eficiencia energética, con módulos de comunicaciones, manejo de bases de datos y se diseñará e implementará una pila del protocolo industrial Modbus TCP.

El prototipo permitirá la creación de un “baseline” de comunicaciones industriales con el objetivo de obtener un conocimiento previo de la red industrial logrando un ataque sigiloso y efectivo.

3. Supuestos del proyecto Para el desarrollo de la investigación se supone la asignación de un paquete de horas que se encuentra explicitado en la sección 6.

4. Requerimientos Para describir los requerimientos y agruparlos, consideremos la siguiente descomposición tentativa del sistema de adquisición en subpartes:



Página 9 de 19

Figura 2

A continuación se detalla la lista de requerimientos según las divisiones ilustradas en la Figura 2. La definición de prioridades de los requerimientos se ubica entre paréntesis al final de cada uno, siendo 1 el nivel más prioritario. Los requerimientos macro del sistema y del subsistema definen la funcionalidad del mismo, por lo tanto son los más prioritarios. 1. Módulo de eficiencia energética

1.1. El sistema poseerá la capacidad de funcionar en modo bajo consumo a través de la activación/desactivación periódica de los componentes de mayor consumo. De esta manera se espera reducir el consumo en un 20%. La frecuencia de activación/desactivación será configurable.

2. Módulo de Comunicaciones

2.1. Gestionará las comunicaciones inalámbricas a través del protocolo TCP IP.

2.2. Gestionará las comunicaciones de la interfaz de escucha soportando los protocolos incluidos en el módulo de Protocolos Industriales.

3. Módulo de Protocolos Industriales

3.1. Poseerá una interfaz multiprotocolo genérica basado en los protocolos que se encuentren definidos. Actualmente se definirá Modbus, sin embargo, será escalable en una segunda versión a los protocolos industriales ETHERNET/IP y CIP. Será capaz gestionar Modbus en la versión prototipo.

4.- Módulo de Comandos

4.1. Tendrá un protocolo capa 7 OSI capaz de gestionar las órdenes del usuario.



Página 10 de 19

5.- Módulo de Baseline

5.1. Por cada equipo de la red se generará un baseline de comportamiento basado en el protocolo industrial que este use. En la primera versión tendrá definido Modbus. Este almacenará:

a) Origen y destino de la comunicación (entre componentes de la red industrial).

b) Operación (comandos/lecturas/escrituras/datos).

5. Entregables principales del proyecto - Manual de uso - Diagrama esquemático - Código fuente - Diagrama de instalación

6. Desglose del trabajo en tareas 1. INICIACIÓN

1.1 Investigación del hardware mas adecuado para la solución 30hs. 2. PLANIFICACIÓN

2.1 Elaboración documento Alcance del Proyecto 2.1.1. Documento Project Scope Statement. 8hs

2.2 Elaboración del WBS 2.2.1. Documento WBS. 8hs

2.3 Construcción del Cronograma de Actividades 2.3.1. Diagrama de GANTT. 2hs

2.4. Análisis de riesgos. 2.4.1. Documento de Riesgos. 2hs

3. DESARROLLO 3.1. Desarrollo del Módulo de Comunicaciones. 3.1.1. Análisis. 10hs 3.1.2. Diseño. 20hs 3.1.3 Codificación. 40hs 3.1.4 Integración. 10hs 3.2. Desarrollo del Módulo de Protocolos Industriales con Modbus. 3.2.1. Análisis. 10hs 3.2.2. Diseño. 20hs



Página 11 de 19

3.2.3 Codificación. 40hs 3.2.4 Integración. 10hs 3.3. Desarrollo del Módulo de Baseline para Modbus. 3.3.1. Análisis. 10hs 3.3.2. Diseño. 20hs 3.3.3 Codificación. 40hs 3.3.4 Integración. 10hs 3.4. Desarrollo del Módulo de Comandos. 3.4.1. Análisis. 10hs 3.4.2. Diseño. 20hs 3.4.3 Codificación. 40hs 3.4.4 Integración. 10hs 3.5. Desarrollo del módulo de Eficiencia Energética 3.5.1. Análisis. 10hs 3.5.2. Diseño. 20hs 3.5.3 Codificación. 40hs 3.5.4 Integración. 10hs

4. TESTING 4.1. Armado del Plan de Testing para los Módulos 4.1.1. Testing Módulo de Comunicaciones. 20hs

4.1.2. Testing Módulo de Protocolos Industriales. 20hs 4.1.3. Testing Módulo Baseline. 20hs 4.1.4. Testing Módulo Comandos. 20hs 4.1.5. Testing Módulo de Eficiencia energética. 20hs

5. CIERRE 5.1. Elaboración de Entregables. 5.1.1. Manual de Uso. 20 hs 5.1.2. Diseño Esquemático. 20hs 5.1.3. Diagrama de Instalación. 10hs Horas Totales: 600hs



Página 12 de 19

7. Diagrama de Activity On Node

INICIO

FIN

1INICIACIÓN

2.1Doc de Alcance

2.4Doc Análisis de Riesgos

2.2Doc de

WBS

2.3Doc GANTT

3.1DesarrolloMod Com.

3.2Desarrollo Mod Com Industrial

3.3Desarrollo

Mod Baseline

3.4Desarrollo

Mod Comandos

4.1.1Testing

Mod Com.

4.1.2Testing

Mod Com Industrial

4.1.3Testing

Mod Baseline

4.1.4Testing

Mod Comandos

5.1.1Manual Usuario

5.1.2Diseño

Esquemati.

5.1.3 Diagrama

Instalación

8. Diagrama de Gantt



Página 13 de 19



Página 14 de 19

9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Hardware(a definir)

3. DESARROLLO

400hs

4. TESTING 100hs

10. Presupuesto detallado del proyecto Categoría Descripción Costo

Costo Directo 600hs a $500 x hs $300000

Costo Indirecto 30% del costo indirecto $90000 Costo Total $390000

11. Matriz de asignación de responsabilidades

Código WBS Título de la tarea

Responsable Primario Colaborador Asesor QA Aprobador

1 Iniciación Almada Pablo Walter Risi

2 Planificación Almada Pablo Nicolas Brahim

Walter Risi

3 Ejecución Almada Pablo Alberto Gonzalez

Alberto Gonzalez

Walter Risi

4 Implementación Almada Pablo Alberto Gonzalez

Alberto Gonzalez

Walter Risi

5 Cierre Almada Pablo Walter Risi

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado



Página 15 de 19

12. Gestión de riesgos Riesgo 1: No se llegan a cumplir todos los requerimientos. ● Severidad (S)=5. El trabajo en base a lo proyectado cumple de forma habitual este tipo de estudios anteriores realizados por la compañía cliente. ● Probabilidad de ocurrencia (O)=3. No es muy probable que ocurra ya que se pretende que el proyecto sea el trabajo final de una carrera de especialización y se terminará a tiempo. Riesgo 2: Cancelación del proyecto de investigación por parte del cliente. ● Severidad (S)=5. Puede realizarse el trabajo en horarios no laborales asumiendo el costo de horas como una inversión para la comunidad. ● Probabilidad de ocurrencia (O)=1. No es muy probable que ocurra ya que se pretende que el proyecto sea un material entregable de publicidad para el cliente a un precio relativamente bajo. Riesgo 3: Indisponibilidad del investigador por proyecto de mayor prioridad de la compañía cliente. ● Severidad (S)=5. Puede realizarse el trabajo en horarios no laborales asumiendo el costo de horas como una inversión para la comunidad. ● Probabilidad de ocurrencia (O)=1. No es muy probable que ocurra ya que se pretende que el proyecto sea un material entregable de publicidad para el cliente a un precio relativamente bajo. Riesgo 4: Indisponibilidad de los colaboradores del proyecto. ● Severidad (S)=6. El impacto al proyecto sería de un grado medio ya que se podría gestionar otros colaboradores implicando una pérdida de tiempo en el proyecto. ● Probabilidad de ocurrencia (O)=1. No es muy probable que ocurra ya que se pretende que el proyecto sea un material entregable de publicidad para el cliente a un precio relativamente bajo. Riesgo 5: Estadías prolongadas fueras del País. ● Severidad (S)=1. La materialización de la amenaza provocaría un pequeño desvío en la modalidad de la investigación y en los tiempos de comunicación. ● Probabilidad de ocurrencia (O)=6. Es probable este tipo de situación ya que el trabajo del principal responsable se centra en clientes del exterior. Riesgo 6: Falta de conocimiento del hardware seleccionado ● Severidad (S)=8. La materialización de la amenaza provocaría un desvío importante en el tiempo del proyecto. ● Probabilidad de ocurrencia (O)=5. Es probable esta situación ya que el equipo a cargo del desarrollo del proyecto no posee experiencia previa en Sistemas embebidos. Riesgo 7: Problemas en la calidad del código en la implementación. ● Severidad (S)=8. La materialización de la amenaza provocaría un desvío importante en el tiempo del proyecto. ● Probabilidad de ocurrencia (O)=5. Es probable esta situación ya que el equipo a cargo del desarrollo del proyecto no posee experiencia previa en desarrollo de código para Sistemas embebidos.



Página 16 de 19

b) Tabla de gestión de riesgos: (El RPN se calcula como RPN=SxO)

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 5 3 15 1 3 3

2 5 1 5

3 5 1 5

4 6 1 6

5 1 6 6

6 8 5 40 5 1 5

7 8 5 40 5 1 5

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 7 Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido: Riesgo 1: No se llegan a cumplir todos los requerimientos. ● Severidad (S)=1. Puede limitarse el alcance del proyecto en base a las necesidades que satisfaga al cliente en una versión inicial. ● Probabilidad de ocurrencia (O)=3. No es muy probable que ocurra ya que se pretende que el proyecto sea el trabajo final de una carrera de especialización y se terminará a tiempo. Riesgo 6: Falta de conocimiento del hardware seleccionado. ● Severidad (S)=5. Puede solicitarse información de forma adelantada a la comunidad. ● Probabilidad de ocurrencia (O)=1. Ya que el hardware a seleccionar será ampliamente aceptado en la comunidad de desarrollo y una documentación madura. Riesgo 7: Problemas en la calidad del código en la implementación. ● Severidad (S)=5. Se monitoreara cercanamente este riesgo y en caso de elevarse la probabilidad de ocurrencia se solicitará soporte a la comunidad. ● Probabilidad de ocurrencia (O)=1. Ya que el hardware a seleccionar tendrá un marco de documentación maduro y una comunidad de desarrollo grande.



Página 17 de 19

13. Gestión de la calidad Para cada uno de los requerimientos del proyecto indique:

■ Req #1.1: El sistema poseerá la capacidad de funcionar en modo bajo consumo. ◆ Verificación: Se realizarán estudios comparativos de la ejecución del hardware con el módulo energético activo y desactivo. La diferencia deberá rondar en un 20% de vida útil. ◆ Validación: El módulo deberá economizar un 20% el uso de la fuente de energía. -■ Req #2.1: Gestionará las comunicaciones inalámbricas. ◆ Verificación: El hardware deberá ser capaz de recibir/enviar información por medios inalámbricos. ◆ Validación: Recibir comunicaciones inalámbricas desde el hardware. -■ Req #3.1: Será escalable a múltiples protocolos. ◆ Verificación: La arquitectura de la aplicación será modular con interfaces bien definidas. ◆ Validación: Se creará un simple protocolo y se agregará el mismo a la solución. -■ Req #3.2: Será capaz gestionar Modbus en la versión prototipo. ◆ Verificación: Se ejecutarán pruebas con otros equipos industriales que utilicen dicho protocolo. ◆ Validación: El hardware será capaz de entender el protocolo industrial en cuestión. -■ Req #4.1: Tendrá un protocolo capa 7 capaz de gestionar las órdenes del usuario. ◆ Verificación: Se emitirán comandos hacia el hardware a través de la interface inalámbrica. ◆ Validación: El sistema será capaz de actuar en base a los comandos recibidos. -■ Req #5.1: Por cada equipo de la red se generará un baseline de comportamiento basado en el protocolo industrial que este use. ◆ Verificación: Se generará tráfico controlado en la red industrial y el mismo será almacenado en el hardware por el módulo de baseline. ◆ Validación: El baseline almacenado deberá corresponder al tráfico generado en laboratorio.



Página 18 de 19

14. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicac.

Responsable

Kick-Off Cliente Comunicar inicio y alinear expectativas

1 Reunion presencial

Almada Pablo

Informe de avances

Cliente Informar avance

1 vez por mes Reunion presencial

Almada Pablo

Presentación de

Entregables

Cliente Entrega del producto final


Almada Pablo

Cierre de Proyecto

Cliente Cierre de Proyecto


Almada Pablo

15. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicac.

1. Entregables terminados de

la fase.

Única vez Pablo Almada Walter Risi Presencial


la fase.



la fase.




Página 19 de 19


la fase.


16. Procesos de cierre ■ Pautas de trabajo que se seguirán para analizar si se respetó el Plan de Proyecto original: - Se revisará que se hayan cumplido los requerimientos, comparándolos con el proyecto terminado. A cargo de Pablo Almada. ■ Identificación de las técnicas y procedimientos útiles e inútiles que se utilizaron, y los problemas que surgieron y cómo se solucionaron: - Para verificar si las tareas fueron realizadas en el tiempo esperado, se comparará el cronograma propuesto con el real, detectando las que llevaron mucho más tiempo de lo planeado y de esta forma poder analizar en dónde falló la planificación. A cargo de Pablo Almada. ■ Por último se enviará un email de agradecimiento al director de la tesis y los colaboradores del proyecto, así como también a los coordinadores de la carrera.

Documents

Sistema Embebido Industrial Autónomo de Monitoreo e ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo... · Plan de Proyecto del Trabajo Final de Carrera de Especialización