Planning the AC6.16 LTS → AC6.22 LTS Migration for Indian FuSa Programs

Arm has announced end-of-life for Arm Compiler 6.16 LTS Term licenses. For most Indian product teams that is a calendar reminder; for a specific subset, automotive Tier-1 and Tier-2 ECU teams, railway-signalling vendors, industrial-controls OEMs, and medical-device firmware teams who certified their safety case against AC6.16 LTS, it is the start of a multi-month re-qualification project. This is the migration playbook GSAS Micro Systems gives those teams.

We are Arm’s authorized partner in India for Arm Development Tools. The advice below assumes you are already using AC6.16 LTS in a certified or in-flight safety program, if you are on the standard AC6 Term branch, the migration is much simpler and you should still talk to us, but you do not need most of what is below.

The AC6 FuSa branch lineage

Arm publishes AC6 in two parallel tracks. The standard branch ships frequently and tracks LLVM upstream, it is what most embedded teams use day-to-day. The FuSa branch is published less often, qualified by Arm against the IEC 61508 / ISO 26262 / EN 50716 / IEC 62304 family of safety standards (per Arm’s published Arm Compiler for Embedded FuSa product page), and ships with a Safety Manual, a Defect Report, and the supporting qualification artefacts that a TÜV auditor or notified body expects to see in a safety case.

The FuSa branch lineage Indian teams should know:

• AC5.04 (2013): first AC5 FuSa branch. Long retired.
• AC5.06 (2016): second AC5 FuSa. Retired.
• AC6.6 (2017): first AC6 FuSa generation. Retired.
• AC6.16 LTS (2021): second AC6 FuSa generation (the AC6 FuSa branch goes 6.6 → 6.16 → 6.22). The branch reaching end-of-life now.
• AC6.22 LTS (2024): third AC6 FuSa generation. The successor.

The pattern is roughly one FuSa generation every 3–4 years, with each generation getting a Long-Term-Support (LTS) maintenance window after release, and a published end-of-life on the predecessor LTS once the successor is qualified and stable.

For Indian teams whose certified safety case rests on AC6.16 LTS, AC6.22 LTS is the forward path within the Arm Compiler for Embedded FuSa family. AC6 FuSa remains Arm’s current TÜV-certified safety compiler for embedded; the longer-term ATfE FuSa roadmap is an Arm conversation, talk to your Arm contact via GSAS for the current planning horizon.

What changes between AC6.16 LTS and AC6.22 LTS

The migration is not a like-for-like drop-in. There are real surface-level changes, real internal changes, and one significant licensing change.

New core support

AC6.22 LTS adds compiler support for cores that AC6.16 LTS does not target. The full delta:

• Cortex-A510, A520, A710, A715, A720 (Armv9-A, common in modern automotive and industrial Linux)
• Cortex-A520AE, A720AE (automotive-extended variants, ASIL-D capable in split-lock configurations)
• Cortex-X2, X3, X4 (the Cortex-X high-performance line)
• Neoverse-V2, V3AE (the V3AE is the automotive-extended variant of Neoverse for vehicle-platform compute)
• Cortex-M52, M85 (Armv8.1-M, with Helium MVE; Cortex-M52 is the safety-class addition, Cortex-M85 adds PACBTI)
• Cortex-R82, R82AE (Armv8-R AArch64; R82AE is the automotive-extended variant)

If your AC6.22 migration is being driven by a new product targeting one of these cores, for example, an Indian automotive HPC platform on Cortex-A520AE or a next-generation motor-control unit on Cortex-M52, the upgrade is partly a feature requirement, not just a maintenance burden.

armasm removal

The legacy armasm assembler is removed in AC6.22 LTS. Code that was still using armasm for hand-written assembly under AC6.16 LTS must move to the GNU-style assembler (armclang -E -x assembler-with-cpp or direct GNU-syntax inputs). For most Indian teams this is a straightforward find-and-replace pass over a small number of .s files; for teams with a meaningful hand-tuned assembly footprint (DSP kernels, cryptographic primitives, low-latency interrupt vectors) it is a real porting exercise.

Certified C Library now bundled with AC6.22 LTS

This is the licensing change that materially affects the cost of running AC6.22 LTS. Under AC6.16 LTS, the Certified C Library: the safety-qualified libc replacement that satisfies safety-case requirements for the standard library, was a separate purchase item. Under AC6.22 LTS, the Certified C Library is bundled into the compiler entitlement (per Arm’s published AC6.22 LTS release materials, verify the bundled-version number against your specific AC6.22 LTS release notes when you procure). Indian teams that were paying for both AC6.16 LTS and a separate Certified C Library subscription see a real budget saving on the AC6.22 LTS renewal.

Certified C++ Library

AC6.22 LTS also adds the Certified C++ Library for safety-critical C++ work on Cortex-A and Cortex-R. The qualification depends on AC6.22 LTS plus the bundled Certified C Library; it is the path forward for Indian teams writing safety-critical C++, which previously had to either (a) restrict to a hand-curated C++ subset and qualify it themselves, or (b) stick to plain C. Refer to Arm’s AC6.22 LTS Certified C++ Library datasheet for the specific C++ language-feature subset, exception/RTTI policy, and qualification level, these details are part of Arm’s documentation rather than something to commit to from a marketing page.

What does not change: and that matters

For Indian safety teams the more important observation is what stays the same:

• Standards coverage: ISO 26262 ASIL-D, IEC 61508 SIL-3, EN 50716 SIL-4 (Railway, supersedes EN 50128), IEC 62304 Class C remain the qualified envelope per Arm’s published AC6 FuSa product page.
• Qualification artefacts: Safety Manual, Defect Report, Test Report, Development Process Report. The format and rigour are the same; the content of each is updated for AC6.22 LTS.
• Tool classification: TQL/TCL classification is unchanged; how your safety case argues for compiler-induced-error coverage stays the same.
• The shape of your safety re-verification: the activities you have to repeat for the AC6.22 LTS upgrade are the same kinds of activities you ran for the original AC6.16 LTS adoption. The plan is well-trodden; you have done it before.

The Arm Safety Qualification Kit ships with both the AC6.16 LTS and AC6.22 LTS qualification artefacts; running them side-by-side during the migration is supported.

A re-verification plan for an Indian Tier-1 ECU team

The migration shape we recommend to Indian automotive Tier-1 / Tier-2 customers running ASIL-D ECU programs:

Phase 1, gap analysis (4 weeks).

• Map every safety-case argument that depends on a compiler-version-specific claim. Identify which arguments need re-running on AC6.22 LTS evidence.
• Inventory hand-written assembly. Plan the armasm removal.
• Confirm whether any project depends on the standalone Certified C Library subscription that is now bundled, usually a procurement-cleanup item rather than a technical one.

Phase 2, compile-only port (2–4 weeks).

• Move the build system to AC6.22 LTS. Resolve armasm removal. Get a clean build with the same warnings posture.
• Bring up unit tests on AC6.22 LTS-built artefacts. Fix the small set of latent issues that always surface on a major-compiler upgrade.

Phase 3, safety re-verification (8–16 weeks).

• Re-run the qualification kit’s evidence-generation artefacts against your codebase under AC6.22 LTS.
• Update the Safety Manual reference in your project’s safety case.
• Generate the new Defect Report applicability analysis, the AC6.22 LTS Defect Report supersedes the AC6.16 LTS one, but you still need to argue that none of the open defects affect your codebase.
• Coordinate with your TÜV auditor or notified body for the re-assessment.

Phase 4, cut-over (2–4 weeks).

• Final builds on AC6.22 LTS. Submit the updated safety case.
• Decommission the AC6.16 LTS toolchain server / image.
• Schedule the next FuSa-branch upgrade review (typically 18–24 months out).

Total: 16–28 weeks for a sizeable safety-case re-verification. These phase durations are GSAS field-experience estimates based on Indian Tier-1 / Tier-2 automotive programmes we have helped through this migration; they are not Arm-published or auditor-calibrated. Smaller teams, simpler safety cases, or programs already in mid-development (so the safety case isn’t sealed yet) compress this significantly. Programs already certified and in production with active recall exposure expand it. Calibrate against your own programme’s complexity and TÜV / notified-body throughput.

Common questions from Indian customers

“Can we skip AC6.22 LTS and wait for ATfE FuSa?”: Probably not. The AC6.16 LTS support window is finite, and the ATfE FuSa roadmap is an Arm conversation we recommend handling directly with your Arm contact via GSAS rather than planning a programme schedule around a publicly unconfirmed date. For most Indian safety teams, AC6.22 LTS is the right next step.

“Do we need to re-qualify the entire toolchain?”: Only the parts of the safety case that depend on compiler version. The qualification kit is structured to make this scoped re-verification tractable; you do not start from scratch.

“What about our long-tail AC5 / AC6.6 projects?”: Those projects are on much older qualified compilers that are themselves long EOL. If they are still in active production, they are running on grandfathered licenses; talk to GSAS about whether the right path is to maintain them on the legacy line or pull them forward into the AC6.22 LTS family as part of the migration.

“Will the move break our Safety Manual references?”: Yes, every cross-reference that cites AC6.16 LTS by version needs updating. Plan the documentation pass; do not let it fall to the last week of the project.

What to do this quarter

If you are an Indian engineering manager running an in-flight or production ASIL-D / SIL-3 / SIL-4 / Class-C program on AC6.16 LTS:

1. Confirm your AC6.16 LTS dependency. Which safety-case arguments cite the compiler version explicitly?
2. Map your armasm exposure. Hand-written assembly file count is the cheapest first signal of porting risk.
3. Talk to GSAS about the AC6.22 LTS quote and the migration timeline. We do this conversation with Indian Tier-1 automotive, railway, and industrial customers regularly; we can give you a calibrated effort estimate for your specific safety case.
4. Coordinate the auditor schedule early. TÜV / notified-body availability is the long-pole item once the technical re-verification is in motion.

Talk to GSAS about your AC6.22 LTS migration →

GSAS Micro Systems is Arm’s authorized engineering partner in India for Arm Compiler for Embedded FuSa, the Arm Safety Qualification Kit, and the broader Arm tools family, across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR, and Visakhapatnam.