曝光臺(tái) 注意防騙 網(wǎng)曝天貓店富美金盛家居專(zhuān)營(yíng)店坑蒙拐騙欺詐消費(fèi)者

specification language and emulators of the requirements are written. The emulators serve
the purpose of a prototype to test the code for correctness of functional behavior.
Structured development to requirements analysis then rigorous development down to
source code performs all of the steps from the previous paragraph. The source code
undergoes a verification process that resembles a proof but falls short of one.
Structured development down to source code is the application of the structured
analysis/structured design method. It consists of a conceptual diagram that graphically
illustrates functions, data structures, inputs, outputs, and mass storage and their
interrelationships. Code is written based on the information in the diagram.
Ad hoc techniques encompass all of the non-structured and informal techniques (i.e.
hacking, code a little then test a little).
J.5.12 Requirements State Machines
Requirements State Machines (RSM) are sometimes called Finite State Machines (FSM). An RSM is a
model or depiction of a system or subsystem, showing states and the transitions between the states. Its goal
is to identify and describe ALL possible states and their transitions. RSM analysis can be used on its own, or
as a part of a structured design environment, e.g., object oriented design or formal methods.
Whether or not formal methods are used to develop a system, a high level RSM can be used to provide a
view into the architecture of an implementation without being engulfed by all the accompanying detail.
Semantic analysis criteria can be applied to this representation and to lower level models to verify the
behavior of the RSM and determine that its behavior is acceptable. The analysis criteria will be listed in a
section below and in subsequent sections because they are applicable at practically every stage of the
development life cycle.
Characteristics of State Machines
A formal description of state machines can be obtained from texts on Automata Theory. This description
will only touch on those properties that are necessary for a basic understanding of the notation and
limitations. State machines use graph theory notation for their representation. A state machine consists of
states and transitions. The state represents the condition of the machine and the transition represent changes
between states. The transitions are directed (direction is indicated by an arrow), that is, they represent a
directional flow from one state to another. A trigger or input that is labeled on the transition induces the
transition from one state to another. Generally the state machine produces an output.
The state machine models should be built to abstract different levels of hierarchy. The models are
partitioned in a manner that is based on considerations of size and logical cohesiveness. An uppermost level
model should contain at most 15 to 20 states; this limit is based on the practical consideration of
comprehensibility. In turn, each of the states from the original diagram can be exploded in a fashion similar
to the bubbles in a data flow diagram/control flow diagram (DFD/CFD) (from a structured
analysis/structured design methodology) to the level of detail required. An RSM model of one of the lower
levels contains a significant amount of detail about the system.
The states in each diagram are numbered and classified as one of the following attributes: Passive, Startup,
Safe, Unsafe, Shutdown, Stranded and Hazard. For the state machine to represent a viable system, the
diagram must obey certain properties that will be explained later in this work.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-21
The passive state represents an inert system, that is, nothing is being produced. However, in
the passive state, input sensors are considered to be operational. Every diagram of a system
contains at least one passive state. A passive state may transition to an unsafe state.
The startup state represents the initialization of the system. Before any output is produced,
the system must have transitioned into the startup state where all internal variables are set to
known values. A startup state must be proven to be safe before continuing work on the
remaining states. If the initialization fails, a timeout may be specified and a state transition
to an unsafe or passive state may be defined.
Properties of Safe State Machines
There are certain properties that the state machine representation should exhibit in order to provide some
degree of assurance that the design obeys certain safety rules. The criteria for the safety assertions are based
on logical considerations and take into account input/output variables, states, trigger predicates, output
predicates, trigger to output relationship and transitions.
　
中國(guó)航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統(tǒng)安全手冊(cè)下(139)