Resumen de la reunión de integrantes del proyecto

[Pablo Ridolfi]

Hola, disculpen la demora. Les paso un resumen de lo que hablamos el viernes pasado. La verdad que fue una reunión muy productiva y positiva. Ojalá para todos ustedes haya resultado igual :)

Voy a ir enumerando los temas y luego explicando el curso de acción que decidimos tomar. Por supuesto siéntanse libres de agregar lo que quieran ya que mis notas pueden estar incompletas.

Saludos a todos. ¡Felices fiestas!

Pablo

A) Servidores Jenkins Slave con CIAA conectada para tests remotos

Gerardo Sager (UNLP) y Santiago Maudet (UTN-FRBA) se encargarán de solicitar recursos para disponer de al menos un servidor en cada UA. Invitamos también a todos los integrantes de la red RUSE, copiados en este correo, a sumarse con servidores Jenkins, si desean implementarlo en sus UAs. Aquellos que deseen participar por favor escríbanme en privado.

B) Nombramiento del Responsable de Hardware del proyecto

Posiblemente Diego Brengi, Noelia Scotti y eventualmente Diego Alamón, que trabajan en el CMNB del INTI, asumirían el rol. Tengo que enviarles un documento con las atribuciones del Responsable de Hardware para que ellos puedan presentarlo a la Directora del Centro y evaluar la aceptación de la propuesta.

C) Organización y generación de la documentación oficial del proyecto

De esto se va a encargar Eric Pernia (UNQ) con ayuda de todos los que fuimos aportando contenido a la Wiki, que está muy desordenada. Eric evaluará otras plataformas como docbook y github.io para que podamos ofrecer a los usuarios de la CIAA todo lo necesario en un sitio centralizado.

D) CIAA-ACC

Noelia Scotti (CMNB-INTI) presentó esta nueva versión de la CIAA e hizo una exposición de sus características principales. Hablamos de la posibilidad de diseñar, en el futuro, una EDU-CIAA-ACC, de funcionalidad similar basada en Zynq, pero más económica. Resolvimos que primero se finalizará el diseño actual y luego en función de la disponibilidad de los recursos se evaluará continuar con otro diseño.

E) CIAA-Safety

El GSTR-UNRC (Gustavo Rodríguez, Manuel Amor, Diego Fusari y Martín Marcos), que participó en forma remota, expuso también las características generales de esta otra CIAA en desarrollo. A diferencia de los modelos actuales no se va a incluir el circuito de debug JTAG sino que deberá utilizarse uno externo, con el objetivo de reducir la cantidad de interfaces que deberían certificarse. Martín Ribelotta (Emtech) propuso la utilización de RTEMS para el firmware de esta CIAA. La CIAA-Safety al final no va a ser "stackeable" con la CIAA-ACC ya que el factor de forma de la segunda será PCIe-104 y el de la primera será PCI-104.

F) CIAA-Firmware: Utilización del estándar HIS para el I/O de periféricos.

En general hubo consenso para la utilización de este nuevo estándar presentado por Mariano Cerdeiro. Necesitamos colaboradores para realizar el porting. Juan Manuel Cruz se ofreció a aportar "horas de programación". Aquellos que deseen participar contactar a Mariano y a Juan. Se recomienda también sumarse a ciaa-f...@googlegroups.com y seguir estos hilos:

https://groups.google.com/forum/#!topic/ciaa-firmware/pDoK_nBefU4

https://groups.google.com/forum/#!topic/ciaa-firmware/t2UOGUx30Wk

G) EDU-CIAA-Xilinx

Pedro Martos (FIUBA), responsable de esta CIAA, me comentó que está en contacto con fabricantes locales de PCB con el objetivo de definir los lineamientos para la fabricación. @Pedro, si ya tenés el esquemático de esta CIAA sería genial que lo compartas :)

H) Uso de herramientas "non-free"

Concluimos que si la complejidad del diseño lo amerita y la institución dispone de todas las licencias que correspondan, no nos opondremos a la utilización de herramientas que no sean libres/open-source, aunque siempre buscaremos la manera de encarar los diseños usando el mayor porcentaje posible de herramientas libres y abiertas, con el fin de favorecer el trabajo colaborativo y en comunidad.

I) Posventa y reparación de EDU-CIAAs

Hasta ahora tuvimos solamente un caso conocido de una EDU-CIAA que aparentemente falló luego de ser utilizada. Sabemos que todas las EDU-CIAAs siempre se entregan testeadas y funcionando correctamente. Dado que se trata de un incidente aislado, desestimamos que se trate de una falla de fabricación, por lo cual las empresas e instituciones que intervinieron en el proceso de producción, venta y distribución no deberían hacerse cargo de la reparación.

[Pedro Martos]

Hola a tod@s,

El 22 de diciembre de 2015, 19:54, Pablo Ridolfi<pablor...@gmail.com> escribió:

G) EDU-CIAA-Xilinx

Pedro Martos (FIUBA), responsable de esta CIAA, me comentó que está en contacto con fabricantes locales de PCB con el objetivo de definir los lineamientos para la fabricación. @Pedro, si ya tenés el esquemático de esta CIAA sería genial que lo compartas :)

En la wiki esta el esquematico y BOM en pdf; y en el repositorio en github esta el proyecto kicad completo, junto con documentacion (datasheets y user guides) de los componentes =D 

cordialmente,

Pedro

 

--

cordiales saludos,

Pedro Ignacio Martos

pma...@fi.uba.ar / pima...@gmail.com

http://web.fi.uba.ar/~pmartos

[Pablo Ridolfi]

Gracias Pedro!

[Diego Salvador Fusari]

Hola como están? Los felicito por la reunión y por la forma de coordinar dicho evento dado que se pudo tratar en su totalidad los temas propuestos en tiempo y forma.

Con respecto al tema en el que estoy participando:

E) CIAA-Safety

El GSTR-UNRC (Gustavo Rodríguez, Manuel Amor, Diego Fusari y Martín Marcos), que participó en forma remota, expuso también las características generales de esta otra CIAA en desarrollo. A diferencia de los modelos actuales no se va a incluir el circuito de debug JTAG sino que deberá utilizarse uno externo, con el objetivo de reducir la cantidad de interfaces que deberían certificarse. Martín Ribelotta (Emtech) propuso la utilización de RTEMS para el firmware de esta CIAA. La CIAA-Safety al final no va a ser "stackeable" con la CIAA-ACC ya que el factor de forma de la segunda será PCIe-104 y el de la primera será PCI-104.

Una lastima la perdida de comunicación que hubo, en un momento se corto el video, las preguntas y las contra respuestas a este tema se escuchaban entre cortado! Una Lastima por que teníamos problemas de conexión con nuestro wifi local! Cuando retorno la comunicación ya estaban hablando de la EDU CIAA. De todas maneras estuvo muy bien! 

Quisiera agregar lo siguiente. Las conexión entre ambas CIAA ACC-Safety no se van a poder comunicar a través de sus correspondientes buses (PCI - PCIe) Debido a que ambos grupos decidimos trabajar con el mismo factor de forma pero con diferentes variedades de bus. Lo que no quita que pueden ser parte del mismo cluster de placas dado que disponen del mismo diseño físico. Su comunicación puede ser a través de algún bus de comunicación de alta velocidad. Ethernet o USB por ejemplo! Hasta pueden compartir la misma fuente de alimentación si contempla ambos conectores como lo describe el modelo PSG011 de 

http://www.connecttech.com/sub/Products/Xtreme-PSU-XP-Power-Supply.asp?l1=PSU

Cabe aclarar como lo hemos mencionado en algún momento (Wiki) que en un futuro es fabricar también la propia fuente!

Por otro lado en estos momentos y después de realizar el curso de Kicad estoy completando el diagrama jerárquico del modulo procesador Safety. En cuanto lo termine lo voy a colgar a la red (CIAA-Hardware) para que tratemos de consensuar esta base de referencia. Es por eso que nuestra intención es comprometer a alguien para que cumpla con la función de "Revisor" o "Revisores". Lo bueno del curso de Kicad, es que conocimos algunos compañeros que se interesaron en participar. Tengo todos las direcciones de email de ellos así que en cualquier momento los voy a invitar a participar. También M. Ribelota nos tiro unos tics así que de seguro le vamos a pedir si nos tira una mano en algún momento al igual que los compañeros del INTI (Hola...! :-)). Muy Buenos profes y el curso de Kicad fue muy completo es por eso que es super recomendable!!! :)

Quedaría definir los responsables y colaboradores de los diferentes temas a tratar en la CIAA Safety. Ejemplo: Requerimientos, estudios de normas de Certificación de los diferentes perfiles que puede tener la CIAA Safety, en Hardware, firmware, Drivers, etc. (Esto quedo por nuestra parte en deuda en la charla del pasado Viernes 18) como así también del Roadmap 2016. Estos temas ya lo hemos charlado en Río Cuarto. Gustavo lo tiene mas claro dado que el estaba tratando el tema.  

Con respecto al firmware en el ambiente aeronáutico se esta utilizando ADA. Lo comento y lo dejo ahí por que no es mi tema pero desde acá los compañeros trabajan con ese lenguaje y por lo que tengo entendido Ada se utiliza en aquellos entornos donde se necesita una gran seguridad y fiabilidad. Ejemplo: Sistemas de defensa, aeronáutica, gestión de trafico aéreo, industria aeroespacial, etc.

Bueno! desde ya los saludo a todos felices fiestas y permanecemos en contacto!!! Un gran abrazo!!!

Diego!.

Gracias Pedro!

--
Has recibido este mensaje porque estás suscrito al grupo "CIAA-Hardware" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ciaa-hardwar...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Mariano Cerdeiro]

Hola Diego,

en la industria aeronautica se utiliza Ada por un tema historico, seria muy caro portar todo a c por ejemplo. En la industria automotriz se adopto C90 y el Ada no existe. No se que se usa en trenes y en industria critica como plantas nucleres pero el iec no especifica ningun lenguaje especifico. si a su utilizacion pero no al lenguaje en si. A mi entender se puede usar cualquier lenguaje de programacion.

Saludos
Mariano.

Has recibido este mensaje porque estás suscrito al grupo "CIAA-Linux" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ciaa-linux+...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a ciaa-...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ciaa-linux/CAPw8p2EHermp7%2BKr5BH-qXU9ZJFvxwWvz1_0qMTd8eX97AVpDQ%40mail.gmail.com.

[Ariel Lutenberg]

Mariano,
Estoy de acuerdo con vos respecto a que en principio se puede usar cualquier lenguaje de programación, pero vale mencionar que existen lenguajes que en principio son mas seguros que otros, como por ejemplo Rust:
- https://www.rust-lang.org/
- "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety."

Esteban Volentini seguramente les podrá contar más al respecto, ya que estamos estudiando esto en el marco de su posible doctorado.

Saludos,
Ariel.

Has recibido este mensaje porque estás suscrito al grupo "CIAA-Software" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ciaa-softwar...@googlegroups.com.

[Ariel Lutenberg]

Muy bueno el resumen Diego!

Me queda una duda sobre el siguiente párrafo:
- "Las conexión entre ambas CIAA ACC-Safety no se van a poder comunicar a través de sus correspondientes buses (PCI - PCIe) Debido a que ambos grupos decidimos trabajar con el mismo factor de forma pero con diferentes variedades de bus."

¿Hay razones técnicas para que cada grupo haya optado por una interfaz diferente o son cuestiones de gusto personal?

Pregunto porque me parece que estaría bueno que ambas placas se puedan intercomunicar a alta velocidad mediante una interfaz confiable.

Abrazos,
Ariel.

[Mariano Cerdeiro]

Hola Ariel,

si fuera por lo seguro de un lenguaje deberia estar PROHIBIDO usar C en safety. hehe :)

Vamos a lo concreto:
Tabla A.3. del estándar:
Suitable programming language
Strongly typed programming language.
Language subset

En ningun lado habla de que el lenguaje en si mismo sea seguro. No se de rust pero parece que no es strongly typed lo cual para safety es un problema.

Igual ojo el estandar solo recomienda.

Saludos
Mariano

[Ariel Lutenberg]

Interesante!
Me parece que este tipo de cosas son las que debería estudiar Esteban en su doctorado, así que quedo atento a lo que él tenga para decir.

Por otra parte, es interesante ver que en general en las carreras de ingeniería electrónica en la Argentina este asunto esta a años luz siquiera de ser mencionado...

Abrazos,
Ariel.

[Mariano Cerdeiro]

Hola Ariel y Esteban,

solo mirando en las tablas de
http://www.cechina.cn/eletter/standard/safety/iec61508-3.pdf de la página 38 en adelante uno se da una idea de que y como se debe programar.

Defensive programming
Structured programming
Functional and black box testing
Interface testing
Static analysis
Software complexity metrics
Use of coding standard
No dynamic objects
No dynamic variables
Limited use of interrupts
Limited use of pointers
Limited use of recursion

No unconditional jumps in programs in higher

level languages

Test case execution from boundary value

analysis
Test case execution from error guessing

hay más, pero solo copie alguno de los nombres. La mayoria son HR ya para SIL3, muchos ya en SIl1 son HR.

Saludos.

Mariano.-

[Ariel Lutenberg]

Excelente Mariano!
Muchas gracias!
Lo vamos a mirar.
Abrazos.