Timing Tolerances in Safety-Critical Software Alan Wassyng, Mark Lawford, Xiayong Hu FM 2005 Software Quality Research Laboratory McMaster University.

Slides:



Advertisements
Similar presentations
Chapter 7 System Models.
Advertisements

Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Formal Modelling of Reactive Agents as an aggregation of Simple Behaviours P.Kefalas Dept. of Computer Science 13 Tsimiski Str Thessaloniki Greece.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Project management Project manager must;
System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
AMI 4622 Digital Signal Processing
Winter 2007SEG2101 Chapter 41 Chapter 4 SDL – Structure and Behavior.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
Software Requirements
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Testing an individual module
Describing Syntax and Semantics
Lecture Slides Elementary Statistics Twelfth Edition
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
Course Instructor: Aisha Azeem
Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory.
Classification of Instruments :
Test Design Techniques
[ §6 : 1 ] 6. Basic Methods II Overview 6.1 Models 6.2 Taxonomy 6.3 Finite State Model 6.4 State Transition Model 6.5 Dataflow Model 6.6 User Manual.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
ECE 720T5 Winter 2014 Cyber-Physical Systems Rodolfo Pellizzoni.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
VTT-STUK assessment method for safety evaluation of safety-critical computer based systems - application in BE-SECBS project.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Engineering High Quality Software Applications Alan Wassyng Presented at CUSEC 2005 Software Quality Research Laboratory Department of Computing and Software.
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
A Safety-Critical Software Approach to Hard Real-Time Applications Alan Wassyng.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
System Testing Beyond unit testing. 2 System Testing Of the three levels of testing, system level testing is closest to everyday experience We evaluate.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Software Requirements Specification Document (SRS)
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
WELCOME TO OUR PRESENTATION UNIFIED MODELING LANGUAGE (UML)
1 Software Requirements Descriptions and specifications of a system.
Project management. Software project management ■It is the discipline of planning, organizing and managing resources to bring about the successful completion.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Probability and statistics - overview Introduction Basics of probability theory Events, probability, different types of probability Random variable, probability.
I&C Lab Seminar Procedure for the Software Requirements Specification for Safety Critical Systems Seo Ryong Koo Korea Advanced Institute Science.
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Abstract descriptions of systems whose requirements are being analysed
Software Design Methodology
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Presentation transcript:

Timing Tolerances in Safety-Critical Software Alan Wassyng, Mark Lawford, Xiayong Hu FM 2005 Software Quality Research Laboratory McMaster University

1 Introduction n Built on definitions and analysis developed at Ontario Power Generation for safety-critical software applications in the nuclear power industry. n Need to describe timing behaviour that includes tolerances in time durations. n Need to describe timing tolerances that allow deviations from ideal behaviour specified by typical requirements models.

2 Examp l e n To filter noisy signals we may specify that a sensor signal above its setpoint (the event) sustained for 300 ms causes a “trip”. n If the event is sustained for less than 300 ms, the trip must not occur. n Similarly, if the event is sustained for 300 ms or longer, the trip must be generated. n Without tolerances on the time duration, these requirements would be impossible to meet, so the duration may be specified as 300±50 ms for instance. Introduction

3 Implementations of example specification. Informal spec: Trip if m_signal is above setpoint for 300±50 ms. Introduction

4 Model & Notation n Model: u Finite State Machine, discrete time with arbitrarily small clock-tick. u Stimuli  monitored variables. u Responses  controlled variables. u C(t) - vector of values of controlled variables at time t. u M(t) - vector of values of monitored variables at time t. u S(t) - vector of values of state variables at time t. u C(t k )  R(M(t k ), S(t k )) S(t k+1 )  NST(M(t k ), S(t k )) where t 0 is time of initialisation,  t = t k+1 - t k k = 0,1,2,…

5 n Notation: u t now represents current time. u variable -n is value of variable n clock-ticks ago. u We use tabular expressions wherever possible: Model & Notation =

6 Definitions n (Condition) Held for (d,  L,  R) (Infix operator) duration defined by constant d (>0), with tolerances -  L, +  R (0 ≤  L < d, 0 ≤  R)

7 n Formal definition of “Held for” Definitions

8 n Periodic(Condition, d,  L,  R) Definitions

9 n Formal definition of “Periodic” Definitions

10 n SyncPeriodic(d,  L,  R) Definitions

11 n Formal definition of “SyncPeriodic” Definitions

12 Functional Timing Requirements n Functional timing requirements are timing requirements that are directly related to the required behaviour of the application. u So, “Held for”, “Periodic” and “SyncPeriodic” are examples of templates describing functional timing requirements. u Other common functional timing requirements can be modeled in similar fashion. u These requirements are interpreted within the constraints of the governing model, in our case the discrete time FSM with arbitrarily small clock-tick. This describes idealised behaviour with the capability of including tolerances on all timing durations.

13 Performance Timing Requirements n Idealised behaviour totally ignores the fact that an implementation cannot continuously monitor sensor values and requires a finite, non-zero amount of time to process its results. n To complete the description of the required behaviour, a requirements document must also specify the performance tolerances that are allowed in meeting functional timing requirements. n We identify two different performance timing requirements. u Timing Resolution u Response Allowance

14 n Timing Resolution PTRs

15 n Response Allowance u The Response Allowance (RA) for a controlled-monitored variable pair specifies an allowable processing delay. u Each controlled variable must have an RA specified for it. The RA applies to the controlled variable and the particular monitored variable on which the controlled variable’s behaviour depends. u The RA is measured from the time the event actually occurred in the physical domain, until the time the value of the controlled variable is generated and crosses the application boundary into the physical domain. u The RA for the pair c-m is meaningless if c does not change its value in response to a change in the value of m (the effect must be visible externally). u The time sequence of externally generated values of a controlled variable c cannot be altered by consideration of the RAs for each c-m pair. PTRs

16 PTRs

17 PTRs NO!

18 Interaction Between FTRs & PTRs n Timing resolution & sustained events (  j: ts j  TR )

19 Interaction ts_min  ts j  ts_max for each j  {0..n} Need at least 2 samples in this interval to ensure decision based on value in this interval

20 Interaction 0 < ts_max  (  L +  R) / 2  implementable (  L +  R) < ts_max  not implementable Need at least 2 samples in this interval to ensure decision based on value in this interval

21 Interaction (  L +  R) / 2 < ts_max  (  L +  R): k min = int((d -  L) / ts_max); k max = int((d -  L) / ts_min) k min  k max  k max  ts_min  d -  L & k max  ts_max > d -  L   k |  ts j = d -  L -  (  arbitrarily small > 0)  not implementable. k = k min = k max   ts j  d -  L   ts j > d -  L So, if (k + 2)  ts_max  d +  R then it is implementable. k j=1 k k+1 and

22 Interaction Analysis applied to examples. The tolerances on the sample intervals are shown in paren- theses. As we would expect, jitter in the sample interval makes it more difficult to implement the requirement.

23 Interaction Analysis applied to examples. The tolerances on the sample intervals are shown in paren- theses. Longer durations are more difficult to implement.

24 Interaction n Response allowance with sustained events u Two cases to consider: F Event ends before it is sustained. Easy to deal with. The usual ra is applied. F Event is successfully sustained. Not so easy. Apply ra for the unsuccessful case in addition to the maximum duration of the sustained event, i.e. d +  R. u Example: ra is 250 ms, event must be sustained for k_delay ms, k_delay in [400-40, ] ms. F Response allowance is 675 ms if sustained, 250 ms if not. F We write it as 675 ms Held for (k_delay) / 250 ms.

25 Conclusion n We have separated functional and performance timing requirements. n We have provided example definitions for specific functional timing requirements, and the definitions include the effects of tolerances. n We have also analysed specific interactions between functional and performance timing requirements.

26 n So - why do we think this is useful? u The definitions are precise and practical. They allow behaviours that agree with our intuitive concepts but can be used to adjudicate objectively in cases where we have a “discussion” between verifiers and developers. u The advantage of having formal definitions and analyses that deal with tolerances is that we can now develop tools that will help automate scheduling and verification of timing requirements. u The analysis is simple yet effective. We do not have to force TRs to be less than (  L +  R) /2. We can find implementable sampling intervals in the range ( (  L +  R) /2, (  L +  R) ), and we have shown that minimising jitter in the sampling intervals is really worth while. Even small jitter can result in not being able to implement a requirement unless we have the maximum sampling interval less than (  L +  R) /2. Conclusion

27 n Future work u Complete formalisation of timing requirements and their implementation using PVS. Currently partially completed, including confirmation of the analysis presented earlier. u Analysis of effect of TRs and RAs on intermediate functions in the requirements decomposition. Conclusion

28 Thanks - see you at FM’06 at McMaster University, Canada