IEEE 148-2000 pdf download IEEE Standard for Verication of Vital Functions in Processor-Based Systems Used in Rail Transit Control
2.References
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.
3. Abbreviations, acronyms, and definitions
3.1 Definitions
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.
3.1.1 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 selectedare determined and identified.
3.12 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 stateor shall cause the system to assume a state known to be safe.
3.1.3 fail-safely: The implementation of a function in a fail-safe manner.
3.1.4 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.
3.1.5 functional fault tree (FFT): A structured analysis method used to identify vital functions at the system 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.
3.1.7 hardware failure: A change in the characteristics of a system hardware element beyond its designtolerances.
3.1.8 hazard: An existing or potential condition that can result in a mishap
3.1.9 implementation level: The level of verification activities at which system components implementingvital functions are comprehensively identified and analyzed to verify that all functions identified as vital areimplemented fail-safely.
3.1.10 mean time between hazardous events (MTBHE): The average time between occurrences of events.where hazardous events and the equipment that may precipitate them are defined at the system level. Thehazardous events included in MTBHE are those whose consequences are of a gven severity, as determinedby the organization generating the safety goals.
3.111 mishap: An unplanned event or series of events resulting in death, injury, occupational illness, ordamage to or loss of equipment or property, or damage to the environment; an accident.
3.1.12 safe: Having acceptable risk of the occurrence of a hazard
3,1.13 safety assurance: A characteristic of the implementation of a system that assures a level of safeoperation.
3.1.14 safety assurance concept: A design concept applied to processor-based systes that assures the failsafe implementation of identified functions, including safe operation in the presence of hardware failuresand/or software errors. Examples are: Checked Redundancy; Diversity and Self-Checking: NumericalAssurance: and N-Version Programming.
3.1.15 safety-critical: A term applied to a syste or function, the correct performance of which is critical tosafety of personnel and/or equipment; also a term applied to a system or function, the incorrect performanceof which may result in an unacceptable risk of a hazard.
3.1.16 safety yalidation: A structured and managed set of activities that demonstrate that the system, asspecified and implemented, performs the intended functions, and that those functions result in overall safeoperation. Validation answers the question, “Did we build the right system?”
3.1.17 safety verification: A structured and managed set of activities that identify the vital functionsrequired to be performed by the system. and demonstrate that the system, including its subsvstems. inter.faces and components.implements the vital functions fail-safely to a level that meets the allocated systemsafety goals. Verification answers the question, “Did we build the system right?”
IEEE 148-2000 pdf download
PS:Thank you for your support!