Specification and Verification with SCR

Part I: Introduction, simple examples, formalmodel

2

Why write specifications?

“ Real programmers don’ t write specs -- usersshould consider themselves lucky to get anyprograms at all and take what they get...”

Common Wisdom 1983

The following lecture notes are adopted from an SCR tutorial given atCOMPASS’97 by C. Heitmeyer and S. Faulk. The SCRTool refers to the tooldistributed by the Naval Research Lab.

3

OutlinePart I.

◆ Introduction to specification languages and SCR

◆ Evolution and examples of industrial use

◆ Main concepts

– Example: safety-injection system

◆ Formal semantics of SCR

Part II.

◆ SCRTool (also known as “SCR* ”)

◆ Verification with SCRTool

◆ Summary

4

Formal Methods in Computer Systems

◆ Formal methods provide mathematically-based techniquesused to specify, develop and verify properties of (softwareand hardware) systems.

◆ A formal method should possess a set of guidelines or a“style sheet” :

– when can the method be applied

– how can the method be applied most effectively

◆ Tangible output - formal requirements specification

5

Users of formal specs

does thisprogramsatisfy thisspecification?

what doesthis programdo?Informal

requirements

6

System Documentation

◆ specification is a description alternative to systemimplementation

◆ serves as a communication medium between

– a client and specifier

– an implementor and specifier

– between implementors

◆ capture “what” rather than “how”

7

Programming vs Specification Languages

PL → SL

SL → PL

◆ Specifications do not have to be executable

◆ are not restricted to expressing only computable functions

◆ All programs are formal objects( and thus can be formallymanipulated - compiled and executed)

◆ Programmers can either work with informal requirementsand formal programs or use additional formalism forrequirements specification.

8

Assumptions◆ Requirements Goal: Establish and Specify what the

software must do (without describing how)

– Establish precisely as possible what is to be built

– Specify (document) results for communication

◆ Targeted to High-Assurance Systems

– Large, complex embedded applications» Traffic control, avionics, medical» Expensive and difficult to build correctly

– Real-Time constraints» Require temporal as well as logical correctness» Correct software delivers results within real time limits

– Software is safety/mission critical» small errors => BIG PROBLEMS!» High cost of failure => high cost of verification

9

Role of Correct RequirementsDEVELOPMENT

PHASE

��� ����� ����� �������������� �REQUIREMENTS

CODING

SYSTEMINTEGRATIONAND TESTING

DESIGN

REQUIREMENTSSPECIFICATION

TESTPLAN

Traceability

� ����� � � � ��� � � � � � � � � � � !"� # � $% ����� � � � ��� � � � � � !"� # � $&� � � � �' ( )&* * + , - ' . , / 0 1 2 0 3 4 * 4 0 3 4 0 .5 6 / * 4 6 . , 4 789 / 0 7 , 7 . 4 0 - :89 / ;* + 4 . 4 0 4 7 7< ( )&* * + , - ' . , / 0 1 =�4 * 4 0 3 4 0 .5 6 / * 4 6 . , 4 78> ' ? 4 . :�* 6 / * 4 6 . , 4 78�@ , 7 7 , / 0 1 - 6 , . , - ' + * 6 / * 4 6 . , 4 7A ��B�� � � C DE� � ��$ D $ � � !GF � F � # $ � � � �� � � � � � !"� # � $' ( H 4 7 . - / I 4 6 ' J 4< ( H 6 ' - 4 ' < , + , . :- ( > . ' . , 7 . , - ' + + : < ' 7 4 3�. 4 7 . , 0 J

10

Example: Temperature Control System

This system is to control a thermostat to maintain constanttemperature. The system can be turned on or off. Theuser is also allowed to set the desired temperature. Thesystem reads the current temperature and turns on theheater or the air conditioner to ensure that the desiredtemperature is maintained.

Insert picture here (thermostat.ps)

11

Specifying this system

◆ Property-oriented approach: specify which properties thesystem is supposed to have

– If the system is ON and the temperature becomes toohigh, the system will turn the air conditioner on

– If the system is ON and the temperature becomes toolow, the system will turn the heater on

– The system never runs the heater and the airconditioner at the same time

– The system should always react to the OFF switch

– The system should not continue running the heater orthe air conditioner if the temperature is within thedesired limits

12

Properties of the Thermostat

◆ Note that these are temporal properties. Can specify themusing CTL.

◆ Example:

– The system never runs the heater and the airconditioner at the same time

– If the system is ON, it is either running an airconditioner, or a heater, or is being idle

– If the temperature is too high, eventually the airconditioner will be turned on

13

Assessment of the Property-Oriented Method

◆ Advantages:

– Describes WHAT not HOW

– No implementation bias

–

◆ Disadvantages:

–

–

14

Model-Oriented Specifications

◆ Specification that defines a system’s behavior directly byconstructing a model of the system in terms of somesimple and well-understood mathematical structures.

◆ Examples:

–

–

–

15

Model of the Temperature-Control System

◆ Identify inputs:

◆ Identify outputs:

◆ Identify required relationship between input and output

◆ Does the system need to keep state? If so, what are thestates? Draw the state machine

16

Assessment of the Model-Oriented Approach

◆ Advantages:

◆ Disadvantages:

17

The Formal Methods Dilemma

◆ Standard approaches (e.g., prose specs) lack sufficient rigor tomeet high-assurance goals

◆ Formal requirements methods have desired technical virtues butindustry slow to adopt

– Capability for unambiguous specification, precision, testability, andanalyzability

– Industry concern for practicality

» Concern for difficulty to write/read, required expertise, ability toscale

» Concern for real-world issues of fuzzy or changing requirements

» Concern for fit with industrial development context

» Adds up to perceived cost/schedule risk

◆ Dilemma: Current methods don’ t meet high-assurance needs,formal methods do but perceived as impractical

18

SCR Principles (1)

◆ Separation of Concerns (divide and conquer)

– Provide distinct mechanisms for distinct concerns

– Separate requirements concerns fromdesign/implementation

» Avoid premature design/implementation decisions

» Know when to stop

– Separate “customer view” from “software view”» Improved communication

» Simpler specification

19

SCR Principles (2)

◆ Practical formalism (usability, communication)

– Formal model for capturing requirements» Precise, unambiguous, testable specifications

» Meaningful verification high-assurance properties

– “User friendly” formats and notations» Use commonly understood math (sets, functions)

» Use tabular representation for ease of writing, reading

◆ Effective automation

– Essential to making formal methods practical» Increases speed and accuracy

» Decreases cost

20

Evolution of SCR

◆ A-7E (NRL 1976 - 1984)

– Formal as possible

– Notations for ease of use

– Industrial strength: demonstrated scalability, effectiveness

◆ Parnas/Madey* (McMaster - 1991)

– Standardized A-7E model (problem domain)

– Mathematical basis for NRL formal model

◆ CoRE* (SPC 1987 - 1992)

– Standardized industrial-strength process

– Added modularization (OO) techniques, graphics

– Applied to real high-assurance development

◆ SCR* (NRL - Ongoing)

– Complete formal model

– Basis for automated formal verification (consistency checking,property verification)

21

Some Industrial Applications of SCR

◆ A-7E

◆ Lockheed C-130J, 1993-1994 (using CoRE)

◆ Ontario Hydro

– Integration with formal design/code verification

◆ Rockwell-Collins (CoRE using SCR tool)

◆ NASA Shuttle, 1997-1998 (SCR, Easterbrook + Ko)

22

Case I: The Lockheed C-130J

◆ C-130J: Lockheed’s next-generation airlifter

– New avionics, propulsion, and flight deck

– Coordination, data transfer, and control by software» 100K SLOC Ada

» All safety critical

◆ Advanced software development paradigm

– Concurrent hardware/software development (IPT’s)

– Asynchronous software development

◆ Key Goals of the C-130J Development

– Safety: consistent with FAA DO-178A Level 1 certification

– Flexibility with stability: Ability to meet market demandswithout re-engineering software

– Low risk: Maintain safety while meeting cost and schedule

– Chose CoRE/SCR as meeting these goals

23

Case II: Ontario Hydro

◆ Build/run nuclear power plants

– 25 years experience with digital systems

– Use of digital systems in safety systems led toregulatory problems

– Led to development standardization based on SCR

◆ Development framework

– SCR for requirements specification

– Captures results of hazard analysis

– Basis for formal verification of design

– Basis for verification including reviews, inspections,and testing

◆ Currently being applied on 6th system

24

Case III:Rockwell Collins Avionics*

◆ Experimental application of CoRE/SCR to generic autopilot(sanitized but real example)

– Full specification of mode logic written in CoRE

– Analysis of behavioral model using SCR tools

◆ In spite of extensive review, tool finds errors

– Found 24 errors, “many of them significant”

– one third each, constructing the model, running thecompletness and consistency checks, and executing the model

Example: Disjointness error leading to two possible flight modes(selection of Go Around leading to Pitch or Go Around mode,ambiguously)

Example: Missing case for controlled variable (Lateral ArmedAnnunciation field not defined if Nav source not selected priorto Lateral Nav Mode selection)

S. Miller, Proceedings of Formal Methods in Software Practice (FMSP), 1998.

25

The Ideal System

◆ Ideal system is a state machine whose outputs are a function ofthe history of the environment

– All digital systems approximate the ideal

– SCR approach: specify the ideal, then specify the tolerances

26

The Four-Variable Model

27

SCR and 4-Variable Model◆ Model relevant environmental quantities as mathematical

variables (called environmental variables)

(1) Monitored variables = quantities measured (e.g.,temperature, pressure, altitude)

(2) Controlled Variables = quantities affected (e.g.,displayed value, valve state, air conditioner on)

Both are either continuous or discrete

◆ Hardware allocation determines available resources

(3) Inputs = resources form which the values ofmonitored variables must be determined

(4) Outputs = resources available to affect controlledvariables

Both are always discrete

28

Altitude

sensor

Interfac

e�

MonitoredVariables

A/D

Interfac

e�

Software

input Output

ControlledVariables

Display

The 4-Variable Viewpoint: Variables

29

4 Variables of the Thermostat System

◆ Monitored quantities: On/Off switch, desired temperature,current temperature (continuous)

◆ Controlled quantities: AC, Heater

◆ Input data items - values produced by input devices:On/Off switch (Switch)

desired temperature, represented as float (DesiredTemp)

current temperature, represented as float, sampled every 3sec (CurrentTemp)

◆ Output data items: values written to the output devices thatturn the AC and the heater on and off.

◆ NAT: in a given time interval, the room temperature can onlychange by a certain amount.

30

Altitude

sensor

Interfac

e�

MonitoredVariables

A/D

Interfac

e�

Softwareinput output

ControlledVariables

Display

NATConstraints

REQ(Requirements)

IN OUT

The 4-Variable Viewpoint: Relations

31

◆ REQ: Required relation between the monitored and thecontrolled variables

◆ NAT: Constraints imposed on the system behavior byphysical laws and the system environment

◆ IN: Required relation between the monitored variables andthe system’s input data items

◆ OUT: Required relation between the controlled variables andthe system’s output data items

Four Relations Define the Software Requirements (SOFTREQ)

32

Representing SCR Relations

◆ All behavioral requirements are defined as a set of functions overthe states of SCR variables

◆ Representing state (and state changes)

– A state is a mapping of variables to values

– Condition - a predicate over the state variablesAltitude > 500 ft. or Pressure = 500 psi or ButtonPressed = true

– Event - a predicate over successive states (denotes a change instate)

@T(Altitude > 500 ft.) @T(Running=false)@T(Running=true) WHEN [Altitude > 500 ft.]

33

Representing Functions of State

◆ Representing functions of state

– A modeclass is a set of system states, called modes,which partition the monitored environment’ s statespace. Modeclasses are finite state machines used tocapture history.

– The system is exactly in one mode of each modeclass.

For the Thermostat:one modeclass, four modes: Off, Idle,RunningHeat, RunningAC.

◆ Term - a function over two or more variables or states

34

ThermostatAbove if CurrentTemp-DesiredTemp > 3

Term tempStatus = Below if DesiredTemp-CurrentTemp > 3

Normal otherwise

Mode Transition Table

Old Mode Event New ModeOff @T(Switch=On) Idle

Idle, RunningAC, @T(Switch=Off) OffRunningHeat

Idle @T(tempStatus=Above) WHEN Switch=On RunningAC

Idle @T(tempStatus=Below) WHEN Switch=On RunningHeat

RunningAC, @T(tempStatus=Normal)WHEN Switch=On IdleRunningHeat

35

Representing SCR Relations

◆ Controlled variable function - a function giving the (ideal)value of a controlled variable

◆ Controlled variable functions define visible behavior

– Specified as a set of functions written in terms ofmonitored variables, terms and modes defining:

» Ideal value: specifies the ideal value of the controlled variableover all possible states

» Accuracy: defines the allowed tolerance in value

» Timing: defines timing constraints, e.g., minimum delay anddeadline

– Together these define the set of acceptable values overall possible states of the monitored space

36

SCR Methodology: Overview

1 Identify the system outputs (controlled quantities)2 Determine the inputs that the system monitors (monitored

quantities) to produce the outputs3 Define auxiliary variables (mode classes and terms)

– functions of the inputs– help make the model concise

4 Specify the ideal system behavior5 Specify the actual system behavior (i.e., the required timing

and precision)

37

◆ Based on a control system in a real nuclear power plant*

◆ System is required to turn on safety injection when waterpressure falls below a threshold ‘Low’ .

◆ Operator can set a Block button to inhibit safety injectionand a Reset button to reset the system after blockage.

*Courtois,Parnas, “Documentation for Safety-Critical Software,” Proc., ICSE’93, Baltimore.

Example: Control Systemfor Safety Injection

Safety Injection SystemK L M N O P Q RS T U V WX Y Z [ \ Y ]^ V W U V WX Y Z [ \ Y ]

Sensor1

Sensor2

Sensor3

S T U V WX Y Z [ \ Y ]^ V W U V WX Y Z [ \ Y ]

_ T Z [ ` a T b Y T WWaterPresBlockReset

SafetyInjection Safety

injectiondevice

38

◆ Mode Class Pressure - capture three states of WaterPres ofinterest and the possible transitions among them

◆ Term Overridden - denotes condition of the injectionsystem being overridden by the operator

◆ Controlled variable SafetyInjecton - defined in terms ofterms, modes, monitored variables

*Courtois,Parnas, “Documentation for Safety-Critical Software,” Proc., ICSE’93, Baltimore.

c d e f g h e g fi j k l�f{ ... {

LowPermit.

.

.

Overriddenmd n jc o h f f{ Pressure

TooLow

High

Permitted

Example: Control System for SafetyInjection

39

Table Functions andDependencies among the Variablesp�q"r s t u v sEw x&s�y s z {&u y s r�|&s x } ~ u q y � }Et { v&� w u q v u ��} � � q � u } w s r"� u w xs ~ s y �"��q r s � w s y ��� } v�r�q {&w � {&w ���q � w q t w x&s � s�t { v&� w u q v ��} y s�s � ��&y s � � s r�u v }Ew } | {&� } y�t q y ��} v&r�x s v � sE} y sE� } � � s r��� ��� �E� �&� � � � � �&� �p�q"r s t u v sEw x&s�y s z {&u y s r�|&s x } ~ u q y � }Et { v&� w u q v u ��} � � q � u } w s r"� u w xs ~ s y �"��q r s � w s y ��� } v�r�q {&w � {&w ���q � w q t w x&s � s�t { v&� w u q v ��} y s�s � ��&y s � � s r�u v }Ew } | {&� } y�t q y ��} v&r�x s v � sE} y sE� } � � s r��� ��� �E� �&� � � � � �&� �

SafetyInjection

Overridden

Pressure

Reset

INPUTS MODES & TERMS

� � � � �   � � � � � ¡� � � � � ¢ � � � � � £Block

OUTPUTS

40

Condition Table for Safety-Injection

Mode ConditionsHigh,Permitted True False

TooLow Overridden NOT Overridden

SafetyInjection Off On

41

Event Table for Safety-Injection

Mode EventsHigh False @T(Inmode)

TooLow, @T(Block=On) @T(Inmode) ORPermitted WHEN Reset=Off @T(Reset=On)

Overridden True False

42

Mode Transition Table for Safety-Injection

Old Mode Event New ModeTooLow @T(WaterPres ≥ Low) Permitted

Permitted @T(WaterPres ≥ Permit) High

Permitted @T(WaterPres < Low) TooLow

High @T(WaterPres < Permit) Permitted

43

SCR Requirements Formal Modal

◆ What is the relationship between the Parnas-Madey FourVariable model and the implicit state machine model thatunderlies SCR specifications?

◆ How does one formally represent a condition? an event? aconditioned event?

◆ What are the semantics of SCR tables?

◆ How are the variables in SCR requirements specs (monitoredand controlled variables, mode classes, terms) related?

44

Entities, Type and System State◆ MS is the union of N pairwise disjoint sets, called mode classes.

Each member of a mode class is called a mode.

◆ TS is a union of data types, where each type is a nonempty set ofvalues

◆ VS = MS ∪ TS is the set of entity values

◆ RF is a set of entity names r. RF is partitioned into four subsets:MR, the set of mode class names, IR, the set of input variablenames, GR, the set of term names, and OR, the set of outputvariable names. For all r∈ RF, TY( r )⊆ VS is the type of theentity named r.

◆ A system state s is a function that maps each entity name r in RFto a value:

where v∈ TY(r).vrsRFr =∈∀ )(:

45

Example: System State

In the example control system are the following sets:Set of input variables: IR = { Block, Reset, WaterPres}Set of output variables: OR = { SafetyInjection}Set of terms: GR = { Overridden}Set of mode classes: MS = { Pressure}¤�¥�¦E§�¨§ © ª «�ª ¬ ª ­ «�®�¯ ® ® ­&° ª ¯&¬ § ¨�±²ª ¬ ³²¬ ³�§ ® §�® § ¬ ®"¯&´ §µ ¶ · ¸�¹ º » ¼ ½ ¼ » ¾ ¿ À�Á Â Ã Ä Â Å Ä Æ Æ Æ Ä Ç È È È Éµ ¶ · Ê ¹ Ë » º Ì Í Î Ï » Ð º Ñ Ò Î�ÀEÁ Ó�Î Ä ÓË Ë Éµ ¶ · Ô Õ Ò Ð Ö ¿ À�× Ø�· Ù » ¾ » º ¿ À�Á Ó�Î Ä ÓË Ë Éµ ¶ · ÓÚ » ¼ ¼ Ñ Û Û » Î ¿ ÀEÁ º ¼ Ü » Ä Ë ¹ Õ ¾ » ɵ ¶ · ½ ¼ » ¾ ¾ Ü ¼ » ¿ ÀEÁ × Ò Ò Ý Ò ÞEÄ ½ » ¼ ß"Ñ º º » Û Ä à�Ñ á â É

WaterPres Block Reset Pressure Overridden SafetyInjectionã ä å æ�ç ç æ�èêé ë ë ì ë íîç ï ð ñ ò æ�ç çExample of a System State

entityname

entityvalue{

{

46

Conditions

◆ Conditions are defined on the values of entities in RF.

◆ A simple condition is true, false, or a logical statement r ó v,where r∈ RF is an entity name, ô ∈ {=, ≠, >, <, ≥, ≤ } is arelational operator, and v ∈ TY(r ) is a constant value.

◆ A condition is a logical statement composed of simpleconditions connected in the standard way by logicalconnectives AND, OR and NOT.

47

Events◆ A primitive event is denoted @T(r=v), where r is an entity in RF,

and v∈ TY(r ). An input event is a primitive event @T(r=v) withr ∈ IR is an input variable.

◆ A basic event is denoted @T(c ), where c is any simple condition.

◆ A simple conditioned event is denoted @T(c ) WHEN d, where@T(c ) is a basic event and d is a simple condition or aconjunction of simple conditions.

◆ A conditioned event e is composed of simple conditioned eventsconnected by AND and OR.

The logical statement represented by a simple conditioned event is

@T(c ) WHEN d = ¬ c ∧ c’ ∧ d

(c denotes the condition in the old state, c’ - in the new state)

48

Examples: Conditions and Events

states õ õ õö® ÷ ® ø®

Ù » ¾ » º À ÓË Ë Ù » ¾ » º À ÓË Ë¸�¹ º » ¼ ½ ¼ » ¾ À ù ú úû¸�¹ º » ¼ ½ ¼ » ¾ À ú È ÈÙ » ¾ » º À ÓË Ë¸�¹ º » ¼ ½ ¼ » ¾ À Ç Å

7 , ;* + 4 - / 0 3 , . , / 0ýü 4 7 4 . þ ÿ ? ? � ü 4 7 4 . þ ÿ ? ? � . 6 � 4 , 07 ' 0 37 �� ' . 4 6 5 6 4 7 � � ÷ ÷ � ' . 4 6 5 6 4 7 � � ÷ ÷ . 6 � 4 , 07 � ? ' + 7 4 , 07 �- / 0 3 , . , / 0 ü 4 7 4 . þ ÿ ? ? )���= ü 4 7 4 . þ ÿ ? ? )���= . 6 � 4 , 07 � ? ' + 7 4 , 07 �� ' . 4 6 5 6 4 7 � � ÷ ÷ � ' . 4 6 5 6 4 7 � � ÷ ÷ü 4 7 4 . þ ÿ ? ? ÿ ü ü 4 7 4 . þ ÿ ? ? ÿ ü . 6 � 4 , 07 ' 0 3�7 �� ' . 4 6 5 6 4 7 � � ÷ ÷ � ' . 4 6 5 6 4 7 � � ÷ ÷* 6 , ;, . , I 4 4 I 4 0 . H � � ' . 4 6 5 6 4 7 þ � ÷ ÷ � � ' . 4 6 5 6 4 7 ≠ � ÷ ÷ )���= . 6 � 4 , 07 � 7 �� ' . 4 6 5 6 4 7 � þ � ÷ ÷ H � ü 4 7 4 . þ ÿ ? ? � ü 4 7 4 . þ ÿ ? ? � ? ' + 7 4 , 07 � 7 �ü 4 7 4 . � þ ÿ ? ?

� ë è � � � � ë è ò �Eò � ò è � H � � ' . 4 6 5 6 4 7 þ � ÷ ÷ � � ' . 4 6 5 6 4 7 ≠ � ÷ ÷ )���= . 6 � 4 , 07 � 7 ������ � ü 4 7 4 . þ ÿ ? ? � ' . 4 6 5 6 4 7 � þ � ÷ ÷ )���=ü 4 7 4 . þ ÿ ? ?

� � � � �&� � � � ��� � � � � ����� � � � � � ��� � �� � � � � �

49

System

A systemΣ is a 4-tuple, Σ = (Em, S, s0, T), where

◆ Em is a set of input events

◆ S is the set of possible system states

◆ s0 is the initial state

◆ T, the system transform, is a partial function from Em x Sinto S

50

Condition Tables

51

Condition Table: Example

Modes ConditionsHigh,Permitted True False

TooLow Overridden NOT Overridden

SafetyInjection Off On

Based on the new state dependencies set

{Pressure, Overridden}

and the above condition table, the function for Safety_Injection, denotedF6, is defined bySafety_Injection =F6 (Pressure, Overridden) =

Off if Pressure = High ∨ Pressure = Permitted ∨(Pressure = TooLow ∧ Overridden = true)

On if Pressure = TooLow ∧ Overridden = false

52

Event Tables

53

Event Table: Example

54

Mode Transition Tables

55

Mode Transition Table: Example

56

Partial Ordering of the Variables

57

Four Different Notations with the SameUnderlying Semantics

)&+ + ÿ ! " h n # j $ % j $� ' 6 3 & ' , +' 4 I

��6 3 ��6 3( ) *,+�- .0/ *,+�- 1 2 +�3�465�- +0- 1 504

7 h 8 o 9 k j : ; < = > ? @ A B @ A C D E = C F G H @ I J F F K L J M BN O P ? @ A @ F B @ A C Q @ I D = C F @ > R S T U MV W X Y Z H X F [ Y C Z \ D = C F @ > J M B O C ] @ B @ A C Q @ \ D = C F @ > ^T = H > E = C F C D E = C F G H @ I < = > ? @ A B @ A J M BV N O P W X Y Z H X F [ Y C Z I D = C F @ > R K _ N O P O C ] @ B @ A C Q @ I D = C F @ > R ^K _ C D E = C F G H @ I J F F K L J M B N O P ? @ A @ F B @ A C Q @ I D = C F @ > RS T U M V W X Y Z H X F [ Y C Z \ D = C F @ > J M BO C ] @ B @ A C Q @ \ D = C F @ > ^*Depends on definitions in 3A.

J. van Schouwen, D. Parnas, J. Madey, “Documentation of Requirements forComputer Systems,” Proc., RE’93, San Diego, Jan. ‘93.

` a ) - +0b c�3 +0de4�5�- +�- 1 504gf h i j�k l m n o p q j r

)&+ + ÿ !ts ' 4 I ��6 3" h n # j $ % j $ sus ��6 3� ' 6 3 & ' , +vsws x& ' , + � 6 4 )&+ + ÿ ! " h n # j $ % j $ � ' 6 3 & ' , +

y�z { |~} � � � � | � � � �0� � | � �

� � @ H @ � T H > I N O P W X Y Z H X F [ Y C Z I D = C F @ > R K _ N O P O C ] @ B @ A C Q @ I D = C F @ > R? @ A I N O P ? @ A @ F B @ A C Q @ I D = C F @ > R S T U MV W X Y Z H X F [ Y C Z I D = C F @ > R J M B O C ] @ B @ A C Q @ I D = C F @ > ^� �

` � ) - +�b c�3 +0d,465�- +�- 1 504�f � a � � � r

)&+ + ÿ ! ? ?� H�� ' 3 ' 4 I =&4 I H 1 1 � ' 6 3 & ' , +1� H 1

� ' 3 ' 4 I =�4 I� H 1 1 � ' 6 3 & ' , +1� H 1

� � � � | � �y�z { |

�0| �y�z { |

TimeD

evice

=fail

ed

� � � � � �� � �� �   ¡ ¢� � £ ¤

¥ ¦ § ¦¨ ©¦ §ª « ¦ ¬ ­ ®ª ¨ ¦ ¯

° ) ±0d +0² .�1 2 +036465�- +0- 1 504