sAPI (simpleAPI): diseño e implementación de unalaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final...Realizar un informe final de proyecto. 4.2. Confeccionar un manual de referencia

sAPI (simpleAPI): diseño e implementación de una biblioteca para sistematizar la programación de Sistemas Embebidos

Autor Esp. Ing. Eric Nicolás Pernia

Director Mg. Ing. Félix Safar (UNQ)

Jurado propuesto para el trabajo:

- Dr. Ing. Pablo Gómez (FI-UBA)

- Mg. Ing. Pablo Ridolfi (UTN FRBA)

- Ing. Juan Manuel Cruz (FI-UBA)

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

El problema a resolver:

En la actualidad existe una enorme variedad plataformas de Sistemas Embebidos en el mercado, y si bien todas cuentan con dispositivos programables con características similares y periféricos compatibles, se observa que en la práctica son muy distintos, provocando que se deba invertir mucho tiempo en aprender a programar con las particularidades de cada una de las plataformas antes de su utilización.


La solución planteada:

Debido a la amplia variedad de plataformas de hardware y lenguajes de programación, se propone en este proyecto la realización del diseño de una biblioteca modelada independientemente del lenguaje de programación y arquitectura del hardware, con la intención de convertirlo en una propuesta de estándar para la programación de Sistemas Embebidos.


La misión del autor:

Dado que el presente autor cumple el rol de Coordinador General del proyecto de hardware y software abierto "Computadora Industrial Abierta Argentina (CIAA)" se realizará la implementación de referencia tomando las plataformas de hardware diseñadas en el marco de este proyecto como casos de validación del diseño de biblioteca a realizar. Esto permitirá a la comunidad de usuarios de las plataformas del Proyecto CIAA programar las diferentes plataformas utilizando la misma biblioteca, reduciendo tiempos de aprendizaje y desarrollo.

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Universidad

Nacional de Quilmes

(UNQ).

Secretaría de investigación

Cliente Mg. Ing. Félix Safar. Ciencia y tecnología. Director de programa de

investigación IACI.

Impulsor Dr. Ing. Ariel

Lutenberg

FI-UBA y Proyecto CIAA. Docente-Investigador.

Director de la MSE.

Vinculación y difusión.

Responsable Esp. Ing. Eric Pernia UNQ, FI-UBA y Proyecto

CIAA.

Docente-Investigador y

Coordinador general

Colaboradores Comunidad de desarrolladores del proyecto CIAA.

Orientadores Martín Ribelotta Emtech y Proyecto CIAA Desarrollador y

Co-Coordinador

Equipo Esp. Ing. Eric Pernia UNQ, FI-UBA y Proyecto

CIAA.

Docente-Investigador y

Coordinador general

Opositores Empresas que mantienen cautivos a sus clientes en su ecosistema

Usuario Final - Comunidad de usuarios y desarrolladores del proyecto CIAA.

- Programadores de Sistemas Embebidos.

Propósito del proyectoEl propósito de este proyecto es diseñar e implementar una biblioteca de software para la programación de sistemas embebidos basados en microcontroladores.

Se desea obtener una biblioteca modelada independientemente del lenguaje de programación y arquitectura del hardware.

Se definirá una interfaz de programación de aplicaciones (API) sencilla que abstraiga los modos de uso más comunes de los periféricos típicos que hallados en cualquier microcontrolador del mercado. De esta forma, es posible programarlos sin necesidad de conocer detalles sobre la arquitectura subyacente.

Propósito del proyecto

Este diseño promueve y permite la programación independiente del hardware, reduciendo la complejidad general del desarrollo de sistemas embebidos. Esta biblioteca se utilizará para programar las diferentes plataformas que componen el Proyecto Computadora Industrial Abierta Argentina (CIAA).

Requerimientos1. Fecha de entrega: 19/11/2018.2. Diseño de la biblioteca.

2.1. Realizar un diseño independiente del hardware y lenguaje de programación, teniendo en cuenta los conceptos familiares al programador de Sistemas Embebidos.

2.2. Debe estar modelada con objetos y contar con una descripción mediante diagramas UML.

2.3. Debe modelar al menos:2.3.1. CORE: un núcleo de procesamiento.2.3.2. GPIO: periférico que consiste en un único pin de entrada/salida de

propósito general (pin), así como un grupo de pines (port). 2.3.3. ADC: periférico conversor analógico-digital.

1. Fecha de entrega: 19/11/2018.2. Diseño de la biblioteca.




propósito general (pin), así como un grupo de pines (port). 2.3.3. ADC: periférico conversor analógico-digital.2.3.4. DAC: periférico conversor digital-analógico.2.3.5. TIMER: periférico temporizador.2.3.6. RTC: periférico reloj de tiempo real.2.3.7. UART: periférico de comunicación serial asincrónico.2.3.8. SPI: periférico interfaz serie sincrónica.2.3.9. I2C: periférico de comunicación serie entre circuitos integrados.

3. Implementación de la biblioteca.3.1. Utilizar un sistema de control de versiones con repositorios on line.3.2. Programar en lenguaje C la biblioteca para cada plataforma de hardware

particular utilizando como plantilla los archivos generados.3.3. Desarrollar ejemplos de utilización para las diferentes plataformas.

Requerimientos

1. Fecha de entrega: 19/11/2018.2. Diseño de la biblioteca.




propósito general (pin), así como un grupo de pines (port). 2.3.3. ADC: periférico conversor analógico-digital.2.3.4. DAC: periférico conversor digital-analógico.2.3.5. TIMER: periférico temporizador.2.3.6. RTC: periférico reloj de tiempo real.2.3.7. UART: periférico de comunicación serial asincrónico.2.3.8. SPI: periférico interfaz serie sincrónica.2.3.9. I2C: periférico de comunicación serie entre circuitos integrados.

3. Implementación de la biblioteca.3.1. Utilizar un sistema de control de versiones con repositorios on line.3.2. Programar en lenguaje C la biblioteca para cada plataforma de hardware

particular utilizando como plantilla los archivos generados.3.3. Desarrollar ejemplos de utilización para las diferentes plataformas.

4. Documentación y difusión4.1. Realizar un informe final de proyecto.4.2. Confeccionar un manual de referencia de la API de la biblioteca.4.3. Desarrollar un tutorial de instalación de las herramientas para utilizar la

biblioteca con las plataformas de hardware citadas.4.4. Publicación on line del código fuente.4.5. Informar a la comunidad del Proyecto CIAA y a la comunidad de

programadores de Sistemas Embebidos.

Requerimientos

Diagrama de Activity On Node



Diagrama de Gantt

Diagrama de Gantt

Diagrama de GanttDiagrama de Gantt (gráfico), parte 1 de 7:







Matriz de uso de recursos de materiales

Recursos requeridos (horas)

Puesto de trabajo

(incluye el lugar físico,

escritorio con PC y

comodidades básicas)

Plata-forma de hardware CIAA-NXP

Plata-forma de hardware EDU-CIAA-

NXP

Plata-forma

de hard-ware CIAA-Z3R0

Plata-forma

de hardwar

e PicoCIAA

Perifé-ricos para

conectar a las plata-

formas

Analizador lógico con software para el

análisis de protocolos

Total de horas por recurso

600 27 47 49 53 32 32

Presupuesto del proyecto

Categoría Detalle Costo

Costos directosIng. Eric Pernia. 600 horas de trabajo a $250 la

hora.$150.000,00

Costos indirectos Estimados como el 60% de los costos directos $90.000,00

Reserva para

contingencia

Estimados como el 15% de la suma de los costos

directos y los costos indirectos.$36.000,00

Total $276.000,00

Asignación de responsabilidades

Tanto la responsabilidad como la autoridad en este proyecto son atribuidas al Responsable del proyecto, ya que se trata de un trabajo final de Maestría individual. Puede darse el caso de recibir colaboraciones de la comunidad del Proyecto CIAA pero bajo ninguna circunstancia se le asignará responsabilidad al posible colaborador.

Los reportes de avance semanales serán informados al Director del Trabajo Final, y supeditados a su aprobación. También serán remitidos al colaborador para recibir posibles sugerencias.

Asignación de responsabilidades

Por otra parte el Director podrá solicitar informes de avance bimestrales para ser entregados al Jurado de este trabajo ya que también cumplen el rol de consultores y deberán expedirse sobre dichos informes, manifestando sus sugerencias y críticas al avance de las tareas.

Gestión de riesgos

Riesgo 1: Se rompe, pierde o roban alguna de las plataformas de hardware, o la PC de desarrollo.

Riesgo 2: Horas de trabajo planificadas insuficientes para alcanzar el deadline.

Riesgo 3: Requerimientos no cumplidos.

Riesgo 4: No se dispone del puesto de trabajo.

Riesgo 5: Problemas de índole personal del único desarrollador que retrasen el tiempo de desarrollo.

Gestión de riesgos

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 10 6 60 3 6 18

2 10 3 30 4 3 12

3 10 2 20 8 2 16

4 6 3 18 - - -

5 8 2 16 - - -

Gestión de riesgos

Criterio adoptado: El RPN tolerable es de 18.

Mitigación de Riesgo 1: Se reemplazará el equipo roto por uno nuevo a cargo del Responsable del trabajo.

Mitigación de Riesgo 2: Se trabajarán más horas a cargo del Responsable.

Mitigación de Riesgo 3: Se trabajarán más horas a cargo del Responsable.

Gestión de la calidad

Para asegurar la calidad requerida por un proyecto de estas características se han asignado tareas específicas de Verificación y Validación (V&V):

Verificación de las tareas del grupo 2, "Diseño de la biblioteca"

Al concluir las tareas del diseño del modelo computacional de la biblioteca del grupo de tareas 2.1 a 2.5 se propone la tarea:

2.6 Verificación del modelo (8 hs.).


Para la verificación del archivo de descripción de la biblioteca en un formato independiente del lenguaje de programación (2.7) se propone la tarea:

2.8. Verificación del archivo de descripción (4 hs.).

De esta manera se abarca la verificación de todas las tareas del grupo 2.

Verificación de las tareas del grupo 3, "Implementación de la biblioteca"

Para la verificación de todas las tareas de implementación se propone la tarea:


3.4. Verificación del funcionamiento de cada periférico en cada una de las plataformas (8 hs.).

Validación

Para la validación se incluye la tarea del grupo 4 (Validación):

4.1. Realización de ejemplos funcionales para cada periférico mediante ejemplos funcionales (30 hs.).

que será evaluada por el Director de trabajo final. Además se incluye la tarea del grupo 5:


5.6. Evaluar el cumplimiento de requerimientos (3 hs.).

también evaluada por el Director de trabajo final.

La calidad del software y firmware resultantes del proyecto estarán determinadas por el seguimiento del cumplimiento de los requerimientos funcionales propuestos en 4.

Finalmente, cabe destacar que La documentación a generar influirá mucho en la adopción de la biblioteca por parte de la comunidad de usuarios.

Comunicación del proyectoLa comunicación entre el Director de Trabajo Final y Responsable se realizará personalmente en reuniones semanales debido a que el proyecto cuenta únicamente con un único desarrollador.

Se consultará al colaborador vía correo electrónico, o hangouts, ya sea utilizando el chat o por videollamada ya que se encuentra a gran distancia.

Podrán solicitarse reuniones extraordinarias en forma presencial o vía videoconferencia. No se informará a terceros de los avances hasta finalizar con las tareas de documentación y publicación.

Una vez aprobada la entrega se comenzará con las actividades de difusión que forman parte del proyecto.

Seguimiento y control

Se realizarán reuniones semanales entre Director del Trabajo Final y el Responsable, en ellas se incluirán reportes de avance, supeditados a la aprobación del Director. Además se comparará el proyecto con el cronograma para actuar en consecuencia. Se asignarán más horas del Responsable (en caso de ser necesarias) para cumplir con la fecha de entrega. Se comparará el diagrama de Gantt propuesto con el estado actual del proyecto corrigiéndolo de ser necesario. Los informes de avance serán remitidos también al colaborador para recibir posibles sugerencias.

Seguimiento y control

Por otra parte el Director de la Carrera podrá solicitar informes de avance bimestrales para ser entregados al Jurado de este trabajo ya que también cumplen el rol de consultores y deberán expedirse sobre dichos informes, manifestando sus sugerencias y críticas al avance de las tareas.

Procesos de cierre

Se realizará una reunión final de evaluación del proyecto para obtener la aprobación formal por parte del director del proyecto. En esta reunión se llevarán a cabo las siguientes tareas:

Se analizará el grado de cumplimiento de los requerimientos del proyecto.

Se contrastará el cronograma propuesto con el cronograma real para verificar si las tareas fueron realizadas en el tiempo esperado. De esta forma se identificarán las tareas cuya duración ha sido mal estimada y las causas, para generar un informe final del proyecto que servirá como experiencia para los futuros.

Procesos de cierre

Se archivará toda la documentación de la gestión del proyecto para ser fácilmente reutilizada en la planificación de futuros proyectos.

Se propondrán proyectos derivados sujetos a aprobación, y además; nuevos proyectos pertenecientes al área de los sistemas embebidos en la UNQ para que el responsable pueda continuar sus labores de investigación.

El responsable del proyecto se encargará de los gastos de la reunión.

Muchas Gracias por su atención

¿Preguntas?

Documents

sAPI (simpleAPI): diseño e implementación de unalaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final...Realizar un informe final de proyecto. 4.2. Confeccionar un manual de referencia