Services
Verify the design before it reaches the floor.
What we deliver are the specific defects and counterexamples that come out of your design — not an explanation of a concept. Start small, with one design.
Design verification diagnosis
This is the way in.
One system under development, one component under evaluation, or a change to a machine already running, verified at the design stage. No hardware is required.
Verification does need the design to be readable — the operating conditions, the states and the interlocks traceable from the documents. Where they are not, making the design verifiable is a preceding step, quoted separately.
The same holds for a modification. What we read is the drawings and the design documents; we do not recover a model from existing control source code. If code is all that is left, the conversation starts with getting the design back onto paper.
Verification of equipment software has always had to wait for integration and site commissioning. The diagnosis pulls that wait forward to design time — to the point where an error is cheapest to fix.
- Target
- One system under development, one component under evaluation, or a change to a machine already running. The verification scope is fixed by agreement before work starts
- Duration
- Agreed with you before we start, once the scope is set. A larger scope is proposed as split engagements
- Terms
- Under NDA. Your design documents remain confidential
- Fee
- Quoted per engagement, based on scope
Deliverables
-
Design defect report
Where the problem is and what it is — in a form you can take straight into your next design review.
-
Counterexample scenarios
The exact event sequence that reproduces each problem. Not "something is wrong" — a reproduction procedure.
-
Safety property proofs
Proof that, within the modelled scope, a hazardous scenario is structurally unreachable. Handed over with the assumptions and the verification scope stated explicitly. That is a different quality of evidence from "we tested and it did not occur".
If the verification does not reach a conclusion within the agreed scope, we report how far we got and why.
What the diagnosis reports
Results come back in concrete form rather than as reassurance — the scope verified, the safety properties confirmed, and the design defects found together with the steps that reproduce them.
The number of defects is not something we promise. Finding none is also a result — it means your design was sound within the stated scope.
Design documents made verifiable
We take on the step before verification.
Verification needs a design expressed in a form that can be verified. Real design documents are written in natural language, and much of the intent lives in a senior engineer's head. That translation cost is the actual barrier to adopting formal methods.
We do that work. Moving natural-language design documents into a verifiable specification is offered as a service in its own right.
A second effect
A formalised design specification is both an input to verification and an organisational asset. When design know-how becomes verifiable, the expertise stays with the organisation rather than the individual. Tacit knowledge that would otherwise leave with a transfer or a retirement stays in readable form.
Assumptions and scope
What we cannot do, written down first.
The worth of a verification lies in being able to state precisely what was checked. Distrust any company that tells you "this will be safe" without bounding the scope — including us.
There are three boundaries. All of them are confirmed in writing before work starts.
- 01
What is verified is the design
Whether the implementation follows that design, whether the wiring is right, whether the motor on the built machine stops within the commanded time — verification says nothing about any of it. Testing does not shrink. What shrinks is one family of bugs: the ones you meant to catch in test and did not.
- 02
The proof answers only the question we agreed
If we check that two axes never enter the shared zone at the same time, then that is what was checked. Nothing about a third axis, nothing about recovery from an emergency stop. What gets verified is agreed in writing before work starts.
- 03
It has to fit in a state space that can be checked
State combinations grow sharply with the size of the target. A model is therefore an abstraction, and judgement about what to discard is involved. That judgement — and the scope that fell outside verification because of it — is included in the report.
What follows
Try it small; continue if it fits
- 1
Diagnosis
One system, or one component. Scope is fixed before we start.
- 2
Pilot
Built into your development process on the next project.
- 3
Ongoing verification
Continuous, as part of design review.
There is no need to start large. One diagnosis tells you what comes out of your design.
Start by choosing one target.
If you are not sure which machine or which part it should be, start there — that is a normal place to begin.