Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
CAN/CSA ISO/IEC TR 15942-04: Technical Report on Programming Languages — Guide for the Use of Ada in High Integrity Systems
A comprehensive overview of the Canadian adoption of the international technical report for Ada-based high-integrity system development
Introduction
CAN/CSA ISO/IEC TR 15942-04 is the Canadian adoption of the international technical report ISO/IEC TR 15942:2004, titled Information technology — Programming languages — Guide for the use of the Ada programming language in high integrity systems. Published by the Canadian Standards Association (CSA) in collaboration with ISO/IEC, this document provides essential guidance for developers, verifiers, and certifiers working with Ada in high-integrity (safety-critical) systems.
The technical report (TR) is not a normative standard but a comprehensive set of recommendations and best practices drawn from decades of industrial experience with Ada. It addresses the unique challenges of engineering software that must operate correctly under strict safety, reliability, and real-time constraints. Industries such as avionics, railway signaling, medical devices, nuclear power, and defence rely heavily on Ada for its strong typing, run-time checking, and support for formal verification. This TR distills the collective knowledge of the Ada community into actionable guidelines for system developers.
Tip: CAN/CSA ISO/IEC TR 15942-04 is a key reference for any project pursuing certification under standards such as DO-178C (avionics), IEC 61508 (functional safety), or ISO 26262 (automotive). Its use can significantly streamline the certification argument by providing a pre-defined, predictable language subset.
Scope and Application
What the TR Covers
The scope of CAN/CSA ISO/IEC TR 15942-04 is to provide guidelines for selecting and using Ada language constructs in a manner that facilitates the development of high-integrity software. It specifically targets:
- Systems where failure could lead to loss of life, significant property damage, or environmental harm.
- Systems requiring formal verification, static analysis, or rigorous testing.
- Applications that must meet hard real-time deadlines and resource constraints.
What the TR Does Not Cover
The TR does not specify a particular Ada subset (like the Ravenscar profile) nor does it define a complete certification framework. Instead, it provides a structured methodology for constructing a project-specific set of rules based on risk analysis, system requirements, and the chosen Ada environment. It is language-level guidance and does not address system architecture, hardware dependencies, or process lifecycle beyond the coding phase.
Important: The TR must be tailored to each project’s specific safety integrity level (SIL). Blindly adopting all recommendations without considering system context can lead to unnecessary restrictions or overlooked hazards.
Technical Requirements and Guidelines
CAN/CSA ISO/IEC TR 15942-04 organizes its technical guidance into several thematic categories. For each language feature, the report recommends an allowed, restricted, or prohibited usage. The following table summarizes the classification of key Ada constructs:
| Ada Language Feature | Recommended Category | Rationale |
|---|---|---|
| Packages (specification/body) | Allowed (with restrictions) | Encapsulation is essential; restrictions apply to order of elaboration and use of limited types. |
| Tasking (Ravenscar profile) | Restricted (profile mandatory) | Full Ada tasking is too complex for high-integrity; the Ravenscar profile enforces deterministic tasking. |
| Protected Objects | Allowed (with restrictions) | Use only for simple mutual exclusion; no nesting of protected procedures. |
| Exceptions | Prohibited (in most cases) | Exception handling can hide faults and complicate coverage analysis; only predefined exceptions at program level may be considered. |
| Dynamic Allocation & Deallocation | Restricted (avoid unbounded) | Dynamic memory can lead to fragmentation, interference, and missed deadlines; use static allocation whenever possible. |
| Access Types (Pointers) | Prohibited (except under strict patterns) | Aliasing and dangling references undermine static analysis; limited to certain design patterns like access to library-level data. |
| Unchecked Programming (Unchecked_Deallocation, etc.) | Prohibited | Breaches type safety; any use must be formally justified and isolated. |
| Representation Clauses & Attributes | Allowed (with analysis) | Necessary for low-level hardware mapping; must be fully documented and verified. |
| Preelaborable Initialization | Allowed | Enables compile-time evaluation and reduces run-time overhead. |
Rationale for Restrictions
The restrictions are designed to eliminate constructs that are difficult to analyze statically, that introduce non-deterministic behavior, or that require complex run-time support. By following these guidelines, the resulting Ada code becomes amenable to formal verification via tools such as SPARK (a subset of Ada with formal contracts). The TR encourages the use of SPARK where possible, as it enforces a deterministic, side-effect-free programming style.
Best Practice: Combine the recommendations of CAN/CSA ISO/IEC TR 15942-04 with the Ravenscar profile (defined in Ada 2005 and later) for a robust, certifiable real-time kernel. Many toolchains provide automatic detection of Ravenscar compliance.
Implementation Highlights
Developing a Project-Specific Coding Standard
The TR should be used as the foundation for a project’s coding standard. The process typically involves:
- Risk Assessment: Identify the highest risks (e.g., timing errors, memory corruption, unhandled exceptions).
- Feature Selection: Map each risk to Ada features that could cause it; then choose the appropriate TR category (allowed, restricted, prohibited).
- Tooling: Select static analysis and code review tools that can check compliance with the chosen subset.
- Training: Ensure the development team understands not only the rules but also the underlying safety rationale.
Relation to Certification Standards
CAN/CSA ISO/IEC TR 15942-04 aligns well with the objectives of DO-178C, IEC 61508, and ISO 26262. For example:
- DO-178C (Aeronautics): The TR supports the “pre-verified” language approach, reducing the need for low-level testing.
- IEC 61508 (Functional Safety): The TR provides evidence of language suitability for SIL 3 and SIL 4 applications.
- ISO 26262 (Automotive): The TR helps fulfill requirements for “language subset and coding guidelines” for ASIL C and D.
Tip: When submitting certification documents, many authorities accept self-declaration of conformance to CAN/CSA ISO/IEC TR 15942-04 if accompanied by a compliance matrix and static analysis results.
Compliance and Certification Notes
Demonstrating Conformance
Since the TR is not a normative standard, formal certification to the TR itself is not required. However, projects often need to demonstrate that their software development has followed the TR’s recommendations. This is typically achieved by:
- Documenting which TR guidelines have been adopted and why.
- Using automated tools to enforce the chosen subset (e.g., AdaControl, CodePeer, SPARK tools).
- Conducting code reviews with checklist items derived from the TR.
Limitations
The TR is based on Ada 95 and Ada 2005. While many guidelines apply to later revisions (Ada 2012, Ada 2022), some new features (e.g., extended containers, parallel blocks) require additional analysis. Projects using newer Ada editions should upgrade the TR’s guidance accordingly.
Caution: The TR does not guarantee safety or correctness on its own. It must be complemented by rigorous verification, including requirements-based testing, code coverage analysis, and potentially formal reasoning. The TR is a tool in the overall safety engineering process, not a substitute for it.
Conclusion
CAN/CSA ISO/IEC TR 15942-04 is an invaluable resource for engineering teams working with Ada in high-integrity contexts. By providing a structured, rational methodology for selecting language features, it bridges the gap between the power and expressiveness of Ada and the stringent constraints of safety-critical certification. The Canadian adoption ensures alignment with regional requirements while maintaining full technical equivalence with the international ISO/IEC TR 15942:2004.
Adopting this report early in a project life cycle, tailoring it to specific risk profiles, and combining it with state-of-the-art static analysis and formal verification tools can dramatically reduce certification latency and overall development cost. For any organization building high-integrity Ada systems, CAN/CSA ISO/IEC TR 15942-04 should be considered a foundational element of the software engineering strategy.
Frequently Asked Questions
Q: Is CAN/CSA ISO/IEC TR 15942-04 identical to the international ISO/IEC TR 15942:2004?
A: Yes, the Canadian adoption is technically identical. CSA may include minor editorial differences (title page, foreword) but the core technical content is unchanged. This ensures international reciprocity for certification projects under bilateral agreements.
A: Yes, the Canadian adoption is technically identical. CSA may include minor editorial differences (title page, foreword) but the core technical content is unchanged. This ensures international reciprocity for certification projects under bilateral agreements.
Q: Can I use CAN/CSA ISO/IEC TR 15942-04 for Ada 2012 or Ada 2022 programs?
A: The recommendations are applicable, but they do not cover language features introduced after Ada 2005. For example, the use of new iteration and container features should be evaluated separately against high-integrity principles defined in the TR. A common approach is to extend the TR’s classification scheme to new features using the same risk-based methodology.
A: The recommendations are applicable, but they do not cover language features introduced after Ada 2005. For example, the use of new iteration and container features should be evaluated separately against high-integrity principles defined in the TR. A common approach is to extend the TR’s classification scheme to new features using the same risk-based methodology.
Q: What is the difference between the TR and the Ravenscar profile?
A: The Ravenscar profile is a specific real-time tasking subset mandated by the TR for high-integrity applications. The TR goes beyond Ravenscar to cover the entire language: packages, types, operators, libraries, etc. Think of Ravenscar as a key component within the larger advisory framework of the TR.
A: The Ravenscar profile is a specific real-time tasking subset mandated by the TR for high-integrity applications. The TR goes beyond Ravenscar to cover the entire language: packages, types, operators, libraries, etc. Think of Ravenscar as a key component within the larger advisory framework of the TR.
Q: Is formal verification required for compliance with this TR?
A: No, the TR does not mandate formal verification. However, it strongly encourages practices that make formal verification feasible, such as avoiding dynamic constructs and using contracts (Ada 2012 preconditions/postconditions). Many projects choose to adopt the SPARK subset precisely because it aligns with TR guidelines and enables formal proof.
A: No, the TR does not mandate formal verification. However, it strongly encourages practices that make formal verification feasible, such as avoiding dynamic constructs and using contracts (Ada 2012 preconditions/postconditions). Many projects choose to adopt the SPARK subset precisely because it aligns with TR guidelines and enables formal proof.
Last reviewed: 2026. This article is for informational purposes and should not replace the official CAN/CSA ISO/IEC TR 15942-04 document for authoritative requirements.