Jherrod ThomasThe Lion of Functional Safety™

September 19, 2026 · 15 min read

ISO 26262-3 §6 / §7 / -4 §6ISO 26262-6 §5.4.8 / -8 §8 / -9 §726V570 / 26TA17 / UN R100.03

When the Safe State Was the Second Hazard: Toyota's 26V570 C-HR EV Shutdown Through an ISO 26262 Calibration-Data and Degradation Lens

Cold morning, battery charged overnight, two-lane road down off the pass. You lift off the accelerator and let regen do the braking, the way the car taught you to drive it in the first week. Somewhere below you the pack crosses a voltage it was never supposed to reach, the controller notices, and the controller does exactly what it was designed to do. The warning lights come on. A buzzer sounds. The drive system shuts off and you are coasting.

Nothing in that sequence is a malfunction, except the first step. The overcharge protection worked. It worked at the only moment it has ever been asked to work, and the price it charged was a stranded vehicle on a grade. That price was never written down anywhere, and that is the entire post.

1. The public record

NHTSA campaign 26V570. Manufacturer's report date September 2, 2026; NHTSA acknowledgement letter to Toyota Motor Engineering & Manufacturing dated September 9, 2026. Toyota's own recall number is 26TA17. Population: 8,521 model-year 2026 Toyota C-HR battery electric vehicles. NHTSA's component classification is ELECTRICAL SYSTEM:PROPULSION SYSTEM. The subject line NHTSA put on its own letter is worth reading twice: "Loss of Drive Power from Software Programming Error." (NHTSA acknowledgement letter, campaign 26V570, September 9, 2026)

The problem description and consequence, verbatim:

"A software programming error may cause the electric drive system battery to become overcharged under certain driving conditions, which can shut down the electric drive system and result in a loss of drive power."

"An unexpected loss of drive power increases the risk of a crash."

Two hazards in one paragraph, and the regulator's filing categories give you no way to tell that the second one is the remedy for the first.

Build window is February 6, 2026 through July 10, 2026 at the Takaoka plant in Japan. The estimated percentage of vehicles with the condition is 100% — every unit in the window carries the suspect parameters. Two part numbers are listed, both supplied by Denso Corporation. The affected car is the e-TNGA-based electric C-HR, 74.7 kWh pack, dual-motor AWD, sold from about $37,080; the same vehicle is the C-HR+ in Europe and the Subaru Uncharted wearing a different badge. Toyota's filing notes that "not all vehicles in this range were sold in the US." (autoevolution, September 14, 2026; Electrek, September 10, 2026)

The mechanism, assembled from the filings and the trade reporting:

| Step | What happens | | --- | --- | | 1 | Cell temperature low, state of charge high, regenerative braking sustained — a descent on a cold morning after a full charge | | 2 | The BEV ECU's battery-protection logic is supposed to cap the charge current flowing back into the pack | | 3 | An incorrectly programmed parameter disrupts the charge-limiting function, and the limiter does not cap the input | | 4 | Pack charges past its design limit; the ECU detects the overcharge state | | 5 | Warning lamps and a buzzer activate, and the electric drive system is shut down | | 6 | Vehicle loses motive power and coasts |

The remedy is a dealer reflash of the BEV ECU with revised battery-protection logic. Owner notification letters go out October 18, 2026.

The chronology is the good news, and nobody reported it that way

In April 2026, Toyota engineers running routine development testing on an undisclosed future BEV model found an incorrect parameter in the control unit. Recognising that the control logic was shared across the electric lineup, they opened a review of the ECUs in the other EVs — and that review found the same error sitting in a car that had been in series production since February. (Carscoops, September 11, 2026)

Toyota is aware of no warranty claims and no field reports. Zero. Eight and a half thousand cars, a hundred percent defect rate, five months of production, and the defect was found by a test engineer on a different program rather than by a customer on a mountain road.

I spent a post in August taking Toyota apart for letting a correct fault tree stay inside one combination-meter program while a second meter program shipped the same failure class. This is the mirror image, and it deserves to be said with the same volume. The read-across worked. Somebody found a bad number, asked "where else does this number live," and got an answer that included a car already in customers' driveways. That is the ISO 26262-8 Clause 8 impact analysis doing its actual job, and it is rarer than it should be.

None of which makes the design decision underneath it defensible.

2. The standards lens

Start by ruling out the wrong standard

Cold weather, a specific grade, a high state of charge, a rare envelope — this has the shape of a scenario people reach for ISO 21448 to talk about. It is not a SOTIF case. ISO 21448 governs hazards arising from insufficiencies of the intended functionality in the absence of a fault: the sensor that cannot see, the algorithm that generalises badly, the performance limitation you cannot debug because nothing is broken.

Here something is broken. A parameter has the wrong value. That is a systematic fault in a safety-related element, introduced in development, present in 100% of the population, and detectable by verification. It lives in ISO 26262 and nowhere else. The unusual operating envelope is not a triggering condition in the SOTIF sense; it is just the part of the calibration grid where the wrong number lives.

Calibration data is a work product, and almost nobody treats it like one

ISO 26262-6:2018 §5.4.8 through §5.4.11 added explicit requirements for configuration data and calibration data: they shall be specified, their valid value ranges declared, verified against those ranges, and subject to the rigour of the ASIL they support. The clauses exist because the 2011 edition left a gap you could drive a recall through.

The gap has not closed, for reasons that are organisational rather than technical:

This matters here more than usual, because of what it means for verification evidence. You can run MISRA C compliance on the limiter function, unit test it to 100% statement and branch coverage, achieve MC/DC on every decision, run it through a qualified compiler, and sign the whole thing off at ASIL D — and if the low-temperature entry in its limit map is wrong, every one of those metrics stays green while the pack overcharges. The code executed the table correctly. The table was wrong. Structural coverage measures whether you exercised the logic, not whether the data the logic reads is true.

Two safety goals, two ASILs, and an arbitration nobody documented

Run the ISO 26262-3 Clause 6 hazard analysis on this item honestly and you get at least two safety goals at different integrity levels:

Now put those two in the same ECU and give one of them an actuator that violates the other. The shutdown is not a bug. It is SG-01's safety mechanism resolving the conflict in its own favour, which is the correct resolution — you do not trade a thermal event for a coast-down, and anyone who argues otherwise has not read an EV fire report.

But ISO 26262-3 §7.4.2.4 requires the functional safety concept to specify the safe state, and where a transition to the safe state cannot be completed within the fault-tolerant time interval, to specify the emergency operation instead. "Drive disable" is a safe state with respect to SG-01 and a hazardous event with respect to SG-02. The standard does not forbid that. It requires you to write it down, classify it, and allocate an ASIL to the consequence of your own safety mechanism firing.

I have reviewed a lot of functional safety concepts. The row that says "SM-01 actuation is itself a hazardous event under SG-02, rated ASIL B, mitigated by X" is almost never there. What is there instead is a safe state named once, in a table, with no arrow pointing out of it.

The degradation ladder had no rungs

This is the one that should change how you write your next technical safety concept.

ISO 26262-4 Clause 6 wants the technical safety concept to specify the measures for fault handling, including degradation. Between "full regenerative braking" and "no propulsion at all" there is a monotone ladder, and every rung on it protects the pack:

  1. Reduce the regenerative current limit.
  2. Inhibit regeneration entirely and blend friction braking to hold the commanded deceleration.
  3. Annunciate, limit propulsion power, request the driver to stop.
  4. Disable the drive system.

Steps 1 through 3 all achieve SG-01. Step 4 is what shipped. And here is why — the function that would have performed step 1 is the function that failed. The charge-current limiter is simultaneously the primary control and the first rung of the degradation ladder. When those are the same function, the ladder is not a ladder; it is a single point of failure with a fallback that skips four levels.

The timing argument makes this worse rather than better. The fault-tolerant time interval for cell overcharge is not milliseconds. Lithium plating is a cumulative electrochemical process; the damage integrates over seconds of sustained over-voltage charging, not over a control loop period. There was time to descend the ladder. The design used none of it, because there was no ladder to descend.

Dependent failure analysis, ISO 26262-9 Clause 7

Name the coupling factors and the picture finishes itself:

What the regulations actually test

UN R100.03 requires overcharge protection and verifies it in Annex 9, test 9G: charge the REESS until the protection interrupts or limits the current, and confirm it does. In the US, FMVSS 305a governs electrolyte spillage and electrical shock protection for electric-powered vehicles; there is no federal in-service overcharge test for a propulsion battery.

So the type approval asks does the protection operate. It never asks what does the vehicle do while it operates. That question belongs to nobody but the HARA, and on this program the HARA did not ask it either.

3. A worked snippet

Here is the hazard analysis I would want on the item. Severity, exposure and controllability ratings are mine, argued from ISO 26262-3:2018 Table 4; Toyota has published no ASIL and is under no obligation to.

| ID | Malfunctioning behaviour | Operational situation | Hazardous event | S | E | C | ASIL | | --- | --- | --- | --- | --- | --- | --- | --- | | MF-01 | Charge current into the traction battery not limited at the cell voltage upper bound | Any drive or charge cycle, occupants aboard | Cell overcharge, lithium plating, internal short, progression to thermal runaway | S3 | E4 | C3 | D | | MF-02 | Regenerative charge-current limit map incorrect in the low-temperature, high-SOC region | Sustained descent, grade 5 to 10 percent, ambient near or below 0 °C, SOC above 90 percent, lift-throttle regen | MF-01 reached through a specific, reachable and repeatable envelope | S3 | E3 | C3 | C | | MF-03 | Tractive effort removed without prior warning or driver request | 70 mph, dense multi-lane highway, no usable shoulder | Unannounced deceleration relative to following traffic; rear-end impact or forced lane change | S2 | E4 | C2 | B | | MF-04 | Tractive effort and regenerative retardation removed together on a descent | Two-lane mountain descent, guardrail, oncoming traffic, no shoulder | Primary retardation lost; friction brakes assume full grade duty; fade risk, or stop in a live lane | S3 | E2 | C2 | A |

MF-04 is the row I have not seen anyone else write, and it is a hypothesis about the architecture rather than a claim about Toyota's design: regenerative braking is a function of the electric drive system. If disabling the drive system also removes regeneration, then the vehicle loses its primary retardation in the one operating situation that produced the fault. A driver who has spent six months learning to descend grades on one pedal now has friction brakes, a cold rotor, and no warning that the rules changed. That deserves its own row whatever the answer turns out to be.

Fault tree for the top event

TOP   Unannounced loss of tractive effort at road speed
      (violation of SG-02, ASIL B)
                            |
                          [ OR ]
         +------------------+---------------------+
         |                                        |
   G1  SM-01 overcharge protection            G2  Other drive-disable
       commands drive-system disable               paths: HV contactor,
         |                                         inverter fault, loss
       [ AND ]                                     of isolation
         |                                         [ out of 26V570 scope ]
   +-----+-----------+----------------------+
   |                 |                      |
 B1  Charge-       B2  Trigger envelope   B3  No graded degradation
     current           entered:               stage between "reduce
     limit map         T_cell low,            regen" and "disable
     value invalid     SOC high,              drive"
     in the cold /     regen sustained        [ UNDEVELOPED - design
     high-SOC cell     on a grade               characteristic, not a
     [ CALIBRATION                              random fault ]
       DATA FAULT ]
                                           |
                                        [ AND ]
                                    +------+------------+
                                    |                   |
                                  B3a  Limiter is     B3b  Monitor has
                                       also the             exactly one
                                       first                actuator:
                                       degradation          drive disable
                                       stage

B3 is drawn as an undeveloped event on purpose. It is not a fault that occurs; it is a property the design always had, sitting in an AND gate with a fault that occurs rarely. Remove B3 and B1 becomes a drivability complaint. That is what a missing degradation concept costs you: it converts an ordinary calibration error into a Part 573 filing.

4. Derived requirements (excerpt)

FSR-BEV-001 (ASIL D). Charge current into the traction battery shall be limited such that no cell exceeds its specified maximum charge voltage under any combination of state of charge, cell temperature and regenerative input duration within the declared operating envelope. Verification: envelope sweep at the cold and high-SOC corners of the declared grid, on cells, on pack, and at complete-vehicle level on a sustained-grade profile.

FSR-BEV-002 (ASIL B). Removal of tractive effort by a battery-protection mechanism shall be preceded by a graded degradation sequence and by driver annunciation. Immediate drive disable shall be permitted only when the graded sequence has failed to arrest the protected quantity, or when an absolute cell voltage limit is exceeded.

TSR-BEV-011 (ASIL D). The regenerative charge-current limit shall be derived at runtime from measured cell voltage and cell temperature. Whenever a calibration map lookup returns a value outside its declared valid range, or its input arguments fall outside the calibrated grid, a monitored fallback limit shall apply within 50 ms. Extrapolation beyond the cold end of the calibrated temperature grid shall be prohibited by design, not by convention. This requirement exists because a map with one wrong cell should degrade to conservative, not to unlimited.

TSR-BEV-012 (ASIL B). The battery-protection function shall implement a four-stage ladder against the maximum cell charge voltage V_max:

Stages 1 through 3 consume under 500 ms of a fault-tolerant time interval measured in seconds. The budget was always there.

TSR-BEV-013 (ASIL A). Where a descent is detected from sustained negative grade and sustained regenerative demand, the transition to Stage 4 shall be inhibited unless the absolute cell limit is exceeded, and the driver shall be annunciated that regenerative retardation is being withdrawn at least 3 s before it is withdrawn.

VER-BEV-021 (ASIL D). Every calibration map that is an argument to a safety mechanism shall be verified across its full declared input grid including all corner cells, with explicit cases at the cold-temperature and high-SOC extremes and at least one case outside the calibrated grid to confirm fallback behaviour. Review of a map by a calibration engineer shall not be accepted as verification of an ASIL D limiting function, and structural coverage of the function that reads the map shall not be presented as evidence about the map.

VER-BEV-022 (ASIL D). Whenever a defect is found in configuration or calibration data for any element, the impact analysis required by ISO 26262-8 Clause 8 shall enumerate every program sharing the dataset, any dataset derived from it, or the tool chain that generated it — including programs in series production and programs not yet launched. Toyota passed this one in April 2026. It is in the list because most organisations would not have.

5. What the headline really tells us

The headline is "Toyota recalls 8,521 electric C-HRs over a software glitch," and it is doing the thing headlines always do with software recalls: collapsing four distinct engineering facts into one word.

There was a programming error, and it was in data rather than in code — a limit value in a region of the operating envelope that a cold mountain descent reaches and a dynamometer cycle does not. That part is ordinary. Calibration defects are the most common systematic fault in modern powertrain software and the least well governed, because the artifact changes faster than the safety process that is supposed to wrap it.

What is not ordinary is what the vehicle did next. The overcharge protection detected the condition and removed propulsion at road speed, with a buzzer and about as much notice as a blown fuse. That behaviour was not a failure. It was the design, executing correctly, discharging an ASIL D safety goal by committing an ASIL B hazardous event — and doing it in one step, from full authority to none, inside a fault-tolerant time interval long enough to have taken four.

The missing artifact is not a better limit table. It is a degradation concept: a written statement of what this item does on the way from "everything is fine" to "nothing is available," with thresholds, with timing, with annunciation, and with an ASIL on the consequence of its own protective action. Write that document and the wrong map cell becomes a warning lamp and a temporary loss of one-pedal driving. Skip it, and the same wrong cell becomes a car stopping on a grade and a filing with the federal government.

Every safety mechanism buys down one risk by creating a smaller one. That trade is legitimate, it is unavoidable, and it is the whole craft. The only unforgivable version is the one where nobody wrote down what the trade cost.

Toyota found this one with a test engineer and a read-across, five months before a customer did. Credit where it is due. But the read-across found a bad number. It was never going to find a missing document, because impact analysis searches for artifacts that exist.

Sources

— Jherrod Thomas, The Lion of Functional Safety™