Minutes 10 Oct 2024

Host: Paul Albertella

Participants: Peter Brink, Daniel Weingaertner, Igor Stoppa, Gabriele Paoloni, Lukas

Agenda:

• Review Kernel self-monitoring PR (https://github.com/elisa-tech/wg-osep/pull/44)

Goal: A top-level document describing kernel self-monitoring as a set of objectives rather than describing it in terms of a specific implementation. This is intended to be used in evaluating a particular implementation of a mechanism.

Document can be viewed here

Gab: Semantically correct, but missing a formalism to specify the objectives that should be met, and missing some objectives, notably about systematic capability and freedom from interference.

Igor: Intended as a first draft, trying to keep it generic.

Implication is that the safety monitor is more trustworthy than other components.

Lukas: Components do not have a trust level, requirements do. If we are more precise in our language then we can be clearer about whether the component achieves a requirement with the required level of trust.

Igor: Component A is monitored by B. C can interfere with A; B detects if this causes A to not achieve its safety requirement. We also need to consider if C can interfere with A

Lukas: Yes this should be covered by a Common Cause Failure (CCF) analysis.

Igor: Expectation that the monitor cannot be interfered with cannot be satisfied at an architectural level, so must instead consider potential fault classes and show how these can be detected and/or mitigated

Lukas: Need to remember that higher integrity components may still be involved in fault propagation.

Could strengthen the document by stating “Examples provided are indicative not comprehensive. To identify which measures are necessary for a given case an appropriate measure such as a CCF will be necessary.”

Qualification is one way to assure ourselves that a particular fault class cannot interfere with a given function, but we might also show that through our own analysis.