Safety Analysis of nlohman in TSF

[aschemmel-tech]

What

TSF defines a Safety Analysis Method in https://pages.eclipse.dev/eclipse/tsf/tsf/extensions/stpa/procedure.html
This method has to be piloted and checked for usability in S-CORE

How

• Pilot the "RAFIA STPA" method - outcome see https://github.com/score-json/nlohmann_json/blob/19b5044a5b92381004b6907286654bbc6e87dc8c/TSF/docs/risk_analysis.md within Update trustable tenet TT-EXPECTATIONS nlohmann_json#22
• Review and compare to S-CORE safety analysis method

Estimates for realization

1 week

Category

• Affects Detailed Design

Requirements / Architecture

• Requirements / Architecture are not affected by this change?

[aschemmel-tech]

@aschemmel-tech and @masc2023 MoM:

• The pilot example seems too detailed, especially as the "Losses", "Hazards" and "System-level constraints" cover a system level safety analysis which we would not see necessary for such a simple SW library
• Tailoring could be the solution: i.e. we could restrict our use of the method to some of the steps 1-10
• Alternatively we could reduce the amount and nature of the faults by using a smaller scope (covering only the JSON lib)
• In our understanding step 3-5 describe a safety analysis based on static architecture and 6-8 is based on dynamic architecture (always with the steps "describe architecture, find faults, devise mitigations") - where the step 9 matches the mitigations to the "TSF specifications" and step 2 is one step on system level covering all
• For our example we agreed that @aschemmel-tech will try to combine the approaches "smaller scope" and "less steps" - the latter would tailor the steps 6-8 completely, as the dynamic architecture is so simple (caller-callee) that it can be omitted. And thus create a reduced analysis
• As a next step we considered to use the S-CORE SW safety analysis method alternatively to find out if it will detect the same faults (apart from security topics) and can be integrated in the TSF - the advantage would be that the team would not need to learn two methods.

[aschemmel-tech]

Additional input from meeting with Exida's Jonathan Moore:

• main driver should be to think about "safety use cases" of the JSON lib and how those could be covered already on a "system" level
• proposed use cases are: JSON used in start-up once, JSON used during operation cyclically
• abstraction should serve as a means to avoid to go into detail too much
• also other Safety Analysis methods can be used
• STPA should focus on functionality (and not processes around)

[aschemmel-tech]

tailored analysis see eclipse-score/nlohmann_json#25