Thời gian thực - hệ thống P6

Safety Assertion in English: If the train needs at least 45 s to travel from the sensor position to the railroad crossing, and the train crossing is completed within 60 s fromthe time th

On the other hand, a behavioral specification shows only the response of eachbraking system component in response to an internal or external event, but does notdescribe how one can build such a system For instance, this specification shows thatwhen the wheel sensors detect wet road conditions, the decision-making computerwill instruct the brake mechanism to pump the brakes at a higher frequency within

100 ms Since we are interested in the timing properties of the system, a behavioralspecification without the complexity of the structural specification often suffices forverifying the satisfaction of many timing constraints Furthermore, to reduce specifi-cation and analysis complexity, we restrict the specification language to handle onlytiming relations This is a departure from techniques that employ specification lan-guages capable of describing logical as well as timing relations, such as real-timeCTL

148

Copyright ¶ 2002 John Wiley & Sons, Inc.

ISBN: 0-471-18406-3

EVENT-ACTION MODEL 149

6.1 SPECIFICATION AND SAFETY ASSERTIONS

To show that a system or program meets certain safety properties, we can relatethe specification of the system to the safety assertion representing the desired safetyproperties This assumes that the actual implementation of the system is faithful tothe specification Note that even though a behavioral specification does not show howone can build the specified system, one can certainly show that the implemented sys-tem, built from the structural-functional specification, satisfies the behavioral speci-fication

One of the following three cases may result from the analysis relating the cation and the safety assertion:

specifi-1 The safety assertion is a theorem derivable from the specification, thus thesystem is safe with respect to the behavior denoted by the safety assertion

2 The safety assertion is unsatisfiable with respect to the specification, so the tem is inherently unsafe since the specification will cause the safety assertion

sys-to be violated

3 The negation of the safety assertion is satisfiable under certain conditions,meaning that additional constraints must be added to the system to ensure itssafety

The specification and the safety assertion can be written in one of several time specification languages The choice of language would in turn determine thealgorithms that can be used for the analysis and verification We begin the study withthe event-action model and a first-order logic called real-time logic (RTL) [Jahanianand Mok, 1986]

real-6.2 EVENT-ACTION MODEL

The event-action model [Heninger, 1980; Jahanian and Mok, 1986] captures the datadependency and temporal ordering of computational actions that must be taken inresponse to events in a real-time application There are four basic concepts

1 An action is a schedulable unit of work and can be primitive or composite A primitive action is atomic in that it cannot or does not need to be broken into

subactions for the purpose of analysis It consumes a bounded amount of time

A composite action is a partial ordering of primitive actions or other composite

actions The same action may appear more than once in a composite action.Recursive actions and circular chains of actions where an action is a subaction

of its predecessor in the chain are not allowed

The notation A;B indicates that the sequential execution of action A is lowed by action B For example, TRAIN-APPROACH;DOWN-GATE meansthat the train first approaches the railroad crossing sensor, then the gate moves

fol-down The notation A
B indicates the parallel execution of action A and action

B For example, DOWN-GATE
RING-BELL means that the moving-down ofthe gate and the ringing of the alerting bell happen simultaneously

2 A state predicate is an assertion about the state of the specified system For

example, GATE-IS-DOWN is true if the gate is in the down position

3 An event is a temporal marker for indicating a point in time that is significant

in describing the system behavior There are four classes of events:

(a) An external event is caused by actions outside the specified system.

For example, APPLY-BRAKE is an external event which means thepressing of the brake pedal by the drive or operator

(b) A start event marks the beginning of an action, for example, the start

of the DOWN-GATE action

(c) A stop event marks the end of an action, for example, the end of the

DOWN-GATE action

(d) A transition event marks the change in a certain attribute of the system

state For example, GATE-IS-DOWN becomes true when the gate ismoved to the down position

4 A timing constraint is an assertion about the absolute timing of system events.

re-For example, conventional temporal logic can specify that an action B followsanother action A such as TRAIN-APPROACH followed by DOWN-GATE, but can-not specify that DOWN-GATE will occur within a certain time period (say 5 s) afterthe occurrence of TRAIN-APPROACH Furthermore, temporal logic uses an inter-leaving model of computation to specify concurrency in computer systems, but thismodel cannot express true parallelism For example, temporal logic models two par-allel actions as if one is followed by the other or vice versa, so that from an initial

state s0 there are two paths, corresponding to the two orderings of these actions,

leading to state s1

A scheduler is often an integral part of a real-time system The correctness of areal-time system depends on the correctness of its scheduler Temporal logic, how-ever, usually assumes the fair scheduling of the specified system’s resources andevents This is appropriate for non-time-critical systems but certainly is not suffi-cient for the analysis of real-time systems

REAL-TIME LOGIC 151

RTL is based on the event-action model, augmented with several features such

as the occurrence function @, which assigns time values to event occurrences

@(TrainApproach, i) = x means that the ith occurrence of the train approach

oc-curs at time x There are three types of RTL constants: actions, events, and integers.

Action constants are as defined in the event-action model and capital letters are used

to denote them to distinguish them from variables A subaction B i of a composite

action A is denoted as A.B i Event constants serve as temporal markers and areclassified into: (1) start events indicating the beginning of actions, preceded by↑;(2) stop events indicating the end of actions, preceded by↓; (3) transition eventsindicating the change in certain attributes of the system state; and (4) external events,preceded by.

Example We now use RTL to specify a simple railroad crossing with one train rail.

From the field measurements and the knowledge about the mechanical characteristics

of the train, train sensor, gate controller, and gate, we obtain the following tions The goal of the gate controller is to ensure that when the train is crossing theintersection of the road with the rail, no car is on the intersection In this simplifiedversion, this is achieved by having the gate in the down position when the train iscrossing

specifica-Specification in English: When the train approaches the train sensor and is detected

by the sensor, a signal is sent to the gate controller to initiate the lowering of the gate

at the railroad crossing

The gate will be moved to the down position within 30 s from the time when thetrain approach is detected by the sensor

The gate needs at least 15 s to lower itself to the down position

Safety Assertion in English: If the train needs at least 45 s to travel from the sensor

position to the railroad crossing, and the train crossing is completed within 60 s fromthe time the train is detected by the sensor, then we are assured that at the start

of the train crossing the gate has moved to the down position and that the train leavesthe railroad crossing within 45 s from the time the gate has completed moving to thedown position

We now show the specification and the safety assertion in RTL

Specification in Presburger Arithmetic Formulas:

∀x f (x) ≤ g1(x) ∧ g2(x) ≤ f (x) + 30

∀yg1(y) + 15 ≤ g2(y)

Safety Assertion in Presburger Arithmetic Formulas:

∀t∀u f (t) + 45 ≤ h(u) ∧ h(u) < f (t) + 60 →

g2(t) ≤ h(u) ∧ h(u) ≤ g2(t) + 45

In these formulas, t , u, x, and y are variables, f , g1, g2, and h are uninterpreted integer functions f corresponds to the occurrence function for event TrainApproach.

g1corresponds to the occurrence function for the start of action Downgate g2

corre-sponds to the occurrence function for the end of action Downgate h correcorre-sponds to

the occurrence function for event Crossing

The problem of determining whether SA follows from SP is in general able for the full set of RTL formulas, so not all analysis problems of this type can

undecid-be solved For the subclass of RTL formulas that are decidable, the solutions stillrequire exponential run time

Several ways are available to improve the efficiency of the analysis First, wecan use approximations to yield a simpler set of specification and safety assertionsfor analysis Second, we can focus the analysis on the part of the specification that

is relevant to the validity of the given safety assertions Third, we can restrict thespecification language so that less general but more efficient analysis procedures can

be applied Here we consider the third approach

6.4 RESTRICTED RTL FORMULAS

One restricted class of RTL formulas [Jahanian and Mok, 1987] is motivated by thefact that in the specification of many real-time systems:

graph-each inequality is of the form x i − x j ≤ ±a i j where x i and x j are variables

and a i j is an integer constant We can also use a constraint graph to representthe set of inequalities Each variable is presented by a node in the graph, and

an inequality x i ± a i j ≤ x jis represented by a directed edge with weight±a i j connecting x i to x j Then, a set of inequalities represented by such a graph

is unsatisfiable iff a cycle is present in the graph with a positive total weight

on it

As a result of these observations, we restrict the RTL formulas to consist of metic inequalities of the following form:

arith-occurrence function± integer constant ≤ occurrence function.

Note that @(E1, i)±I < @(E2, j) can be rewritten as @(E1, i)±I +1 ≤ @(E2, j).

Also,¬(@(E1, i)±I ≤ @(E2, j)) can be rewritten as @(E2, j)±I +1 ≤ @(E1, i).

All formulas in the preceding railroad crossing example satisfy this restriction andthus are in this RTL subclass However, the formula

corre-placed by a function f e (i) where e is an event and i is an integer or a variable Next,

we express Fin clausal form Fin preparation for the analysis Fis a formula ofthe form

C1∧ C2∧ · · · ∧ C n Each C i is a disjunctive clause

L1∨ L2∨ · · · ∨ L n and each L j is a literal of the form

v1± I ≤ v2wherev1andv2are uninterpreted integer functions corresponding to the occurrence

functions and I is an integer constant.

Given a system specification SP and a safety assertion SA expressed in the stricted RTL subclass, the goal is to show that SA is a theorem derivable from SP,that is, SP→ SA This is equivalent to showing that the negation of SP → SA, that

re-is,¬(SP → SA), is unsatisfiable Since SP → SA can be rewritten as ¬SP ∨ SA,

our analysis is to prove that the formula SP∧¬SA is unsatisfiable The followingexample shows the clausal form of the specification and the negation of the safetyassertion of the preceding example

Example Consider SP and ¬SA in clausal form T and U are Skolem constants corresponding to variables t and u, respectively.

Specification in Clausal Form:

Negation of Safety Assertion in Clausal Form:

¬(∀t∀u f (t) + 45 ≤ h(u) ∧ h(u) < f (t) + 60 → g2(t)

CHECKING FOR UNSATISFIABILITY 155

Rewriting the formula in clausal form yields the following three clauses:

Algorithm Build Graph: Initially, the graph G is empty.

For each clause C i , for each literal in C i:v1± I ≤ v2:

1 Find the cluster with the function symbol of termv1 If not found, create a newcluster

2 Search the cluster found or created in step 1 for a node labeledv i If not found,add the node labeledv1to the cluster (Note that if the cluster has just beencreated in step 1, the search is not necessary as the cluster is empty.)

3 Repeat steps 1 and 2 for the termv2

4 Create a directed edgev1, v2 with weight ± I from node v1to nodev2

Figure 6.1 shows the construction of the constraint graph corresponding to the aboveexample specification and negation of the safety assertion

6.5 CHECKING FOR UNSATISFIABILITY

We can use the constructed constraint graph G representing Fto determine whether

Fis unsatisfiable by identifying cycles with positive weights in G To do so, we firstdefine unification and then redefine the concepts of a path and a cycle for this type

of graph

Unification: We say there is a unification ofv i andv

i if a substitution S (whichreplaces a term by another term) exists such that v iS = v

iS where v iS andv

iSdenote the terms after applying S tov iandv

i, respectively

Chapter 2 contains a discussion of unification as well as related concepts, and vides examples

30

g1(x)f(x)

0

15

g1(x)f(x)

h(U)f(T)

0

0

g1(x)f(x)

b

g1(x)f(x)

a

g2(x)30

30

g2(x)

30

g1(x)f(x)

g2(x)e

46-59

145

g2(T)f

c 0 15 g2(x)

30

g1(x)f(x)

Figure 6.1 Constructing the constraint graph corresponding to example

EFFICIENT UNSATISFIABILITY CHECK 157

Path: We say there is a path from node v0 to nodev n in a graph G if there is a

Now we are ready to show that if there is a cycle with positive weight in the

graph G corresponding to formula F, then the formula consisting of the conjunction

of literals (inequalities) corresponding to the edges in the cycle is unsatisfiable We

apply the substitution S to each inequality L i in the cycle

I0+ I1+ · · · + I n−1≤ 0,

which is clearly unsatisfiable, meaning that the original RTL inequalities ing to these edges are unsatisfiable

correspond-6.6 EFFICIENT UNSATISFIABILITY CHECK

We have shown that if every edge in a positive cycle corresponds to a literal that

belongs to a unit clause, then the formula Fmust be unsatisfiable, and hence thesafety assertion SA is derivable from the specification SP However, if an edge inthe cycle corresponds to a literal that belongs to a non-unit clause, then we have

to show that each of the remaining literals in this clause corresponds to an edge

in a different positive cycle The intuitive reason behind this is that the clause isdisjunctive Therefore, to show that the entire clause is unsatisfiable (false), each ofits disjuncts must be shown to be unsatisfiable (false) In our example, the negation

of the safety assertion contains the clause

h (U) + 1 ≤ g2(T ) ∨ g2(T ) + 46 ≤ h(U).

If an edge in a positive cycle that corresponds to h (U) + 1 ≤ g2(T ) is identified,

then we also have to show that another positive cycle exists with an edge

correspond-ing to the second literal g2(T ) + 46 ≤ h(U).

Obviously, as the number of edges in positive cycles that correspond to literalsbelonging to non-unit clauses increases, the number of different positive cycles thatmust be identified increases combinatorially In fact, the problem of determining the

unsatisfiability of F is NP-complete Considering the difficulty of the problem, amore efficient, but still exponential-run-time, algorithm is developed in [Jahanianand Mok, 1987] to check for unsatisfiability

The algorithm makes use of the following observations Recall that the

for-mula Fis a conjunction of n clauses

C1∧ C2∧ · · · ∧ C n , where each C kis a disjunctive clause

L k ,1 ∨ L k ,2 ∨ · · · ∨ L k ,m k

Note that the literals in different clauses need not be distinct We use the following

notations to denote the inequalities corresponding to the edges in the i th positive

cycle found:

X i ,1 , X i ,2 , , X i ,n i , where X i , j is the literal corresponding to the j th edge in the i th positive cycle found, and each X i , j is in at least one of the C ks Suppose

P i = X i ,1 ∧ X i ,2 ∧ · · · ∧ X i ,n i

We know from the above discussion that P i is unsatisfiable Therefore, F is

satisfiable iff F∧ ¬P i is satisfiable As a result, the existence of the positive cycle

is equivalent to adding the clause

¬P i = ¬X i ,1 ∨ ¬X i ,2 ∨ · · · ∨ ¬X i ,n i

to F, making it possible to use¬P i to show that Fis unsatisfiable.

Example We use capital letters to denote the literals in the set S1 of clauses of F:

A = f (x) ≤ g1(x)

B = g2(x) − 30 ≤ f (x)

C = g1(y) + 15 ≤ g2(y)

EFFICIENT UNSATISFIABILITY CHECK 159

The unsatisfiability check algorithm builds a search tree using the clauses in

set S2, and while doing so, determines the unsatisfiability of the clauses in sets S1

and S2 Each new level in the tree is the result of examining a new clause in S2responding to a new positive cycle found Each node in the tree is either one literal

cor-in a clause of S2or the conjunction of literals in different clauses of S2 In our

ex-ample, the nodes in the first level correspond to literals in the first clause of S2, that

E

E

F

F G

is, literals¬F and ¬G To build the second level, the algorithm adds the literals in

the second clause of S2, that is, literals¬B, ¬D, and ¬F, to each subtree rooted byliterals¬F and ¬G Similarly, the algorithm constructs the remaining levels in the

tree Figure 6.2 shows the worst-case search tree for the set S2 A worst-case tree isone in which all conjunctions of literals are explored However, in practice, a largenumber of nodes need not be constructed (1) by checking for unsatisfiability as soon

as the algorithm creates a new node or (2) by rearranging the order of the clauses in

S2according to certain heuristics to reduce the size of the tree

To prove that the conjunction of clauses in S1and S2is unsatisfiable, we need toshow that each leaf node in the tree satisfies one of the following two conditions:

(1) the conjunction of literals in the leaf node and at least one clause in S1is false, or(2) the conjunction of literals in the leaf node is by itself unsatisfiable

The first condition follows from basic logic: C k ∧ ¬C k where C k is a clause in

set S1and¬C k is the conjunction of literals in a leaf node; that is,

(L k ,1 ∨ L k ,2 ∨ · · · ∨ L k ,m k ) ∧ (¬L k ,1 ∧ ¬L k ,2 ∧ · · · ∧ ¬L k ,m k )

is always false, making the collection of clauses in S1 and S2 unsatisfiable Theleftmost leaf node of our example tree is the conjunction¬F ∧ ¬B ∧ ¬A, which can be “and-ed” with either of the first two clauses of S1, that is, A or B, makingthe conjunction false Since the conjunction of literals in every leaf node of the tree

makes at least one clause in S1is unsatisfiable, we can conclude that the collection

of clauses in S1and S2is unsatisfiable The second condition follows from a similarreasoning

6.6.1 Analysis Complexity and Optimization

In the worst case, where the full search tree is constructed using all positive cyclesdetected, the running time of the unsatisfiability check algorithm is exponential with

respect to the number of positive cycles found For example, if there are n positive cycles and each cycle has m edges, there are m literals in each clause with only negated literals in S2 Therefore, there are m nleaf nodes (conjunctions) in the worst-

case search tree and thus the running time is proportional to m n

Several ways are available to reduce the size of the search tree and hence speed

up the analysis The first optimization approach stops expanding a node if its labeled

conjunction of negated literals makes S1 unsatisfiable If a newly created node in

the tree has a conjunction of negated literals that makes a clause in S1unsatisfiable,then every node in the subtree rooted by that node has the same property and thusneeds not be generated In our example search tree, the nodes in the subtree rooted

by the node labeled(¬F, ¬B) need not be created since this conjunction together with the second clause, B, of S1is false, and hence this node makes S1unsatisfiable.Similarly, the nodes in the subtree rooted by the node labeled(¬F, ¬D) need not be created since this conjunction together with the fourth clause, D, of S1is false, and

hence this node makes S unsatisfiable

INDUSTRIAL EXAMPLE: NASA X-38 CREW RETURN VEHICLE 161

F A

F G

F C

F E F

F G F

D B

Figure 6.3 Rearranging positive cycles to trim the search tree

The second optimization approach rearranges the order of the clauses in S2responding to the positive cycles found) so that the first approach can be applied assoon as possible, that is, closer to the root of the search tree This may require back-tracking by undoing the generation of a tree node In our example search tree, thenode labeled(¬F, ¬B) makes S1 unsatisfiable because¬B “and-ed” with the sec-ond clause, B, is false Note that the first negated literal¬F does not contribute to

(cor-the unsatisfiability of S1 We can reject the first positive cycle by rearranging the firstand second clauses, corresponding to the first and second positive cycles found, sothat the second clause appears first This makes it possible to declare unsatisfiability

of S1for two nodes¬B and ¬D at the first level of the tree This approach may trimthe tree under many conditions, as shown in Figure 6.3

The third optimization approach, which is not pointed out in [Jahanian and Mok,1987], reuses the unsatisfiability of previously generated nodes to declare that anewly generated nodev makes S1 unsatisfiable if the labels ofv have been gen-

erated earlier In our example, note that the labels of the last node(¬F, ¬G) are the

same as those of a previous leaf node

6.7 INDUSTRIAL EXAMPLE: NASA X-38 CREW RETURN VEHICLE

Now we use RTL to specify and analyze the timing properties of the avionics ofthe X-38, a family of vehicles built as incremental development prototypes for theCrew Return Vehicle (CRV) of the International Space Station (ISS) The CRV,planned for a 2003 launch on board the Space Shuttle, will be attached to the ISSand will have the capability to automatically and safely bring to earth a crew ofseven passengers in the event of an emergency ISS evacuation The CRV will be de-signed to autonomously perform all guidance, navigation, and control functions, thedeorbit burn, a parafoil-assisted glide through the atmosphere, and will be designed

to land horizontally at one of several predetermined landing sites

The X-38 131 model vehicle was successfully drop-tested from a B-52 in March

1998 to demonstrate body design and parafoil landing The X-38 132 model will crementally employ increased automatic guidance capability and will undergo sev-eral atmospheric drop tests The immediate precursor to the CRV, the X-38 281model vehicle, is being designed and is planned for a 2001–2002 on-orbit deploy-ment from the Space Shuttle It will perform the CRV functions of automatic guid-ance, re-entry, glide, and landing, but be unmanned Here we focus on the X-38 201vehicle avionics design A more detailed description and analysis of the X-38 avion-ics is found in [Rice and Cheng, 1999]

pro-6.7.2 Timing Properties

For safety and verifiability reasons, all X-38 avionics design efforts have focused

on designing a system that is highly deterministic The quad-redundant design ofthe four FCCs relies on Byzantine agreement (a voting and message-passing proto-col) to tolerate a single Byzantine fault [Pease, Shostak, and Lamport, 1980; Lam-port, Shostak, and Pease, 1982] Because of this design, tasks are required to run atthe same time in all processors, with results of their processing being voted every20-ms “minor” frame The ICP and FCP processors are thus synchronized to thesame 20-ms processing frame Another example of similar real-time fault-tolerantavionics is the quad-redundant fly-by-wire flight control of the Lockheed F-117Astealth fighter aircraft Other examples of fault-tolerant avionics include the Boe-ing 777 Integrated Airplane Information Management System [Yeh, 1998] and theAirbus 340 Flight Warning System

We consider a snapshot of the anticipated task timing relationships for the X-38vehicle The most critical control loop begins 18 ms into the processing frame wherethe ICP inputs all 50 Hz (cycles per second) sensor data These data are passed to theFCP, which reads the sensor data, processes them, and provides output actuator com-mands back to the ICP The ICP then reads and issues those commands to affectedactuators To effect safe guidance of the vehicle, this whole processing loop must becompleted within 10 ms To ensure this type of deterministic processing, tasks are

INDUSTRIAL EXAMPLE: NASA X-38 CREW RETURN VEHICLE 163

generally assigned fixed priorities based upon the Rate-Monotonic Scheduling rithm presented in chapter 3, and scheduling is partially accomplished with the aid

algo-of a cyclic executive

6.7.3 Timing and Safety Analysis Using RTL

To analyze and verify system timing properties, we use RTL, described in this ter, to specify the safety-critical aspects of the X-38 system As we have seen, RTLallows timing and safety analysis which may flexibly be used for what-if scenarios aswell as life-cycle system verification, and may be extensible to represent broader as-pects of the X-38 avionic system The two X-38 flight-critical control loops, as well

chap-as one non-flight critical control loop and the chap-associated safety chap-assertion, are eled After converting the RTL representation into a Presburger arithmetic formatand ultimately a constraint graph, cycle analysis verifies safety assertion satisfaction

mod-6.7.4 RTL Specification

This section presents the RTL specification for a representative set of X-38 tasks.The tasks listed under “workload and event definitions” contain the workloads inmilliseconds (ms) for each task modeled Nomenclature of the task names are thatthe first three characters define the processor; the next character designates eitherI(input), P(process), or O(output); the number identifies the speed of the process

in Hertz or cycles per second, next is the criticality such as FC(flight-critical) orNFC(non-flight-critical); and last is any other necessary information such as data

type The variable i represents the loop count or iteration number For example, the

set of tasks in the flight critical 50-Hz control loop are the first five listed and areshown below

; 50HzFCworkloads

∀i@(↑ ICP I50FC SENSOR, i) + 2 ≥ @(↓ ICP I50FCSENSOR, i)

∀i@(↑ FCP I50FC, i) + 1 ≥ @(↓ FCP I50FC, i)

∀i@(↑ FCP P50FC, i) + 5 ≥ @(↓ FCP P50FC, i)

∀i@(↑ FCP O50FC, i) + 1 ≥ @(↓ FCP O50FC, i)

∀i@(↑ ICP I50FC CMDS, i) + 1 ≥ @(↓ ICP I50FC CMDS, i)

The workload for the first task, designated “Instrumentation Control Processor(ICP) Input (I) of 50 Hz Flight Critical (FC) Sensor Data,” is a maximum of 2 ms.The above group of tasks are representative of the ICP reading all 50-Hz flight-critical sensors, such as flap, rudder positions, and Global Positioning System data;passing that data to the FCP as input; having the guidance application process thatdata and formulate command output; passing that output to the ICP; and having theICP actuate the command This list is the first of two flight-critical timing loops, re-quiring completion within 10 ms for safe vehicle control The 10-Hz flight-critical

control loop is similar, but a loop completion time of 50 ms, rather than 10 ms, isrequired This completion requirement is represented in the safety assertion section.The non-flight-critical tasks only receive sensor input, produce no command out-put, and are included as a representation of the many non-flight-critical tasks thatrun in the background but whose execution is not considered safety-critical Theprecedence-relations section depicts the order in which the tasks must execute Forexample, to properly specify system behavior, it must be stated that the end of anytask must not occur before its beginning.

∀i@(↑ ICP I50FC SENSOR, i) ≤ @(↓ ICP I50FC SENSOR, i)

Furthermore, the beginning of the next task to execute must not occur before theend of its predecessor In this case, the FCP’s input of flight critical data must happenafter the ICP’s 50 Hz sensor scan

; 50 Hz FC precedence relations

∀i@(↓ ICP I50FC SENSOR, i) ≤ @(↑ FCP I50FC, i)

A precedence relationship between the end of the successor task and the tion of the predecessor task must also be represented In this case, the FCP’s input

initia-of flight-critical data should happen at or before the completion initia-of the ICP’s sensorscan predecessor task workload In reality, we want the FCP I50FC task to happenprecisely after the completion of the ICP I50FC SENSOR task, but this truth is cap-tured by the clauses cited above in addition to the workload definition

∀i@(↑ FCP I50FC, i) − 2 ≤ @(↑ ICP I50FC SENSOR, i)

The priority assertions loosely mimic a rate-monotonic scheduling paradigm inwhich the higher rate tasks have priority over lower rate tasks For example, thefollowing formula states that the flight-critical 50-Hz task has precedence over theflight-critical 10-Hz task

∀i@(↓ FCP I50FC, i) ≤ @(↑ FCP I10FC, i)

; 50 Hz FC higher priority than 10 Hz FC

∀i@(↓ FCP I50FC, i) ≤ @(↑ FCP I50NFC, i)

; 50 Hz FC higher priority than 50 Hz NFCThe periodicity section simply defines the rates at which the tasks execute, in ms,and in this case they are to run precisely every 20 or 100 ms, so they are found inpairs as follows

∀i@(↑ ICP I50FC SENSOR, i) + 20 ≤ @(↑ ICP I50FC SENSOR, i + 1)

∀i@(↑ ICP I50FC SENSOR, i + 1) − 20 ≤ @(↑ ICP I50FC SENSOR, i)

INDUSTRIAL EXAMPLE: NASA X-38 CREW RETURN VEHICLE 165

Finally, the safety assertion, shown below, states that each of the flight-criticalcontrol loops, the 50-Hz and the 10-Hz, from initial sensor read through commandactuation, must execute within 10 and 50 ms, respectively

∀i@((↓ ICP I50FC CMDS, i) ≤ @(↑ ICP I50FC SENSOR, i) + 10 ∧ (↓ ICP I10FC CMDS, i) ≤ @(↑ ICP I10FC SENSOR, i) + 50)

The negation of the safety assertion is ultimately used to verify safety-criticalsystem performance through constraint graph analysis

RTL System Specification Representation:

Workload and event definitions:

; 50 Hz FC workloads

∀i@(↑ ICP I50FC SENSOR, i) + 2 ≥ @(↓ ICP I50FCSENSOR, i)

∀i@(↑ FCP I50FC, i) + 1 ≥ @(↓ FCP I50FC, i)

∀i@(↑ FCP P50FC, i) + 5 ≥ @(↓ FCP P50FC, i)

∀i@(↑ FCP O50FC, i) + 1 ≥ @(↓ FCP O50FC, i)

∀i@(↑ ICP I50FC CMDS, i) + 1 ≥ @(↓ ICP I50FC CMDS, i)

; 10 Hz FC workloads

∀i@(↑ ICP I10FC SENSOR, i) + 2 ≥ @(↓ ICP I10FCSENSOR, i)

∀i@(↑ FCP I10FC, i) + 1 ≥ @(↓ FCP I10FC, i)

∀i@(↑ FCP P10FC, i) + 40 ≥ @(↓ FCP P10FC, i)

∀i@(↑ FCP O10FC, i) + 1 ≥ @(↓ FCP O10FC, i)

∀i@(↑ ICP I10FC CMDS, i) + 1 ≥ @(↓ ICP I10FC CMDS, i)

; 50 Hz NFC workloads

∀i@(↑ ICP I50NFC SENSOR, i) + 5 ≥ @(↓ ICP I50NFCSENSOR, i)

∀i@(↑ FCP I50NFC, i) + 1 ≥ @(↓ FCP I50NFC, i)

Precedence relations:

; precedence between start and stop events

∀i@(↑ ICP I50FC SENSOR, i) ≤ @(↓ CP I50FCSENSOR, i)

∀i@(↑ FCP I50FC, i) ≤ @(↓ FCP I50FC, i)

∀i@(↑ FCP P50FC, i) ≤ @(↓ FCP P50FC, i)

∀i@(↑ FCP O50FC, i) ≤ @(↓ FCP O50FC, i)

∀i@(↑ ICP I50FC CMDS, i) ≤ @(↓ ICP I50FC CMDS, i)

∀i@(↑ ICP I10FC SENSOR, i) ≤ @(↓ ICP I10FCSENSOR, i)

∀i@(↑ FCP I10FC, i) ≤ @(↓ FCP I10FC, i)

∀i@(↑ FCP P10FC, i) ≤ @(↓ FCP P10FC, i)

∀i@(↑ FCP O10FC, i) ≤ @(↓ FCP O10FC, i)

∀i@(↑ ICP I10FC CMDS, i) ≤ @(↓ ICP I10FC CMDS, i)

∀i@(↑ ICP I50NFC SENSOR, i) ≤ @(ICP I50NFCSENSOR, i)

∀i@(↑ FCP I50NFC, i) ≤ @(FCP I50NFC, i)

; precedence between beginning of prior task and beginning of next

∀i@(↑ FCP I50FC, i) − 2 ≤ @(↑ ICP I50FC SENSOR, i)

∀i@(↑ FCP P50FC, i) − 1 ≤ @(↑ FCP I50FC, i)

∀i@(↑ FCP O50FC, i) − 5 ≤ @(↑ FCP P50FC, i)

∀i@(↑ ICP I50FC CMDS, i) − 1 ≤ @(↑ FCP O50FC, i)

∀i@(↑ FCP I10FC, i) − 2 ≤ @(↑ ICP I10FC SENSOR, i)

∀i@(↑ FCP P10FC, i) − 1 ≤ @(↑ FCP I10FC, i)

∀i@(↑ FCP O10FC, i) − 40 ≤ @(↑ FCP P10FC, i)

∀i@(↑ ICP I10FC CMDS, i) − 1 ≤ @(↑ FCP O10FC, i)

∀i@(↑ FCP I50NFC, i) − 5 ≤ @(↑ ICP I50NFC SENSOR, i)

∀i@(↑ FCP P50NFC, i) − 1 ≤ @(↑ FCP I50NFC, i)