The Autoware Foundation
Replies: 2 comments
-
|
@oguzkaganozt @m-zain-khawaja Please take a look. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
In my opinion (and Validas is active in S-Core) S-Core is rather a development framework / process for the development of classical ASIL Software / Middleware, whereas Autoware already has a stack and we are going to find out how compliant it is hopefully soon. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
What this assesses: the right relationship between Eclipse S-CORE and Autoware — framed not as "which middleware wins" but as a division of labor between a system substrate and an autonomous-driving (AD) application, and as a functional-safety architecture question. It answers three things: (1) can S-CORE deliver Automotive Safety Integrity Level (ASIL) safety by itself; (2) can an item be functionally safe with a Quality Management (QM) Autoware main system under an ASIL Safety Island; and (3) where, concretely, should Autoware/TIER IV adopt S-CORE — with a specific Safety-Island substrate track. The narrow "S-CORE vs the ROS 2 system layer" comparison is retained as supporting evidence in Appendix A.
1. Executive summary & verdict
The strategic picture (and it is the point of this memo): S-CORE and Autoware occupy different layers, and that is the correct relationship. S-CORE's own "Scope of S-CORE v1.0" diagram draws the Application / Functions tier (ADAS apps, the driving function) as dashed and out of scope ("to be discussed for future releases / contributor not fixed"), above a solid platform/middleware/OS block that is S-CORE. S-CORE is an open SDV system substrate plus a genuinely useful open ISO 26262 process spine; Autoware is the open AD application plus the safety ecosystem that owns SOTIF — Safety Of The Intended Functionality (ISO 21448) — and fills the dashed box. There is nothing to "lose to" on the AD axis: S-CORE deliberately leaves it blank.
S-CORE cannot deliver ASIL by itself, and this is structural, not a maturity gap. Under ISO 26262 the ASIL is derived top-down from the item (the vehicle-level driving function) via a Hazard Analysis and Risk Assessment (HARA); a middleware/OS at the bottom of that chain receives an allocation, it can never originate one. S-CORE develops as a Safety Element out of Context (SEooC) shipping Assumptions of Use (AoU) that an integrator must discharge at item level — and it omits the very function (the dashed box) from which safety goals arise. For L4, the dominant hazard is SOTIF — perception/planning insufficiency, which lives entirely in that dashed box and which S-CORE addresses nowhere.
Can a QM Autoware main + an ASIL Safety Island be "functionally safe"? Conditional yes — never a blanket yes. This is the textbook ISO 26262-9 doer/checker decomposition (
ASIL X(D)checker +QM(D)doer). It is genuinely safety-bearing for the failure classes the island can independently observe and judge (electrical/electronic + middleware faults, out-of-envelope/implausible commands, freshness, geofence) — which is exactly why keeping Autoware QM is the right call (uplifting ~1,535/2,957 rclcpp-coupled files to ASIL is the wrong, near-impossible fight). But it does not cover the binding L4 hazard — SOTIF perception insufficiency — because a mis-perception produces a plausible, in-envelope, fresh, lockstep-valid command that passes every fault-oriented check; a thin island that shares or trusts the main channel's perceived world earns zero ASIL credit against it (common-cause failure). §3 makes the conditions exact.Decisive consequence — substrate ≠ coverage. S-CORE (or NXP S32Z2+FS86 / Zephyr-FreeRTOS / a certified DDS) can be the island substrate that carries the checker's ASIL. But coverage-completeness — independent, SOTIF-sufficient perception redundancy, ODD restriction, the Dependent Failure Analysis (DFA), the ISO 21448 argument — is the integrator's unsolved problem regardless of substrate. "Pick a certified substrate and the item is safe" is a fallacy. This is why the dashed box is Autoware/TIER IV's moat: own the box.
Net recommendation. Do not replace Autoware's system layer with S-CORE, and do not put QM Autoware "on top of" an S-CORE ASIL floor (that voids the ASIL — Appendix A, and §3). Do (a) adopt S-CORE's process/coding-discipline spine now as patterns (C1/C2/C8/C12, §5), and (b) open one concrete engineering track: evaluate S-CORE as a substrate for the Safety Island's native ASIL element, benchmarked against the incumbent S32Z2/Zephyr island, with eyes open that the substrate carries only the checker's ASIL (§4). Keep the AD application and its SOTIF safety case firmly in Autoware's hands.
2. Strategic framing: who owns the dashed box
The stack diagram is the argument. In "Scope of S-CORE v1.0", the solid block S-CORE owns is the substrate: Platform APIs (Logging/Persistency/Lifecycle/Time/Config/Crypto/…), System Services, Communication (IPC/LoLa today; SOME/IP, DDS, Ethernet design-only), C++/Rust base libraries, OS abstraction, hypervisor / Board Support Package (BSP), plus the cross-cutting development-environment/process tooling. The dashed tier above it — "ADAS Applications / Functions", "AI based Functionalities", "Telematics & Connectivity Applications", "Domain-Specific Applications" — is grey-filled and explicitly out of scope. Only the substrate is tagged
:safety: ASIL_B(and the metamodel is hard-capped atQM|ASIL_B— it cannot even express ASIL-C/D). S-CORE ships zero perception/localization/prediction/planning/control and zero AD developer tooling (no rviz/rosbag/tf2/message_filters/simulator) at any milestone (v0.5 → v1.0 end-2026 → v2.0/SOP-2030).ASIL is item-level, top-down — so S-CORE cannot "have" it. ISO 26262-3 derives the ASIL from a HARA on the vehicle-level driving function, attaches it to a safety goal, and decomposes it downward onto components. S-CORE has no item, no HARA, no item-level safety goal; its
ASIL_Btags are assumed/target integrity in the SEooC sense, shipped with Assumptions of Use. What S-CORE can legitimately claim is "ASIL-B-target SEooC platform building blocks + AoU" — not "an ASIL autonomous-driving system." (And even the substrate claim is intent-not-product today: "not for production" on every release, empty FMEA (Failure Mode and Effects Analysis)/DFA template stubs, no qualified tool, no certificate — see Appendix A.)The dashed box is the hard part (SOTIF), and it is owned by neither today. ISO 26262 covers malfunctions/faults (the substrate S-CORE targets). The dominant L4 safety challenge is SOTIF / ISO 21448 — perception and planning insufficiency with no component fault (missed pedestrian in glare, misclassification, wrong intention prediction, a subtly unsafe trajectory in a complex scene). That is the most differentiating, most expensive, least-solved safety work (scenario mining, ODD definition, fleet data + edge-case triage, perception-KPI validation, statistical sufficiency). S-CORE addresses none of it. Autoware fills the function — but as QM — and cannot make that box ASIL-D directly, because complex inductive perception/planning is not directly certifiable and its SOTIF residual is irreducible by ISO 26262 means.
Ownership map.
"Own the box, don't rent it out." The empty dashed box is a deliberate competitive marketplace: S-CORE's backers are OEM/Tier-1-dominated (~60–65% BMW-authored; Mercedes holds the council seat; Bosch/ETAS/Qorix/Continental/Valeo…), and they intend to fill it with their own proprietary AD stacks. Autoware is not the automatic filler — it is the open candidate. The strategic moat for Autoware/AWF/TIER IV is exactly that box: the ASIL/SOTIF perception-planning-control function plus its safety case, which cannot be commoditized and which S-CORE explicitly will not build.
Figure 1 — The division of labor (who owns which layer).
flowchart TB AD["<b>AD application</b><br/>perception · localization · planning · control<br/><i>+ SOTIF safety case</i>"]:::aw SUBME["<b>System substrate</b><br/>IPC · execution · lifecycle · OS abstraction · communication · base libraries"]:::sc PROC["<b>ISO 26262 process spine</b><br/>requirements traceability · work products · coding subset"]:::sc CASE["<b>Item-level safety case</b><br/>HARA · safety goals · QM/ASIL decomposition"]:::integ AD --- SUBME PROC -.->|adopt as patterns| AD PROC -.-> SUBME CASE -.->|owns + integrates| AD CASE -.-> SUBME classDef aw fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,stroke-dasharray:6 4,color:#111 classDef sc fill:#e6f4ea,stroke:#188038,stroke-width:2px,color:#111 classDef integ fill:#fef7e0,stroke:#b06000,stroke-width:2px,color:#111Blue dashed = Autoware (the AD box S-CORE leaves blank and Autoware fills) · green = S-CORE scope (substrate + process spine, adopt as patterns) · amber = integrator / TIER IV.
3. The functional-safety architecture: QM main + ASIL island
This section answers directly: if the Safety Island subsystem is ASIL-ready but the main Autoware is QM, can the item be functionally safe?
Verdict: a scoped, conditional YES — and a fallacy as a blanket claim. It is the standards-sanctioned ISO 26262-9 Cl.5 decomposition
ASIL X(D)[island: detect + actuate safe state]+ QM(D)[Autoware: nominal driving function], using the permitted schemeASIL X → X(X) + QM(X)and the Cl.5.4.7 allowance for decomposing an intended functionality from its corresponding safety mechanism. Autoware is legitimately QM for a given safety goal precisely and only when an independent ASIL element fully and independently discharges that goal.Figure 2 — The QM-doer / ASIL-checker decomposition (and what it does not cover).
flowchart LR AW["<b>Autoware</b> on ROS 2<br/><i>the 'doer'</i> — QM<br/>perception · planning · control"]:::aw GW["<b>E2E-protected gateway</b><br/>CRC · sequence · DataID<br/><i>QM input treated as untrusted</i>"]:::gw MON["<b>Safety monitor + MRM</b><br/><i>the 'checker'</i> — ASIL<br/>Safety Island"]:::asil SAFE["<b>ASIL safe state</b><br/>independent sensing + actuation"]:::safe SOTIF["<b>SOTIF residual</b><br/>perception/planning insufficiency<br/><b>NOT covered by the island</b><br/>→ integrator owns"]:::resid NOTE["S-CORE = candidate <b>island substrate</b><br/>carries the checker's ASIL — <b>not</b> coverage"]:::note AW ==>|commands, monitored| GW GW ==> MON MON ==>|fallback| SAFE AW -.->|insufficiency flows through| SOTIF NOTE -.-> MON classDef aw fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#111 classDef asil fill:#fce8e6,stroke:#c5221f,stroke-width:2px,color:#111 classDef gw fill:#ffffff,stroke:#5f6368,stroke-width:2px,color:#111 classDef safe fill:#e6f4ea,stroke:#188038,stroke-width:2px,color:#111 classDef resid fill:#ffffff,stroke:#c5221f,stroke-width:2px,stroke-dasharray:6 4,color:#111 classDef note fill:#fef7e0,stroke:#b06000,stroke-width:1px,color:#111Three points that must be kept exact:
QM(D)is not requirement-free. "QM" means only "no integrity claim is made on Autoware for that goal" — because an independent ASIL element handles it. The QM(D) channel still carries the decomposed safety requirement and its ASIL-D provenance; it is inside the safety concept, not outside.Necessary conditions (each is a failure point):
What the island legitimately covers (the failure classes adjudicable from signals independent of the main channel's correctness, judging Autoware's output, not its internals): systematic/random faults of the QM compute (hangs, crashes, schedule violations) — which is exactly why the exception/STL/heap-using rclcpp code is legitimately QM — plus out-of-envelope or implausible commands, freshness/timeout, lockstep/control faults, kinematic plausibility, and geofence/ODD-exit.
What the island cannot cover — the binding L4 case: SOTIF perception/planning insufficiency. A false-negative pedestrian, a misclassification, sensor degradation in rain/glare, or a wrong intention prediction is not a fault the doer commits — it is the function working as built. The killer property: such an insufficiency produces a plausible, in-envelope, fresh, lockstep-valid command, so every fault-oriented check the island runs passes. If the island shares or trusts Autoware's perceived world, the insufficiency is a common-cause failure — the DFA must reject it, so the decomposition earns zero ASIL credit against the dominant L4 hazard. Catching it requires the island to have its own independent (different-physics sensors) and SOTIF-sufficient perception + safety world-model — effectively a second perception stack. That is the standing, expensive, unsolved problem; Responsibility-Sensitive Safety (RSS) / IEEE P2846 relocate it (every envelope guarantee is conditional on correct perception input), they do not solve it.
Substrate ≠ coverage (the strategic crux). S-CORE, S32Z2+FS86, Zephyr-FreeRTOS, Apex.Grace, or eProsima Safe DDS can serve as the island substrate and carry the checker's ASIL — qualified compute/OS/comms on which the checker and MRM run. None of them provides coverage-completeness. Whether the island actually makes the item safe depends on the independent-perception redundancy, the ODD restriction, the DFA, and the ISO 21448 argument — all owned by the integrator, all independent of the substrate choice. "Choosing a certified substrate makes the item safe" is the central misconception to avoid.
Misconceptions this section retires: "the ASIL island makes the L4 vehicle safe" (only goals it can independently observe + judge); "QM anywhere = unsafe" (false — Cl.5 permits a QM doer under an independent ASIL checker); "QM(D) is requirement-free"; "two boxes = decomposition" (needs DFA); "redundancy reduces ASIL" (only diversity does); "the DDS bridge is plumbing" (it is the primary common-cause-failure risk); "a simple monitor catches a missed pedestrian" (it cannot); "RSS solves SOTIF perception"; "a bare stop is always safe"; "a certified substrate makes the item safe."
4. Direction: evaluate S-CORE as a Safety-Island substrate
This is the one concrete engineering track worth opening — and §3 fixes its scope precisely.
Why this is the only ASIL-preserving placement. ASIL integrity is end-to-end; it cannot be handed upward through an interface. Putting QM Autoware on top of an S-CORE ASIL floor yields a QM system on a wasted ASIL floor (the per-ASIL FFI has no ASIL peer to protect; its Assumptions of Use are violated on a Linux/QM host; FEO determinism collapses the moment an activity re-enters rclcpp/DDS/STL). Of the placements analysed (rmw/transport shim, OS substrate, executor shim, decomposition boundary — Appendix A.3), only the decomposition boundary beside the apps preserves ASIL value. That boundary is the Safety Island.
The architecture (Figure 2). Keep the entire Autoware AD stack verbatim on ROS 2/rclcpp as the QM doer. Beside it, on the far side of an ISO 26262-9 decomposition boundary, run a small, fully-controlled native ASIL element — a fallback/MRM controller + an independent safety monitor (the checker) — with the "thin API" being an E2E-protected gateway (CRC + sequence counter + DataID; its own FMEA/DFA arguing independence). TIER IV's Safety Island already proves the shape: the pure-C++/Eigen controller subset runs with no rclcpp, DDS-bridged, on a separate domain.
What S-CORE would contribute to that element (and only that element): the exception-free base-library coding subset (C8), Fixed Execution Order (FEO) deterministic execution / Worst-Case Execution Time (WCET) discipline (C6), LoLa (S-CORE's zero-copy IPC) per-ASIL freedom-from-interference (C5), a certifiable OS path (C7), and — most valuably — the open ISO 26262 process spine (C1/C2) for the element's work products. It carries the checker's ASIL substrate. It does not carry coverage-completeness (§3): the independent-perception/ODD/DFA/21448 work remains TIER IV's.
Benchmark against the incumbent — do not assume S-CORE wins. The existing FreeRTOS/Zephyr-on-S32Z2+FS86 island already implements this decomposition and currently beats S-CORE on the safety axis: ASIL-D-capable lockstep silicon + ASIL-targeted Microcontroller Abstraction Layer (MCAL) today vs S-CORE's ASIL-B-capped, uncertified, stub-artifact posture through start-of-production (SOP) 2030. Since L4 motion/fallback typically needs ASIL-D, the silicon-based island remains the integrity-bearing channel. S-CORE is therefore evaluated as an alternative/complementary substrate for the island's compute element, not as a replacement of the island concept, and chosen only if "open/ownable substrate + richer compute + the open process spine" outweighs the proven MCU island.
Decision gates for this track:
Recommended evaluation — a bounded PoC. Build a native S-CORE fallback controller + independent monitor behind a DDS↔LoLa E2E bridge on a dev board, and compare head-to-head with the current S32Z2 island on: reachable ASIL ceiling, certification-evidence maturity, WCET/determinism, developer ergonomics, and whether the open process spine + richer compute justify it over the MCU island. Treat it as substrate selection for the checker, never as a safety claim for the item.
5. What to actually adopt from S-CORE now (ASIL gap-fill)
Independent of the substrate track, S-CORE has a few capabilities Autoware genuinely lacks, ranked by real ISO 26262 contribution (maturity-verified, adversarially checked; full detail in Appendix A.2). After verification, none rated "High" — the strongest are process/coding-discipline assets, adoptable as patterns today:
# req-Id:tag is language-agnostic).Result<T>/expected, safesafe_math, bounded allocation; Real, TRL 6). Pilot inside the Safety-Island element (§4), not the rclcpp main compute..clang-tidy+ MISRA-C++ pack). Cheap CI win (largely off-the-shelf).Honest caveat: the traceability/process machinery is real, but the safety nodes it links (FMEA/DFA/FMEDA — Failure Mode, Effects and Diagnostic Analysis — confirmation-review results, coverage) are still empty templates, nothing is a qualified tool/certified component, and everything is ASIL-B-capped.
6. Timing & conditions — roadmap gates
S-CORE roadmap: v0.5 alpha (Nov 2025) → v0.5 beta (Dec 2025) → v0.6 (Feb 2026, revoked) → v0.7 (May 2026) → v1.0 "ready for series development" (end-2026, ASIL-B) → v2.0 "ready for SOP 2030" (2028). ASIL-D never named or dated. Date credibility: v0.5 shipped on time, but v0.6 was revoked and cadence is "still adjusting"; v1.0's certifiability evidence lands essentially at the deadline with no slack.
rmw/rclcpp-compatible binding → only then is any transport-level reuse even coherent (and still only for QM-grade gains).7. Recommendation & next actions
rmwbinding, a State-Manager reference) to keep an open-substrate × open-AD pairing buildable for AWF/robotaxi integrators.Appendix A — Direct comparison: S-CORE vs the ROS 2 system layer
This is the narrow "could S-CORE replace Autoware's ROS 2 system layer" analysis, retained as supporting evidence. Verdict: No-Go for replacement — 8 of 10 system layers land on Keep ROS 2, 2 on Complement, 0 on Replace (all High confidence, all Very High migration cost). Weighted scorecard: ROS 2 4.27 vs S-CORE 2.27.
A.1 Layer-by-layer
mw::com+ LoLa zero-copy; DDS/SOME-IP gateways design-onlyrclcppover CycloneDDS, 3-ECU split, Agnocast zero-copyrclcppexecutors, components, launch+systemddiagnostic_graph+ command-mode + MRMscore::mw::log, tracing, diagnostics (no impl.)rclcpplog +/rosout,ros2_tracing/CARET, diagnostics, rosbag2score::timegPTP +feo_timerclcpp::Time/TF2/use_sim_time; OSptp4l/PHCcolcon/ament; no traceability/processResult<T>, safe containersrclcpp+autoware_utilsetc.; STL + exceptionsWhy replacement fails: (1) no compatibility seam — S-CORE exposes
ara::com/ara::execas its public API, not anrmwbackend, so replacement is a >1,500-file rewrite (Autoware is 1,535/2,957 C++ files rclcpp-coupled); (2) maturity is intent-heavy — pre-1.0, "no backwards-compat guarantee", v0.6 revoked; (3) cheaper incumbents already occupy the seams — Agnocast (zero-copy), CycloneDDS (wire), the Safety Island (ASIL).A.2 Weighted scorecard (0–5)
The functional-safety tie (2/2) reflects that S-CORE has the better open process while ROS 2 has already-certified ASIL-D paths (Apex.Grace, Safe DDS) — neither ships a certificate an Autoware project can inherit.
A.3 Thin-API hybrid placements (why "beside", not "under")
Evaluating "keep Autoware on ROS 2, port only the low layer to S-CORE behind a thin API": ASIL value is voided at every under-the-apps placement and preserved only at the beside-the-apps decomposition boundary (§3, §4).
rmw_lolaunder rclcpp)A.4 ASIL gap-fill — verified capability ranking
After adversarial verification, the actionable set is C1 (traceability, Real/TRL 8, adopt now), C2 (process framework, adopt pattern), C8 (base libraries, pilot on the Island), C12 (coding-standard CI, cheap). Mid-tier Watch: C5 FFI, C9 health-monitoring, C3 safety analyses (largely stubs), C4 tool-qualification. Low: C6 FEO, C7 QNX-OS-abstraction, C10 persistency, C11 crypto. See §5.
Appendix B — MoU signatories (industry backing; context, not capability)
The MoU (explicitly not legally binding) is signed by 33 organizations. Initial (May 2025, 11): BMW, Bosch, Continental, ETAS, FORVIA (HELLA), Mercedes-Benz, QORIX, Valeo, Vector, Volkswagen, ZF. Addition (Dec 2025, 22): 42dot, AVL, Accenture, Capgemini, Coretura, Cummins, ECARX, Elektrobit, Infineon, Lear, LG Electronics, Michelin, Hyundai Mobis, QNX, Qualcomm, Red Hat, Stellantis, Schaeffler, TRATON, T-Systems, Useblocks. Founders (Eclipse records): Accenture, BMW, ETAS, Mercedes-Benz, Qorix; commit data is BMW-dominant. Breadth of signatories ≠ breadth of co-development.
Appendix C — ROS-2-native certified safety baselines
rclcpp-compatible ROS 2 subset, ~100 work products, 100% MC/DC. (~65K LoC first round, ~14 person-years, >$5M.)Appendix D — Methodology & evidence base
Produced by a multi-agent investigation with adversarial verification of every per-layer verdict, ASIL-capability rating, and the functional-safety reasoning (ISO 26262-9 decomposition + ISO 21448 SOTIF cross-checked against the normative texts). Sources:
github.com/eclipse-score,metrics.eclipse.org/projects/automotive.score,eclipse.dev/score, the S-CORE Convergence deck (2026-05-27) and signed MoU; the "Scope of S-CORE v1.0" stack diagram;apex.ai/apexgrace+ Apex.AI ASIL-D report; eProsima Safe DDS 3.0 (TÜV SÜD);eclipse-score/communication(LoLa,ara::com); ISO 26262-9 Cl.5 decomposition and ISO 21448 SOTIF; the TIER IV Safety Island (NXP S32Z2 + FS86, Zephyr/FreeRTOS) and Agnocast.Glossary
ASIL Automotive Safety Integrity Level (A–D) · QM Quality Management (no ASIL) · SEooC Safety Element out of Context (ISO 26262-10) · AoU Assumptions of Use · HARA Hazard Analysis and Risk Assessment · FFI Freedom From Interference (ISO 26262-9) · DFA Dependent Failure Analysis · decomposition ISO 26262-9 Cl.5 ASIL tailoring (
X → X(X)+QM(X)etc.) · doer/checker complex QM channel + independent ASIL monitor/safe-state · FTTI Fault-Tolerant Time Interval · MRM Minimal Risk Maneuver · SOTIF Safety Of The Intended Functionality (ISO 21448) · FMEA / FMEDA Failure Mode (and Effects) (and Diagnostic) Analysis · MC/DC Modified Condition/Decision Coverage · RSS / IEEE P2846 formal safety-envelope models · MCAL Microcontroller Abstraction Layer · WCET Worst-Case Execution Time · BSP Board Support Package · TRL Technology Readiness Level · SOP Start of Production · LoLa S-CORE zero-copy IPC · FEO Fixed Execution Order ·ara::*AUTOSAR Adaptive APIs ·rmwROS Middleware abstraction · ODD Operational Design Domain.Beta Was this translation helpful? Give feedback.
All reactions