Skip to content

Minutes 18 05 2023

Jump to bottom
Paul Albertella edited this page May 18, 2023 · 2 revisions

Host: Paul Albertella

Participants: Pete Brink, Dana Vede, Gab Paoloni

Agenda: Finalise safety analysis PR and plan next steps

  • New particiant: Dana Vede

    • Eclipse SDV
    • Automotive Software Process Engineer

  • Overview of STPA approach and the Telltale Use Case

    • Next step: Where to draw the system boundary?

  • Gab: Challenge when doing STPA at kernel level is that for some UCAs there are no obvious mitigations or constraints that we can apply

    • Answer cannot only be provided from an architectural point of view - i.e. based on our examination of the kernel architecture

  • Paul: We can arguably rely on the OS to perform its fundamental functions - for these, the OS is operating as an extension of the application, and the intent (and required results) are known to the application.

    • As part of the integration process, if we execute the applications using the OS, we are effectively verifying the parts of the OS that are exercised by those applications.
    • Goal with using STPA is to identify the OS roles and responsibilities relating to safety that we cannot rely on application testing to verify

  • Dana: But this does not prove your OS - it is using your OS to prove your applications

    • May be cases where there are overlapping errors in the application and the OS that result in ‘false negative’ test results (test pass when they should fail)

  • Pete: Is this viewing Linux only as an ‘untrusted’ component, that we must surround by safety mechanisms?

    • Paul: Some of these safety mechanisms may be provided by existing features or design characteristics of Linux. It is these that we need to identify and ‘lift the lid’ on the black box of the OS to prove that they work as required.

  • Dana: In other automotive contexts, ‘plausibility algorithms’ are used to check the viability of a component, by requiring them to compute a response and verifying it independently. Could we use a similar approach here?

    • Paul: Yes! For example, a watchdog that could use a challenge/response approach to apply this principle to Linux Would require a proven external component, but this would be less complex and thus capable of being proven by conventional methods
Clone this wiki locally