Input File Formats

From DESUMA Wiki
Input File Formats
Jump to: navigation, search
m
Line 2: Line 2:
  
  
=== Individual FSM ===
+
== Individual FSM ==
  
  
Line 27: Line 27:
  
  
=== Stochastic Information for an FSM ===
+
== Stochastic Information for an FSM ==
  
  
Line 45: Line 45:
  
  
=== Sensor Data Map (compose)===
+
== Sensor Data Map (compose)==
  
  
Line 59: Line 59:
  
  
=== Global Sensor Map for the System (sensmap) ===
+
== Global Sensor Map for the System (sensmap) ==
  
  
Line 75: Line 75:
  
  
=== Events Map for the System (I-Diagnosability) ===
+
== Events Map for the System (I-Diagnosability) ==
  
  
Line 90: Line 90:
  
  
=== Failure Partition for Building Diagnoser ===
+
== Failure Partition for Building Diagnoser ==
  
  

Revision as of 18:10, July 29, 2013

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


Contents

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


Stochastic Information for an FSM

The machine.stoc file can be created using the create_sfsm routine. You need to have the machine you want to add probabilities to already created.

{FROM STATE name} {TO STATE name} {EVENT name} {Probability}

S1 S2 a 0.5

S1 S2 b 0.5

S2 S4 e 0.7

..... ...... ...... ......

In the above g.ft, we have partitioned {Stuck Closed 1, Stuck Closed 2} as failure type 1 and {Stuck Open 1, Stuck Open 2} as failure type 2.


Sensor Data Map (compose)

The sensor data map contains the state of each sensor for every state of the system. For large systems part of the map creation process can be automated using sensmap. The sensor data map contains one line for each state and corresponding sensor values.


C9, V1, P4, F2, B2, L1 PNP, NF
{State} {Sensor values at this state}

C9, V3, P3, F2, B2, L1 PPP, F

.... .... .... ....


Global Sensor Map for the System (sensmap)

Sensmap is a utility to help automate the creation of sensor data maps for use with the compose routine. For each state in the global sensor map, sensmap searches for states in the system with that state as a substring. It then assigns the corresponding sensor values to that FSM state. The states in the global sensor map must have components ordered the same way as in sync.fsm. 10 {# of pairs of mapping}

P1 PNP, NF
{State Components} {Sensor1, Sensor2} {Assigns all states containing string p1 to have sensor values PNP,NF}

P4 PNP, NF
{State Components} {Sensor1, Sensor2} {Assigns all states containing string P4 to have sensor values PNP, NF}

.... .... .... ....


Events Map for the System (I-Diagnosability)

Events.ift contains information about the indicator events and the failure partition each indicator event detects. 6
{# of pairs mapping}

CV 1
{indicator event} {Failure Type}

OV 2

... ... ... ...


Failure Partition for Building Diagnoser

The g.ft data file can be created from the sync.uo. From the sync.uo, we append the failure type for each unobservable event. SC1 1
{Unobservable Event} {Failure Type}

SC2 1

SO1 2

... ... ... ...

In the above g.ft, we have partitioned {Stuck Closed 1, Stuck Closed 2} as failure type 1 and {Stuck Open 1, Stuck Open 2} as failure type 2.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
EECS @ UM
Tools