Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
CAN/CSA-ISO/IEC TR 24717-12: Guidelines for Programming Language Selection in Real-Time and Safety-Critical Systems
Navigating the Framework for Language Evaluation and Adoption in High-Integrity Applications
Introduction and Scope
CAN/CSA-ISO/IEC TR 24717-12 is the Canadian adoption of the international Technical Report ISO/IEC TR 24717-12:2020, titled “Information technology — Programming languages, their environments and system software interfaces — Guidelines for the selection and adoption of programming languages — Part 12: Real-time and safety-critical systems.” This Technical Report provides a structured framework for evaluating and selecting programming languages for applications where timing correctness, reliability, and safety are paramount.
The scope of this document encompasses a comprehensive set of criteria against which programming languages can be assessed. It is intended for use by system architects, software engineers, project managers, and regulatory bodies involved in the development of real-time embedded systems, avionics, medical devices, industrial control systems, and other safety-critical software. The report does not prescribe a specific language but offers a decision framework that can be tailored to the specific requirements of the application domain. By adopting this TR, organizations can systematically reduce risks associated with language features that may lead to unpredictable behaviour or safety hazards.
Technical Requirements and Evaluation Criteria
The core of TR 24717-12 is a set of evaluation criteria organized into several categories. Each criterion includes weighting guidance and assessment methods. The key categories include:
- Data Typing and Type Safety – The strength of the type system, support for static type checking, and ability to prevent type errors at compile time.
- Memory Management – Deterministic memory allocation and deallocation, support for static or region-based memory management, avoidance of garbage collection uncertainty.
- Exception Handling – Mechanism for handling run-time anomalies, impact on timing, and support for fault tolerance.
- Concurrency and Tasking – Language-level support for threads, tasks, rendezvous, and deterministic scheduling.
- Verification and Tool Support – Availability of static analysis tools, formal verification methods, and test coverage tools.
- Regulatory and Certification History – Previous use in certified systems; qualification data from standards bodies such as FAA, EASA, or IEC 61508.
The following table summarizes the primary evaluation categories along with typical weighting ranges for safety-critical applications:
| Evaluation Category | Description | Weighting (1–10) |
|---|---|---|
| Type Safety | Ability to prevent type errors at compile time | 9 |
| Deterministic Memory Management | Predictable memory use without GC pauses | 8 |
| Exception Handling Determinism | Bounded execution time for exception mechanisms | 7 |
| Concurrency Model | Support for tasks, schedulability analysis | 9 |
| Verification Support | Availability of static analysis and formal methods | 10 |
| Regulatory Acceptance | History of use in certified systems | 8 |
| Portability | Availability of compilers and runtimes for target platforms | 6 |
| Community and Vendor Support | Long-term maintenance, documentation, training | 5 |
The TR recommends that each criterion be rated using an ordinal scale (e.g., low, medium, high) and then aggregated using a multi-criteria decision analysis method such as the Analytic Hierarchy Process (AHP) or a weighted sum model. Sensitivity analysis is also encouraged to understand the impact of weighting changes.
Implementation Highlights
Adopting the guidelines of TR 24717-12 within a development organization involves several steps:
- Define Application Requirements – Identify the criticality level of the system (e.g., SIL 1–4 per IEC 61508, DAL A–E per DO-178C).
- Map Criteria to Requirements – Weight each evaluation criterion according to the specific domain constraints.
- Evaluate Candidate Languages – For each language under consideration, gather evidence regarding each criterion from official language standards, existing certification reports, tool qualification data, and published case studies.
- Pilot Assessment – Prototype key functionality in the shortlisted language(s) to validate assumptions about tool chains and runtime behaviour.
- Document and Rationalize – Produce a selection report that documents the evaluation process, weightings, scores, and final recommendation.
Tip: When applying the TR, involve domain experts in the weighting step to ensure the criteria weights reflect the real risks and safety constraints of the target application. Avoid generic weightings from similar but not identical projects.
Warning: The TR should not be used as a checklist for ignoring deeper architectural analysis. Even a language scoring highly on all criteria can lead to unsafe systems if misused. Always complement language selection with appropriate design patterns, coding standards, and verification planning.
Compliance and Certification Considerations
Compliance with CAN/CSA-ISO/IEC TR 24717-12 is not a regulatory requirement in itself, but adherence to its guidelines is often cited as evidence of due diligence in language selection for projects that must conform to domain-specific safety standards. The TR is widely referenced in:
- IEC 61508 (functional safety of electrical/electronic/programmable electronic systems)
- ISO 26262 (road vehicle functional safety)
- DO-178C (software considerations in airborne systems)
- IEC 62304 (medical device software)
Certification bodies may request a Language Selection Qualification Package that includes the evaluation results, rationale for language choices, and evidence that the chosen language features comply with the safety objectives of the applicable standard. Using the framework of TR 24717-12 helps structure this documentation clearly and defensibly.
Success: Several major safety-critical system developers have adopted variants of the TR 24717-12 criteria to justify the use of modern languages such as Ada, SPARK, and Rust in place of traditional languages like C, by providing a systematic comparison that highlights the safety benefits.
Danger: Failing to systematically evaluate language features can result in late-stage discovery of unsafe or non-deterministic behaviour, especially in mixed-criticality systems where isolation of time- and safety-critical tasks is required. This can lead to costly redesign or certification gaps.
Frequently Asked Questions
Q: Is CAN/CSA-ISO/IEC TR 24717-12 identical to the international ISO/IEC TR 24717-12?
A: Yes, the Canadian Standards Association (CSA) adoption is technically identical to the ISO/IEC Technical Report. Canadian users will find the same framework, criteria, and guidance. The document may include a Canadian foreword but no technical deviations.
A: Yes, the Canadian Standards Association (CSA) adoption is technically identical to the ISO/IEC Technical Report. Canadian users will find the same framework, criteria, and guidance. The document may include a Canadian foreword but no technical deviations.
Q: Do I need to follow this TR if I’m using a single programming language already mandated by my company or regulator?
A: The TR is most valuable when a choice exists among languages or when evaluating a new language for adoption. However, even when a language is fixed, the criteria can help define permissible language subsets and coding rules to mitigate known weaknesses.
A: The TR is most valuable when a choice exists among languages or when evaluating a new language for adoption. However, even when a language is fixed, the criteria can help define permissible language subsets and coding rules to mitigate known weaknesses.
Q: What tools can assist in the evaluation process?
A: The TR does not prescribe specific tools, but suggests using multi-criteria decision analysis (MCDA) tools. Spreadsheet-based scoring matrices are common. Specialized tools like AHP software or risk assessment platforms can also be tailored to the criteria set.
A: The TR does not prescribe specific tools, but suggests using multi-criteria decision analysis (MCDA) tools. Spreadsheet-based scoring matrices are common. Specialized tools like AHP software or risk assessment platforms can also be tailored to the criteria set.
Q: Is there a standard template for the language selection report?
A: An informative annex in the TR provides an outline of a language selection report, including sections for system description, criticality assessment, weighting rationale, scoring tables, sensitivity analysis, and conclusions. Users are encouraged to adapt this to their organizational needs.
A: An informative annex in the TR provides an outline of a language selection report, including sections for system description, criticality assessment, weighting rationale, scoring tables, sensitivity analysis, and conclusions. Users are encouraged to adapt this to their organizational needs.