Services
Verify the design before you build it.
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, or one component under evaluation, 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, design specification formalisation is a preceding step, quoted separately.
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, or one component under evaluation. The verification scope is fixed by agreement before work starts
- Duration
- 4–8 weeks as a guide for the agreed scope. 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 specification formalisation
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.
Certification and regulatory documents
The safety standards already ask for this.
Formal methods are not a new vendor claim. The major safety standards already require or recommend them at their highest integrity levels.
We take the hazardous scenarios from your risk assessment, prove that within the modelled scope they are structurally unreachable, and prepare those proofs and their supporting evidence as material you can use as part of a certification submission. When certification is imminent, this document is often more urgent than the verification itself.
We prepare the submission material; we do not guarantee the certification outcome. Which standard and which requirement applies to your equipment depends on the safety integrity level and the application. That judgement is confirmed with the certification body, or with your own safety function.
| Standard | Domain | Position on formal methods |
|---|---|---|
| IEC 61508 | Functional safety (general) | Formal methods highly recommended at SIL 4 |
| EN 50128 | Railway | Strongly recommended at SIL 3 and 4 |
| ISO 26262 | Automotive | Recommended |
| DO-178C | Aerospace | A separate supplement, DO-333, covers formal methods |
Training and workshops
In the vocabulary of people who build machines.
Formal methods have not spread because of doubt about the technique. In a survey of 130 experts, 71.5% named a lack of engineer education as the leading adoption barrier. What is needed is explanation, not persuasion.
The curriculum's spine is the single rung from models to proof. There is no need to start from zero — we start from the model-based development your engineers already know and add one step: proving the model is right.
Formats
In-house workshops, technical seminars, and sitting in on design reviews. We can work from your own equipment, or start from a generic worked example.
Our articles cover the same material if you would like to read it before deciding.
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. 4–8 weeks as a guide, once scope is agreed.
- 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.