Notional tiers of configuration

[matthew-l-weber]

Tiers

High Assurance (HA) - ASIL D, DO178C-AB
Real-time (RT) -------- ASIL BC, DO178C-C
Standard (STD) ------- ASIL A, DO-178C-DE

Tier	Prog Languages	Stdlib	Networking	Filesystem	Drivers	Memory Alloc	Userspace Init	Userspace	Notes
HA	C	Limited MUSL	None (Could be Userspace based)	Limited	Limited	Bound	Custom Minimal	Static binaries	DO-178C SWL-A drives reduced code count and feature set. Kernel has limited threads running async
RT	C/C++	Limited MUSL	Limited	Limited	Limited	Normal	Custom Minimal	Static binaries	DO-178C SWL-C drives reduced code count and feature set for lower size of statement coverage testing. Kernel threads prioritized with Userspace
STD	Any	GLIBC	Normal	Normal	Normal	Normal	SystemD	Normal + Namespacing support	Common with a SGL config?

Assumptions

• Must be intentional about the split between tiers
• Any higher tier's software shall run on a lower tier
• Higher tiers would have defined Kernel and API limitations to reduce certification size
• A lower tier could be used to developer for a higher tier, assuming an integration occurs "shrinking" to API footprint.
• All tiers are compatible with
  • Being a Xen FuSa domain/partition
    • Support fault tolerance cases
    • Mixed safety criticality
  • Hosting a ARINC653 environment (Xen-based)
  • Hosting a NASA cFS environment

Actions (From a App developer angle)

• Define tier compatibility
• Doc tools used
• API support tables / interface control documents
• Define tier component support (e.g. userspace stuff, networking, filesystem, languages)
• Define build outputs / presentation of image formats / supported targets
• Contribution workflow
• Development workflow
  • Example of doing HA work but starting with RT
  • Build env awareness of tier to account for API support

[matthew-l-weber]

For example, the Use case light demo work looked at it this way.

1. Preparing a "STD" environment with python for the initial emulated example.
2. Targeting a minimal RT like environment which strips away some features and sticks to C based applications w/o scripting.
3. To get to HA, we'd have to rework how testing executes and shell support would most likely be stripped out. E.g. no userspace beyond a simple init and lighting app.

[matthew-l-weber]

@ivanperez-keera (from the defs above) when you discussed porting cFS, I assume you'd want to initially try targeting a RT environment where you have full POSIX but limit other userspace dependencies? Then work towards HA?

[ivanperez-keera]

@matthew-l-weber indeed. I'd probably try to do the same with the light switch example.

[matthew-l-weber]

Initial ideas around this in slide form for the Gov board call. The mapping table isn't accurate yet but was close enough as an example.

ELISA-202506-Boeing-Govboard-minimal-linux-project.pptx

[matthew-l-weber]

@brian-wood mentioned we should consider understanding the size of cFS SLOC once running on the DO178C-C or above.

Brian also asked about which toolchain for which parts. LLVM or GCC and why?

[matthew-l-weber]

What would a ARM System Ready offering look like across the spread of tiers?

[matthew-l-weber]

Presented the attached slides at Gov board call. - Feedback focused on next steps and some hesitation on approaching the safety assessment, as it is usually an early step, but for this scope it's lifecycle work. E.g. bringing a code base up to a possible "system assessment" at a lower fault rate then today.