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 forty-nine 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.
See More

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.

Forty-nine tests and five Kani proofs, 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.

What has been checked, and by whom

Case study Embassy #6528 — RP2350 lost alarm An intermittent embassy-time failure traced through hardware alarm arming, timer-queue liveness, and a response time with no upper bound. Published entire, with the evidence and the hypotheses kept apart and labelled. Read the analysis → Cross-check Two implementations, one answer The AxonOS kernel carries its own response-time analysis, written months earlier for a different reason. On a shared set they agree — and the first attempt at that comparison was too easy to be worth anything, which the write-up says before it says anything else. See the derivation →

Engage

One problem, traced end to end, in writing.

Send a task set, or send the failure you cannot pin down. What comes back is 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 — with the tool version and a hash of the input, so the result can be reproduced without me.

When it will not wait An intermittent failure that survives every fix.

A timer that stops for minutes. A deadline miss that will not reproduce under a debugger. A race nobody can corner because it only shows on the bench at four in the morning.

$4,800 · a written report within 48 hours of me accepting
What that buysTwo days of my attention ahead of everything else, and the report at the end of them — whatever it finds, including the parts that stay hypothesis.
What it does not buyA promise that the cause will be found. Nobody can promise that about a bug they have not seen, and a vendor who does has not met a hard one. What you get instead is a gate before the money: send the description, and if I do not think forty-eight hours will get anywhere, I say so and there is nothing to pay.
Schedulability audit $2,400 One task set, or one reproducible timing problem, traced end to end.
  • Written report within five working days
  • Every iteration shown, not just the answer
  • The assumptions your set rests on, named
  • Fixed price, fixed scope, quoted before anything starts
Asynchronous · EUR or USD
System review from $8,000 Several sets, a scheduler design, or hardware-in-the-loop verification against a bench.
  • Scoped in a short exchange that costs nothing
  • Priced before it starts, not after
  • If the answer is that you do not need this, that is the answer you get
Quoted after scoping
Qualification support Quoted Engineering time spent on your tool-confidence argument under IEC 62304 or ISO 26262.
  • Assembling the evidence your safety case needs
  • Stated precisely: this is work on your documentation
  • It is not a claim that the tool is qualified — nothing here is
Hourly or fixed, your choice
Three things that are not for sale here

A licence to the tool. dy-wcet is Apache-2.0 OR MIT and that licence is irrevocable. Nobody can sell you one, including me. For debugging it is free and it is the right answer.

Tool qualification data. It does not exist. When it does it will be published with the evidence behind it, and until then selling it would be selling a document I have not written.

A warranty on the result. A one-person practice with no professional indemnity should not offer one, and you should not accept one from anybody who would. What is paid for is the analysis, the assumptions named, and the arithmetic shown so you can check it yourself.

Start a priority review $4,800 · 48h Send a task set $2,400 · 5 days

The full scope, what it excludes, and a complete worked example →

If the analysis will not tell you anything useful, I will say so before you pay for it.

How it works

You describe itThe task set, or the failure you cannot pin down. Anonymised if you prefer — the analysis does not need to know what the tasks do.
I scope it, freeA short exchange, and a fixed price before anything starts. If the analysis will not tell you anything useful, that is what I say, and there is nothing to pay for.
You get it in writingEvery iteration shown, the assumptions named, and next steps that each say what would confirm them and what would kill them.

What arrives

A markdown report, in the shape of the Embassy analysis above. That case study is the standard of delivery rather than a sample of it.

The failure chainTraced end to end through your source, not summarised from the outside.
Evidence, and hypothesis, kept apartMarked as such and never blended. Where the evidence stops, the report says so.
Next steps that name their own testEach one saying what would confirm it and what would kill it.
A proposed fixWhere the evidence carries that far, and an explicit note where it does not.

Who

Denis Yermakou

Timing analysis for systems where the worst case is the only case that matters. Author of dy-wcet, a response-time analysis in integer arithmetic whose every expected test value is derived by hand, and of AxonOS, an open hard-real-time layer for brain–computer interfaces.

GitHub LinkedIn Email