Skip to main content
Unit Testing for India's Two-Wheeler EV Industry: ISO 26262 ASIL for Motor Controller and Inverter Firmware, featured image

Unit Testing for India's Two-Wheeler EV Industry: ISO 26262 ASIL for Motor Controller and Inverter Firmware

GSAS Editorial · · 6 min read

Unit Testing for India’s Two-Wheeler EV Industry: ISO 26262 for Motor Controller Firmware

India’s two-wheeler electric vehicle market is entering a new phase. The initial wave of EVs prioritized time-to-market, get the product out, capture early adopters, iterate on hardware and software simultaneously. That approach worked for the first generation. But as the industry matures, as fleet operators demand reliability guarantees, and as export markets impose safety certification requirements, the engineering rigour behind the firmware must catch up.

Motor controller firmware, inverter control algorithms, and battery management logic are safety-critical software. A firmware defect in the field of weakened torque limiting, uncontrolled regenerative braking, or thermal runaway mismanagement can injure the rider. ISO 26262, the automotive functional safety standard, applies to two-wheelers, and its unit testing requirements are the same whether the vehicle has two wheels or four.

Where the Safety Risk Lives

In a two-wheeler EV powertrain, the safety-critical firmware components include:

Inverter control. The firmware that switches the IGBT/MOSFET bridge to drive the BLDC or PMSM motor. Timing errors can cause shoot-through (simultaneous high-side and low-side conduction), destroying the power stage and potentially causing a fire. Dead-time management, overcurrent detection, and fault reaction logic are ASIL B or higher.

Motor control algorithms. Field-oriented control (FOC) and direct torque control (DTC) algorithms compute PWM duty cycles based on motor position, speed, and torque demand. Errors in the coordinate transformation (Clarke/Park) or PI controller tuning can produce unintended acceleration or loss of torque. For throttle-by-wire systems, this is ASIL C or D.

Battery management. Cell voltage monitoring, state-of-charge estimation, thermal management, and charge/discharge current limiting. Firmware errors can lead to overcharging, deep discharge, or operation outside the safe operating area, all of which pose fire or thermal runaway risk.

Regenerative braking. The algorithm that converts kinetic energy back to battery charge during deceleration. Incorrect regen torque calculation at high speed or on low-traction surfaces can cause rear-wheel lock-up.

Why Indian 2W EV Teams Need ISO 26262

Three forces are driving ISO 26262 adoption in India’s two-wheeler EV segment:

Export market access. European and Japanese markets require functional safety evidence for type approval. Indian OEMs targeting global markets need ISO 26262 compliance, not as a nice-to-have, but as a regulatory prerequisite.

Fleet operator requirements. Large fleet operators (delivery logistics, ride-sharing) are beginning to include safety certification in their procurement criteria. A fleet of thousands of vehicles amplifies the probability of encountering firmware defects.

Regulatory trajectory. India’s automotive safety regulation framework (AIS standards) is progressively aligning with international standards. While ISO 26262 compliance is not yet mandated for two-wheelers in India, the trajectory points toward mandatory functional safety requirements.

What ISO 26262 Requires for Unit Testing

ISO 26262 Part 6 names three structural coverage metrics for unit testing, statement coverage, branch coverage and MC/DC, and grades its recommendation for each across the four ASILs. Three points about that gradient matter to a two-wheeler programme. Branch coverage is already recommended at ASIL A, so it is not something that starts at ASIL B. Statement coverage is relaxed at the higher ASILs rather than dropped, because 100% branch coverage implies 100% statement coverage, so a team reporting branch coverage has already reported statement coverage. And MC/DC carries the standard’s strongest recommendation only at ASIL D.

Note also that ISO 26262 has no “mandatory” rating: the strongest it applies to any method is highly recommended, and because these metrics are alternative entries the obligation is to apply an appropriate combination and give a rationale for the combination selected. For motor controller and inverter firmware rated ASIL C or D, MC/DC is the metric to plan for, along with that rationale. It means every atomic condition in every compound boolean expression must be demonstrated to independently affect the decision outcome.

The standard separately recommends systematic test case derivation, analysis of requirements, equivalence classes, boundary values and error guessing, with equivalence classes and boundary values reaching their strongest recommendation from ASIL B upward. Ad hoc testing is not one of the listed routes.

One part-selection trap specific to this segment: for motorcycle items, ISO 26262 Part 12 supersedes the corresponding Part 6 requirements. A two-wheeler programme that plans straight off Part 6 is planning against the wrong part.

GSAS does not reproduce the standard’s clause numbers, table numbers, row letters or rating grids. Read them from your licensed copy; the ISO 26262 page sets out the obligations in substance.

How TESSY Addresses 2W EV Testing

Razorcat TESSY provides the unit testing infrastructure that two-wheeler EV teams need:

MC/DC coverage measurement. TESSY measures MC/DC and MCC coverage on the compiled firmware, using the project’s actual cross-compiler (Arm Compiler 6 for Cortex-M, TASKING for AURIX). Coverage results reflect the production binary, not a host simulation.

Classification Tree Editor. The CTE enables systematic test design for complex motor control algorithms. Engineers define equivalence classes for motor speed, torque demand, temperature, and battery state-of-charge, then generate test vectors that systematically exercise boundary conditions and error scenarios.

On-target execution. Through SEGGER J-Link, TESSY executes tests on the actual microcontroller, STM32 Cortex-M, TI C2000, or Infineon AURIX, and collects coverage data from real hardware. Safety assessors accept this as evidence of target-based verification.

ReqIF traceability. TESSY links test cases to safety requirements via ReqIF import/export, providing the bidirectional traceability that ISO 26262 Part 6 mandates for ASIL C and D.

CI/CD integration. Automated regression testing in Jenkins or GitLab ensures that firmware changes do not break existing test coverage, critical for fast-moving 2W EV development cycles.

The Pune and Chennai Context

India’s two-wheeler EV development is concentrated in two cities:

Pune is the traditional hub for two-wheeler engineering. Established OEMs and new EV startups alike maintain R&D centres here, with proximity to automotive component suppliers and test tracks. Motor controller firmware development for two-wheeler EVs is a growing discipline in Pune’s embedded engineering community.

Chennai hosts significant two-wheeler manufacturing and R&D capacity. The city’s automotive ecosystem includes both OEM engineering centres and Tier-1 suppliers developing powertrain electronics for the EV transition. Chennai’s embedded teams are increasingly working on safety-critical firmware for inverter and BMS applications.

Both cities need access to safety-qualified unit testing tools with local technical support, tools that understand embedded cross-compilers, work on real target hardware, and produce the certification evidence that ISO 26262 assessors require.

Why Buy from GSAS

GSAS Micro Systems is the authorized Razorcat partner, providing TESSY licensing for two-wheeler EV and automotive projects with INR invoicing, onboarding training, and ISO 26262 tool qualification consulting. Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR help motor controller and BMS firmware teams deploy TESSY with the correct compiler integration, target hardware support, and CI/CD pipeline configuration. Whether your team is a two-wheeler OEM starting its ISO 26262 journey or a Tier-1 supplier deepening its safety verification capability, GSAS provides the tooling and local expertise to get your unit testing to certification standard.

Request a TESSY evaluation for EV firmware →

Interested in Razorcat tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Side by side comparison of a 10BASE-T1S multidrop mixing segment, one balanced pair with four nodes on short stubs and a termination at each end, against a point to point star of four separate links into switch ports, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

10BASE-T1S and PLCA: Multidrop Ethernet Explained

10BASE-T1S is the one member of the T1 single-pair Ethernet family that keeps a shared medium, and PLCA is the reconciliation sublayer that stops the nodes on it from colliding. This article covers what IEEE 802.3cg standardises, how the beacon and transmit opportunities schedule a cycle, the node count and segment length figures the OPEN Alliance interoperability test suite works to, and the failure modes that put a segment quietly back into contention while every link still looks up. Written by the GSAS Micro Systems engineering team in India for teams bringing up multidrop segments on the bench.

29 Aug 2026 · 12 min read
Side by side vehicle outlines comparing a domain E/E architecture grouped by function against a zonal E/E architecture grouped by physical location, with zone controllers on an Ethernet backbone into central compute, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Domain vs Zonal E/E Architectures Explained

Domain architectures group ECUs by function, zonal architectures group them by where they sit in the vehicle. This guide is the engineer's read on the difference: what physically moves, what the in-vehicle network has to become, and what happens to diagnostics, rest bus simulation and time sync. It also refuses to repeat the harness mass and ECU-count figures that circulate without a public source, and says exactly which claims are citable and which are not. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 13 min read
Diagram of where drift enters a vehicle network toolchain, showing a bench edit applied directly to the switch with no upstream path back to the description, leaving a stale description, a mismatch between artefacts and a failed integration, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Network Configuration as Code for Vehicle Networks

A vehicle network programme can end up holding the same network in five incompatible places: an AUTOSAR ARXML description, a FIBEX export, a switch configuration typed at a bench, a simulation project and a folder of test scripts. Nothing enforces agreement between them, so the bench quietly becomes the source of truth and integration week finds out. This article covers the format landscape as the standards bodies describe it, what a generated pipeline produces downstream, the validation gates worth adding, and an honest account of what configuration as code does not fix. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 13 min read