A research team at National Yang Ming Chiao Tung University proposes cross checking two timing methods for the in vehicle network that carries safety critical messages between sensors, brakes, and driver assistance software.
A car navigating a highway merge at speed needs an answer from its sensor network within a fraction of a second. That answer travels over a bus called CAN, the Controller Area Network, a 40-year-old wiring standard originally designed for simple sensor and actuator communication. As modern vehicles pile on driver-assistance and autonomy software, the same bus now carries safety-critical messages between brakes, radar, and the chips running perception and decision logic. The question of whether every message actually arrives on time has become a load-bearing constraint on what software can be added to a car.
Engineers have spent decades answering that question with a mix of math and measurement. On the analytical side, schedulability analysis and worst-case response time (WCRT) calculations give conservative upper bounds on message latency. On the empirical side, simulation tools and bus traces show what real traffic looks like. Each view is useful, and each view has a blind spot. WCRT bounds are safe but can be pessimistic enough to reject designs that would actually work. Simulations and traces show realistic behavior but miss rare worst-case combinations. The result is a long-running tension in automotive timing engineering: two methods that should agree often give different answers, and program leads must pick which to trust.
A research group at National Yang Ming Chiao Tung University (NYCU) and Chung Yuan Christian University is proposing a discipline to make them agree, by cross-validating worst-case response-time analysis with a stochastic simulation method called Deterministic and Stochastic Petri Nets (DSPN) for the same CAN bus under the same traffic assumptions. The idea, summarized in Semiconductor Engineering's coverage of the paper, is straightforward: run both methods on the same workload, and treat the agreement or disagreement between them as evidence about whether the design is really safe. Where WCRT is too pessimistic, the simulation can show realistic slack. Where simulation underestimates rare bursts, the analytical bound catches the gap. Neither method is new. The contribution is treating cross-checking as a verification step rather than a research afterthought.
That distinction matters because the stakes are no longer academic. Software-defined vehicles push more functions onto shared in-vehicle networks, and ADAS and autonomy stacks add message classes with hard deadlines for braking, steering, and sensor fusion. In the world of functional-safety engineering, timing budgets are assumed to be met — and that assumption only holds if the timing analysis is sound. A methodology that forces two independent timing views to line up, before a design is committed to silicon and production software, is a way to make that auditable rather than hopeful.
The honest framing is incremental. This is a cross-check, not a new protocol, not a new safety standard, and not a replacement for either WCRT or measurement-based timing analysis. The work stands on its methodological merit: a way to reduce the gap between conservative math and observed behavior on a bus that has to keep working as cars become more software-driven. For timing engineers and program leads, the question is not whether the math gets prettier. The question is whether two independent timing views can be made to agree often enough to trust the result, on a network that increasingly cannot afford to be wrong.