Practically Formal Development and Assurance of Complex Software-Intensive Safety-Critical Systems Alan Wassyng work with Zinovy Diskin, Nicholas Annable, and Mark Lawford CyPhyAssure, 20 March 2019
GSN-like Assurance Cases Pros § Appealingly intuitive § Does seem to improve safety (for example) by making people examine the “case” more critically A1 Assumption C1 G1 C2 Context Top Claim More context S1 A2 J1 Strategy: Assumptions Justification for GSN was introduced by Tim Kelly why in strategy strategy G2-G5 in 1998 [Kelly1998] G2 G3 G4 G5 He and others have turned it into Sub-claim of Sub-claim of Sub-claim of Sub-claim of G1 G1 G1 G1 the most popular notation for assurance cases S2 S3 Sn1 Sn2 Strategy: Strategy: Evidence Evidence why why for G3 for G5 G6-G7 G8-G9 GSN-like is meant to include other similar G6 G7 G8 G9 Sub-claim of Sub-claim of Sub-claim of Sub-claim of notations such as G2 G2 G4 G4 Claims, Arguments and Evidence (CAE) and Sn3 Sn4 Sn5 Sn6 Evidence Evidence Evidence Evidence 1 tabular approaches f or G6 for G7 for G8 for G9
GSN-like Assurance Cases Cons [Wassyng2011] § Cases tend to have an ad hoc structure dictated by experience & preference • Patterns help but they are not the “solution” § Cross-cutting concerns abound § There is an element of confirmation bias § Provides a false sense of confidence (no matter how we “measure” confidence) since we think our reasoning is rigorous (most never claim formal) – but it is not § Safety impact analysis is difficult to impossible • In general, effective traceability is tough 2
GSN Intent The actual intent behind GSN was fundamentally flawed in some ways 1. Strategy is optional! 2. The arrows indicate decomposition, not an argument based on premises 3. The promised explicit �� argument is just not �� present – if justification was supposed to represent reasoning as some people claim, then why does it support strategy instead of the other �� way around? 4. GSN/CAE experts say that the only place an explicit argument is necessary is to support evidence, but �� there is no strategy node even – so, what argument? Better in SACM 2.0 GSN COMMUNITY STANDARD 3 [GSN2011] VERSION 1 - 2011
A New Approach § Before we explore why we came up with a different approach the following slide shows components of the new assurance – as an integral part of the development § This gives us some idea of where we are headed § The basis is metamodels and model transformations, refinements and instances 4
workflow+ Product Process Assurance 5
Assurance Case Templates (ACTs) P Describes an assurance case (AC) for a product line or domain. Needs to be instantiated for a specific product. Developed BEFORE building products. 1 1-2 Reduces confirmation-bias. Facilitates incremental assurance. 0-1 0-1 Could be used to direct development – Legend: as a process guide or even as a - Claim or sub-claim standard. - Evidence - A is claim A B [Wassyng2016] B is premise 6 acceptance criteria on evidence required specified in the template
Assurance Case Templates (ACTs) P Describes an assurance case We have championed “product-focused certification” (AC) for a product and we really like ACTs – so why develop workflow+ ? line or domain. Needs to be instantiated for a specific product. Developed BEFORE building products. 1 1-2 Reduces confirmation-bias. Facilitates incremental assurance. 0-1 0-1 Could be used to direct development – Legend: as a process guide or even as a - Claim or sub-claim standard. - Evidence - A is claim A B [Wassyng2016] B is premise 7 acceptance criteria on evidence required specified in the template
Extract from Assurance Case Safety Template for ADAS G <ADAS> considered as an ISO 26262 item, delivers the behaviour required, and does not adversely affect the safety of the vehicle, over its expected lifetime, in its intended environment. SR Strategy: G can be decomposed into 1. Functional safety concept verified. (GS) 2. <ADAS> complies with Functional safety requirements and is released for production (26262). (GR) 3. Production and maintenance processes. (GPM) 4. Configuration management. (GC) 5. Change management. (GCM) 6. <ADAS> not expected to violate documented assumptions (GA) Reasoning: Premise: GS, GR, GPM, GC, GCM and GA are true. Claim: G is true i) These 6 premises cover all the major premises in 26262 (See SRi) ii) GR as in 26262 has been supplemented by our knowledge of SE. Specifically, general functional requirements must not adversely interact with the safety requirements. (See SRii) iii) Important component is operational assumptions are not so onerous that drivers are likely not to comply with them, and those related to the environment will also be valid. (See SRiii) GS GR GPM GC GCM GA Safety of the Implementation of Configuration Change The safety <ADAS> <ADAS> complies vehicle is Management Management concept of operational maintained <ADAS> is with requirements complies with complies with assumptions are throughout its within tolerance. ISO 26262. ISO 26262. Verified. This documented, and operating life, Requirements are includes that all operation of the unambiguous, through necessary vehicle in which compliance functional safety complete on input <ADAS> is with Production domain and requirements installed is not Requirements, internally are derived from expected to consistent. Service a vehicle level violate these Maintenance hazard and risk They include all assumptions. Requirements, & necessary <ADAS> analysis and Decommissioning [Chowdhury2017] Functional Safety validated Requirements, Requirements in ISO 26262. 8 derived from HARA.
Extract from Assurance Case Safety & Security Template [Chowdhury2018] 9
We Like the Benefits of ACTs § They are templates for a product line developed ahead of work on individual products § They facilitate incremental assurance in the same way that information hiding makes software designs robust with respect to anticipated changes § They provide some protection against confirmation bias § They standardize an approach so that regulators (in particular) can develop expertise in evaluating them 10
But Could Not Overcome the Flaws in GSN § GSN is inherently ad hoc – there is no theoretical foundation for its assurance steps § The “logic” for the explicit argument is either non- existent or hopelessly inadequate to deal with a property like safety • We have not managed to define safety semantics for the arrows in GSN – No, SACM does not do this [SACM2.0] • Safety or security impact analysis in GSN is fundamentally unsound § Cross-cutting concerns are unavoidable § GSN diagrams typically are a mixture of template and instance – see next slide 11
Template or Instance? T I I This is not inherent in GSN – but GSN T T T I T is so ad hoc in its approach that this is what we see T T most of the time I T T I I I I I I I I I 12
Why workflow+? § We need process! • Even if we want product-focused certification we have always said it has to be based, at the very least, on notions of an idealized process § We can cope with process, product, people, in much more structured ways § workflow+ is a formal notation and the inherent assurance steps are not ad hoc § workflow+ provides a rigorous way of producing and maintaining traceability links providing a method to turn incremental analysis into syntactic checks 13
Where did it come from? § Last year we published an early version of the framework in MoDELS [Diskin2018] Struct. is Ok sound …. SM def is Ok … compl …. Constr. Ok MT def [H] is Ok TM def is Ok is Ok … [C] is Ok EJ pattern [ Process is done Ok ] Trc. def is Ok … [multipl] Ok … Process Definition Process Rules Pr ndsOn pends depe de Sour So urce tr traceability ility Target Tar et ndsOn Metamodel Me metamo me model Metamode Me pends depe de c e l o u r S i s a t a d Execu- conformsTo O k | = conformsTo Def is | = tion is Ok O n n d s e p e Ok d :exeT = Tar Target et Sour So urce tr traceability ility Da Data Data Da mapping ma SD is Ok Exe is Ok Structure verify conforms verify uB1 = ? gw1(F1) Constr. are validate validate satisfied uB2 = ? gw1(F2) sound sound F1 is Ok uB3 = ? gw2(F2) complete F2 is Ok gw5(F1)? … gw7(F2)? .... complete other functions? These “assurance steps” are suggested by the 12 mathematical structure - no longer ad hoc. 14
Demonstrate by Way of Example 15
Example of an Assurance Case Segment Note: We do realize that this was produced to illustrate GSN constructs not as an example of a safety case, but it is useful for our purpose since it is (sort of) plausible and is simple enough but with some (implicit) detail GSN COMMUNITY STANDARD VERSION 1 - 2011 16
workflow+ representation based on the GSN example Legend 17
So, where did the assurance steps come from? There is a constraint that says every hazard must be “dealt with” by a safety requirement We then have 2 checks on that: 1. semantic – needs people 2. syntactic – can be automated 18
Recommend
More recommend
