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



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



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



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



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



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



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



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



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



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



Lic. Danilo Zecchin

8. Diagrama de Gantt

Página 11 de 28



Lic. Danilo Zecchin

Página 12 de 28



Lic. Danilo Zecchin

Página 13 de 28



Lic. Danilo Zecchin

Página 14 de 28



Lic. Danilo Zecchin

Página 15 de 28



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



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



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


comunicación

P I C C


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


subsistema de comunicación

P I


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



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



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



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



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



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



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



Lic. Danilo Zecchin

Avances en las tareas de

implementación

Sandro De Monte,

Guillermo Leanza

Evitar errores, consultar técnicas

de implementación


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


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



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

Mail

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



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



Mail

4.1 Cantidad de

requerimientos

implementados

en el hardware



Reunión

4.2, 4.3, 4.4 Cantidad de

funciones del Una vez por semana

Danilo Zecchin Sandro De Monte,

Mail

Página 26 de 28



Lic. Danilo Zecchin

diseño

implementadas Guillermo Leanza

4.5 Cantidad de

subsistemas

integrados en el

diseño

Una vez por semana


Reunión

6.1, 6.2, 6.3 Cantidad de test

unitarios

completados con

éxito



Mail, Documento de evidencias

de test

6.4 y 6.5 Cantidad de test

funcionales

completados con

éxito



Mail, Documento de evidencias

de test

7.1 Cantidad de

secciones del

documento

desarrolladas

Una vez por semana


Guillermo Leanza

Mail, Documento de informe

final

7.2 Cantidad de

secciones del

documento

desarrolladas

Una vez por semana


Mail

7.3 Cantidad de

tópicos cubiertos

para la

presentación

Una vez por semana

Danilo Zecchin Guillermo Leanza

Mail

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



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

Sistema de adquisición de datos para equipos del sector de...

Documents

Transcript of Sistema de adquisición de datos para equipos del sector de...