This is not a hypothetical. It is the standard compliance picture for any connected EV powertrain component developed after 2022. The question is not whether these standards apply simultaneously — they do — but how a development organization manages them without creating four parallel documentation silos that contradict each other.

Where the Standards Collide

The BMS-OTA scenario generates specific cross-standard conflicts that are not obvious until you attempt to implement both requirements simultaneously.

OTA Update: Safety vs. Security vs. SOTIF

ISO 21434 requires that OTA updates be cryptographically authenticated and that the update channel be included in the TARA. This is straightforward.

ISO 26262 requires that any software update to a safety-relevant function be treated as a change that may require re-validation of the safety concept. ISO 26262-8 Clause 9 specifies the change management requirements. For ASIL B software, a field OTA update that modifies the overcharge protection threshold calculation is a safety-relevant change requiring regression of the affected safety analysis.

SOTIF adds a third dimension: if the OTA update modifies the SOC estimation algorithm, it may change the system's performance envelope in ways that create new SOTIF triggering conditions — scenarios where the algorithm is correct per its specification but produces outputs that cause unsafe behavior in field conditions the update was not tested against.

The conflict: ISO 21434 wants fast, authenticated updates deployed without delay. ISO 26262 requires change impact analysis before deployment to safety-relevant functions. SOTIF requires post-deployment monitoring for unexpected algorithm behavior. UNECE R156 (Software Update Management System) requires a formal SUMS that satisfies all three.

Teams that implement SUMS for UNECE R156 without connecting it to their ISO 26262 change management and SOTIF monitoring process end up with three separate update approval workflows that must be manually reconciled before each deployment.

The HVIL (High Voltage Interlock Loop) monitors the integrity of high-voltage connectors. It is an ASIL C safety function: if the HVIL detects an open circuit (connector removed or damaged), it must interrupt the high-voltage system within the FTTI.

The HVIL state is communicated over the internal CAN network. ISO 21434 identifies this message as a safety-relevant asset: an attacker who can inject a false "HVIL OK" message while the connector is actually open creates a life-safety hazard.

ISO 26262 requires the HVIL monitoring function to meet ASIL C Diagnostic Coverage requirements. The CAN message must be protected by a CRC and message counter (end-to-end protection per ISO 26262-6 Clause 7.4.2).

ISO 21434 requires, additionally, that the message be authenticated via SecOC (Secure Onboard Communication) to prevent replay and injection attacks from an external attacker who has compromised another node on the CAN bus.

The implementation conflict: SecOC adds a MAC (Message Authentication Code) to each CAN frame. This increases frame length and therefore bus load. On a high-load safety CAN network, the additional bus load from SecOC may push cycle times beyond the latency budget of the ASIL C FTTI. The safety engineer who designed the latency budget did not account for the SecOC overhead because the cybersecurity requirements were defined later, by a different team.

SOC Algorithm: SOTIF vs. ASPICE

The SOC estimation algorithm uses an Extended Kalman Filter (EKF) with neural network correction terms trained on charging cycle data. SOTIF requires that the known and reasonably foreseeable performance limitations of this algorithm be identified and that the operational design domain (ODD) be bounded to exclude conditions where the algorithm degrades beyond acceptable error bounds.

ASPICE SWE.1 (Software Requirements Analysis) requires that every software requirement be specified with measurable acceptance criteria. The SOTIF-derived requirement — "SOC estimation error shall not exceed ±3% under field conditions" — must be translated into a testable software requirement with explicit test conditions.

The problem: SOTIF's "field conditions" include battery aging states, temperature profiles, and charge history combinations that cannot all be enumerated in a software requirements document. The SOTIF analysis produces a qualitative risk acceptance argument; ASPICE requires quantitative acceptance criteria. Bridging these two requires an intermediate architecture decision that neither standard specifies.

The Traceability Problem at Scale

Each document has dependencies on the others. A change to the HARA hazardous event list affects the TARA damage scenario list, the SOTIF triggering condition list, and the ASPICE software requirements baseline. In a typical program, these documents live in separate tools maintained by separate teams. The links between them exist in engineers' heads, in email chains, and in review meeting minutes.

When the OEM requests a change — a new battery chemistry requires a different SOC algorithm — the impact ripples across all four standards. Tracking that impact manually, in four separate teams, with separate document review cycles, is where programs accumulate the silent inconsistencies that surface in certification audits.

How ISO WIZ Addresses the BMS-OTA Scenario

ISO WIZ was built specifically for programs with multi-standard compliance requirements. For the BMS-OTA scenario, it provides:

Unified item definition. A single item definition feeds all four standards. The BMS interfaces, the OTA channel, the HVIL function, and the SOC algorithm are defined once and referenced across HARA, TARA, SOTIF analysis, and ASPICE software requirements.

Cross-standard traceability. The link between a HARA hazardous event and the corresponding TARA damage scenario is a live, bidirectional traceability link. When either document is updated, the other flags the linked item for review. The same mechanism connects SOTIF triggering conditions to ASPICE software requirements.

Gap detection across standards. If the SecOC implementation adds CAN bus load that affects the ASIL C FTTI budget, ISO WIZ detects the gap between the safety timing requirement and the cybersecurity implementation constraint and surfaces it as an open finding — before it becomes a field problem.

Change impact analysis. When the battery chemistry changes, a single change entry in ISO WIZ propagates to all affected work products across all four standards, with a prioritized list of what needs re-review and what can be closed by confirmation that the change is out of scope.

The BMS-OTA compliance problem is hard not because any single standard is incomprehensible, but because the standards were written independently and their interactions are left to the development organization to manage. ISO WIZ provides the infrastructure to manage those interactions systematically.