Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
CSA R7004-17: Requirements for Onboard Automatic Train Control Software in Railway Operations
Technical requirements, implementation guidelines, and compliance framework for ATC software safety and performance
1. Scope
CSA R7004-17 applies to the software elements of onboard automatic train control (ATC) equipment used in mainline and urban rail vehicles operating within Canadian jurisdiction. The standard covers the entire software lifecycle, from specification through design, verification, validation, and maintenance. It is intended for manufacturers, integrators, and railway operators who develop or procure safety-critical software for ATC subsystems, including speed supervision, brake assurance, and train integrity monitoring.
The scope explicitly includes software developed in accordance with safety integrity levels (SIL) as defined by IEC 61508, but tailors the requirements for the railway domain. CSA R7004-17 does not cover non-ATC onboard systems such as diagnostics or passenger information, though interaction with these systems is addressed.
Tip: CSA R7004-17 is often used in conjunction with CSA R7003-17 (hardware requirements) and the overarching system safety standard CSA R7000-17.
2. Technical Requirements
2.1 Safety Integrity Levels (SIL)
The standard mandates that ATC software functions be assigned a SIL from 0 to 4, with SIL 4 being the most rigorous. The SIL allocation must follow a hazard analysis and risk assessment per CSA R7000-17. Each software element must then meet corresponding systematic capability thresholds.
| SIL | Failure Rate Range (per hour) | Required Design Techniques | Independence of Verification |
|---|---|---|---|
| 0 | No safety requirement | Standard quality management | None |
| 1 | ≥ 10-6 to < 10-5 | Structured programming, peer review | Independent reviewer |
| 2 | ≥ 10-7 to < 10-6 | Modular design, static analysis, unit testing | Independent team |
| 3 | ≥ 10-8 to < 10-7 | Formal methods, code generation, fault injection testing | Independent department |
| 4 | < 10-8 | Proven-in-use evidence, diverse software, semiautomatic generation | Third-party assessor |
2.2 Software Development Process
The standard defines a V-model lifecycle with specific activities at each phase:
- Software Requirements: Traceability to system hazards and SIL allocation.
- Design: Partitioning of safety-critical functions into isolated modules, using diversity where required.
- Implementation: Coding standards (e.g., MISRA C/C++), avoidance of dynamic memory in SIL 3/4, and prohibition of certain language constructs.
- Verification: Static analysis, code reviews, unit and integration testing with coverage metrics (statement, branch, MC/DC for SIL 3/4).
- Validation: Comprehensive testing on target hardware using realistic operational scenarios.
Warning: For SIL 3 and SIL 4, the use of automatic code generation is strongly recommended. Hand coding must be justified and subjected to extra rigour.
3. Implementation Highlights
To successfully implement CSA R7004-17, organizations should establish a dedicated software safety assurance programme. Key implementation highlights include:
- Configuration Management: All software artifacts (requirements, design, source code, test cases, evidence) must be under strict configuration control including change impact analysis.
- Tool Qualification: Tools that automate verification or code generation must be qualified according to their impact on safety. Unqualified tools require manual cross-check.
- Software Maintenance: The standard requires a formal process for operating experience feedback and safety-relevant updates.
- Independence: Verification and validation activities must be performed by personnel not directly involved in design, with independence levels matching SIL.
Best Practice: Early engagement with a recognized assessor (e.g., CS SCDB or an independent safety assessor) can streamline certification and reduce rework.
4. Compliance Notes
Compliance with CSA R7004-17 is mandatory for all new and significantly modified onboard ATC software deployed in Canada after December 31, 2018. The standard is referenced by Transport Canada regulatory documents for rail safety. Certification typically involves:
- Submitting a Software Safety Plan (SSP) that describes lifecycle and methods.
- Providing a Software Integrity Level assignment report with hazard log.
- Demonstrating through a Software Verification and Validation Report that all requirements have been met.
- Undergoing a safety audit by an accredited third-party organisation (e.g., Bureau Veritas, TÜV Rheinland).
Non-compliance can result in operational restrictions or grounding of rolling stock.
Important: The standard requires that software used for ATC functions be updated only via a secure process to prevent unauthorized changes. This includes digital signature of field upgrades.
Frequently Asked Questions
Q: Does CSA R7004-17 apply to software for subway and light rail vehicles?
A: Yes. The standard covers all onboard ATC software for mainline and urban rail. However, subway systems may already use an equivalent standard such as IEEE 1474 or CENELEC EN 50128; CSA R7004-17 is accepted as an alternative for Canadian operations.
A: Yes. The standard covers all onboard ATC software for mainline and urban rail. However, subway systems may already use an equivalent standard such as IEEE 1474 or CENELEC EN 50128; CSA R7004-17 is accepted as an alternative for Canadian operations.
Q: Can we reuse software previously certified to IEC 61508 or EN 50128 for CSA R7004-17 compliance?
A: Partially. CSA R7004-17 includes specific railway requirements not present in generic IEC 61508, particularly regarding operational profiles and interoperability with Canadian train control systems. A gap analysis is recommended.
A: Partially. CSA R7004-17 includes specific railway requirements not present in generic IEC 61508, particularly regarding operational profiles and interoperability with Canadian train control systems. A gap analysis is recommended.
Q: What is the role of the “proven-in-use” argument in SIL 4 software compliance?
A: CSA R7004-17 allows limited use of proven-in-use evidence for existing software libraries that have a documented history in rail applications. The standard requires a detailed analysis of configuration, operating conditions, and failure data to justify the safety claim.
A: CSA R7004-17 allows limited use of proven-in-use evidence for existing software libraries that have a documented history in rail applications. The standard requires a detailed analysis of configuration, operating conditions, and failure data to justify the safety claim.
© 2026 CS Standards Authority