IEEE 1474.4-2011 pdf download
IEEE 1474.4-2011 pdf download.IEEE Recommended Practice for Functional Testing of a Communications- Based Train Control (CBTC) System.
4.1.4 Application-specific requirements
The correctness of application-specific data (i.e.. infrastructure data, such as curves. grades. station locations, etc.. and train-specific data, such as braking rates and response times. etc.) and that this data has been correctly implemented within the system databases, should aLso be verified as an clement of the functional test process.
When resignalrng with a CHTC system, application-specific external (legacy) equipment interfaces. application-specific operating modes, and application-specific functional requirements are common. This can result in application-specific designs that should be reflected in the application-specific functional test process. To exploit the operational capabilities of CHT(’ systems. the design of a (‘HTC system is oftcn integrated with the design of other fixed operating clements of a rapid transit system such as traction power systems, tunnel and station ventilation systems, passenger infonnation and security systems, and backbone communications networks. tir example. In addition, the designs of the onboard train locationspeed nicasurement subsystems arc also often application-specific due to vehicle-specitic interfaces. As such, the pcrtbrinancc of these application-specific designs should be verified through the functional test process.
4.2 CBTC applications
The CBTC functional test process for resignaling applications can be significantly more onerous than signaling new lines, primarily because of the need to maintain revenue operations and the integnty of the existing signaling system during the migration to the new CHTC system, which in turn results in track access limitations and the need to support mixed modes of operation. In addition, the specific signaling’train control system being replaced is typically different from one application to another.
NOTE—For the purposes of this recommended practice, and for consistency with IEEE Std 1474.3-200g. the CItC sysLcm is assumed to interlace with an cxtcrnal separate interlocking subsystem, which is more cumnion for rcsignaling applications. As a corssequciwe. this recommended practice does not include testing of interlocking functions, but does include the testing of functional interfaces between CHIC and external interloekings’
5. Overall test process
5.1 General
This recommended practice addresses system-level functional testing only, as an integral element of the overall test process, to serif in the factory, on a CHTC test track, and in the field that the CHTC system functional requirements have been satisfied, as highlightcd in Figure I.
This recommended practice does riot address unit testing at a module level, subsystem tests, hardware qualification tests, hardware post-installation check-out testing, and data communications coverage testing, which arc all necessary prerequisites to system-level functional testing. Trial operations. reliabilityavailabilityimaintainabiIity demonstrations and other customer-specific final acceptance testing arc also not included
If a functionsub-function has been previously verified in one application, it may not be necessary to retest the functionsub-flinction in a subsequent application, based on consideration of any ditlrrences in hardware, software, system databases, and operating environment.
5.2.2 Subsystem testing
All lower-level testing at the subsystem level should be completed. In addition, prior to test track and field functional testing. the post installation check-out of all applicable hardware should be completed, to include both wayside and train-borne CBTC cquipmcnL
For the CHTC data communications subsystem. thc nctwork pertormance and availability should be verified, supported by analysis, as necessary, of wome-ca%c conditions that Cannot be easily duplicated in the factory or in the fiekL
5.2.3 Documentation requirements
l)ocumentation requirements with respect to system-level test plans (including migration strategy. extent of testing, and responsibilities of all parties involved in the test process), test pwcedures. pasafail criteria, and test results should be defined.
5.2.4 Simulation facility verification
Any simulation facilities that are to be used for factory or CBTC test track testing should be verified as being appropriately representative of the equipment and interbces being simulated.
5.3 Database verification
Correct functioning of a CBTC system is critically dependent upon application-specific databases that include infrastructure data, train data, and CIITC data. Infrastructure data and vehicle data is specific to the particular application. CHTC data is specific to the particular CHTC system design for that application.
5.3.1 VerIfying infrastructure data
Any infrastructure input data required by the (.BTC system such as alignment data (location and value of all grades, curves. civil speed limits, etc.). track layout (location of switches and terminal track configuration), and location of all stations and platform stopping positions, for example, should be verified against appropnate survey data at a level of precision appropriate to the application-specific CBTC performance requirements. The party responsible for vcritiing infrastructure data should be clearly ideniiticd.
