A Model Management Approach for Assurance Case Reuse due to System - PowerPoint PPT Presentation

A Model Management Approach for Assurance Case Reuse due to System Evolution Sahar Kokaly, Rick Salay Valentin Cassano, Tom Maibaum and Marsha Chechik kokalys@mcmaster.ca

2

3

4

5

“Standards are documented agreements containing technical specifications or other precise criteria to be used consistently as rules , guidelines , or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.” [ISO 1997] 6

DO-178B - Software Considerations in Airborne Systems and Equipment Certification. 7

IEC62304 – Medical device software – software life cycle processes. 8

ISO26262 - Functional Safety of Road Vehicles 9

Compliance What is it? The extent to which software developers have acted in accordance with practices set down in the standard. Why it is done? Establish consistency between actual development process and normative models embedded in the standards. How is it done? An artifact, called an Assurance Case, is often required to demonstrate that a system meets the property set forth by the standard (e.g., Safety, Privacy, Security, etc.) 10

Standards are great, but they are also… BIG coMpleX 11

12

…this makes compliance Co$$$tly What is needed? Ways to (semi-)automate compliance assessment activities to reduce their cost. 13

In a previous position paper [MiSE@ICSE’16] • Identified compliance management scenarios: • Compliance with multiple standards. • Standard/system slicing for partial compliance checking. • Lifting compliance assessment from products to product lines. • Identifying relationships between standards. • Assurance case reuse • Showed how model management techniques could be adapted and used to address these scenarios. 14

In this paper: Assurance Case Reuse due to System Evolution S S’ change R’ R A A’ ? 15

Contributions 1. Defined a generic model management framework for assurance case reuse due to system evolution. 2. Identified and specified model management operators required for a management approach and presented an algorithm for reuse. 3. Evaluated the generic framework by instantiating for ISO 26262 vehicle safety cases with the KAOS goal modeling language used for expressing assurance cases. 4. Applied this instantiation to a power sliding door system from the automotive domain. 16

Outline ¤ Introduction and Motivation ¤ Summary of Contributions ¤ Geging started: ¤ Assurance Case Modeling ¤ Model Management ¤ Assurance Case Impact Assessment Algorithm ¤ Demonstration: Power Sliding Door ¤ Analysis ¤ Conclusion and Future Work 17

What is an Assurance Case? • An artifact that shows how important claims about the system (e.g., requirement satisfaction) can be argued for, ultimately from evidence obtained about the system such as model checking, test results, expert opinion, etc. 18

Example: Power Sliding Door assurance case SG1: Avoid ac/va/ng the actuator while the vehicle speed is greater than 15 km/h Strategy: AND refinement FSR5: The FSR4: The FSR2: The AC actuator is FSR3: The VS Redundant ECU does not FSR1: The VS ac/vated ECU sends Switch is in an power the ECU sends the only when accurate open state if actuator if the accurate powered by vehicle speed the vehicle vehicle speed vehicle speed informa/on to the AC ECU speed is informa/on to is greater than and the the Redundant greater than 15 km/h the AC ECU Redundant Switch. 15 km/h. Switch is closed E3: Model E4: Model E5: Model E2: Model E1: VS Sensor Checking Checking Checking Checking Accuracy System System System System Test Results Models Models Models Models

Assurance Case Modeling • Some approaches for modeling assurances cases: – GSN, CAE, KAOS-based, OMG SACM… Argument * 1 conclusion * In the paper: Claim premiss • Dependency Relations • Semantic Assumptions * state: TruthState Evidence evidence * state:ValidityState Generic Assurance Case Metamodel 20

The Toolbox: Model Management (MM) § High-level view in which entire models and their relationships can be manipulated using operators to achieve useful outcomes. § Megamodel: a special type of model in which the elements represent models and the links between the elements represent relationships between the models. 21

Some Model Management Operators + slice merge diff match + Megamodel Operators (Map, Filter, Reduce) [ MODELS’15 ] bidirectional MT lift 22

Outline ¤ Introduction and Motivation ¤ Summary of Contributions ¤ Geging started: ¤ Assurance Case Modeling ¤ Model Management ¤ Assurance Case Impact Assessment Algorithm ¤ Demonstration: Power Sliding Door ¤ Analysis ¤ Conclusion and Future Work 23

Recall: Assurance Case reuse due to system evolution S S’ change R R’ A A’ ? • Challenge: carefully managing the assurance case elements (claims, arguments, evidence) and dependencies between them. • Goal : Reuse as many of the original assurance case components as possible. 24

Assurance Case Impact Assessment S: T S’: T change ★ ac dc c c D ★ a d R’ R A ’ R A A’ ★ complete revise recheck ★ ★ + ★ “Heterogenous Megamodel Slicing for Model Evolution”. Rick Salay, Sahar Kokaly , Marsha Chechik, Tom Maibaum. Models and Evolution Workshop @MODELS’16 25 ★ Assurance Case specific operators

Model Management AC Reuse Impact Assessment Algorithm Params : <Slice T ; Merge T > Input : initial spec S : T, assurance case A : AC, traceability map R, changed spec S’ : T, delta D = <C0a;C0d;C0c> Output : Impact set estimate A RMM , impact kind annotation k RMM 1: R’ A ß Restrict(R, D) 2: dc ß Slice T (S, Merge T (d,c)) 3: ac ß Slice T (S‘, Merge T (a,c)) 4: C2 recheck ß Merge AC (Trace(R, dc), Trace(R‘ A , ac)) 5: C2 revise ß Trace(R, d) • Takeaways: 6: C3 revise ß Slice AC (M, C2 revise ) • Model Management (MM) Operators 7: C3 recheck ß Slice AC (M, C2 recheck ) • Adapted MM Operators for 8: A RMM ß Merge AC (C3 revise , C3 recheck ) Assurance Cases 9: k RMM (C3 recheck ) ß ‘recheck’ • MM Workflow 10: k RMM (C3 revise ) ß ‘revise’ • Challenge working with ACs: 11: return A RMM , k RMM • Dependencies • Argument Structure 26

Example: Power Sliding Door System System S Δ: removal of redundant switch Evolved System S’ 27

Power Sliding Door Megamodel requestSpeed() getSpeed(sensedspeed) requestDoorOpen() closed: Boolean sensed_speed: Real requestDoorClose() sensed_speed: Real communicatesWith communicatesWith communicatesWith controls open:Boolean requestSpeed() openDoor() powers controls sensed_speed: Real closeDoor() powered: Boolean activated: Boolean a:Actuator s: Redundant_Switch :VS ECU :AC ECU :Driver Switch par s.requestSpeed() [if sensed_speed<=15] s.closed else s.open requestDoorOpen() requestSpeed() sensed_speed [if sensed_speed<=15 and a.powered and s.closed] a.activated = True, a.openDoor() requestDoorClose() requestSpeed() sensed_speed [if sensed_speed<=15 and a.powered and s.closed] a.activated = True, a.closeDoor() 28

Input: Original Assurance Case SG1: Avoid ac/va/ng the actuator while the vehicle speed is greater than 15 km/h G(not(a.activated and (sensed_speed > 15)) and a.sensed_speed=vehicle_speed and s.sensed_speed=vehicle_speed) Strategy: AND refinement FSR2: The AC ECU FSR5: The FSR4: The FSR1: The VS ECU does not power the FSR3: The VS ECU actuator is Redundant Switch sends the accurate actuator if the sends accurate ac/vated only is in an open state vehicle speed vehicle speed is vehicle speed when powered by if the vehicle speed informa/on to the greater than 15 informa/on to the the AC ECU and is greater than 15 AC ECU km/h Redundant Switch. the Redundant km/h. Switch is closed G (a.powered à G(a.sensed_speed G(s.sensed_speed G(s.sensed_speed = vehicle_speed) a.sensed_speed<= = vehicle_speed) G(a.activated >15 à ~s.closed ) 15) à (a.powered and s.closed) ) E3: Model E4: Model E5: Model E1: VS Sensor E2: Model Checking Checking Checking Accuracy Test Checking System Models System Models System Models Results System Models

Assurance Case after impact assessment SG1: Avoid ac/va/ng the actuator while the vehicle speed is greater than 15 km/h G(not(a.activated and (sensed_speed > 15)) and a.sensed_speed=vehicle_speed and s.sensed_speed=vehicle_speed) reuse revise recheck Strategy: AND refinement FSR2: The AC FSR4: The FSR5: The FSR3: The VS FSR1: The VS ECU does not Redundant actuator is ECU sends ECU sends the power the Switch is in an ac/vated only accurate vehicle accurate vehicle actuator if the open state if the when powered speed speed vehicle speed is vehicle speed is by the AC ECU informa/on to informa/on to greater than 15 greater than 15 and Redundant the Redundant the AC ECU km/h km/h. Switch is closed Switch. G(a.sensed_speed G(a.powered à G(a.activated à G(s.sensed_speed G(s.sensed_speed = vehicle_speed) >15 à a.sensed_speed<= (a.powered and = vehicle_speed) 15) ~s.closed ) s.closed) ) E1: VS E3: Model E2: Model E4: Model E5: Model Sensor Checking Checking Checking Checking Accuracy System System System System Test Results Models Models Models Models