Hi all,
please find attached the decks that I presented at the AGL meeting. They contain a high-kevel summary of the information I was exposed to in the last few months. I had excellent attendance (+100) for both
talks at the AGL meeting.
In the last 2 weeks a number of interesting possibilities arose:
- AGL is currently looking at defining reference stack that includes the Xen Hypervisor. Whether this will be agreed by the AGL board is still open. If
this happens it may be possible that Suzuki or Toyota may get engaged with Xen.
- There is also
https://dornerworks.com/blog/high-performance-space-computing-platform-nasa-sbir which may help our efforts. I had conversations with DornerWorks and StarLabs regarding engagement with the SIG: each will have internal discussions and get back to me. In
a nutshell, what the article proposes is similar to the idea of the AGL reference stack, for a different market segment. And in some sense, we do also already have a reference stack for automotive (EPAM) and a more generic one from XILINX.
- There will also be an ELISA Project workshop (https://elisa.tech/)in Cambridge
UK, in September, which I hope I will be able to attend. This may provide an opportunity to help with elements of the certification story
@Kate: would it be possible to have a quick chat about the meeting and how it would be possible to engage with ELISA? I would like to discuss the at the next SIG meeting or maybe via a 1-2-1 this week - I also had several positive conversations with
Anas Nashif from the Zephyr project, who are facing similar challenges around tooling and process compared to us. Their current goal is to procure licenses for commercial tools to deal with Misra checking, requirements
management, traceability, etc. – However, I don’t think this would work for Xen
At the developer summit we agreed to complete the implementation of the first phase changes to our CI infrastructure and agreed some second phase goals. If implemented in time, this would enable a git centric
workflow assisted by bots at various stages of development.
The open question is whether Misra checking tools, requirements management and traceability functionality can be seamlessly integrated into such a workflow. Proprietary compilers most certainly can, if licensing
can be resolved.
If they can, most community issues that may arise from functional safety, would be significantly more manageable. What would be left fundamentally comes down to community scaling (not a new problem) and funding
activities.
E.g. for Misra checking it would be necessary to trigger an incremental check from a CI system, and pipe the results (again a delta) back into the development workflow for a bot to process and to be sent back
to developers. I don’t believe that QA Verify as it is today could fit into such a model: the same may be true for many other tools.
In any case, we should discuss at the next SIG meeting
Best Regards
Lars
