Engineer reviewing a build pipeline and test results

Sectors · Development partners and contract manufacturers

Contract manufacturers that deliver the whole device, software included.

Clients ask for the whole device, from mechanics and electronics to production and software, and the software file has to pass the client's audit as well as yours. We write the firmware, the application software, the verification and the IEC 62304 documentation, as your named subcontractor or white label under your name and inside your quality management system, for the EU MDR and the FDA. Where a project also needs electronics or mechanical design, we bring in hardware and mechanical engineering partners we have worked with for years.

Book a 30 minute call Write to us

Delivery: Subcontract or white label
Standards: IEC 62304 · ISO 13485 · ISO 14971 · IEC 62366-1
First step: Free 30 minute call with engineering

The software path

A device project from the bid to the design transfer.

Bid

A client asks for the whole device. Mechanics, electronics and production are in house, but nobody on your staff writes the software.

ImprovementWe write the software part, so you can bid for the whole device.

Plan and safety class

The safety class is set before the device risk analysis exists.

ImprovementWe write the plan with your hardware and risk team, so the safety class follows from the device risks.

Requirements and interface

The prototype firmware was written by one engineer who has left, and it has no requirements and no architecture document.

ImprovementA gap analysis, and a refactoring where needed, turn the prototype into code that can be tested.

Build

Firmware, application and backend are built by different people, without one SOUP list (software of unknown provenance, meaning third party code used in the device).

ImprovementAll three are built under one lifecycle, and the SOUP list is written in the first weeks.

Verification

Tests wait for the next prototype batch, and firmware that passed its tests starts to fail on a new board revision.

ImprovementTests run against a simulation layer, and hardware in the loop tests run on the boards you supply.

Security file

Cybersecurity is looked at only before submission, when a weakness in the hardware design can no longer be fixed.

ImprovementSecurity risks are analysed with the first architecture, while hardware and software can still be changed to close them.

Design transfer

Your client's notified body (the independent organisation that certifies a device under the EU MDR) reads the software file as if the client had written it, and the gaps fall back on you.

ImprovementThe file is written for your client's quality system from the start, so it is ready for the handover.

The goal

A complete device, and a software file that passes two audits.

For your company

A bid for the whole device, software included
Software capacity that grows and shrinks with the work packages
A file that passes your client's audit as well as yours

For the device

Firmware tested on your boards and in simulation
A SOUP list with version, known anomalies and the reason each item is acceptable
Cybersecurity documentation before the board is frozen

For patients

A complete device that reaches the market on time, with its software verified
Fixes that reach their device quickly
A device the manufacturer can still maintain years after the handover

Problems and solutions

What we hear, and what we do about it.

Our clients ask for the whole device, and software is the part we do not staff.

We write the firmware, the application software, the verification and the IEC 62304 file. We work as your named subcontractor, or white label under your name.

How we work

The software file has to pass our client's audit as well as ours.

The documents follow your templates, numbering and change control, and they are written for your client's quality system from the start. Your purchasing process evaluates Silurus Software as a supplier under ISO 13485 clause 7.4. A quality agreement sets out who owns the design inputs, the change control and the release.

QA, compliance and regulatory

We cannot keep a firmware team busy between projects.

We provide a team sized to the work package, or engineers who join your project team for a design phase or for verification. The first engineers start within two to three weeks of signature.

Team extension

The prototype firmware has no requirements, tests or architecture document.

We start with an IEC 62304 gap analysis (a review of what is missing against the standard) of the code, the documents and the process. Where the structure does not allow testing, we refactor the code first and then write the file. The firmware is restructured and documented before it enters design controls.

Legacy modernisation and takeover

Firmware tests wait for the next prototype batch.

We build a simulation layer, so most tests run without hardware. Hardware in the loop tests then run on the boards you supply, including each new board revision.

Embedded and firmware development

Our name is on the deliverable, and we are afraid of losing control of it.

Our engineers work in your repositories and tools and answer to your project lead. Reviews and releases follow your procedures, and the design history file stays in your system.

How we work

Cybersecurity questions arrive after the hardware is frozen.

We write the threat model (a structured analysis of how the device could be attacked) and the SBOM (software bill of materials, the list of every software component in the build) with the first architecture. The vulnerability process covers IEC 81001-5-1 and FDA section 524B.

Medical device cybersecurity

Work products

What goes into your design file, and the standards behind it.

Work product	Standards	What the client receives
Software development plan and safety class	IEC 62304 · ISO 14971	Written with your hardware and risk team, so the class follows from the device risk analysis.
Hardware and software interface	IEC 60601-1 clause 14, programmable electrical medical systems	An interface specification against your schematics, a simulation layer, and hardware in the loop tests on the boards you supply.
SOUP list	IEC 62304	RTOS, vendor SDK, runtime and third party libraries, each with version, requirements, known anomalies and the reason it is acceptable, written in the first weeks. The compiler and the build tools are recorded and qualified as development tools.
Cybersecurity file	IEC 81001-5-1 · MDCG 2019-16 · FDA 524B for cyber devices	Threat model, SBOM and vulnerability handling.
Supplier controls	ISO 13485 clause 7.4	What your supplier evaluation asks for, and a quality agreement on design inputs, change control, problem resolution and the release decision.
Design transfer package	ISO 13485 clause 7.3.8 · IEC 62304	Development plan, requirements, architecture, verification records, traceability matrix, release notes and a build environment that reproduces the released binary.

Fit

When we are the right partner.

Call us when

You want to bid for the whole device, software included
You want prototype firmware turned into a product under design controls
You want a software file prepared for your client's audit, the notified body review and the FDA submission
You want more firmware or test engineers for a design phase or for verification

Talk to us

Tell us what you are working on.

A device bid, prototype firmware or a verification phase. Write a few lines, or book a free 30 minute call with our engineers.

Book a 30 minute technical call

FAQ

Frequently asked questions.

Can you work white label under our company name?

Yes. In a white label project the documents, repositories and release notes carry your name, and your client sees one supplier. As a named subcontractor, Silurus Software appears as the software supplier in your documents, and our engineers join technical meetings with your client when you ask for it.

Do you work inside our ISO 13485 quality management system?

Yes. Our engineers follow your procedures, templates and design controls. Your purchasing process evaluates Silurus Software as a supplier under ISO 13485 clause 7.4, and a quality agreement sets out who owns the design inputs, the change control and the release.

Our prototype firmware has no documentation. Can it become a product?

Yes. We start with an IEC 62304 gap analysis of the code, the documents and the process, and the report becomes the plan for the remediation. Where the structure does not allow testing, we refactor the code first and then write the file.

Which microcontrollers and operating systems do you work with?

Whatever your device uses: microcontrollers and application processors, with an RTOS, embedded Linux or bare metal, and every common wired and wireless interface. Desktop and mobile applications and the cloud backend are built under the same lifecycle.

How many engineers can you add, and how fast?

From one engineer to a full team. Some projects need a single specialist, others a full team inside the client's organisation. The first engineers start within two to three weeks of signature.

What does a first project cost?

The 30 minute call is free. Each step after it is quoted individually, with scope, deliverable, duration and price agreed in writing. We reply within one business day.

Related services and sectors.

Embedded and firmware development IEC 62304 gap analysis Verification and validation Medical device cybersecurity Dedicated engineering teams How we work