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ómico­financiera 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 OSEK­OS para el                         multiprocesador asimétrico disponible en los modelos CIAA­NXP y EDU­CIAA­NXP, 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                         OSEK­OS disponible en el Firmware de la CIAA. Los modelos basados en el microcontrolador                           LPC4337 (CIAA­NXP y EDU­CIAA­NXP) disponen de un multiprocesador asimétrico (Cortex­M4 +                     Cortex­M0). 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 CIAA­Firmware 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 CIAA­NXP y                     

EDU­CIAA­NXP. ­ 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. ­ End­User: 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 CIAA­Firmware para Cortex­M0 (LPC4337) con test de conformidad aceptados, que funcionará en forma independiente de la implementación existente para Cortex­M4. 

2. La implementación del Cortex­M4 dispondrá de una nueva funcionalidad que habilite al Cortex­M0 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 Cortex­M4 podrá detener su ejecución con el objetivo de disminuir el 

consumo del sistema, dejando a la instancia de Cortex­M0 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 CIAA­NXP y EDU­CIAA­NXP. 

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, CIAA­NXP y                       

EDU­CIAA­NXP están basados en el microcontrolador LPC4337 de la firma NXP. Este                       microcontrolador dual­core asimétrico incluye además del Cortex­M4F como core principal o                     “master”, un Cortex­M0 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 Cortex­M4 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 Cortex­M0, por su parte, es un procesador                               de 32­bits 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 EDU­CIAA­NXP y de una CIAA­NXP. ­ 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 OSEK­OS a un multiprocesador asimétrico 1. Implementación del port de FreeOSEK a Cortex­M0. 

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 CIAA­Firmware a Cortex­M0. 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 inter­procesador de Tareas. 3.2. Implementación de comandos para activación inter­procesador 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 EDU­CIAA­NXP y/o CIAA­NXP. 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. 

­ EDU­CIAA­NXP: 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 EDU­CIAA­NXP: 

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, End­Users y Champions, quienes                   evaluarán y eventualmente aprobarán los resultados del proyecto. 

   

 

11 de 11 

 Plan de trabajo: Extensión de OSEK­OS 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 EDU­CIAA­NXP  Cualquier fallo en este hardware es crítico para el cumplimiento de los requerimientos. 

4  8  2  64  Obtener otra EDU­CIAA­NXP.  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