The Role of Systems Engineering in Battery Electric Powertrain Development

Electric powertrain development has a requirements problem. Not a shortage of requirements — if anything, a surplus. The problem is structural: requirements written by battery engineers don’t connect to requirements written by thermal engineers, which don’t connect to requirements written by charging systems engineers, which may or may not reference the safety requirements that govern all of them. The powertrain ships. The integration problems surface in validation, or worse, in field operation.

This pattern repeats across automotive OEMs, heavy truck manufacturers, and off-highway equipment makers precisely because battery electric powertrains are not electrified versions of what came before. A diesel drivetrain couples a relatively contained combustion system to a mechanical transmission. An electric powertrain couples a high-voltage battery pack, an inverter, one or more motor-generator units, a thermal management system that spans all of them, a battery management system that makes real-time safety decisions about all of them, and a charging interface that connects that entire system to infrastructure designed to standards written by a different industry. Requirements written in functional silos will not survive first integration.

The systems engineering demands this creates are significant, and not yet fully understood across the industry. This article covers what’s actually driving the complexity, where established standards frameworks fall short, and how teams are adapting their practice.

What Makes Electric Powertrain Requirements Different

A combustion powertrain has tight interfaces but relatively separable subsystems. The engine has its own control domain. The transmission has its own control domain. Thermal loads are real but manageable within each subsystem’s boundary, with the radiator as a shared but simple resource. Requirements can be decomposed to subsystem level and managed largely in parallel.

A battery electric powertrain does not decompose cleanly. The battery pack’s allowable power output is a function of cell temperature, state of charge, state of health, and coolant inlet temperature — simultaneously. The inverter’s switching behavior generates heat that flows into a shared coolant loop. The motor’s efficiency map changes with rotor temperature. The onboard charger, if active, is adding thermal load to the same cooling circuit while the pack is constrained to a narrow voltage and temperature window for safe charging. Every requirement that touches power, thermal, or safety is potentially a requirement that couples to every other system.

This tight coupling has three immediate consequences for systems engineering practice:

Interfaces must be specified, not assumed. In document-based requirements practice, interface requirements often live as footnotes or in separate interface control documents that drift from the functional requirements over development cycles. In an electric powertrain, the interface between the BMS and the thermal management controller is where most system-level safety behavior is implemented. If those interface requirements are ambiguous, the safety argument is ambiguous.

Requirements have more operational contexts. A diesel engine operates in a relatively narrow band of thermal and electrical conditions. A traction battery operates across charge, discharge, idle, regenerative braking, DC fast charge, AC charge, and various fault conditions — each with different constraints on voltage, current, temperature, and state of charge. A requirement that is correct in one context may be dangerous in another. Requirements must be context-aware and that context must be traceable.

Change propagation is asymmetric and fast. Changing a cell chemistry late in development doesn’t just affect the battery team. It changes the BMS charge algorithm, the thermal management setpoints, the safety limits, and potentially the charging interface compliance envelope. Teams that manage requirements in disconnected documents discover this at integration. Teams that manage requirements as a connected graph discover it when the cell chemistry change is proposed.

Battery Management System Requirements

The BMS is the most requirements-dense subsystem in an electric powertrain. It is simultaneously a safety system (preventing conditions that lead to thermal runaway), a performance system (maximizing usable energy within safe limits), and an interface system (communicating pack state to the vehicle controller, charger, and thermal manager).

BMS requirements span multiple abstraction levels simultaneously: cell-level electrochemical constraints, module-level balancing and monitoring requirements, pack-level protection requirements, and system-level communication and diagnostic requirements. A typical production BMS for a heavy truck application will have several hundred functional requirements, a similar number of safety requirements derived from FMEA and fault tree analysis, and dozens of interface requirements connecting to adjacent systems.

The practical problem is that most teams write these in layers that don’t connect. Cell-level constraints come from the cell supplier’s datasheets and get transcribed into a requirements document. Pack-level protection thresholds get defined by the battery systems team. Safety requirements get written by the functional safety team working from a FMEA that was done at a different point in the program. When cell constraints change — as they routinely do during chemistry optimization — the change doesn’t automatically propagate to protection thresholds or safety requirements. It propagates when someone manually notices the discrepancy, if they do.

The IEC 62133 standard (covering secondary lithium cells and batteries for portable applications, with the automotive-relevant IEC 62133-2 covering lithium systems) addresses cell and battery-level safety test requirements. It does not address BMS functional requirements directly. ISO 26262, the automotive functional safety standard, addresses the BMS as a safety element but requires that safety requirements be derived from a hazard analysis and risk assessment at the vehicle level. Neither standard tells teams how to manage the requirements that live between cell physics and vehicle-level safety — and that’s where most of the engineering complexity lives.

Thermal Management System Complexity

Thermal management is where electric powertrain integration debt becomes visible. The reason is that thermal behavior is emergent: it is a property of how all the thermal loads in the system interact over time, not a property of any individual component.

Battery pack thermal requirements specify acceptable cell temperature ranges for charge, discharge, and storage. Inverter thermal requirements specify maximum junction temperatures and minimum coolant flow rates. Motor requirements specify winding and magnet temperature limits. Cabin HVAC requirements specify heat pump performance that shares refrigerant with battery thermal conditioning on many platforms. These requirements are real and individually defensible. The problem is that they compete for a finite thermal budget — cooling capacity, coolant flow rate, compressor power — and that budget is itself a function of ambient conditions, vehicle speed, and drive cycle.

Requirements written at the subsystem level often implicitly assume thermal resources that don’t exist simultaneously. A battery thermal management requirement may specify a coolant temperature setpoint that conflicts with what the inverter’s cooling circuit needs during peak performance. These conflicts are not discoverable by reading individual requirements documents. They are only discoverable when the requirements are placed in the context of a system model or when physical integration reveals them in test.

Heavy trucking and off-highway applications compound this because thermal loads are sustained differently than in passenger vehicles. A Class 8 truck operating a 500 kWh pack on a mountain grade is asking the thermal management system to maintain cell temperatures in a narrow window under sustained discharge rates that a passenger vehicle would see only transiently. Off-highway equipment — mining vehicles, agricultural machines — adds vibration, dust, and wide ambient temperature ranges that make thermal assumptions from automotive development invalid.

The systems engineering response to this has to be requirements that are written at the right level of abstraction and connected to the system model that defines the thermal budget. A thermal management requirement that says “maintain cell temperature between 15°C and 35°C during discharge” is incomplete without a reference to the discharge rate profile, the ambient conditions envelope, and the coolant system capacity that makes it achievable. Without that context, the requirement is not verifiable in any meaningful operational sense.

Charging Interface Standards Compliance

Charging interface compliance adds a dimension of external requirements pressure that combustion powertrain development never faced. The traction battery connects, through a charging interface, to infrastructure governed by standards written by standards bodies that have no direct relationship to the vehicle OEM’s development process.

In North America, the transition from CCS1 to NACS (now SAE J3400) has forced engineering teams to manage requirements that reference external standards versions that themselves change. In Europe, CCS2 compliance requirements interact with the Megawatt Charging System (MCS) standard relevant to heavy trucking. ISO 15118, covering vehicle-to-grid communication, adds protocol compliance requirements that sit on top of the physical interface requirements. Each of these creates a class of requirements that the development team did not author and cannot change, but must trace into the vehicle’s own requirements structure.

The practical problem is traceability. If a charging interface standard is updated — as J3400 has been — the team needs to identify every internal requirement that was derived from or allocated to that standard. In a document-based system, this is a manual audit. In a connected requirements system, it is a query. The difference in effort and reliability is significant, particularly for off-highway and heavy trucking programs that are managing multiple charging interface standards simultaneously across different regional markets.

Adapting ISO 26262 and IEC 62133

ISO 26262 was written for automotive electrical and electronic systems. IEC 62133 was written for portable battery systems, then extended to lithium systems. Neither was written for a vehicle-scale traction battery system that is both an automotive E/E system and a multi-hundred-volt energy storage system. Applying both to a single development program requires deliberate decisions about scope, applicability, and requirements partitioning.

The most common approach is to treat ISO 26262 as the governing framework at the vehicle and system level — covering the BMS as a safety-related system, covering the charging interface as a safety-relevant function, covering the thermal management system’s safety functions — and to treat IEC 62133 as governing the cell and battery-pack-level performance and safety test requirements. The boundary between these frameworks needs to be explicitly defined in the safety plan, and the requirements that live at that boundary need to be explicitly allocated to one framework or traced to both.

What this means in practice is that teams need requirements structures capable of holding multiple compliance contexts simultaneously. A cell temperature limit requirement may need to satisfy IEC 62133 test criteria at the cell level and ISO 26262 safety requirements at the BMS level. If those requirements are managed in separate documents with separate owners, ensuring consistency across both compliance contexts is a manual process. If they are managed as connected artifacts in a shared model, consistency can be checked systematically.

This is where modern requirements tools are showing real differentiation from legacy systems. Platforms like Flow Engineering, built on a graph-based requirements model, allow teams to represent the IEC 62133 / ISO 26262 boundary as an explicit structural relationship rather than a document cross-reference. Requirements at the boundary carry their compliance context with them; changes to cell-level requirements surface their downstream effect on safety cases immediately rather than at the next manual audit. For teams managing both standards on the same program — which is now standard practice for any vehicle with a purpose-built traction pack — this architectural capability is not optional. It’s the mechanism by which the safety argument stays coherent across the development cycle.

What Adaptation Actually Looks Like

The teams getting this right share a few concrete practices that distinguish them from teams still fighting integration fires.

They define system boundaries before writing requirements. Before any subsystem requirements are written, the architecture model defines the major functional interfaces: BMS to vehicle controller, BMS to thermal management controller, charger to BMS, thermal management to HVAC. Requirements are then allocated to those interfaces explicitly, not implicitly assumed.

They write requirements with operational context. Rather than a single temperature limit requirement, they write requirement sets that specify limits per operating mode: charge, discharge, regen, idle, fault. This is more requirements to manage, but fewer integration conflicts to resolve.

They treat standards compliance as a requirements attribute, not a separate document. Each requirement that traces to ISO 26262, IEC 62133, SAE J3400, or ISO 15118 carries that traceability as a property, not as a footnote. When standards change, affected requirements are identifiable by query.

They run requirements reviews at the interface level. Rather than reviewing BMS requirements with the BMS team and thermal management requirements with the thermal team, they review interface requirements with both teams present. This is organizationally uncomfortable and technically necessary.

Honest Assessment

The electric powertrain development challenge is not primarily a technology problem. The cell chemistry, the power electronics, the motor designs — these are understood and improving systematically. The challenge is integration: managing the coupling between systems that each have legitimate and complex requirements of their own.

Systems engineering practice has the tools to address this. Model-based requirements management, explicit interface specifications, standards-aware traceability — these are not research concepts. They are implemented practice at the organizations shipping production electric powertrains on schedule. The gap between those organizations and the ones still fighting integration fires is largely a gap in requirements practice, not a gap in engineering knowledge.

The industry is not fully there. Document-based requirements management is still the majority practice at tier-two and tier-three suppliers, and those suppliers are building BMS components, thermal systems, and charging interfaces for vehicle programs that need them to be integrated partners, not document deliverers. Closing that gap is the near-term systems engineering challenge in electric powertrain development, and it will determine which programs ship on time and which ones learn their integration lessons in the field.