IEEE 1483-2000 pdf free.IEEE Standard for Verification of Vital Functions in Processor-Based Systems Used in Rail Transit Control.
IEEE 1483 This standard shall be used in conjunction with the following publication. If the following publication issuperseded by an approved revision, the revision shall apply.In case of a conflict between this standard andthe referenced document, this standard shall take precedence. Those provisions of the referenced documentthat are not in conflict with this standard shall apply as referenced.
MIL-Std-882C:1996,System Safety Program Plan Requirements.
For the purposes of this standard, the following terms and definitions apply. IEEE 100-1996, The IEEEStandard Dictionary of Electrical and Electronic Terms [B13],- should be referenced for terms not defined inthis clause.
concept level: The level of verification activities at which vital functions and vital implementationrequirements,imposed on the system’s design and implementation by the safety assurance concept selected,are determined and identified.
fail-safe: A design philosophy applied to safety-critical systems such that the result of hardware failureor the effect of software error shall either prohibit the system from assuming or maintaining an unsafe state,or shall cause the system to assume a state known to be safe.
fail-safely: The implementation of a function in a fail-safe manner.
fault tree analysis (FTA): A structured analysis method used to comprehensively identify faults andcombinations of faults of software and hardware components as they relate to a hazard.
functional fault tree (FFT): A structured analysis method used to identify vital functions at the sys-tem functional level by comprehensively examining system functional faults that could precipitate hazards.3.1.6 functional level:The level of verification activities at which vital system functions are identified fromsystem functional and operational requirements.
Each safety assurance concept has an associated set of factors upon which the fail-safe implementation ofvital functions is dependent, that is, “dependent factors,”and a set of critical assumptions. The dependentfactors shall be identified and used to subsequently identify concept-specific design and developmentrequirements.The critical assumptions shall be identified and included in the concept level documentation.
NOTE—Again using Checked Redundancy as an example, dependent factors include: the ability of the comparisonmechanism to detect all discrepancies that affect safe operation; frequency of comparison; the extent to which failures inone redundant element are detectable at the points of comparison; executable software correctness; and others.
A Checked Redundancy concept-specific design requirement related to the dependent factor,frequency of comparison,would be that the interval between comparison of the outputs of each redundant unit be implemented fail-safely such thatit is no greater than a specified time.
One example of a concept-specific development requirement associated with the dependent factor“softwarecorrectness”would be that the software is developed in accordance with a process that ensures a specified level ofcorrectness.
Verification methods shall be identified at the concept level. Verification methods shall comprise analysis,demonstration，test,and/or inspection applied to products and processes， as required, to verify that theprocessor-based system fail-safely implements all vital functions, both those identified at the concept leveland those identified at the functional level, to the degree required by the system safety goals.IEEE 1483 pdf download.