Embedded Systems & Product Development Consultancy · London, UK

Functional safety and ATEX

Safety has to be designed in, not tested in at the end. We develop safety-critical firmware to IEC 61508, with the analysis, coding rules and verification it needs, and design electronics for hazardous areas under IEC 60079-11.

Talk to an engineer Testing & verification

Safety requirements discovered too late

Most safety projects slip for the same reason: the standard was read properly only after the design was done.

Safety requirements written after the architecture, so the design can’t meet them without rework.
Code that works but can’t show traceability from requirement to test.
Coding rules and static analysis applied at the end, producing thousands of findings at once.
Hazardous-area limits on energy and temperature that force a board redesign late on.
Component changes that quietly break an intrinsic safety assessment.
No clear evidence trail when the certification body asks for it.

We plan the safety work with the design, so the evidence builds up as the product does.

Where we help on safety projects

Safety-critical firmware. Firmware developed to IEC 61508 processes, with a defined architecture, coding rules and defensive design.
Verification and unit testing. Static analysis, code review and unit testing with the LDRA tool suite, with coverage measured and reported. →
Traceability. Requirements linked to design, code and tests, so every safety function can be followed end to end.
Diagnostics and safe states. Watchdogs, memory and clock checks, plausibility tests and defined safe states when something fails.
Intrinsically safe hardware. Electronics for hazardous areas designed to IEC 60079-11, with energy limits, segregation and component ratings considered from the first schematic. →
Certification support. Documentation and test evidence prepared for notified bodies, test houses and CE marking.

Building the safety case as you go

Agree the target. Safety functions, the required integrity level or equipment protection level, and the standards that apply.
Design for it. Architecture, diagnostics and hardware choices made against the target and reviewed before coding starts.
Code to rules. A coding standard, static analysis and reviews from the first commit, not the last.
Verify and trace. Unit and integration tests with coverage, linked back to every requirement.
Prepare the evidence. Documents and records organised for the assessor, ready when they ask.

Standards, tools and evidence

Standards: IEC 61508, IEC 60079-0 and IEC 60079-11 for ATEX and IECEx, CE marking, IEC 62304 and IEC 60601-1 for medical devices

Verification tools: LDRA tool suite, static analysis, unit test frameworks, code coverage

Coding standards: MISRA C, project coding rules, peer review

Process: requirements traceability, version control, change control, Git and JIRA

Safety work on real products

Client names stay private. The engineering doesn’t.

Detection algorithms and safety-critical firmware for a device built at over a million units

View case studies

An air-quality monitor for power stations, including early design work on an intrinsically safe board

View case studies

Talk it through

Safety projects are rarely the same twice. Tell us the standard and the integrity level, and we’ll tell you honestly where we can help.

Ask about this work

Frequently asked safety and ATEX questions

What IEC 61508 experience do you have?

We have developed safety-critical firmware for a mass-market product to IEC 61508, using the LDRA tool suite for static analysis, code review and unit testing, backed by formal LDRA training.

Do you have ATEX experience?

Yes. Our ATEX experience comes from leading the hardware design of an intrinsically safe board iteration (Ex ib IIA T4) to IEC 60079-11 through its early design stages, on an industrial monitoring product.

Can you certify our product?

No consultant can: certification comes from a notified body or test house. We design for the standard, prepare the evidence and support you through the assessment.

Can you bring existing firmware up to a safety standard?

Sometimes. We assess the code against the standard and the coding rules, then tell you honestly whether to remediate it or rewrite the safety-relevant parts.

Do you follow MISRA C?

Yes, where the project requires it, checked with static analysis tools. On other projects we still apply a defined coding standard and review every change.

Do you work on medical device safety too?

Yes. Medical device software follows IEC 62304 and electrical safety follows IEC 60601-1. We design with these in mind and work alongside your quality and regulatory team.

Working on a product that has to be safe?

Tell us the standard, the integrity level or zone, and where the project is today.

An engineer will read it and reply within one business day.

Talk to an engineer