Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
Carrera de Especialización en Sistemas Embebidos
Trabajo Final
Extensión del sistema operativo FreeOSEK a un multiprocesador
asimétrico
Plan de Trabajo Ing. Pablo Ridolfi Septiembre de 2015
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
Índice
Índice Project Charter Propósito Objetivos y Alcance Identificación de Stakeholders Requerimientos Factibilidad técnica
Contexto y Justificación Criterio de aceptación Restricciones Suposiciones
Factibilidad económicofinanciera WBS Diagrama de Gantt Recursos materiales y presupuesto
Presupuesto Gestión de Riesgos Gestión de la Calidad
Calidad y Grado de Calidad Costos de Conformidad y de No Conformidad
Costos de Conformidad Costos de No Conformidad
Verificación y Validación Plan de Comunicación
Elementos que garantizarán una comunicación efectiva Responsables de la comunicación Audiencia Medios de comunicación
Gestión de Recursos Humanos Autoridad y Responsabilidad Micromanagement
Gestión de Compras y Statement of Work Plan de compras Statement of Work
Control y Seguimiento Proceso de Cierre
2 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
1. Project Charter
Atención Coordinadores y Sponsors del Proyecto CIAA
Buenos Aires, 1 de Agosto de 2015 De mi consideración:
Con el fin de comenzar los trabajos de investigación, análisis de requerimientos, diseño e implementación del sistema operativo en tiempo real OSEKOS para el multiprocesador asimétrico disponible en los modelos CIAANXP y EDUCIAANXP, se asigna este proyecto al ingeniero Pablo O. Ridolfi, quien actuará como gerente del proyecto y de quien se espera que al momento de la fecha de finalización prevista para el 31 de Diciembre de 2015 entregue los archivos de código fuente y documentación asociada.
En principio no se solicitará aporte económico alguno salvo que sea necesario, en cuyo caso se realizará una solicitud a los sponsors del proyecto, ya que el hardware necesario para la implementación fue provisto oportunamente. El recurso principal a emplear consistirá en horas de trabajo de los miembros del equipo, que se estima en 100 horas mensuales (aproximadamente 500 horas en total).
Sin otro particular, saluda atentamente,
Dr. Ing. Ariel Lutenberg Coordinador General
Proyecto CIAA
2. Propósito
El propósito de este proyecto es mejorar la implementación actual del sistema operativo OSEKOS disponible en el Firmware de la CIAA. Los modelos basados en el microcontrolador LPC4337 (CIAANXP y EDUCIAANXP) disponen de un multiprocesador asimétrico (CortexM4 + CortexM0). Actualmente se hace uso de uno de los procesadores, con lo cual se trabajará para que el usuario pueda hacer uso de los dos procesadores disponibles.
3 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
3. Objetivos y Alcance Objetivos:
Implementar la primer versión de CIAAFirmware y su RTOS FreeOSEK con soporte para multiprocesadores asimétricos.
Finalizar los entregables para el 31 de Noviembre de 2015, fecha considerada como deadline para la validación de la plataforma según el criterio de aceptación, para luego realizar la defensa del trabajo alrededor del 15 de Diciembre de 2015.
Alcances: Implementación específica para el microcontrolador LPC4337, presente en la CIAANXP y
EDUCIAANXP. Instancias independientes de FreeOSEK y stack POSIX en cada core del LPC4337. Mecanismo básico de comunicación entre instancias mediante el control de activación de
Tareas y Eventos de FreeOSEK.
4. Identificación de Stakeholders
Client: Comité de Evaluación de la Carrera de Especialización en Sistemas Embebidos. Sponsor: Sponsors del Proyecto CIAA (empresas e instituciones que colaboran con el
proyecto) y Pablo Ridolfi. EndUser: Desarrolladores y usuarios finales del Proyecto CIAA. Los usuarios finales son
quienes implementan la aplicación final de la CIAA, pueden o no formar parte del equipo de Desarrollo.
Champion: Responsable de Firmware del Proyecto CIAA. Drivers: Coordinadores y desarrolladores del Proyecto CIAA. Supporters: Desarrolladores del Proyecto CIAA. Project Manager: Pablo Ridolfi. Team members: No disponible. Trabajo de carácter individual.
5. Requerimientos
1. Deberá implementarse CIAAFirmware para CortexM0 (LPC4337) con test de conformidad aceptados, que funcionará en forma independiente de la implementación existente para CortexM4.
2. La implementación del CortexM4 dispondrá de una nueva funcionalidad que habilite al CortexM0 a ejecutar su instancia.
3. Ambas instancias de Firmware se compilarán en forma automática. 4. La API ActivateTask de ambas implementaciones será mejorada para permitir la activación
de tareas entre cores. 5. La API SetEvent de ambas implementaciones será mejorada para permitir la activación de
eventos entre cores. 6. La instancia en CortexM4 podrá detener su ejecución con el objetivo de disminuir el
consumo del sistema, dejando a la instancia de CortexM0 las tareas básicas de control y monitoreo de I/O. Esta última realizará un requerimiento a la primera para actividades de mayor complejidad, como el envío de datos a través del stack Modbus/RS485.
4 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
7. Se deberá mantener absoluta compatibilidad entre los modelos CIAANXP y EDUCIAANXP.
8. Los materiales necesarios son importados y difíciles de reemplazar en caso de rotura o falla. Deberá tenerse en cuenta un mecanismo de reemplazo y el tiempo que deberá transcurrir hasta que el repuesto esté disponible, considerando tiempo de entrega y restricciones de importación.
6. Factibilidad técnica
Contexto y Justificación Los modelos más utilizados de la Computadora Industrial Abierta Argentina, CIAANXP y
EDUCIAANXP están basados en el microcontrolador LPC4337 de la firma NXP. Este microcontrolador dualcore asimétrico incluye además del CortexM4F como core principal o “master”, un CortexM0 como procesador secundario o “slave” funcionando también a 204MHz.
La idea de disponer de un multiprocesador asimétrico está fuertemente relacionada con las diferentes características que cada procesador posee: El CortexM4 es un procesador de alta performance que permite implementar algoritmos extensos como stacks USB o TCP/IP con el menor tiempo de ejecución y ocupación de memoria. El CortexM0, por su parte, es un procesador de 32bits sencillo cuya principal característica es su reducido consumo. Ambos procesadores tienen acceso completo a los periféricos y memorias del sistema. En una aplicación donde es necesario disponer de ambas ventajas en simultáneo (bajo consumo y ejecución de algoritmos extensos y complejos) pueden dividirse las actividades a realizar entre dichos cores: mientras el M4 funciona solamente al momento de ejecutar los algoritmos mencionados, el M0 se encarga del monitoreo general del sistema (entrada/salida y periféricos de baja velocidad) y también de activar al M4 en caso de que sea necesario ejecutar un algoritmo complejo en el menor tiempo posible. De esta forma será posible reducir el consumo promedio del sistema.
Para que el usuario pueda disponer de esta versatilidad en el Firmware de la CIAA será necesario implementar una extensión del Sistema Operativo de Tiempo Real basado en el estándar OSEK (FreeOSEK) que soporte un sistema multiprocesador asimétrico como el mencionado. Es importante destacar que dicho estándar no contempla sistemas con más de un procesador, con lo cual la extensión no podrá encuadrarse en el mismo.
Criterio de aceptación El criterio de aceptación de este trabajo estará determinado por el grado de cumplimiento
de los requerimientos enumerados en la sección anterior.
Suposiciones Las horas de trabajo planificadas son suficientes para alcanzar el deadline. Se dispone de los materiales y los recursos necesarios para la construcción del prototipo
funcional. Se dispone de una EDUCIAANXP y de una CIAANXP. No ocurrirán eventos fortuitos ni de fuerza mayor que limiten la cantidad de horas
semanales asignadas a este proyecto.
5 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
7. Factibilidad económico-financiera Se trata de un proyecto de final de carrera, que se convertirá en una plataforma libre y
abierta, por lo tanto los recursos ya se han asignado y no existirá una tasa interna de retorno, al no existir ánimo de lucro.
8. WBS El WBS de este proyecto se ha elaborado en función de sus entregables:
Extensión de OSEKOS a un multiprocesador asimétrico 1. Implementación del port de FreeOSEK a CortexM0.
1.1. Definición de arquitectura. 1.2. Implementación de las rutinas de cambio de contexto. 1.3. Adaptación de los tests de conformidad.
2. Adaptación de CIAAFirmware a CortexM0. 2.1. Definición de bibliotecas y tipos de datos estáticos. 2.2. Implementación del driver Dio.
3. Implementación del módulo ciaaMulticore, que provea una API interna de IPC (InterProcess Communication) para el kernel de FreeOSEK. 3.1. Implementación de comandos para activación interprocesador de Tareas. 3.2. Implementación de comandos para activación interprocesador de Eventos.
4. Extensión del programa generador de FreeOSEK con el objetivo de generar imágenes separadas del RTOS para cada procesador.
5. Extensión de la API ActivateTask. 6. Extensión de la API SetEvent. 7. Implementación de los tests funcionales. 8. Documentación general de la extensión.
6 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
9. Diagrama de Gantt Dada la limitación en recursos disponibles para el desarrollo de este proyecto, no es
posible paralelizar ciertas tareas. Por lo tanto el diagrama de Gantt real del proyecto será el siguiente, adaptado para que trabaje el alumno del curso, con ayuda ocasional de un colaborador:
7 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
10. Recursos materiales y presupuesto Durante todo el desarrollo del proyecto será necesario disponer de una PC para desarrollo
y una EDUCIAANXP y/o CIAANXP. Ninguno de los recursos mencionados es crítico, con lo cual no resulta necesario realizar un análisis de disponibilidad de los mismos.
Presupuesto
Categoría Detalle Costo
Trabajo Directo PR: 145 días, $500. por día. $72500.
Costos Indirectos 60% de los Costos Directos $43500.
Reserva para Contingencia 15% CD+CI $17400.
Total $133400.
11. Gestión de Riesgos Ver Anexo I.
12. Gestión de la Calidad
Calidad y Grado de Calidad La calidad de este proyecto estará determinada por el nivel de cumplimiento de los
requerimientos funcionales definidos oportunamente. El Trabajo será aceptado al determinarse que la totalidad de los requerimientos son cumplidos.
El grado de calidad, en cambio, debería obtenerse mediante una comparación entre la extensión multicore de FreeOSEK y una plataforma de requerimientos similares. Sin embargo, al no existir otra plataforma similar, en esta etapa el grado de calidad se determinará en la etapa de validación. En la segunda etapa del Proyecto (correspondiente a la Maestría) se podrá analizar si existió un incremento en el grado de calidad de la plataforma desarrollada, comparándola con los resultados obtenidos en la presente etapa.
13. Costos de Conformidad y de No Conformidad
Costos de Conformidad Entrenamiento en técnicas de testing de software. Tiempo invertido en diseñar las plataformas de testing.
Costos de No Conformidad Bug de hardware en el microcontrolador LPC4337. Fallas de diseño en la API:
Debe rediseñarse la API de usuario por no cumplir los requerimientos. Retraso en la fecha de release puede provocar desilusión entre los potenciales
usuarios de la plataforma.
8 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
14. Verificación y Validación En este proyecto la V&V será clave:
Existen etapas de verificación bien definidas en el plan de proyecto: 1.3. Adaptación de los test de conformidad. 7. Implementación de test funcionales.
Las etapas de validación serán llevadas a cabo por los eventuales usuarios de la plataforma, de quienes se espera recibir comentarios para realizar mejoras posteriores.
15. Plan de Comunicación
Elementos que garantizarán una comunicación efectiva En orden de importancia:
Reuniones personales con los colaboradores así como los clientes del proyecto. Frecuencia: Mensual.
Correos electrónicos, informando avances o solicitando entregables. Frecuencia: La que sea necesaria, sin superar un correo diario.
Documentación general, contemplada dentro del plan de proyecto, que luego será publicada: Frecuencia: Primer versión al finalizar los entregables del trabajo, luego se actualizará conforme se implementa nueva funcionalidad.
Sitio web del Proyecto CIAA, donde se dejará asentada dicha documentación, así como la funcionalidad actual, futura y posibles issues (“bugs” o problemas detectados) que tenga la plataforma. Frecuencia: Hito único en principio, pero se revisará con cada release de la plataforma con el fin de mantener la documentación pública actualizada.
Responsables de la comunicación En este proyecto el responsable de la comunicación será el Project Manager respecto a
reuniones, correos electrónicos y documentación, con eventual asistencia de los mantenedores del sitio web del proyecto CIAA a la hora de publicar resultados y actualizar dicha documentación.
Audiencia Para las reuniones: PM, colaboradores, equipo de desarrollo del Proyecto CIAA. Para los correos electrónicos, documentación y sitio web: Comunidad de Sistemas
Embebidos en general.
Medios de comunicación Principalmente a través de Internet mediante páginas web, correo electrónico y
videollamadas.
9 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
16. Gestión de Recursos Humanos
Autoridad y Responsabilidad Tanto la responsabilidad como la autoridad en este proyecto son atribuidas al PM, ya que
se trata de un trabajo final de carácter individual. A lo sumo podrán delegarse tareas en algún eventual colaborador, pero la responsabilidad por el cumplimiento de las mismas no será transferible a dicho colaborador. Si este determina que puede optimizar el resultado de la tarea que se le asigna valiéndose de más personas, se evaluará la posibilidad de delegarle un grado de autoridad acorde a la tarea para facilitar el trabajo en equipo.
Micromanagement Dado el grado de avance actual del proyecto, la posibilidad de que exista micro
management es muy remota dado que al momento sólo el alumno ha trabajando en las diferentes tareas.
17. Gestión de Compras y Statement of Work
Plan de compras En el caso de este proyecto todos los materiales están disponibles y no es necesario realizar un plan de compras. De todas formas, a modo de plan de contingencia, se evaluará la compra de dichos materiales y sus escenarios probables.
EDUCIAANXP: la única vía de compra es a través de la ACSE o Electrocomponentes. De todas formas existen unidades disponibles que pueden pedirse prestadas para continuar el trabajo final.
Statement of Work Ejemplo para solicitud de una EDUCIAANXP:
Ciudad de Buenos Aires, 1 de Junio de 2015
Sres. ACSE/Electrocomponentes S.A.:
Mediante la presente se solicita una (1) unidad EDU-CIAA-NXP, bajo las siguientes condiciones:
- Costo: $600.- (seiscientos pesos argentinos) - Modalidad de pago: Contado. - Plazo de entrega: inmediato. - Lugar de entrega: Oficinas de Electrocomponentes S.A. en CABA. - Garantía: El equipo se entrega debidamente testeado y funcionando, no existiendo
reclamos por fallos detectados luego de la entrega. Firma Proveedor Firma Gerente de Compras
10 de 11
Plan de trabajo: Extensión de FreeOSEK a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
18. Control y Seguimiento
a. Los días Lunes, al comienzo de cada semana, se evaluará el estado de avance contrastando la situación actual con el diagrama de Gantt y el análisis de Riesgos.
i. En caso de estar adelantado, se proseguirá normalmente, buscando la posibilidad de adelantar tareas posteriores.
ii. En caso de estar atrasado, se asignará mayor carga horaria al desarrollo del proyecto (Riesgo 1).
iii. Se analizará el cumplimiento parcial de los requerimientos. Si se observa un desvío significativo (Riesgo 2), se aplicarán las acciones correctivas correspondientes.
b. En caso de designar colaboradores, se llevarán a cabo reuniones semanales para seguir el avance de las tareas delegadas, siguiendo un criterio similar al punto anterior.
19. Proceso de Cierre
a. Se hará un análisis preliminar que determinará el grado de cumplimiento de los requerimientos. Si es satisfactorio, se continuará con el punto siguiente.
b. Se llevará a cabo en forma interna el Plan de Validación, siguiendo el Criterio de Aceptación. Si es satisfactorio, se continuará con el punto siguiente.
c. Se procederá a la publicación de la documentación generada para el uso de la plataforma. d. Se llevará a cabo el Plan de Validación siguiendo el Criterio de Aceptación en presencia de
los stakeholders, principalmente los Clients, Sponsors, EndUsers y Champions, quienes evaluarán y eventualmente aprobarán los resultados del proyecto.
11 de 11
Plan de trabajo: Extensión de OSEKOS a un multiprocesador asimétrico
Alumno: Pablo Ridolfi
Anexo I - Gestión de Riesgos ID Riesgo Descripción O S D RPN Acción correctiva O S D RPN 1
1 Tiempo insuficiente No se dispondrá de tiempo suficiente para finalizar los entregables en Diciembre de 2015.
5 10 5 250 Reorganizar agenda. Priorizar actividades relacionadas con la CESE y MSE.
2 10 2 40 ↓84%
2 Requerimientos no cumplidos
Los entregables no satisfacen los requerimientos total o parcialmente.
7 10 2 140 Implementar adecuadamente la plataforma de testing funcional y etapas de V&V.
4 5 1 20 ↓86%
3 Documentación insuficiente No se puede acceder a documentación necesaria para el avance del desarrollo.
4 8 3 96 Consultar a desarrolladores. 2 8 1 16 ↓83%
Utilizar una plataforma mejor documentada.
2 4 1 8 ↓92%
4 Bug de hardware en LPC4337
Existe un bug en el microcontrolador que dificulta o impide la comunicación entre los procesadores.
3 7 3 90 Utilizar una revisión del microcontrolador con el bug corregido.
3 5 2 30 ↓67%
5 Falla EDUCIAANXP Cualquier fallo en este hardware es crítico para el cumplimiento de los requerimientos.
4 8 2 64 Obtener otra EDUCIAANXP. 2 4 2 16 ↓75%
Ocurrencia: 1 (muy baja) a 10 (muy alta). Severidad: 1 (muy baja) a 10 (muy alta). Detectabilidad: 1 (muy alta) a 10 (muy baja).
1 Además del RPN calculado luego de la acción correctiva, se indica el porcentaje de disminución del RPN respecto al riesgo original (sin acción correctiva).
1 de 1