Jherrod ThomasThe Lion of Functional Safety™

September 27, 2026 · 12 min read

ISO 26262-7 §5 / §7ISO 26262-6 Annex C / -8 §7 / §826V582 / 26E063 / 26S68 / 26S70

When the Repair Was the Fault: Ford's 26V582 Mach-E Replacement BECM and the Learned State Nobody Migrated, Through an ISO 26262-7 Service Lens

The car goes into the dealer with a battery controller fault. It comes out with a new battery controller, a clean scan, and a range estimate that looks better than it did the day before. The owner is pleased. The owner should not be, because the new module has just been introduced to a three-year-old battery pack and has decided, on no evidence whatsoever, that the pack is brand new.

Nothing in the vehicle as designed was wrong. The vehicle as repaired was. That distinction is the whole post, and it is the distinction most functional safety programs quietly stop caring about the day of SOP.

1. The public record

Two campaigns, one defect. On September 9, 2026, Ford Motor Company filed two Part 573 reports with NHTSA. NHTSA acknowledged both on September 14, 2026, under the same subject line: "Loss of Power or Fire Risk from Incorrect BECM Software." (NHTSA acknowledgement letters, 26V582 and 26E063)

NHTSA's consequence statement, identical in both letters:

"An inaccurate state-of-charge reading can lead to an unexpected loss of drive power, increasing the risk of crash. Additionally, an overheating BECM increases the risk of a fire."

The mechanism. The trade press, working from Ford's filings, is consistent on what happened. The newly installed module "initializes at 100 percent battery state of health instead of inheriting the real value of the high-voltage battery," and the resulting overestimate makes the cluster display an unrealistically high state of charge (autoevolution, September 15, 2026). Every affected vehicle has a lithium iron phosphate (LFP) traction battery. When real energy runs out before displayed energy does, the drive system limits power, the wrench or turtle telltale appears, and eventually motive power is lost (Carscoops, September 19, 2026).

The fire path is quieter and, to my eye, more interesting. AutoGuide's summary of Ford's technical documentation: overestimating SOH "leads to accelerated lithium plating within the high-voltage battery cells during repeated DC Fast Charging (DCFC) cycles," and severe plating raises the risk of thermal venting (AutoGuide, September 15, 2026). NHTSA's one-line summary compresses this to "an overheating BECM," which is not quite the same thing. I will go with the more detailed description, and note the difference so nobody accuses me of smoothing it over.

The discovery. Ford's Electrified Propulsion Engineering team spotted SOH discrepancies in LFP Mach-Es following module replacement. The Critical Concern Review Group opened a formal investigation on July 7, 2026, then reviewed warranty claims, service-parts sales and connected-vehicle data through August. Ford counted one warranty report, one Global Contact Center report and two internal quality-indicator reports, and says it knows of no crashes, injuries or fires (autoevolution; AutoGuide).

Why there are two campaigns. Some of these BECMs were "sold over the counter or installed as warranty replacements without sufficient traceability to individual vehicles" (autoevolution). Ford could name 86 VINs. It could not name every car that received one of the 83 modules, so the part itself gets recalled. Autobody News also flags the over-the-counter and warranty channels (Autobody News, September 15, 2026).

The remedy. Dealers reflash the BECM through Ford's Diagnosis and Repair System. The revised software "adds the data-migration protocol" so the replacement module inherits the pack's real SOH (autoevolution).

A note on sources: Ford Authority's write-up says the displayed SOC may read lower than actual (Ford Authority, September 20, 2026). Every other account, and the physics below, says higher. Overstating SOH can only overstate SOC, so I treat "lower" as an editing error.

2. The standards lens

The easy take is "software bug, Part 6, done." It's wrong, and it lets the wrong organization off the hook. The code shipped in the original BECM presumably learned SOH correctly over thousands of cycles. The failure is that learned, safety-relevant state was bound to a replaceable part rather than to the physical asset it describes, and the service process had no step to carry it across. Five places in ISO 26262 should have caught that.

ISO 26262-7 §5 — Planning for production, operation, service and decommissioning. Part 7 exists so the safety argument outlives the factory gate. Clause 5 requires planning for maintenance and repair, and that planning must be driven by the safety requirements. Swapping a BECM is a planned, catalogued repair with its own part number. The plan should have asked one question about it: what does this module know that the new one won't?

ISO 26262-7 §7 — Operation, service (maintenance and repair), and decommissioning. Here the maintenance and repair instructions become real work instructions, and the safety-relevant conditions for performing them get specified. "Install module, flash, clear DTCs" is a complete procedure for a body controller. For a controller holding a capacity estimate that drives both a propulsion limit and a charge-current limit, it is missing a step. That step has a name: state migration, with verification.

ISO 26262-4 §6 — Technical safety concept. The TSC is where requirements for production, operation, service and decommissioning are supposed to originate, next to the safety mechanisms themselves. If the charge-current safety mechanism depends on an accurate capacity estimate, the capacity estimate is a safety-relevant input. The TSC must then state how that input survives the replacement of the ECU holding it. I have not seen Ford's TSC. What I can say is that the 26V582 remedy, a data-migration protocol, is exactly the requirement that document would have produced.

ISO 26262-6 Annex C — Software configuration. Annex C is about configuration and calibration data, and the verification a configured build needs. People read it for variant coding and calibration maps. It applies just as much to learned parameters that initialize to a default. A default is a calibration value. "SOH = 100 % until proven otherwise" is a calibration choice with a safety consequence, and it needs the same scrutiny as any hand-tuned limit. The safe default for an unknown pack is the least favourable plausible value, not the most favourable.

ISO 26262-8 §7 and §8 — Configuration management and change management. The equipment recall tells us that service parts left the building without traceability to the vehicles they went into. Configuration management has to include the service population, not just the production bill of materials. Ford needed a second campaign because it could not answer "which cars have this part?"

One adjacent point. The remedy runs through a dealer tool, not over the air. Under UN R156 the workshop reflash is itself a software update that the software update management system has to govern. The migration step belongs in that update's integrity checks, so the next replacement module ships with the fix already applied.

3. A worked snippet

3a. Why SOH error becomes SOC error, and why LFP makes it worse

A BMS that counts coulombs computes state of charge roughly as:

SOC(t) = SOC(t0) - (integral of I dt from t0 to t) / (SOH x C_nominal)

  SOH        state of health, fraction of nominal capacity still available
  C_nominal  nominal pack capacity, Ah

Put SOH = 1.00 into a pack whose true SOH is 0.88 and the denominator is about 14 % too large. Every amp-hour drawn moves the estimate about 12 % less than it moves the real charge. Drive from full and the error builds up. Here is an illustrative case. The numbers are mine, not Ford's.

| True energy used | True SOC | Estimated SOC (SOH assumed 1.00) | Displayed error | |---|---|---|---| | 0 % of true capacity | 100 % | 100 % | 0 pts | | 50 % | 50 % | 56 % | +6 pts | | 80 % | 20 % | 30 % | +10 pts | | 90 % | 10 % | 21 % | +11 pts | | 100 % | 0 % | 12 % | +12 pts |

A nickel-rich pack would correct this without help. Its open-circuit voltage slopes across the SOC range, so every rest period is a chance to re-anchor the estimate. LFP has one of the flattest OCV curves in commercial use. Across most of the usable window, voltage says almost nothing about SOC. Reliable correction points exist only near the top of charge and at the low-SOC knee. So an LFP BMS leans harder on coulomb counting and on the capacity term inside it. That's why this recall is LFP-only, and why the error can survive until the cells hit the knee. At the knee, minimum cell voltage drops, the power limiter acts, and the driver is looking at a display that still says 12 %.

The charging side is the mirror image. DC fast-charge current is normally tapered as a function of estimated SOC and temperature. Overstate capacity and the estimate lags the real SOC during charging, so the pack gets high-current table entries at a real SOC where the anode can no longer accept them. That condition is textbook lithium plating, and it's cumulative across DCFC sessions.

3b. Fault tree (top two levels, service-induced branch)

TOP: Unexpected loss of motive power, OR thermal event in traction battery
 |
 +-- OR -- Capacity term in SOC estimator exceeds true pack capacity
 |          |
 |          +-- AND -- Replacement BECM installed                      [service event]
 |          |      +-- Learned SOH/capacity not migrated to new module [missing procedure step]
 |          |      +-- New module default SOH = 1.00 (optimistic)      [Annex C default choice]
 |          |      +-- No plausibility check detects mismatch before   [missing safety mechanism]
 |          |          knee / DCFC exposure
 |          |
 |          +-- (development branch: estimator drift, sensor offset - not in scope here)
 |
 +-- Consequences
      +-- Discharge: knee reached at displayed SOC well above zero -> power limit -> loss of drive
      +-- Charge:    DCFC current table applied at under-estimated SOC -> Li plating -> venting risk

The AND gate is the lesson. Any one of its four inputs, fixed, cuts the branch. Ford's remedy fixes input two. A reviewer should ask why inputs three and four were ever allowed to be that way.

3c. Service-process FMEA (AIAG-VDA 2019 format, excerpt)

This is the table that should exist for the repair procedure, not for the part. Ratings are my own illustrative assessment. Action Priority uses the AIAG-VDA lookup table.

| Process step | Failure mode | Effect | S | Cause | Prevention (current) | O | Detection (current) | D | AP | |---|---|---|---|---|---|---|---|---|---| | Replace BECM | Learned SOH/capacity not transferred to new module | Displayed SOC overstated; loss of drive power near knee; Li plating under DCFC | 9 | Procedure and software lack a migration step; module defaults to SOH 1.00 | None specific | 4 | End-of-line DTC scan (does not see SOH) | 7 | H | | Replace BECM (over-the-counter part) | Part installed with no link to VIN | Affected population cannot be identified in a later campaign | 7 | No registration step for OTC safety-relevant modules | Parts-sale records only | 5 | None | 9 | H | | Replace BECM (after action) | Same as row 1 | Same | 9 | Same | Migration protocol with read-back verify; conservative default if migration fails | 2 | Tool confirms stored SOH matches source within tolerance; DTC on mismatch | 2 | L |

Note that a scan tool that reports "no DTCs" is rated D = 7 for a failure that, by definition, sets no DTC. That's the recurring trap: a detection control gets credit for coverage it doesn't have.

4. Derived requirements (excerpt)

Requirement IDs are stable and illustrative. Numeric values are placeholders a real program would justify from cell data.

Requirement 04 is the one I would fight hardest for in a review. Requirements 01–03 fix this failure path. Requirement 04 is a diagnostic on the physical quantity itself: the cell voltage cannot be fooled by a default value.

5. What the headline really tells us

"Ford recalls 86 Mach-Es over software issue" is accurate and almost useless. The software did what it was written to do. Faced with a pack it had never met, it assumed that pack was perfect. The missing artifact is not a line of code. It's a service-phase safety requirement: a sentence in the technical safety concept, carried into the Part 7 repair instructions, stating that learned battery state belongs to the battery and has to follow it across any controller swap. Without that sentence, a correct module plus a correct procedure add up to a vehicle that overstates its range and fast-charges its cells into plating.

Ford gets real credit here. A population of 86 vehicles, found by an engineering team reading SOH trends in connected-vehicle data before any customer was hurt, is what post-production monitoring is supposed to look like. The second campaign also shows honest configuration accounting. Ford admitted it couldn't trace every part, and recalled the part.

The broader point applies to anyone whose product learns: a BMS, an adaptive cruise model, an infusion pump's occlusion baseline, a robot's calibrated payload. The safety case covers the system as designed and as built. It also has to cover the system after its third repair by a technician who has never seen the design. If the learned state that keeps it safe can be wiped by a part swap, the service manual is part of the safety architecture, whether or not anyone wrote it that way.

Sources

— Jherrod Thomas, The Lion of Functional Safety™