Title: Maintain ELISA example system
Proposal: The idea is to provide a CI maintained example system with Xen and Zephyr along Linux to serve a a blueprint for other projects. It could e.g. be based on AGL SoDeV, but requires a separate maintainer who integrates ELISA deliverables into the system. Examples are Basil, VMA PoC, Requirements Sidecar.
How it supports ELISA: The Railways SIG already asked, if they can base their work on the example system of the systems WG, but it is currently not properly maintained. The Automotive WG can derive their ADAS stack based on AGL SoDeV in an own flavor. Another benefit would be potentially with Aerospace WG or meta-sgl (but this would need more claritication). The tools WG can demonstrate the tools capabilities and the Linux Features WG can incorporate their results into the system. Overall ELISA in this way would have something to refer to for community members and people who want to get in touch and experience ELISA deliverables.
Tangible deliverables: We can deliver safety concepts and elements at e.g. Automotive Linux Summit or have a stand at embedded world AGL booth during embedded world as a showcase. Additionally, you can have a download based on a daily builds (of course including the SBOM) on qemu and an arm based reference hardware (Renesas, Raspberry Pi, Qualcomm, ..). This is in best case in line with the latest AGL release, but also could be an AutoSD flavor in parallel or instead. It includes examples of requirements tracing, some small "tools" to work with the linux kernel and represent results like the safety monitor from automotive WG.
What's preventing progress: Lack of contributors, Lack of technical expertise, Lack of funding
Being worked on by other project/community: It is not worked on directly by other projects, but we may benefit from a close relationship to AGL SoDeV. This may avoid duplicated efforts and potential deviation.
Funding: In best case we fund someone between 40% and 80% of time for the initial phase of 2-3 month and move on to maintenance of 20%. The estimated budget on low cost location (or part time consulting) is expected to be 50%
If not pursued, what opportunities/benefits/capabilities will be lost: Deliverables are not visible to the wider community outside ELISA. We miss to benefit from the current hype on AGL SoDeV and Eclipse S-CORE which give SDVs and safety-criticality a recent momentum. Additionally, we cannot demonstrate ELISA capabilities at Workshops and Conferences. We would miss the opportunity to show more technical credibility of the project. Without the funding we would remain in the status in which we are already. If we would have taken this step more seriously earlier, maybe it would have been ELISA SoDeV and not AGL SoDeV. (Still the place is good to lower our efforts and join forces in the way it is now set up.)
Title: Maintain ELISA example system
Proposal: The idea is to provide a CI maintained example system with Xen and Zephyr along Linux to serve a a blueprint for other projects. It could e.g. be based on AGL SoDeV, but requires a separate maintainer who integrates ELISA deliverables into the system. Examples are Basil, VMA PoC, Requirements Sidecar.
How it supports ELISA: The Railways SIG already asked, if they can base their work on the example system of the systems WG, but it is currently not properly maintained. The Automotive WG can derive their ADAS stack based on AGL SoDeV in an own flavor. Another benefit would be potentially with Aerospace WG or meta-sgl (but this would need more claritication). The tools WG can demonstrate the tools capabilities and the Linux Features WG can incorporate their results into the system. Overall ELISA in this way would have something to refer to for community members and people who want to get in touch and experience ELISA deliverables.
Tangible deliverables: We can deliver safety concepts and elements at e.g. Automotive Linux Summit or have a stand at embedded world AGL booth during embedded world as a showcase. Additionally, you can have a download based on a daily builds (of course including the SBOM) on qemu and an arm based reference hardware (Renesas, Raspberry Pi, Qualcomm, ..). This is in best case in line with the latest AGL release, but also could be an AutoSD flavor in parallel or instead. It includes examples of requirements tracing, some small "tools" to work with the linux kernel and represent results like the safety monitor from automotive WG.
What's preventing progress: Lack of contributors, Lack of technical expertise, Lack of funding
Being worked on by other project/community: It is not worked on directly by other projects, but we may benefit from a close relationship to AGL SoDeV. This may avoid duplicated efforts and potential deviation.
Funding: In best case we fund someone between 40% and 80% of time for the initial phase of 2-3 month and move on to maintenance of 20%. The estimated budget on low cost location (or part time consulting) is expected to be 50%
If not pursued, what opportunities/benefits/capabilities will be lost: Deliverables are not visible to the wider community outside ELISA. We miss to benefit from the current hype on AGL SoDeV and Eclipse S-CORE which give SDVs and safety-criticality a recent momentum. Additionally, we cannot demonstrate ELISA capabilities at Workshops and Conferences. We would miss the opportunity to show more technical credibility of the project. Without the funding we would remain in the status in which we are already. If we would have taken this step more seriously earlier, maybe it would have been ELISA SoDeV and not AGL SoDeV. (Still the place is good to lower our efforts and join forces in the way it is now set up.)