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

software and heavy demand on CPU resources, scheduling and timing conflicts etc.
Computational Delay: Computers take a finite time to read data and to calculate and output
results, so some control parameters will always be out of date. Controls systems must
accommodate this. Also, check timing clock reference datum, synchronization and accuracy
(jitter). Analyze task scheduling (e.g., with Rate Monotonic Analysis (RMA)).
J.4 Structured Design Phase Techniques
Structured design techniques greatly reduce the number of errors, especially requirements errors which are
the most expensive to correct and may have the most impact on the overall safety of a system. These
Structured Analysis and Design methods for software have been evolving over the years, each with its
approach to modeling the needed world-view into software. The most recent analysis/design methods are
Object Oriented Analysis & Design (OOA & OOD) and Formal Methods. To date, the most popular analysis
methods have been Functional Decomposition, Data Flow (or Structured Analysis), and Information
Modeling. OOA actually incorporates some of the techniques of all of these within its method, at lower
levels, once the system is cast into objects with attributes and services. In the discussion of Structured
Analysis, “analysis“ is considered as a process for evaluating a problem space (a concept or proposed
system) and rendering it into requirements that reflect the needs of the customer. Functional Decomposition
has been, and still is, a popular method for representing a system. Functional Decomposition focuses on
what functions, and sub-functions, the system needs to perform and the interfaces between those functions.
The general complaints with this method are 1) the functional capability is what most often changes during
the design life cycle and is thus very volatile, and 2) it is often hard to see the connection between the
proposed system as a whole and the functions determined to create that system. A detailed discussion of
Structured Analysis and Formal Methods appears in Appendix D of this handbook.
J.4.1 Architectural Design Analysis
The software architectural design process develops the high level design that will implement the software
requirements. All software safety requirements developed above are incorporated into the high-level software
design as part of this process. The design process includes identification of safety design features and
methods (e.g., inhibits, traps, interlocks and assertions) that will be used throughout the software to
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-11
implement the software safety requirements. After allocation of the software safety requirements to the
software design, Safety Critical Computer Software Components (SCCSCs) are identified. Bottom-up safety
analysis is performed on the architectural design to identify potential hazards, to define and analyze SCCSCs
and the early test plans are reviewed to verify incorporation of safety related testing. Analyses included in the
Architectural Design Phase are:
·  Update Criticality Analysis
·  Conduct Hazard Risk Assessment
·  Analyze Architectural Design
·  Interdependence Analysis
·  Independence Analysis
·  Update Timing/Sizing Analysis
J.4.2 Update Criticality Analysis
The software functions begin to be allocated to modules and components at this stage of development. Thus
the criticality assigned during the requirements phase now needs to also be allocated to the appropriate
modules and components.
Software for a system, while often subjected to a single development program, actually consists of a set of
multi-purpose, multifunction entities. The software functions need to be subdivided into many modules and
further broken down to components.
Some of these modules will be safety critical, and some will not. The criticality analysis provides the
appropriate initial criticality designation for each software function. The safety activity relates identified
hazards from the following analyses previously described to the Computer Software Components (CSCs)
that may affect or control the hazards.
This analysis identifies all those software components that implement software safety requirements or
components that interface with SCCSCs that can affect their output. The designation Safety Critical
Computer Software Component (SCCSC) should be applied to any module, component, subroutine or other
software entity identified by this analysis.
J.4.3 Conduct Risk Assessment
The safety activity performs a system risk assessment to identify and prioritize those SCCSCs that warrant
　
中國航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統(tǒng)安全手冊下(132)