Sistema de adquisición de datos para equipos del sector de...
Transcript of Sistema de adquisición de datos para equipos del sector de...
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Sistema de adquisición de datos para equipos del sector de upstream (Industria del
Petróleo) Autor
Lic. Danilo Zecchin
Director del trabajo
Ing. Guillermo Leanza
Jurado propuesto para el trabajo
Ing. Pablo Escudero Ing. Nicolás Dassieu Blanchet Esp.Ing. Pedro Ignacio Martos.
Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre abril y mayo de 2016.
Página 1 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Tabla de contenido
Registros de cambios
Acta de Constitución del Proyecto
Identificación y análisis de los interesados
1. Propósito del proyecto
2. Alcance del proyecto
3. Supuestos del proyecto
4. Requerimientos
5. Entregables principales del proyecto
6. Desglose del trabajo en tareas
7. Diagrama de Activity On Node
8. Diagrama de Gantt
9. Matriz de uso de recursos de materiales
10. Presupuesto detallado del proyecto
11. Matriz de asignación de responsabilidades
12. Gestión de riesgos
13. Gestión de la calidad
14. Comunicación del proyecto
14. Gestión de Compras
16. Seguimiento y control
17. Procesos de cierre
Página 2 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Registros de cambios
Revisión Cambios realizados Fecha
1.0 Creación del documento 30/03/2016
1.1 Se completan las secciones 1 a 6 del documento 02/04/2016
1.2 Se ajusta la planilla de interesados y se refinan los requerimientos en la sección 4
06/04/2016
1.3 Se completan las secciones 7 a 11 del documento 09/04/2016
1.4 Se ajusta tiempos en tareas de cierre.
Se agrega tarea de informe de avance.
Se completan las secciones 12 a 17.
16/04/2016
1.5 Se completa director y ajustes en sección 15 20/04/2016
1.6 Se completa el jurado 26/04/2016
1.7 Se ajusta plan de comunicación y se agregan comentarios sobre requerimientos
30/04/2016
1.8 Se ajusta el título y propósito 10/05/2016
Página 3 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Acta de Constitución del Proyecto
Buenos Aires, 30 de marzo de 2016
Por medio de la presente se acuerda con el Sr. Danilo Zecchin que su Proyecto Final de la
Carrera de Especialización en Sistemas Embebidos se titulará “Sistema de adquisición de datos para
equipos del sector de upstream (Industría del Petróleo)”, consistirá esencialmente en el prototipo
preliminar de un sistema embebido para adquisición de datos , y tendrá un presupuesto preliminar
estimado de 662 hs de trabajo, con fecha de inicio miércoles 30 de marzo de 2016 y fecha de
presentación pública miércoles 14 de diciembre de 2016.
Se adjunta a esta acta la planificación inicial.
Ariel Lutenberg Sandro De Monte
Director de la CESEFIUBA TEIA SRL
Página 4 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Identificación y análisis de los interesados
Rol Nombre y Apellido Departamento Puesto
Auspiciante TEIA SRL Gerencia
Cliente TEIA SRL Gerencia
Impulsor Sandro De Monte Departamento Técnico y
Desarrollo
Gerente
Responsable Danilo Zecchin Departamento Técnico y
Desarrollo
Desarrollador
Colaboradores Guillermo Leanza FIUBA Docente
Orientadores Sandro De Monte,
Adolfo Doorn
Departamento Técnico y
Desarrollo
Equipo
Usuario Final Empresas operadoras o
contratistas prestadoras
de servicio
Orientadores: Sandro De Monte es el ingeniero electrónico del equipo que nos ayudará con las
cuestiones relativas al diseño del hardware. Adolfo Doorn es geólogo, nos ayudará a elaborar
los requisitos funcionales de la adquisición.
Usuario final: toda aquella empresa que necesite o requiera el servicio de adquisición de datos
para monitoreo de sus equipos o análisis para optimización. Destinado a empresas contratistas
u operadoras de la industria del petróleo.
1. Propósito del proyecto
El propósito de este proyecto es diseñar y construir un sistema embebido de adquisición de datos para
modernizar y reemplazar el sistema actual, incluyendo funcionalidad que sirva a los propósitos del
análisis de telemetría y optimización postproceso de equipos de torre que prestan servicio en la
industria del petróleo en el sector de upstream. Se proyecta una plataforma de adquisición enriquecida
con aspectos de procesamiento de señales de diversos tipos de fuentes, que permita la elección de una
estrategia de adquisición por configuración e implemente interfaces de comunicación aptas para dar
soporte a la escalabilidad.
Página 5 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
2. Alcance del proyecto
Para lograr el objetivo propuesto, se prevé dar cobertura a los siguientes puntos:
1. Análisis, investigación y elección de hardware basado en la arquitectura ARM con la premisa
principal de soportar adquisición a altas frecuencias.
2. Diseño de un prototipo de hardware de adquisición según la elección del punto 1.
3. Diseño e implementación del firmware de adquisición con enfoque en las características antes
descritas.
4. Especificación, diseño e implementación de las interfaces de comunicación y protocolo para la
interacción.
5. Plan y ejecución de pruebas unitarias e integración sobre los productos de los puntos 3 y 4.
6. Documentación del sistema que incluya:
a. Descripciones de diseño (diagramas de arquitectura, estructurales y de
comportamiento)
b. Detalle de las técnicas de procesamiento de señales aplicadas
c. Resultados de test aplicados
d. Manuales para utilización y consumo de datos proporcionados. API exportada.
El presente proyecto no incluye:
1. Plataforma de interacción y consumo de datos provisto por la adquisición (ej: aplicación cliente
que almacene en base de datos, clientes de visualización realtime)
3. Supuestos del proyecto
Para el desarrollo del presente proyecto se supone lo siguiente:
● El sistema embebido interactúa con sensores en señal de corriente de 4 a 20 mA
● La señal de entrada estará aislada galvánicamente
● Se dispone de tensión de línea y es estable (se delega en otro componente externo al sistema)
4. Requerimientos
Para describir los requerimientos y agruparlos, consideremos la siguiente descomposición tentativa del
sistema de adquisición en subpartes:
Página 6 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Figura 1
A continuación se detalla la lista de requerimientos según las divisiones ilustradas en la Figura 1. 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 de adquisición definen
la funcionalidad del mismo, por lo tanto son los más prioritarios. Los requerimientos del protocolo de
configuración y comunicación definen la necesidad de interacción entre los módulos, por esa razón
también resultan obligatorios para dar soporte a la escalabilidad. Finalmente, los requerimientos de
procesamiento de señales resultan de la necesidad de obtener valores enriquecidos, con cierto nivel de
preproceso útil a procesamientos posteriores, por lo cual se encuentran en un nivel de prioridad
inferior al resto.
1. Sistema de adquisición:
a. Deberá estar compuesto por unidades individuales identificadas como módulos de
adquisición (1)
b. Cada módulo deberá implementar la funcionalidad de adquisición completa (1)
c. Deberá ser capaz de configurarse y trabajar con 1 a 8 módulos de adquisición según la
demanda de la operación a monitorear (1)
d. Cada módulo se conectará de forma dinámica a una red desde la cual puede interactuar
con otros módulos y clientes (1)
e. Cada módulo deberá operar por lo menos con dos sensores (1)
f. Los sensores deberán ser de característica analógica o digital (1)
g. Deberá trabajar con tensión de alimentación en 5V (1)
Página 7 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
2. Subsistema de adquisición de datos:
a. Deberá disponer los siguientes modos de operación según la interfaz con el sensor:
analógico, digital, lógico y contadores (1)
b. Deberá ser capaz de trabajar con frecuencias de adquisición de al menos 16 kS/s (1)
c. Deberá ser capaz de variar la frecuencia de adquisición según el requerimiento en el
rango de 1 S/s a 16 kS/s (1)
d. Deberá almacenar los datos adquiridos durante un periodo de tiempo especificado de 1
segundo (1)
e. Deberá procesar datos obtenidos por lo menos de dos sensores en simultáneo
(canales). (1)
f. Deberá contar con mecanismos de detección de errores eléctricos o funcionales en la
interfaz con el sensor (2)
g. Deberá utilizar un conversor AD onchip de precisión extendida configurable (20 bits) (1)
h. Deberá consistir en un diseño portable que no dependa de un periférico específico (1)
3. Protocolo de configuración y comunicación:
a. Deberá contar con mecanismo para identificar el módulo (1)
b. Utilizará un protocolo específico de comunicación: CAN (1)
c. Implementará un mecanismo de sincronización por reloj descentralizado (1)
d. Deberá exponer una API para recuperar datos de la adquisición, reaccionando a
demanda (clienteservidor) (1)
e. Deberá definir el mecanismo de configuración del modo de operación de cada canal (1)
f. Deberá representar un diseño portable que no dependa de un periférico específico (1)
4. Procesamiento de señales digitales:
a. Implementará técnicas para normalizar las señales entrantes: filtrados digitales,
técnicas de muestreo, evaluación de precisión, supresión de ruidos. (3)
b. En el modo analógico, deberá generar un bucket notable: una única muestra
representativa de los datos almacenados durante el tiempo de adquisición especificado
(requerimiento 2.d) (2)
5. Entregables principales del proyecto
● Equipo prototipo de adquisición de datos configurable y escalable
● Documentación de diseño y pruebas
● Manual de usuario y desarrollador
● Informe final del proyecto
6. Desglose del trabajo en tareas
El tiempo total estimado del proyecto es de 662 hs. Se describe a continuación el desglose de tareas y
el tiempo estimado de cada una:
1. Análisis preliminar y planificación (total 24 hs):
Página 8 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
1.1. Definición de alcance, requerimientos y desglose de tareas (8 hs)
1.2. Construcción de presupuestos, estimación de costos y recursos (8 hs)
1.3. Planificación de seguimiento: establecimiento de responsabilidades, identificación de
riesgos y definiciones de calidad, parámetros de seguimiento y proceso de cierre (8 hs)
2. Análisis y estudio específico (total 120 hs):
2.1. Análisis del hardware disponible para implementación del sistema, evaluación de
alternativas según los requerimientos. Análisis de MCUs de la arquitectura ARM Cortex
M (20 hs)
2.2. Análisis y estudio de las herramientas de desarrollo disponibles del hardware revisado
(20 hs)
2.3. Análisis y estudio del protocolo de comunicación CAN (40 hs)
2.4. Análisis y estudio de técnicas de adquisición de datos aplicadas en la industria (20 hs)
2.5. Análisis y estudio de algoritmos de procesamiento digital de señales (20 hs)
3. Diseño (total 100 hs):
3.1. Diseño de arquitectura del sistema (20 hs)
3.2. Diseño del prototipo del hardware del sistema (20 hs)
3.3. Diseño detallado (estructural y comportamiento ) de subsistema de adquisición (30 hs)
3.4. Diseño detallado de subsistema de comunicación y configuración (20 hs)
3.5. Diseño de aplicación de procesamiento digital de señales (10 hs)
4. Implementación (120 hs):
4.1. Construcción del prototipo del sistema (30 hs)
4.2. Implementación del subsistema de adquisición (30 hs)
4.3. Implementación del subsistema de comunicación (30 hs)
4.4. Implementación del subsistema de procesamiento de señales (20 hs)
4.5. Implementación de integración de los subsistemas (10 hs)
5. Control de avance: construcción de informe (8 hs)
6. Verificación y validación (190 hs):
6.1. Ejecución de test unitarios sobre subsistema de adquisición (30hs)
6.2. Ejecución de test unitarios sobre subsistema de comunicación (30 hs)
6.3. Ejecución de test unitarios sobre subsistema de procesamiento de señales (20 hs)
6.4. Ejecución de test de integración y evaluación de arquitectura (30 hs)
6.5. Ejecución de test funcionales sobre la arquitectura completa (40 hs)
6.6. Documentación de evidencias de cada test anterior (40 hs total / 8 hs por test)
7. Cierre (total 100 hs):
7.1. Elaboración de informe final (60 hs)
7.2. Construcción de manual de usuario y desarrollador (20 hs)
7.3. Elaboración de presentación del trabajo (20 hs)
7. Diagrama de Activity On Node A continuación se describe el diagrama de actividades. El tiempo de cada tarea está expresado en
horas. El diagrama describe cómo podrían desarrollarse las tareas, indicando el paralelismo posible
entre ellas. El camino crítico está indicado por las tareas sombreadas en rojo. Finalmente, la fecha de
Página 9 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
fin se calcula a partir de establecer un único recurso asignado al 100 % para todas las tareas (el
responsable del proyecto, con este escenario no podría ejecutarse tareas en simultáneo) y un tiempo
diario de 4 hs (Lunes a Viernes).
A continuación se describe en detalle la tarea 1 de “Análisis preliminar y planificación”. En este caso, el
tiempo de las tareas también está expresado en horas y cada tarea de la secuencia se lleva a cabo en
una semana diferente. Por esta razón, la fecha de fin es 14/4/16.
Página 10 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
8. Diagrama de Gantt
Página 11 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Página 12 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Página 13 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Página 14 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Página 15 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
9. Matriz de uso de recursos de materiales Se describe a continuación la matriz de uso de recursos, utilizando como referencia las tareas macros
definidas en la sección 6:
Código WBS
Nombre de la tarea
Recursos requeridos (horas)
PC Hardware prototipo
Laboratorio técnico
1 Análisis preliminar y planificación
24
2 Análisis y estudio específico 120
3 Diseño 80 20 20
4 Implementación 90 90 30
5 Control de avance 8
6 Verificación y validación 190 190 70
7 Cierre 80
10. Presupuesto detallado del proyecto La tabla a continuación detalla el presupuesto del proyecto, indicando cada categoría de costo y su
detalle:
Categoría Detalle Costo
Costo directo 662 hs a $150/h $ 99300
Costo indirecto Se calcula como el 30% del costo directo, incluyendo mantenimiento de recursos utilizados: Laboratorio técnico y PC.
$ 28530
Materiales Kit desarrollo y prototipado ARM Cortex M3 (10 unidades)
Precio unitario: 10 USD
Flete: 50 USD (courier estándar)
Cotización de referencia: 1 USD 15 ARS
Incluye arancel aduanero
$ 3375
Materiales Construcción de prototipo placa base $ 3000
Materiales Componentes electrónicos $ 4000
TOTAL (expresado en ARS) $ 138205
Página 16 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
11. Matriz de asignación de responsabilidades
Para cada tarea del WBS, indicamos la responsabilidad específica de cada participante del proyecto:
Código WBS
Título de la tarea
Danilo Zecchin
Sandro De
Monte
TEIA SRL Gerencia
Sandro De Monte,
Adolfo Doorn
Guillermo Leanza
Responsable Impulsor Cliente,
Auspiciante Orientadores Colaboradores
1.1 Definición de alcance, requerimientos y
desglose de tareas
P C,A A C
1.2 Construcción de presupuestos, estimación
de costos y recursos
P C,A A
1.3 Planificación de seguimiento P C,A A
2.1 Análisis del hardware P C, A C
2.2 Análisis y estudio de las herramientas de
desarrollo disponibles del hardware
revisado
P C,A C
2.3 Análisis y estudio del protocolo de
comunicación CAN
P C C
2.4 Análisis y estudio de técnicas de
adquisición de datos aplicadas en la
industria
P C C
2.5 Análisis y estudio de algoritmos de
procesamiento digital de señales
P C C
3.1 Diseño de arquitectura del sistema P A I C C
3.2 Diseño del prototipo del hardware del
sistema
P S, A C
3.3 Diseño detallado (estructural y
comportamiento ) de subsistema de
adquisición
P A C C
3.4 Diseño detallado de subsistema de
comunicación y configuración
P A C
3.5 Diseño de aplicación de procesamiento
digital de señales
P A C C
Página 17 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
4.1 Construcción del prototipo del sistema P S, A
4.2 Implementación del subsistema de
adquisición
P I C C
4.3 Implementación del subsistema de
comunicación
P I C C
4.4 Implementación del subsistema de
procesamiento de señales
P I C C
4.5 Implementación de integración de los
subsistemas
P A C C
5 Construcción de informe de avance P I I A
6.1 Ejecución de test unitarios sobre
subsistema de adquisición
P I
6.2 Ejecución de test unitarios sobre
subsistema de comunicación
P I
6.3 Ejecución de test unitarios sobre
subsistema de procesamiento de señales
P I
6.4 Ejecución de test de integración y
evaluación de arquitectura
P A I
6.5 Ejecución de test funcionales sobre la
arquitectura completa
P A I I
6.6 Documentación de evidencias de cada
test anterior
P A I
7.1 Elaboración de informe final P C A A
7.2 Construcción de manual de usuario y
desarrollador
P A
7.3 Elaboración de presentación del trabajo P A
Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado
Página 18 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
12. Gestión de riesgos A continuación se describirán los riesgos detectados del proyecto en tres secciones:
a) Identificación de los riesgos: Riesgo 1: Capacidad de procesamiento del hardware seleccionado que no permite alcanzar los requisitos de frecuencia de la adquisición.
● Severidad (S): 7. Moderada dado que no permitirá disponer de modos de alta frecuencia para intervenciones especiales que lo requieran.
● Probabilidad de Ocurrencia: 2. La elección y sizing del hardware se realizó en función a las necesidades de procesamiento, por eso la tasa ocurrencia es baja.
● Tasa de no detección: 2. Es fácil de detectarlo ejecutando los test unitarios del subsistema de adquisición.
Riesgo 2: Capacidad de procesamiento del hardware seleccionado que no permite alcanzar los requisitos de cantidad de sensores con los que debe interactuar.
● Severidad (S): 8. Alta dado que no permitirá interconectar varios sensores a la vez. ● Probabilidad de Ocurrencia (O): 2. La elección y sizing del hardware se realizó en función a las
necesidades de procesamiento, por eso la tasa ocurrencia es baja. ● Tasa de no detección (D): 2. Es fácil de detectarlo ejecutando los test unitarios del subsistema
de adquisición. Riesgo 3: Mal funcionamiento del equipo en condiciones ambientales adversas, como temperaturas elevadas o muy bajas.
● Severidad (S): 9. El equipo de adquisición debe proveer alta disponibilidad, por eso la severidad de este riesgo es elevada.
● Probabilidad de ocurrencia (O): 2. Se seleccionarán componentes de hardware de rango industrial, por lo cual la probabilidad de ocurrencia es baja.
● Tasa de no detección (D): 7. Este problema puede no ponerse de manifiesto durante el desarrollo e implementación del prototipo y suceder en ensayos o pruebas de campo.
Riesgo 4: Velocidad de transmisión del protocolo de comunicación deficiente.
● Severidad (S): 7. Severidad moderada, no permitirá realizar transmisiones a máxima velocidad, relegando los modos de funcionamiento de alta frecuencia.
● Probabilidad de ocurrencia (O): 2. La elección del protocolo de comunicación contempla una tecnología de alta velocidad.
● Tasa de no detección (D): 2. Es fácil de evaluar esta características durante las etapas de test unitarios del subsistema de comunicación.
Riesgo 5: Falta de stock del hardware seleccionado. Al momento de comenzar a diseñar e implementar el prototipo, no disponer de stock de stock de componentes para construcción del prototipo.
● Severidad (S): 9. Tiene alto grado de severidad, dado que es mandatorio para construir el prototipo y su falta demoraría los plazos del proyecto.
Página 19 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
● Probabilidad de Ocurrencia (O): 3. El proveedor elegido dispone de venta directa de sus productos como así también varios revendedores, por eso la posibilidad de falta de stock es poco probable.
● Tasa de no detección (D): 3. El proveedor expone el stock actual actualizado a diario. Riesgo 6: Necesidad de licencia del responsable del proyecto o participantes secundarios, que impliquen retrasos en el desarrollo del proyecto.
● Severidad (S): 6. Severidad moderada dado que las licencias suelen durar dos o tres días. ● Probabilidad de ocurrencia (O): 3. Se toma como base la cantidad de licencias que ocurrieron en
años anteriores. ● Tasa de no detección (D): 5. Depende del motivo por el cual es necesaria la licencia, pueden
manifestarse repentinamente.
b) Tabla de gestión de riesgos: (El RPN se calcula como RPN=SxOxD.)
Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.*
Detecc * RPN*
1 7 2 2 28
2 8 2 2 32
3 9 2 7 126 9 2 3 54
4 7 2 2 28
5 9 3 3 81 4 3 3 36
6 6 3 5 90 6 3 3 54
Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 60 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 3: efectuar stress tests que expongan las condiciones ambientales a las cuales podrá estar sometido el dispositivo.
● Severidad (S): 9. La severidad no varía, dado que la disponibilidad del equipo debe ser alta. ● Probabilidad de ocurrencia (O): 2. No varía dado que si bien se efectúa el test, la probabilidad
de falla en un escenario productivo sigue estando presente.
Página 20 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
● Tasa de no detección (D): 3. Al efectuar el test simulando un entorno adverso, permitirá determinar con más facilidad si el dispositivo podrá trabajar bajo condiciones ambientales adversas.
Riesgo 5: realizar una reserva o compra adelantada sobreestimada al inicio para solapar el tiempo de fabricación necesario con las etapas tempranas del proyecto.
● Severidad (S): 4. La severidad disminuye, dado que el plazo de entrega se solapa con otras tareas y se dispondrá de mayor stock al necesario inicialmente.
● Probabilidad de ocurrencia (O): 3. No varía dado que el proveedor es el mismo. ● Tasa de no detección (D): 3. No varía dado que el mecanismo de comunicación es el mismo.
Riesgo 6: seguimiento de cumplimiento de los exámenes médicos mandatorios por la legislación laboral.
● Severidad: 6. No varía, dado que su ocurrencia implica la necesidad de una licencia. ● Probabilidad de ocurrencia: 3. Permite detectar la necesidad de aplicar acciones preventivas. ● Tasa de no detección: 3. La realización de exámenes médicos puede alertar tempranamente de
ciertas enfermedades.
13. Gestión de la calidad A continuación se describen las acciones a aplicar para evaluar y gestionar la calidad de cada requerimiento identificado, según la descomposición ilustrada en la Figura 1:
1. Sistema de adquisición:
a. Deberá estar compuesto por unidades individuales identificadas como módulos de
adquisición
■ Verificación: se revisará el diseño para identificar la solución propuesta a este
requerimiento
■ Validación: se efectuarán tests funcionales y de arquitectura para evaluar el
funcionamiento de los módulos en conjunto
b. Cada módulo deberá implementar la funcionalidad de adquisición completa
■ Verificación: se efectuarán test unitarios sobre el subsistema de adquisición
■ Validación: se efectuarán test funcionales y de integración sobre las
características del subsistema adquisición.
c. Deberá ser capaz de configurarse y trabajar con 1 a 8 módulos de adquisición según la
demanda de la operación a monitorear
■ Verificación: se efectuarán tests de utilización de 8 módulos e integración entre
los mismos.
■ Validación: se efectuarán tests de arquitectura y funcionales sobre los 8
módulos.
d. Cada módulo se conectará de forma dinámica a una red desde la cual puede interactuar
con otros módulos y clientes.
■ Verificación: se ejecutarán tests unitarios para evaluar la comunicación y
mecanismo dinámico de configuración al conectar/desconectar un módulo.
Página 21 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
■ Validación: se ejecutarán test funcionales y de arquitectura que demuestren la
operabilidad de la red.
e. Cada módulo deberá operar por lo menos con dos sensores.
■ Verificación: se realizarán tests utilizando dos o más sensores conectados a un
módulo.
■ Validación: se ejecutarán tests funcionales para comprobar los valores
obtenidos.
f. Los sensores deberán ser de característica analógica o digital.
■ Verificación: se ejecutarán test conectando sensores analógicos y digitales.
■ Validación: se ejecutarán test funcionales usando sensores analógicos y
digitales, comprobando las lecturas obtenidas.
g. Deberá trabajar con tensión de alimentación en 5V
■ Verificación: se alimentará el dispositivo con 5V
■ Validación: se ejecutarán test funcionales y examinarán lecturas
2. Subsistema de adquisición de datos:
a. Deberá disponer los siguientes modos de operación según la interfaz con el sensor:
analógico, digital, lógico y contadores
■ Verificación: se ejecutarán tests unitarios configurando el dispositivo en cada
modo y conectando diferentes sensores según el mismo.
■ Validación: se ejecutarán tests funcionales para evaluar las lecturas en cada
modo.
b. Deberá ser capaz de trabajar con frecuencias de adquisición de al menos 16 kS/s
■ Verificación: se ejecutarán test unitarios que configuren el dispositivo en
frecuencias de 16 Ks/s o superiores
■ Validación: se ejecutarán tests que examinen el volumen y calidad de los datos
adquiridos
c. Deberá ser capaz de variar la frecuencia de adquisición según el requerimiento en el
rango de 1 S/s a 16 kS/s
■ Verificación: se ejecutarán tests unitarios que configuren cada uno de los
modos soportados
■ Validación: se ejecutarán tests funcionales que comprueben la cantidad de
datos obtenidos en cada modo
d. Deberá almacenar los datos adquiridos durante un periodo de tiempo especificado de 1
segundo
■ Verificación: se ejecutarán tests unitarios que prueben que los datos varían
segundo a segundo
■ Validación: se ejecutarán test funcionales de obtención de datos en el tiempo.
e. Deberá procesar datos obtenidos por lo menos de dos sensores en simultáneo
(canales).
■ Verificación: se ejecutarán tests unitarios configurando y conectando dos
sensores a la vez.
Página 22 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
■ Validación: se ejecutarán tests funcionales que evalúen los datos obtenidos de
cada sensor al mismo tiempo.
f. Deberá contar con mecanismos de detección de errores eléctricos o funcionales en la
interfaz con el sensor.
■ Verificación: se ejecutarán tests que provoquen un cortocircuito en la conexión
con el sensor o desconexión del mismo.
■ Validación: se ejecutarán tests funcionales que determinen la alerta y respuesta
del sistema en esas situaciones.
g. Deberá utilizar un conversor AD onchip de precisión extendida configurable (20 bits)
■ Verificación: se ejecutarán tests unitarios que especifiquen ese modo de
operación del AD.
■ Validación: se ejecutarán tests funcionales que evalúen la precisión de los datos
de salida.
h. Deberá consistir en un diseño portable que no dependa de un periférico específico.
■ Verificación: examinar el diseño y código para detectar si se aplicó un enfoque
de separación en capas.
■ Validación: aplicar una adaptación a otro periférico sin cambios en el diseño del
subsistema
3. Protocolo de configuración y comunicación:
a. Deberá contar con mecanismo para identificar el módulo
■ Verificación: ejecutar tests unitarios con dos o más módulos simultáneamente
solicitando datos a uno específico.
■ Validación: ejecutar tests funcionales examinando el resultado de la
adquisición.
b. Utilizará un protocolo específico de comunicación: CAN
■ Verificación: inspeccionar la aplicación del estándar CAN
■ Validación: ejecutar tests funcionales que demuestran la operación efectiva del
protocolo.
c. Implementará un mecanismo de sincronización por reloj descentralizado
■ Verificación: ejecutar tests unitarios donde un módulo es responsable de
manejar el reloj y luego otro módulo recibe esa responsabilidad.
■ Validación: ejecutar tests funcionales y de arquitectura para evaluar el
sincronismo del sistema global.
d. Deberá exponer una API para recuperar datos de la adquisición, reaccionando a
demanda (clienteservidor).
■ Verificación: ejecución de tests unitarios para cada comando de la API.
■ Validación: ejecución de tests funcionales para demostrar la usabilidad y
completitud de la API.
e. Deberá definir el mecanismo de configuración del modo de operación de cada canal
■ Verificación: ejecución de tests unitarios que envíen todas las configuraciones
posibles a un módulo de adquisición.
Página 23 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
■ Validación: ejecución de tests funcionales que comprueben las muestras de
datos esperadas en cada modo.
f. Deberá representar un diseño portable que no dependa de un periférico específico.
■ Verificación: examinar el diseño y código para detectar si se aplicó un enfoque
de separación en capas.
■ Validación: aplicar una adaptación a otro protocolo de comunicación sin
cambios en el diseño del subsistema.
4. Procesamiento de señales digitales:
a. Implementará técnicas para normalizar las señales entrantes: filtrados digitales,
técnicas de muestreo, evaluación de precisión, supresión de ruidos.
■ Verificación: comparación de los datos adquiridos antes y después de la
aplicación de la técnica.
■ Validación: análisis y comparación de la señal de entrada y la reconstruida por
la adquisición y el proceso de normalización.
b. En el modo analógico, deberá generar un bucket notable: una única muestra
representativa de los datos almacenados durante el tiempo de adquisición especificado
(requerimiento 2.d)
■ Verificación: ejecución de tests unitarios que examinen la muestra notable.
■ Validación: ejecución de tests funcionales que determinen que la muestra
notable es un resumen del tiempo de adquisición especificado.
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
Avances y conclusiones de las tareas de
análisis
Sandro De Monte,
Guillermo Leanza
Evitar errores, obtener opiniones
y recomendaciones
Cada semana Mail Danilo Zecchin
Avances en las tareas de diseño
Sandro De Monte,
Guillermo Leanza
Evitar retrasos, verificar
soluciones
Cada semana Mail, documentación
de diseño
Danilo Zecchin
Finalización del diseño
Sandro De Monte, Gerencia TEIA SRL
Informar avances, exponer y verificar
soluciones de diseño
Al completar el diseño por única vez
Reunión Danilo Zecchin
Página 24 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
Avances en las tareas de
implementación
Sandro De Monte,
Guillermo Leanza
Evitar errores, consultar técnicas
de implementación
Cada semana Mail Danilo Zecchin
Avances en la ejecución de los
test
Sandro De Monte,
Guillermo Leanza
Mostrar y evaluar los resultados
parciales, verificar los test ejecutados y por
ejecutar
Cada semana Mail, documento de evidencias de
test
Danilo Zecchin
Finalización de ejecución de test
Sandro De Monte, Gerencia TEIA SRL
Exponer el funcionamiento
de los requerimientos
Al completar los tests por única vez
Reunión, documento de evidencias de
test
Danilo Zecchin
Avances en la elaboración del informe final y tareas de cierre
Sandro De Monte,
Guillermo Leanza
Obtener lineamientos y
opiniones, aplicar correcciones
Cada semana Mail Danilo Zecchin
15. Gestión de Compras Para la construcción del prototipo es necesario analizar y estudiar alternativas para diseñar e
implementar el hardware de adquisición. Se seleccionarán los siguientes proveedores tentativos:
● Se evaluarán las propuestas disponibles de microcontroladores ARM Cortex M de los siguientes
fabricantes:
○ Cypress Semiconductor
○ Texas Instrument
○ ST
● Digikey: compra de componentes electrónicos necesarios.
Para evaluar estos proveedores se aplicarán los siguientes criterios:
1. Disponibilidad y variedad de productos que permitan cubrir los requerimientos del proyecto.
2. Disponibilidad de kits de desarrollo.
3. Stock disponible, tiempo de fabricación y plazos de entrega.
4. Herramientas de desarrollo de software.
5. Documentación técnica, de desarrollo y manuales.
6. Soporte profesional y comunidad de desarrollo.
Una vez seleccionado el proveedor, se redactará el statement of work, mediante el cual se deja expresada la cantidad de componentes comprados, el plazo de entrega estimado y el monto a pagar (por adelantado/contraentrega).
Página 25 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
16. Seguimiento y control La matriz a continuación describe los parámetros considerados para medir el avance de las tareas del WBS y quienes serán los involucrados en el proceso de 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 Cantidad de
secciones
desarrolladas del
documento de
planificación
Una vez por semana
Danilo Zecchin Sandro De Monte, Gerencia TEIA SRL
2.1 y 2.2 Cantidad de
opciones
analizadas
Dos veces por semana
Danilo Zecchin Sandro De Monte
Mail, reunión
3.1 Cantidad de
subsistemas
diseñados
Dos veces por semana
Danilo Zecchin Sandro De Monte, Gerencia TEIA SRL
Mail, reunión, documento de diseño
3.2 % completado
del diseño Dos veces por
semana Danilo Zecchin Sandro De
Monte, Guillermo Leanza
Mail, reunión
3.3, 3.4, 3.5 Cantidad de
requerimientos
resueltos
durante el
diseño
Dos veces por semana
Danilo Zecchin Sandro De Monte
4.1 Cantidad de
requerimientos
implementados
en el hardware
Dos veces por semana
Danilo Zecchin Sandro De Monte
Reunión
4.2, 4.3, 4.4 Cantidad de
funciones del Una vez por semana
Danilo Zecchin Sandro De Monte,
Página 26 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
diseño
implementadas Guillermo Leanza
4.5 Cantidad de
subsistemas
integrados en el
diseño
Una vez por semana
Danilo Zecchin Sandro De Monte, Gerencia TEIA SRL
Reunión
6.1, 6.2, 6.3 Cantidad de test
unitarios
completados con
éxito
Dos veces por semana
Danilo Zecchin Sandro De Monte
Mail, Documento de evidencias
de test
6.4 y 6.5 Cantidad de test
funcionales
completados con
éxito
Dos veces por semana
Danilo Zecchin Sandro De Monte, Gerencia TEIA SRL
Mail, Documento de evidencias
de test
7.1 Cantidad de
secciones del
documento
desarrolladas
Una vez por semana
Danilo Zecchin Sandro De Monte,
Guillermo Leanza
Mail, Documento de informe
final
7.2 Cantidad de
secciones del
documento
desarrolladas
Una vez por semana
Danilo Zecchin Sandro De Monte,
7.3 Cantidad de
tópicos cubiertos
para la
presentación
Una vez por semana
Danilo Zecchin Guillermo Leanza
17. Procesos de cierre Al finalizar el proyecto, se realizará una evaluación de la performance del plan aplicado, considerando las siguientes actividades por parte del responsable:
1. Evaluación global de la ejecución del plan de proyecto, incluyendo: a. Plazos cumplidos e incumplidos, evaluación de la estimación.
Página 27 de 28
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Lic. Danilo Zecchin
b. Gestión eficiente de las comunicaciones y control de avance, identificando problemas de interpretación, de selección de la audiencia y de técnicas y soportes a la comunicación (diagramas, documentos, informes, etc.)
c. Cantidad de rediseño o reimplementación, asociado a requerimientos incompletos o mal definidos.
d. Demoras incurridas, identificación de su causa y planes de mitigación para proyectos futuros.
e. Gestión de los riesgos, midiendo el éxito del plan de mitigación e identificando ajustes a los que no lo tienen.
2. Evaluación del producto final, incluyendo:
a. Requerimientos funcionales implementados b. Entregables funcionales c. Documentación de utilización y reproducción
Finalmente, se incluirá en el informe final del trabajo y durante la exposición del mismo un apartado especial para agradecer a todas las personas involucradas en el proyecto, en especial al director, impulsor y colaboradores.
Página 28 de 28