Output File Formats

From DESUMA Wiki
Output File Formats
Jump to: navigation, search

The description of each element is found in italics with { } directly underneath it.

Contents

Diagnoser

Total Diagnoser States = 33 Id = 1

{Diagnoser State ID = 1}

V1, P3, C1 F4

{FSM State}

V1, P3, C1 F1F4

{FSM State}

Total pairs = 2

{# Pairs in diagnoser state}

Certain: F4

{Failure (and indicator) types that are certain}

Uncertain: F1

{Failure (and indicator) types that are uncertain}

OV, PP, F -> 10

{Event transition and next diagnoser state}

OV, PP NF -> 8

{Event transition and next diagnoser state}

PP, NF -> PP, F -> 4

{Event transition and next diagnoser state}

Id = 2

... ...

... ...


Diagnoser FSM

The diagnoser FSM is written in the standard standard fsm format. Simplified Diagnoser The simplified diagnoser has the following changes from the regular diagnoser format: Each diagnoser state has the following format: ID number, followed by a Certain attribute field, followed by an Uncertain attribute field, followed by the next events and states. The list of state, label pairs that are present in the regular diagnoser format, as well as the total pairs field, is removed. Normal states are indicated by an empty Certain field and an empty Uncertain field. When the state label pairs include a normal sate along with other failed states, a N label appears in the Uncertain field. Total Diagnoser States = 33 Id = 1

{Diagnoser State ID 1}

CertThe description of each element is found in italics with { } directly underneath it. Individual FSM

The default for each event (transition) is controllable and observable (c and o). If an event is uncontrollable and unobservable, you may specify so after the new state with 'uc' and 'uo'. If the event is either uncontrollable but observable or unobservable but controllable, you may simply state the variable ('uc' or 'uo') that describes the negative characteristic. Please note that you may ignore 'uc' and 'uo' completely if you choose to create the unobservable events file manually by writing this text file. If you choose to use the routine write_uo, you have to state the event properties in the machine.fsm files. Also, the program called "add_prop" adds the uc and uo properties to all events in the FSM file based on the events.uo and events.uc inputs.

4 {# of states}

VC 1/0 4 {State} {Marked/Unmarked} {# of Transitions}

SC1 VSC {Event} {New State}

CV VC

..... ......

Optionally, additional events not appearing in transitions can be added to a machine. To do this, after the last state and transition, add a new line beginning with the key word EVENTS. After this line, additional events can be listed in the format for an event list. i.e. to add uncontrollable and unobservable event 'a' to an FSM, add the following at he end of the file.

EVENTS

a uc uo

Fi-indeterminate cycles

The simplified diagnoser has the following changes from the regular diagnoser format: The first line of the dcycle output is the first Fi-indeterminate cycle. The Ids of the diagnoser state followed by the transitions to the next state are linked together with a '->'. The uncertain failure types in the cycle and the FSM states which compose each diagnoser state are then listed.

4 d -> 2 n -> 3 g -> 4

{1st D state} {Failure event} {2nd D State} {Failure Event} {3rd D state} {Failure event} {Failure event}

Uncertain: F1

{Uncertain failure types in cycle}

Diagnoser State 4 contains the following FSM states:

5

10

12

... ...

... ...


Fi-indeterminate Cycles for Multiple Failure Diagnoser and (Fi,li)-indeterminate Cycles

6 4 5 {1st D_state} {2nd D_state} {3rd D_state}

... ...

... ...


List of States that Violate Opacity Constraints

After opacity verification functions are run on an FSM, an output file will be created. This output file will list the states in the observer that violate opacity. The states will be listed as sets, since the observer is used to verify opacity.

{state1, state2}
{state2}

In the above example, the output file g.states lists two states in the observer that violate opacity constraints. In other words, the states {state1, state2} and {state2} cause the system to be not opaque. If g.states is empty, there are no states that violate opacity, thus the system is opaque.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
EECS @ UM
Tools