Safety as an Increasingly Important Topic for CUDA
Starting with the migration of CPU based high-performance computing code to GPU accelerated computing, GPUs today are no longer confined to graphics and high-performance computing. They now serve as accelerators enabling safety-critical systems such as ADAS (Advanced Driver Assistance Systems) and industrial and medical robotics. “Safety First” is the motto when transitioning to the era of physical AI to meet a wide range of standards. This shift brings new challenges with meeting safety certification requirements with GPU-based software.
As CUDA plays an ever-bigger role in these environments, the user community needs clear, enforceable coding rules to ensure not only performance and efficiency but reliability and safety as well.
Safety-Regulated Industries: Coding Guidelines are a Must
Industries such as automotive, aerospace, industrial automation, and medical devices are governed by strict safety standards (e.g., ISO 26262, IEC 62304, IEC 61508). In these environments, software failures can lead to critical safety hazards. Coding guidelines are not optional here—they are mandated by certification processes to:
- Mitigate the risks of dangerous coding patterns.
- Ensure traceability and verifiability of software behavior.
- Support audits and compliance.
It is no longer sufficient for the QA function to identify bugs but rather developers are now responsible for providing evidence for the absence of flaws. Additionally, safety must be considered even when SW is operating as intended without faults or failures. Coding guidelines are developed by and for the industry experts to support the validation and verification process and serve as an essential tool for achieving the required level of quality and transparency.
Coding Guidelines for Functional Safety
Now that CUDA is increasingly used within regulated industries, e.g., for real-time perception in autonomous vehicles or advanced diagnostics in healthcare, safety-compliant CUDA development requires adherence to NVIDIA CUDA Coding Guidelines (NCCG) that NVIDIA recently provided to the user community.
Previously Available Coding Guidelines Outside of CUDA
Several well-established coding guideline sets are available for C and C++ which form the basis of CUDA development:
- MISRA C:2025 / MISRA C++:2023 have their origins in the automotive industry and are widely adopted in safety-related software.
- CERT C / C++: Focused on security and undefined behavior.
- CWE: Rules derived from the community-developed catalog of common software and hardware security weaknesses
These rulesets vary in scope, but they share the goal of preventing unsafe constructs and improving code readability and reliability. A subtle point when applying the guidelines: developers not only have to consider the current version of the code but also need to think about future changes and how to minimize the risk introduced to seemingly unrelated parts of their systems.
Coding Guidelines for CUDA
As per the previously mentioned MISRA rulesets, CUDA is not only not covered but flagged as an illegal language extension. As a consequence of using CUDA, the C/C++ parts of the projects checked with MISRA now need to acknowledge CUDA code.
With the recent publication of NVIDIA's CUDA C++ Guidelines for Safety-Critical Programming, an official set of coding guidelines covering CUDA development has become available. With the guiding principle of safety and security engineering being “if it is available, you have to apply it”, not only new but existing projects will be best served by implementing these rules in their code bases to meet safety and security mandates.
CUDA 4.1 - click on images to enlarge
CUDA 4.2 - click on images to enlarge
Preventing and Fixing Violations
Introducing coding guidelines into an existing project often reveals many violations. Attempting to fix everything at once is rarely practical and can be paralyzing. With Axivion, however, teams can approach this challenge in stages:
- Baseline and gradual improvement: Establish a baseline of current violations and focus on reducing them incrementally with each iteration.
- On-the-fly fixes: Developers correct violations as they encounter them while working on relevant code.
- Prevention: When adding new code, developers can automatically check the rules and fix issues even before pushing flaky code to their repositories.
- Proactive cleanup: Teams dedicate time to systematically improving critical parts of the codebase, especially with regards to guidelines with high runtime failure risk and modules reused in safety-relevant contexts.
This incremental approach makes guideline adoption manageable without stalling ongoing development.
Delta Analysis – “If it Ain’t Broke, Don’t fix it”
For many projects, it can be assumed to some extent that code from the past is “as it is” and is proven in use. So, rather than focusing on the full history of violations, Axivion’s novel delta analysis highlights changes introduced in each commit or merge request. Developers can then:
- Immediately see whether new violations have been introduced between two selectable end points.
- Prioritize fixing findings related to recent changes.
- Ensure that the overall quality trend of the project is improving over time.
This is particularly useful in large CUDA projects where legacy code may or may not fully meet the now available guidelines, but new code is expected to comply. By nature, newer code is more risky than older code already “proven in use”.
Find it Early, fix it Fast: Integrating Guideline Checks into Workflows
Guideline enforcement works best when seamlessly integrated into the development and reviewing workflow. It begins at the at the user’s workstation:
- Integration of the guideline check results into IDEs (e.g., Visual Studio Code, Eclipse) provides immediate feedback.
- Local analysis allows developers to fix violations even before pushing faulty code to the repository.
- By implementing proper policies, companies can minimize software erosion by preventing violations from percolating from the developers' desk into project code
The second line of defense is the CI/CD integration:
- Automated checks during merge requests ensure violations are caught before integration and immediately visible to reviewers.
- Continuous monitoring of important branches helps maintain long-term code quality.
- Feature branch analysis provides early feedback.
- Using push or pull notifications, stakeholders remain informed and able to promptly take corrective action.
By embedding automated checking throughout the workflow, guideline compliance becomes a natural part of development rather than an afterthought. This does not only save time and reduce human errors but produce documentation useful for compliance certification.
Beyond the Standardized Guidelines
Standardized rulesets like MISRA or NCCG are essential, but projects often require additional project-specific rules that are specific to their needs:
- Custom guidelines: Rules on naming conventions, directory structures, or CUDA kernel launch patterns that reflect project-specific needs.
- Architectural rules: Verifying compliance with modularization, safety concepts, and system-level design decisions.
- Given that the ratio of reading old code to authoring new code is understood to be 1:1 or even 10 to 1 or higher, code readability help control cost and reduce technical debt.
Such custom rules can easily be implemented in Axivion and the combination of standardized rules plus tailored extensions ensures that guidelines match both external certification requirements and internal project goals.
Architecture Verification for Large-Scale Projects
In larger CUDA projects, the complexity goes beyond coding rules. Axivion Architecture Verification feature checks if the software structure as implemented aligns with design specifications, safety concepts, and intended modularization and as such contributes to assure the Freedom From Interference (FFI) in safety architectures. By strictly monitoring the interactions of architectural components in different safety levels, automated architecture verification can detect all unintended dependencies, layering violations, or architectural drift—issues that are critical in regulated domains.