John D. McGregor Session 6 Preparing for Architecture V & V

Slides:



Advertisements
Similar presentations
KAIS T The Vision of Autonomic Computing Jeffrey O. Kephart, David M Chess IBM Watson research Center IEEE Computer, Jan 발표자 : 이승학.
Advertisements

Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
CPSC 872 John D. McGregor Session 22 Architecture Design, cont’d.
Page 1 Building Reliable Component-based Systems Chapter 13 -Components in Real-Time Systems Chapter 13 Components in Real-Time Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Ensuring Non-Functional Properties. What Is an NFP?  A software system’s non-functional property (NFP) is a constraint on the manner in which the system.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Critical Systems Specification 3 Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
CPSC 871 John D. McGregor MSumS2 Summary – technical issues in software engineering.
Chapter 6 Software Implementation Process Group
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
An Introduction to Software Architecture
CPSC 875 John D. McGregor Vehicle Technologies. Modern vehicles – 10 years of effort
© Copyright 2014 Rockwell Collins, Inc. All rights reserved. Resolute: An Assurance Case Language for Architecture Models Andrew Gacek, John Backes, Darren.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
CPSC 875 John D. McGregor C10 – Physical architecture.
John D. McGregor Session 2 Preparing for Requirements V & V
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
1 Safety - definitions Accident - an unanticipated loss of life, injury, or other cost beyond a pre-determined threshhold.  If you expect it, it’s not.
Introduction to Control / Performance Flight.
CPSC 371 John D. McGregor Session 32 This is it..
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Geoffrey Duval (ISAE-SUPAERO) Naples, October 1 st, 2012.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. NFP Design Techniques Software Architecture Lecture 20.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. NFP Design Techniques Software Architecture Lecture 20.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
NCAF_May03.ppt Slide - 1 CSE International Ltd Data Integrity: The use of data by safety-related systems Alastair Faulkner CEng CSE International Ltd Tel:
Smart Home Technologies
Architecture Analysis and Design Language: An Overview Drew Gardner.
CPSC 873 John D. McGregor Session 6 Preparing for Architecture V & V.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
CPSC 875 John D. McGregor Reference Architectures C9.
CPSC 873 John D. McGregor Session 3 Requirements V & V.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
A Brief Introduction to Architectural Modeling Using AADL and Collaborative, Adaptive Cruise Control John D. McGregor Roselane S. Silva.
I&C Lab Seminar Procedure for the Software Requirements Specification for Safety Critical Systems Seo Ryong Koo Korea Advanced Institute Science.
CPSC 875 John D. McGregor C18. Partitions Requirements Need is for an e-commerce system which presents catalog item descriptions and takes orders. The.
CPSC 875 John D. McGregor Wrap-up. Ultimate goal Encapsulate uncertainty, risk, and change We analyze and measure to determine where to form modules.
CPSC 875 John D. McGregor C16.
Chapter 6 - Modern Concepts of Accident Prevention
John D. McGregor C10 – Error architecture
CATSY: Catalogue of System and Software Properties
John Backes, Rockwell Collins Dan DaCosta, Rockwell Collins
CPSC 875 John D. McGregor C16.
CPSC 875 John D. McGregor C24.
John D. McGregor Session 3 Requirements V & V
Air Carrier Continuing Analysis and Surveillance System (CASS)
Yogesh Mahajan, Sharad Malik Princeton University
John D. McGregor Quality attributes
John D. McGregor Session 8 Evaluating Architectures written in AADL
John D. McGregor C15.1 – Process/AUTOSAR
Software Architecture Lecture 20
Software testing.
How S-18 processes help make systems trustworthy
John D. McGregor Session 5 Error Modeling
An Introduction to Software Architecture
John D. McGregor Design Concept C5
Software Verification, Validation, and Acceptance Testing
Lecture # 7 System Requirements
Software Engineering for Safety: a Roadmap
Human Computer Interaction Lecture 14 HCI in Software Process
John Backes, Rockwell Collins Dan DaCosta, Rockwell Collins
Presentation transcript:

John D. McGregor Session 6 Preparing for Architecture V & V CPSC 873 John D. McGregor Session 6 Preparing for Architecture V & V

Modern development techniques verification architecture requirements

So far Use cases Requirements Decomposition reconsider Idea Architecture Implementation Retire Scope review feedback Configuration management Process/ notations Infrastructure

Decomposition

Hazards In identifying hazards there are two principal considerations: exceptional conditions within architecture elements (characterized using the EMV2 error ontology) and mismatched assumptions (mismatched assumption-guarantee contracts between systems) about their interactions. We will handle both

Hazard Analysis http://people.cs.ksu.edu/~scbarrett/pcashutoff-doc/index.html# http://people.cs.ksu.edu/~scbarrett/pcashutoff-doc/app/shutoff.html http://santoslab.org/pub/mdcf-architect/HazardAnalysis.html

Traceability As we build the requirements model we have traceability in the form of references to the entity constrained by the requirement. We also have traceability via requirements categories.

Agree model checking An annex to AADL that allows the specification of guarantees and checks their correctness. annex agree {** guarantee ”dummy” : true ; **}; Inserted into an AADL component specification We need to replace dummy and true

2. Select .impl and right click and select all levels 1. insert 3. Read results

Agree example-1 system top_level features Input: in data port Base_Types::Integer; Output: out data port Base_Types::Integer; annex agree {** assume "System input range " : Input < 10; guarantee "System output range" : Output < 50; **}; end top_level;

Agree example-2 A B subcomponents A_sub : system A ; B_sub : system B ; C_sub : system C ; connections IN_TO_A : port Input -> A_sub.Input {Communication_Properties::Timing => immediate;}; A_TO_B : port A_sub.Output -> B_sub.Input A_TO_C : port A_sub.Output -> C_sub.Input1 B_TO_C : port B_sub.Output -> C_sub.Input2 C_TO_Output : port C_sub.Output -> Output end top_level.Impl; C

Agree example-3 system A features Input: in data port Base_Types::Integer; Output: out data port Base_Types::Integer; annex agree {** assume "A input range" : Input < 20; guarantee "A output range" : Output < 2*Input; **}; end A ;

In-line agree models https://github.com/smaccm/smaccm/blob/master/models/Microwave/Microwave_SEng5861.aadl

Function Hazard Analysis Failure Condition (hazard description) Phase Effect of Failure Condition on Aircraft/Crew Classification Reference to supporting material Verification Control Thrust Engine provides no thrust   Engine provides too little thrust Engine provides too much thrust Engine is slow to provide commanded thrust (increase or decrease) Engine will not shutdown when commanded Engine cannot be controlled - Loss of Engine Thrust Control (LOTC) Taxi, Takeoff, Landing , and Flight

System-Level (operational) Hazards Accident System-Level (operational) Hazards A-1: Loss of life or serious injury due to aircraft engine   A-2: Catastrophic damage to aircraft or other property due to aircraft engine H0: Ineffective thrust to maintain controlled flight or safe taxi H1: Engine provides no thrust H2: Engine provides too little thrust H3: Engine provides too much thrust H4: Engine is slow to provide thrust (increase or decrease) H5: Engine will not shutdown when commanded H6: Complete Loss of Engine Thrust Control (LOTC)

Hazards Safety Requirements H1: Engine provides no thrust SC1: Thrust must be provided at all times when commanded H2: Engine provides too little thrust H3: Engine provides too much thrust SC2: Thrust level must be provided at the commanded level. H4: Engine is slow to provide commanded thrust SC3: Engine must provide commanded thrust in xxx seconds. H5: Engine will not shutdown when commanded [The relevant safety constraints arising out of this include SC1, SC2, and SC4] H6: Engine cannot be controlled - Loss of Engine Thrust Control (LOTC) SC4: Engine must respond to all commands SC4.1: Engine must start when commanded SC4.2: Engine must shutdown when commanded

Error handling

Resolute SumForThread(t: component) : real = let executions_per_minute : real = (60.0 * 60.0 * 1000.0) / property(t, Period, (60.0 * 60.0 * 1000.0)); let milliwats_per_execution : real = property(t, Power_Properties::PowerBudget, 0.0); milliwats_per_execution *executions_per_minute

Resolute Example Resolute models https://github.com/smaccm/smaccm

PCA Shutoff Valve http://people.cs.ksu.edu/~scbarrett/pcashutoff-doc/index.html# http://people.cs.ksu.edu/~scbarrett/pcashutoff-doc/app/shutoff.html