IEEE 1474.4-2011 pdf free

IEEE 1474.4-2011 pdf free.IE EE Recommended Pra ctice for Functional Testing of a Com munications-Based Train Control (CBTC) System.
With train location determination independent of fixed-block track circuits, alternative control strategies become possible (where movement authority limits are not constrained by physical fixed-block track circuit boundaries) that should be reflected in the CBTC functional test process. Certain test practices for fixed- block, track circuit-based signaling systems may no longer be applicable or practicable, and alternative test procedures are necessary to reflect the specific principles of operation of CBTC systems.
4.1.2 Bidirectional train-to-wayside data communications
The performance and availability of a geographically continuous train-to-wayside and wayside-to-train data communications network is critical to CBTC operations. Hence, as an element of the system level functional testing, the network performance and availability (including network stability, data-link bandwidth, and message latency) should be verified, supported by analysis, as necessary, of worse-case conditions that cannot he easily duplicated in the factory or in the field.
4.1.3 Train-borne and wayside vital processors
The distributed CBTC wayside and train-borne vital processors that process the train status and control data and provide continuous automatic train protection (ATP). automatic train operation (ATO), and automatic train supervision (ATS) functions are typically highly integrated. As a consequence, the final functional testing can only be performed at a systems level with all major CBTC subsystems operational and with multiple vehicles operating. CI3TC systems also typically include significant levels of equipment redundancy to achieve the high system availability required. The need to verify the overall stability of such a distributed computer system and the need to verify switchover capabilities between redundant sets of wayside and’or train-borne CBTC equipment also should be reflected in the functional test process.
(‘BTC systems—typical of other advanced technology systems—are software/database driven. In such complex software-based systems it is important to understand that whereas the majority of software development often occurs prior to field testing, the software development process does not end until the system is verified to be operating correctly in the field. Multiple software releases arc also typically required in a given application (specifically for complex cut-overs in a resignaling application) resulting in a need for a defined level of regression testing following each software update.
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 element of the functional test process.
When resignaling with a CRTC system. application-specific external (legacy) cquipmcnt 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 CBTC systems, the design of a CBTC system is often integrated with the design of other fixed operating elements of a rapid transit system such as traction power systems. tunnel and station ventilation systems. passenger information and security systems. and backbone communications networks, for example. In addition, the designs of the onboard train location/speed measurement subsystems are also often application-specific due to vehicle-specific interfaces. As such, the performance of these application-specific designs should be verified through the functional test process.
4.2 CBTC applications
The CI3TC 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 integrity of the existing signaling system during the migration to the new (‘BTC system, which in turn results in track access limitations and the need to support mixed modes of operation. In addition, the specific signalingitrain control system being replaced is typically different from one application to another.IEEE 1474.4 pdf free download.