ISO 26262 functional safety with Understand

ISO 26262, Road vehicles — Functional safety, governs how safety-critical automotive electronics and software are developed. Part 6 (Product development at the software level) sets expectations for coding guidelines, structural complexity, and verification that Understand directly supports. Like DO-178C, Understand does not ship a single "ISO 26262 mode" — it provides features that support several parts of a functional-safety program, and produces the artifacts you attach as evidence.

This page maps that workflow onto the concrete how-tos. For anything about certified status or tool qualification, read the certification page first — those statements are version-specific and carry legal weight.

Certification & qualification claims live on one page

Whether Understand is certified for ISO 26262 (and the exact certified build, languages, and OS scope), and how tool qualification / tool confidence applies to your program, is answered authoritatively — with the correct caveats — in Is Understand certified?. Do not rely on any paraphrase of it. Confirm the scope for your release with support@scitools.com.

1. Enforce the coding guidelines

ISO 26262-6 expects a documented coding standard. CodeCheck ships the ones automotive programs use — MISRA C and MISRA C++ (including MISRA C++ 2023), AUTOSAR C++14, and more. See Which standard should I check against? to map your obligation to a configuration, then:

• What is CodeCheck? and Run your first check to get going.
• Baseline existing violations so an in-flight project can adopt a standard without drowning in day-one findings.
• Suppress a violation / document a deviation — deviation records are a first-class part of every real MISRA/AUTOSAR program.

2. Control and evidence structural complexity

Functional-safety standards care about structural complexity because complex code is hard to test and review to the required rigor. The HIS (Hersteller-Initiative Software) metric set is a common contractual requirement in automotive — Understand ships it as a metric set, an interactive report, and a CodeCheck standard. See HIS metrics, and Interpret key metrics for when a number should worry you.

3. Analyze per component and per ASIL

Automotive software is typically built from many reusable components, each carrying its own safety level (ASIL) that must be evaluated on its own. Set up Understand so analysis matches how you build: scope a project (or an architecture) per component, so a component's coding-standard results and metrics can be reviewed and signed off independently rather than averaged across the whole system.

4. Automate and gate

Compliance that only happens at milestones drifts. Run checks continuously so a regression fails fast:

• Run automatically in the background while engineers work.
• Run in CI (Jenkins) and gate merges on the result — a simple pass/fail signal at check-in keeps risky changes from slipping through.

5. Produce the evidence

When it's time to demonstrate conformance, generate a compliance report — the standard-by-rule artifact reviewers expect, including your documented deviations and the rules that require manual review. The report catalog lists further reports you can attach as supporting evidence.

Where to next

• Is Understand certified? — the authoritative certification & scope statement.
• The compliance lifecycle — adopt → measure → triage → evidence.
• Check code for security vulnerabilities — where cybersecurity requirements sit alongside safety.
• Safety-critical software — the cross-domain overview.