The problem Side by side Regulatory The library Delivery Beyond FAQs

A plug-and-play library for medical software

medular is a reusable embedded software foundation for regulated medical devices. It provides the architecture, the infrastructure services and the verification and documentation record, so the team's work goes into what makes your device yours.

Talk to an expert Delivery options

Weeks, not months

Start with the foundation already built, and put the team on what really matters.

Any chip, any silicon

Hardware agnostic by design, so a shortage or an end-of-life notice never becomes a redesign.

Audit-ready

Developed from the ground up to IEC 62304 Class C, with a record of everything. No SOUP justification.

THE PROBLEM

Most of your budget and time goes where the value isn't.

In embedded development, only a fraction of the effort goes into what makes the product yours. The rest disappears into building the low-level foundation, debugging it, and writing the documentation the auditor will ask for.

Slow bring-up

Before a device can do the one thing it exists for, someone has to bring the hardware to life. Getting a display to show an image or a sensor to return a reading you can trust takes a good engineer weeks, sometimes months. It is work no user will ever see, no investor will pay a premium for, and nobody outside the team can read as progress.

Supply lock-in

Code written directly against a chip only works with that chip. When a part is discontinued, allocated or simply unavailable, the hardware change is small and the software change is not: it must be rewritten, tested and documented again, for a device that already worked.

Failing to reach market

Time lost at software is never recovered. A week added before a working prototype pushes verification and submission back and every delay raises the risk of never reaching the market.

Device uncertainty

A team that cannot explain why something failed is the clearest early warning of cost and delay you will get. With no way to ask the device or see what's happening inside, every question means another build, another assembly and disassembly, another day, and an answer that is still a guess.

Hardware-bound testing

Software written directly against hardware cannot be proven without it. The team waits for the first boards, no work happens in parallel, and the earliest defects surface on the prototype, months after they could have been found and at many times the cost.

Late documentation

Requirements, design records and test evidence get written after the code, close to submission, for software nobody documented while building it. It is one of the most common sources of audit findings.

SIDE BY SIDE

The same project, with and without medular

Plug in medular so your team focuses on the clinical function nobody else can write for you.

Without medular

With medular

Where the team starts

From manufacturer examples, written to show a chip working, never meant to ship.

From components already running in medical devices.

What a part gives you

Read and write. Health checks, start-up and shutdown, failure reporting: work nobody scheduled.

All of it, around every part, from the first day.

Changing chip supplier

A documentation and code rewrite.

A configuration change.

Testing

Waits for the first boards. Nothing runs in parallel.

Runs from the first week, with no hardware attached.

When something fails

Add a print line, rebuild, take the device apart, try again.

Ask the device. What failed, when, and why.

Documentation

No compliance.

Compliant, with full provenance.

REGULATORY

100% traceable, by design.

medular is developed within the ISO 13485 quality system, under a software lifecycle that follows IEC 62304 and targets Class C from the first line. Requirements, architecture, detailed design, verification and release records exist for every component and are versioned with the code they describe.

100% traceable, by design.

SRS / SDS per module, versioned with the code

Traceability matrix, requirement to design to test

V&V reports archived for every release

Software FMEA, failure characterisation per component

Safety manual and anomaly list, per component

Software architecture, interfaces, ports and dependencies described per module

Unit test suite and coverage reports, run on the host at every release

Configuration and release records, versions, build hashes and change history

medular is a software component, not a medical device, and carries no CE mark of its own. We deliver the foundation, you build on top of it: the component record comes complete, and the device-level claims, hazard analysis and clinical evidence stay where they belong, with you.

THE LIBRARY

Everything your device needs, already built.

medular sits between your hardware and the part your team writes. It runs the sensors, screens and chips your device already contains, tells you what the device is doing while it runs, and handles what happens when something fails. All of it built to IEC 62304, with the documentation already written. The full catalogue is there. Your device carries only what it uses.

A growing catalogue of supported hardware

Displays, touch panels, sensors, chargers, battery gauges, memory, network and signal conversion chips, from many different manufacturers. Your hardware team picks parts on cost and availability, and the software to make them work is already written and verified. New parts added with every release.

Manufacturer independent by design

Your software never talks to any one manufacturer’s code. medular sits in between, and we maintain that connection for each processor family, so your software stays as it is. A shortage, a price rise or an end-of-life notice becomes a business decision instead of a rewrite.

Structure for the code your team writes

Your software never talks to any one manufacturer’s code. medular sits in between, and we maintain that connection for each processor family, so your software stays as it is. A shortage, a price rise or an end-of-life notice becomes a business decision instead of a rewrite.

Ask the device what is happening

Your team connects to the software while the device is running and asks it directly: what it is doing right now, how much memory it has left, how is the overall status. No rebuilding, no taking the device apart, no guessing. In development it replaces the trial and error entirely, and it is still there in the field when someone has to service a device that is already with a customer.

Error management, at every moment

Every part of medular reports its own faults, so your team never writes that code. What failed, where and when is recorded automatically, searchable by part, severity or time. The same record comes back from a prototype and from a device in the field, in a form your own systems can read.

IEC 62304 development and full documentation available

Requirements, design records and test evidence were written while the code was written, not reconstructed before a submission. Every part arrives with its own record, developed under a lifecycle that meets IEC 62304 in full. It enters your file as developed software, not as SOUP you have to justify. The work is carried out under an ISO 13485 quality system, so the way it was produced holds up in your audit as well.

DELIVERY

Delivery options and subscriptions

The engineering core is the same in every option. What changes is how much of it you receive, and what your regulatory submission can claim about it.

Source code

The components you select, delivered as source for the processors your device uses.

For non-regulated products , and for teams whose own quality system will carry the regulatory record.

Source code + documentation

Adds the full Class C package: SRS, SDS, traceability matrix, V&V reports, software FMEA, safety manual with anomaly list, and an SBOM per release.

Enters as developed software, with the record behind it.

Custom

We adapt medular to what your device needs: drivers for the components on your board and

Engineering by Perdigó Medical, scoped per

Subscriptions

Maintenance and compliance

medular keeps growing: improvements, new versions, bug fixes, and new components in development, with support for new chips as they arrive. The documentation package moves with it, revised for each release and for changes in the applicable standards, including per-release V&V reports, SBOM and anomaly list.

Support

Adds engineering support with agreed response times, and assistance during integration and board bring-up.

Licences are scoped by field of use. A licence sold for non-regulated products cannot be used in a regulated device without an upgrade. Clients developing a device with Perdigó Medical receive the documentation package as part of the engagement.

Start a conversation

Pricing on request

BEYOND THE SOFTWARE

medular covers the software. Perdigó covers the device.

medular removes the embedded software layer that every device needs and no device is judged on. The rest of the device still has to be designed, engineered, verified and submitted. Perdigó Medical is an ISO 13485-certified medical device design and engineering house in Barcelona.

Innovation

Circuit design, PCB layout and hardware integration for active medical devices.

Mechanical engineering and industrial design

Structural design, tolerancing, and user-centred form development for manufacture at scale.

Usability engineering

Formative and summative evaluation structured to IEC 62366-1.

Risk management

ISO 14971 hazard identification, risk estimation and risk-benefit analysis across the device lifecycle.

Verification and testing

Mechanical, electronics, software and accelerated aging tests in-house, with compliant documentation.

Regulatory strategy and submission

Classification, standards mapping, evidence planning and technical documentation for the EU, US and UK.

Components adapted to your device, or new components developed for hardware not yet in the catalogue, executed inside the same quality system and delivered with their records. Clients developing a device with Perdigó Medical receive the medular documentation package as part of the engagement.

See our full development process

FAQs

Questions we are asked the most

1. Does medular require an RTOS?

No. medular makes no assumption about an operating system. Scheduling, locking and timing are reached through ports, so the same components run bare metal or under an RTOS. NEEDS which RTOS ports exist today

2. How does medular enter our IEC 62304 file?

It depends on what you receive. A binary alone is software of unknown provenance and carries the SOUP obligations that follow. A binary delivered with the full development record enters your file as developed software, with the requirements, design records, verification evidence and traceability behind it.

3. Is medular SOUP?

With the documentation package, no. The purpose of the record is to remove that question. Delivered as a binary alone, it would be treated as SOUP by your quality system.

4. What does the Class C documentation package contain?

SRS and SDS per module, a traceability matrix from requirement to design to test, V&V reports per release, a software FMEA, a safety manual with anomaly list, the software architecture description, unit test and coverage reports, configuration and release records, and an SBOM per release.

5. Can we use medular in a non-regulated product?

Yes. Licences are scoped by field of use, and a licence sold for non-regulated products cannot be used in a regulated device without an upgrade.

6. Is medular certified?

medular is a software component, not a medical device, and carries no CE mark of its own. It is developed under Perdigó Medical’s ISO 13485 quality system and an IEC 62304 lifecycle targeting Class C. Device-level certification remains with you.

Start your next device on a documented foundation.

Tell us about the device: the processor, the components on the board, the safety class and where you are in development. We will show you what medular already covers and what it leaves your team to build.

Talk to a medular expert