Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.
Fiktives Beispiel. Die ACME Embedded GmbH, ihre Produkte, Nachweise und Dokument-IDs sind zur Veranschaulichung erfunden. Nutzen Sie das als strukturelles Vorbild, nicht als unverändert zu übernehmende Vorlage — und nicht als Rechtsberatung.
ENG-REC-031 — EOL Check: Tools and Dependencies (SensorNode S300)
| Document ID | ENG-REC-031, rev. 1.0 |
| Product | SensorNode S300 (project P-2026-04) |
| Reference | CRA Annex I Part II; policy SDL-POL-005 §2(1) |
| Prepared by | DevOps Lead, 2026-07-20 |
| Approved by | Product Security Lead |
| Planning horizon | Product launch Q3/2027 + declared support period 7 years → components must be maintainable until ≥ Q3/2034; policy margin +12 months → target horizon Q3/2035 |
1. Rule applied
A component passes only if (a) its published EOL/LTS end lies beyond the target horizon, or (b) a concrete, costed migration or self-maintenance path is documented and approved. "We'll deal with it later" is not a pass.
2. Assessment table
| # | Component / tool | Candidate version | Published EOL / support end | vs. horizon Q3/2035 | Verdict |
|---|---|---|---|---|---|
| 1 | RTOS: Zephyr LTS | LTS 4.x line | LTS maintained ~2.5 y per line; project provides overlapping LTS lines | Requires planned LTS migrations (~every 2–3 y) | Pass with condition C-1 |
| 2 | Crypto: mbedTLS LTS | current LTS | LTS ~3 y per branch, overlapping | Same pattern as #1 | Pass with condition C-1 |
| 3 | SoC vendor HAL/SDK (MCU candidate A) | v5 | Vendor longevity program: 10 y from 2024 → 2034 | Ends inside support period (2034 < 2035) | Conditional — see C-2 |
| 4 | SoC vendor HAL/SDK (MCU candidate B) | v3 | Longevity program 15 y from 2025 → 2040 | OK | Pass |
| 5 | Bootloader: MCUboot | current | Active, no LTS scheme; small codebase | Self-maintenance feasible (source, in-house expertise) | Pass with condition C-3 |
| 6 | Toolchain: Arm GNU toolchain | pinned release | Old releases remain reproducible; archived by us | Build reproducibility, not security exposure on device | Pass (archive rule C-4) |
| 7 | Build/CI: containerized build image | Debian 12 base | LTS ~2028 | CI-side only, not shipped | Pass — refresh image at every major release |
| 8 | 802.15.4 stack (vendor binary blob, candidate A) | v2.1 | No EOL commitment published | Cannot be self-maintained (binary) | Fail — knock-out per SDL-POL-005 §3(4) unless vendor contract per CON-CLS-007 |
3. Conditions and decisions
- C-1 (LTS migration cadence): project plan reserves one maintenance release per ~2.5 years for Zephyr/mbedTLS LTS migrations across the support period; effort estimate 6–8 PW each, recorded in the product maintenance budget.
- C-2 (MCU candidate A): SDK support ends 2034, one year short of horizon. Acceptable only if the vendor signs the CON-CLS-007 clause set with EOL notice ≥ 24 months — otherwise candidate B is selected. → Input to hardware decision in ENG-REC-032.
- C-3 (MCUboot): PSL confirms in-house patch capability; component flagged "self-maintainable" in registry.
- C-4 (toolchain archive): exact toolchain and build container archived with each release dossier to guarantee patch-build capability in year 7.
- Decision on #8: vibration analysis favors candidate A's radio, but the unmaintainable binary stack fails the policy. Resolution: request CON-CLS-007 terms from vendor A by 2026-08-15; if declined, hardware selection moves to candidate B. Owner: Purchasing + PSL.
4. Re-check schedule
This record is re-run at architecture freeze (M2), at every major release, and annually during the support period (delta form). All versions retained as quality records; current version referenced in the technical documentation.