1、The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2000 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 5 April 2000. Printed in the United States of America.Print: ISBN 0-7381-1966-0 SH94825PDF
2、: ISBN 0-7381-1967-9 SS94825No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.IEEE Std 1483-2000 (R2007)IEEE Standard for Verification ofVital Functions in Processor-Based Systems Used in R
3、ail Transit ControlRail Transit Vehicle Interface Committeeof theIEEE Vehicular Technology SocietyApproved 30 March 2000Reaffirmed 5 December 2007IEEE-SA Standards BoardAbstract: A set of standard verification tasks for processor-based equipment used in safety-criticalapplications on rail and transi
4、t systems is covered. This standard also covers processes that verifythe level of safety achieved in the implementation of safety-critical functions that are required to befail-safe. Quality assurance or validation processes that affect the overall level of system safety arenot covered.Keywords: rai
5、l, safety, safety critical, software, transit, verification, vitalAuthorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on June 1, 2009 at 10:18 from IEEE Xplore. Restrictions apply.Copyright 2000 IEEE. All rights reserved.1IEEE Standard for Verification ofVital Functions in Processo
6、r-Based Systems Used in Rail Transit Control1. OverviewThis standard defines a method for the identification and subsequent verification of vital functions imple-mented in processor-based equipment used in safety-critical applications on rail and transit systems. Thisstandard requires the production
7、 of analyses and other supporting documentation necessary to demonstratethe achievement of the established safety goals.This standard is limited to verifying fail-safe implementation of functions in processor-based equipment.This includes the identification of the functions that must be implemented
8、fail-safely, the allocation of thosefunctions to specific hardware and/or software components of the system, the identification of how thosehardware and/or software components are expected to achieve the desired fail-safe operation (safety assur-ance concept), and the verification that the hardware
9、and/or software component implements the functions ina fail-safe manner (see 3.1.2 for the definition of fail-safe used in this standard). This standard is intended tocomplement the execution of a total system safety program, and does not address all system safety issues.Detailed system, subsystem,
10、and interface hazard analyses, hazard tracking, and risk assessment are consid-ered part of the overall system safety program and, while elements of such hazard analyses may be requiredand/or referenced, generation of the analyses is not within the scope of this standard.Throughout this standard the
11、 term system will be used. A system may be an entire transit or railroad controlsystem, or it may be a subsystem or device, such as a track circuit or vehicle overspeed control unit. Theapplication of this standard requires that the system or subsystem being verified is clearly defined, includingits
12、 place within the overall system, and that all assumptions and interface requirements are clearlydocumented.This standard is divided into five clauses. Clause 1 provides the scope and purpose of this standard. Clause 2lists references to other standards that are useful in applying this standard. Cla
13、use 3 provides definitions thatare either not found in other standards, or have been modified for use with this standard. Clause 4 describesthe verification approach, dividing it into activities performed at three levels: functional, concept, andimplementation. Clause 5 defines analyses and supporti
14、ng documentation required to identify the imposedsafety design requirements derived from each of the three levels, to allocate those safety requirements to thevarious components of the system, and, finally, to confirm that the safety goals have been attained.The standard also contains three annexes.
15、 Annex A provides description and examples of techniques,analyses, and procedures that may be used in completing the concept-level tasks established in Clause 5.Annex B provides an example of the application of this standard. Annex C is a bibliography.It is not intended that systems installed prior
16、to the effective date of this standard comply with this standard.Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on June 1, 2009 at 10:18 from IEEE Xplore. Restrictions apply.IEEEStd 1483-2000 IEEE STANDARD FOR VERIFICATION OF VITAL FUNCTIONS IN2Copyright 2000 IEEE. All rights
17、reserved.1.1 ScopeThis standard provides a set of standard verification tasks for processor-based equipment used in safety-critical applications on rail and transit systems. The scope of this standard shall encompass, and be limitedto, processes that verify the level of safety achieved in the implem
18、entation of safety-critical functions thatare required to be fail-safe. This standard does not address quality assurance or validation processes, whichalso affect the level of overall system safety achieved. Figure 1 illustrates the elements of the safety verification process (within the dotted box)
19、 in the context ofthe overall system safety and design and development processes.1.2 PurposeThe purpose of this safety verification process standard is to provide a well-defined and well-structured setof analysis methods and documentation that Fulfills the primary purpose of the verification process
20、. Is flexible enough to accommodate all viable design methods. Satisfies the safety requirements of the end user.Figure 1Safety verification standard context diagramAuthorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on June 1, 2009 at 10:18 from IEEE Xplore. Restrictions apply.IEE
21、EPROCESSOR-BASED SYSTEMS USED IN RAIL TRANSIT CONTROL Std 1483-2000Copyright 2000 IEEE. All rights reserved.3This standardDefines a necessary and sufficient set of analyses at the concept, functional, and implementationlevels that comprehensively identify and verify all functions required to be impl
22、emented as fail-safe.Defines responsibilities for equipment suppliers and end users.2. ReferencesThis 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
23、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.13. Abbreviations, acronyms, and definitions 3.1 Defin
24、itionsFor the purposes of this standard, the following terms and definitions apply. IEEE 100-1996, The IEEEStandard Dictionary of Electrical and Electronic Terms B13,2should be referenced for terms not defined inthis clause.3.1.1 concept level:The level of verification activities at which vital func
25、tions and vital implementationrequirements, imposed on the systems design and implementation by the safety assurance concept selected,are determined and identified.3.1.2 fail-safe:A design philosophy applied to safety-critical systems such that the result of hardware failureor the effect of software
26、 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.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 comprehensiv
27、ely 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 sys-tem functional level by comprehensively examining system functional faults that coul
28、d 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 ha
29、zard:An existing or potential condition that can result in a mishap.1MIL publications are available from Customer Service, Defense Printing Service, 700 Robbins Ave., Bldg. 4D, Philadelphia, PA19111-5094.2The numbers in brackets correspond to those of the bibliography in Annex C.Authorized licensed
30、use limited to: IHS Stephanie Dejesus. Downloaded on June 1, 2009 at 10:18 from IEEE Xplore. Restrictions apply.IEEEStd 1483-2000 IEEE STANDARD FOR VERIFICATION OF VITAL FUNCTIONS IN4Copyright 2000 IEEE. All rights reserved.3.1.9 implementation level:The level of verification activities at which sys
31、tem 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
32、 that may precipitate them are defined at the system level. Thehazardous events included in MTBHE are those whose consequences are of a given severity, as determinedby the organization generating the safety goals.3.1.11 mishap:An unplanned event or series of events resulting in death, injury, occupa
33、tional 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 assu
34、rance concept:A design concept applied to processor-based systems that assures the fail-safe 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;
35、 and N-Version Programming.3.1.15 safety-critical:A term applied to a system 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
36、.3.1.16 safety validation: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 safet
37、y 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 subsystems, inter-faces and components, implements the vital functions fail-safely to a level that meets the allocated sys
38、temsafety goals. Verification answers the question, “Did we build the system right?”3.1.18 self-revealing component failures:Component failures whose effects on system operation areimmediately and clearly apparent to a properly trained person.3.1.19 software error:An error in a software element whic
39、h, when executed, results in unintended systemoperation.3.1.20 system safety:The application of engineering and management principles, criteria, and techniques tooptimize all aspects of safety within the constraints of operational effectiveness, time, and cost throughoutall phases of the system life
40、 cycle. 3.1.21 system safety goalsquantitative:A quantitative limit of the probability and/or frequency withwhich any vital function fails to be implemented safely.3.1.22 system safety program:The combined tasks and activities of system safety management and systemsafety engineering that enhance ope
41、rational effectiveness by satisfying the system safety requirements in atimely, cost-effective manner throughout the system life cycle.3.1.23 system safety program plan: A formal document that fully describes the planned safety tasksrequired to meet the system requirements, including organizational
42、responsibilities, methods ofAuthorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on June 1, 2009 at 10:18 from IEEE Xplore. Restrictions apply.IEEEPROCESSOR-BASED SYSTEMS USED IN RAIL TRANSIT CONTROL Std 1483-2000Copyright 2000 IEEE. All rights reserved.5accomplishment, milestones,
43、depth of effort, and integration with other program engineering andmanagement functions.3.1.24 unsafe:Having unacceptable risk of the occurrence of a hazard.3.1.25 vital function:A function in a safety-critical system that is required to be implemented in a fail-safemanner.NOTEVital functions are a
44、subset of safety-critical functions.3.2 Abbreviations and acronymsASCE American Society of Civil EngineersATP automatic train protectionCENELEC European Committee for Electrotechnical StandardizationFFT functional fault treeFMEA failure modes and effects analysisFTA fault tree analysisIEC Internatio
45、nal Electrotechnical CommissionIEEE Institute of Electrical and Electronics EngineersISO International Organization for StandardizationMTBHE mean time between hazardous eventsPHA preliminary hazard analysisSSHA subsystem hazard analysisSSIHA subsystem interface hazard analysisSSn-FTA subsystem fault
46、 tree analysisSSPP system safety program planSVP safety verification plan4. Safety verification approachComprehensive safety verification shall include the identification of vital functions and the verification thatthe identified vital functions have been implemented fail-safely to the degree requir
47、ed by the system safetygoals.The activities associated with safety verification shall be divided into the following three levels: Concept level Functional level Implementation levelFigure 2 illustrates the three levels and their relationships. These levels correspond to different areas ofsafety veri
48、fication. Concept-level activities shall analyze the safety assurance concept employed, identify theconcept-specific design requirements necessary for the fail-safe implementation of vital functions, andidentify the concept-specific verification methods. Functional-level activities shall identify al
49、l user-specifiedsystem functions required to be implemented fail-safely. Implementation-level activities shall apply theverification methods determined at the concept level to the implemented system to ensure that the identifiedset of vital functions has been implemented fail-safely.Software and hardware components implementing vital functions are thus identified from two sources; theuser specified system functional requirements identified at the functional level, and concept-specific designAuthorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on June
