DY Research

Timing analysis with
the arithmetic shown.

Safety-critical systems are certified on numbers that nobody outside the vendor can reproduce. The tools that produce them are closed, licensed per seat, and disagree with each other in the last decimal. This is work on the part where the arithmetic decides the answer.

Start here dy-wcet Clone it, run cargo test, and read the twelve tests. The one that matters takes thirty seconds to check.
All repositoriesgithub.com/DYResearch AxonOSWhere these problems arrived first

The failure, in four lines

Two tasks. One number. Most implementations get it wrong.

task A  100 µs every  400 µs   ← higher priority
task B  200 µs every 1000 µs

What is B's worst-case response time?
400 µs
Counting preemptions across B's period: two activations of A fit inside 1000 µs, so 200 + 2×100.
300 µs
Counting across B's response window, which is what the recurrence actually says. At R = 200 one activation fits, giving 300; at R = 300 still one, so 300 is the fixed point.

Here the mistake is conservative and the system merely looks worse than it is. Change the periods and it inverts: the wrong method reports a deadline met that is missed on hardware. Both answers are plausible, neither is flagged, and a test written by the same person who wrote the bug passes.

That is the shape of every defect this work is about. Not crashes — numbers that are quietly wrong in the direction that flatters the result.

Why now

Brain–computer interfaces

Devices are moving from laboratories to people. A decoder that misses its window does not drop a frame — it moves a limb late, or does not move it. The field has excellent signal processing and almost no formal timing discipline, and regulators are beginning to ask for one.

Everything else that must not stop

DO-178C, IEC 61508 and ISO 26262 all require evidence that deadlines are met. The evidence is generated by proprietary tools, priced per seat, whose internals no auditor can inspect. The standard asks for proof and the industry supplies a receipt.

The reproducibility gap

A bound computed in floating point has last bits that depend on the compiler and the optimisation level. Two teams running the same analysis on the same task set get different numbers and cannot tell who is right. This is normal, and it should not be.

Nobody is fixing it openly

The analysis has been public since 1986. The implementations are not. There is no open tool an engineer can read end to end, run on their own set, and hand to a reviewer who can run it too.

Repositories

dy-wcetavailable

Worst-case response time for fixed-priority task sets. Integer arithmetic throughout, checked operations, and an explicit unschedulable result where an over-utilised set has no bound — rather than the last value before the loop gave up.

Twelve tests, including the 300-versus-400 case above. no_std, zero dependencies, unsafe forbidden.
dy-certifyin progress

A signed schedulability certificate: the task set, the derivation step by step, the tool version, and a hash. An auditor re-runs it and gets the same bytes, or the certificate is void.

The thing standards actually require and closed tools cannot provide — because reproducing their result means trusting their binary.
dy-blockingplanned

Priority-inheritance and priority-ceiling blocking terms, derived from a resource graph instead of estimated. Today the blocking term is an input to every analysis and usually a guess.

The weakest number in most timing arguments, and the one nobody checks.
dy-traceplanned

Turns an instrumented trace into execution-time inputs with their confidence stated — so an analysis says whether its inputs were measured or assumed.

A bound computed from a spreadsheet is arithmetic about a guess, and nothing currently forces that to be visible.

How this is built

  1. Integers where the result matters Same input, same bits, any machine, any compiler. Two implementations agree exactly or one of them is wrong — a property no floating-point tool can offer and no test can pin.
  2. Refusal over approximation When a computation has no answer it returns that, not the last value before the iteration was capped. An infinite response time fails every deadline comparison it is put into, which is the safe direction to be wrong in.
  3. Checked arithmetic as a rule Overflow is reported. A wrapping add in a schedulability test converts a real failure into an apparent success, and that is the one direction an arithmetic error must never go.
  4. Limits stated in the code, not the marketing None of this measures anything. It computes bounds from execution times somebody else established, and each crate says so in its own documentation rather than leaving a reader to discover it.
  5. No dependencies where none are needed A crate that computes a bound should not pull in a runtime to do it. no_std, verified against a bare-metal target in CI rather than asserted.

Engage

A schedulability audit, invoiced.

Send a task set. You get back the response time of every task with each iteration of the recurrence written out, the verdict per task, and the margin before the first deadline is missed — signed, with the tool version and a hash of the input.

What it costsQuoted per set, invoiced in EUR or USD. Bank transfer. No subscription and no seat licence.
What you sendC, T, D and blocking per task, in any legible format. Anonymised if you prefer — the analysis does not need to know what the tasks do.
What you do not pay forThe tool. It is open and free, and for debugging it is the right answer. What is paid for is someone naming the assumptions your set rests on and standing behind the result.
connect@axonos.org →

What it covers, what it does not, and a worked example →

If the analysis will not tell you anything useful, I will say so and there is nothing to pay for.