Hardware Product Development Company | Design to Manufacturing

One Integrated Product Launch System

From first concept, to shipping first units, to scale-up—without resets, rework, or handoff chaos.

Product Innovation

Turn uncertainty into a clear, feasible product definition before architecture, cost, and commitments lock in.

Product Development

Engineer the product as a coherent system—stable, verifiable, and ready to transfer.

Product Manufacturing

Stabilize designs and processes through pilot builds—so production scales without surprises.

Trusted by teams building complex hardware

ISO 13485 Certified

Medical device quality management system for design and manufacturing

ISO 9001 Certified

Quality Management System for Operational Excellence

FDA Registered Manufacturer

Design and manufacture of regulated medical devices

Since 2004

Toronto • Guangzhou

Your partner for integrated innovation, design, and manufacturing

Our Work

Our portfolio reflects more than two decades of hardware product development and manufacturing across regulated medical devices, robotics, industrial systems, and complex electromechanical products.

Medical & Diagnostics

We design and manufacture regulated medical devices with quality systems, traceability, and design controls integrated from early development through commercial production.

POC Blood Analyzer

Verv’s cartridge-based diagnostic platform is a point-of-care blood analyzer designed for decentralized testing, enabling single-drop biomarker analysis through integrated electrochemistry and precision mechanical interfaces. 

Mobile Medical Workstation

Amico’s Hummingbird LCD and AIO Powered Electric Lift Mobile Workstation is a production-grade, ergonomically engineered point-of-care computing and storage platform designed for clinicians and nurses, enabling continuous bedside documentation and medication workflows through integrated industrial design, mechanical engineering, and modular SmartDrawer development. 

Oxygen Accessory for Ventilator

Baylis’s 100% oxygen accessory is a ventilator add-on designed to extend the oxygen delivery capability of the V4C-560, enabling clinicians to support more severe respiratory cases through an integrated enclosure, flow regulation, plenum, tubing, and manufacturing-transfer architecture built around an existing ventilator platform.

Mobility & Rehabilitation

Most mobility and rehabilitation products don’t fail because the core idea is flawed. They fail because decisions are made without fully accounting for real users, caregivers, environments, and long-term use.

Nuvio One Rollator

Nuvio One is a close-reach mobility device designed to help people with reduced mobility walk, rise, and move with greater support and control.

Mobile Shower Commode Chairs

Raz products are mobility, toileting and bathing systems designed for caregivers, clinicians, and individuals with mobility impairments. They improve safety, positioning and accesibility during toileting, bathing and tub transfers though innovative designs.

Clean Tech & Energy Systems

Most clean tech programs don’t fail because the core technology is wrong. They slip when field constraints—install environments, temperature swings, ingress, service access, and compliance—surface late.

EV Charger Pedestal

Rivian’s Level 2 charger pedestal is an outdoor mounting and cable-management system designed to support one- or two-charger wallbox configurations, combining structural support, service access, and a cleaner field-ready charging experience around an existing charger platform.

Portable Water Purification

Portage is a durable, reliable, go-anywhere water filtration system to provide safe drinking water anywhere in the world. Its novel graphene ultrafilter technology cleans the dirt and bacteria from the water, and when used in a brackish or sea water environment, an optional reverse-osmosis stage removes the salt.

Recirculating Shower

RainStick is a recirculating shower system for homeowners and sustainability focused builders. It delivers a high-flow shower experience while reducing water and energy consumption by recirculating water through an integrated filtration and UV sanitation system.

Robotics & Automation

We build robotics as a single system across industrial design, mechanical engineering, electronics, embedded software, controls integration, and manufacturing—so performance, serviceability, and repeatability are designed in from the start.

Surgical Mining Instrumentation

Novamera’s control unit is a ruggedized subsurface electronics housing for its Surgical Mining™ system, designed to package and protect control, power, communication, conditioning, and telemetry electronics in a compact assembly for underground operation.

Lidar Surface Map Scanner

RockMass Eon is a handheld LiDAR-based underground mapping device designed for geotechnical engineers to capture structured geological data at the rock face with less physical strain, faster field workflow, and reduced post-shift transcription.

Autonomous Weed Picking Robot

Nexus Robotics’ platform is an autonomous, AI-driven agricultural vehicle that enables growers to selectively remove weeds at field scale by integrating machine vision, hybrid-electric propulsion, and robotic manipulation into a commercially deployed, field-ready system.

Defence, Safety & Security

Mission-critical hardware requires disciplined integration from the first decision onward. We align architecture, engineering, verification, and manufacturing so complex systems are built with the control, traceability, and resilience their environments demand.

Portable Forensic Document Imaging System

A portable forensic document imaging system that enables field operators to examine and capture records using transmitted, visible, infrared, ultraviolet, and edge lighting within a compact deployable copy stand.

Laser Rangefinder Monocular

Newcon’s LRM 3500M is a rugged laser rangefinder monocular designed for military and field operators who need precise long-range distance measurement, targeting support, and observation in demanding environments.

Connected Access Hardware

Sera4’s AP3 is a connected padlock designed to secure remote and distributed physical assets, enabling identity-based access control, real-time monitoring, and auditable field operations.

What Makes Inertia Different

We structure hardware development around clear ownership, strong project governance, and decisions that withstand manucturing and scale.

Clear Ownership

A single accountable lead owns system-level trade-offs—so responsibility doesn’t fragment across functions, vendors, or phases.
Judgment Over Escalation

We resolve uncertainty where it occurs instead of pushing decisions upward through layers of approval.
Senior Practitioners

Clients work directly with experienced product development leaders who understand architecture, engineering, manufacturing, and regulatory consequences.

Early, Informed Choices

We force hard choices early—while architecture, cost structure, verification paths, and manufacturability can still be shaped.
Continuity Across Phases

Intent, assumptions, and constraints carry forward—so progress doesn’t reset as programs move from strategy to engineering to manufacturing.
Decision-Led Collaboration

Work is organized around identifying and resolving the decisions that shape architecture, cost, risk, and manufacturability.

Built for Production Reality

We operate where constraints are real—regulated environments, mission-critical systems, and products that must perform reliably beyond the prototype.
Decision Memory

We capture why choices were made—not just what was built—so teams don’t re-litigate settled questions as constraints shift.
Durable Knowledge

Documentation preserves reasoning, trade-offs, and assumptions so program knowledge survives people, timelines, and organizational change.

Trusted by Industry Leaders

We needed a partner who could design, manufacture, and supply-manage our smart lock hardware product so that our team could focus on developing our core services and IP, which is access control and encryption software. The Inertia team certainly delivered on the hardware, which helped ...

Being a first-time entrepreneur, the Inertia team fully immersed me in their product development experience and made me feel in total control of my product's destiny – providing exceptional support required to get the work done right and on time. They shared with me all their ...

The next growing season waits for no one. That's why we partnered with Inertia to be our turn-key hardware engineering and manufacturing team. In six short months they delivered a clean-sheet engineered design for our autonomous weed-picking vehicle – mechanicals, bodywork, ...

We needed a company to work with us on the development of a novel medical device in record time, while in the middle of the COVID-19 pandemic. Inertia was an excellent partner. They stepped up to meet this challenge and we were able to successfully complete the project. Together, we ...

Not only did they design a beautiful vertical grow garden that looks like it actually belongs in your home, they helped to increase our gross profit margins and rapidly scale our manufacturing capacity to meet our growing customer demand.

From the early stages of the project, we were driven by ambitious timelines with a fail-fast mentality. Countless rapid iterations based on user feedback ultimately produced a persuasive prototype. From there, we needed a high-quality product and short time-to-market. We were demanding ...

Inertia brings creative design, thoughtful engineering, and a sensitivity to scaled manufacturing, along with proactive thinking around potential roadblocks. I haven't contracted a firm with the same scope as Inertia before—other vendors have had much more specific areas of focus for ...

For Pioneers Building What's Next

Our perspective from the engineers and strategists shaping what’s next in new product innovation

Latest Insights

Insights From Our Blog

Practical strategies from Inertia’s engineers and product strategists — clear, evidence-based guidance that reduces risk and accelerates launch.

General Category 12 min read

Field Notes from MHSRS 2026: The Hardest Part of Military Medical Innovation Is the Handoff

The most dangerous moment in autonomous casualty evacuation is the handoff, the instant when control passes between the machine and the human operator. Full autonomy is manageable. Full manual control is manageable. The seam between them is where things break. After several days at MHSRS 2026, I think that insight reaches well beyond unmanned vehicles. Military medical innovation keeps running into trouble at its handoffs: between technology and operator, between a diagnostic output and clinical judgment, between a funded prototype and an acquisition program, and between engineering intent and scalable production. The technology on display was impressive. The harder problem was building systems that people can trust, field, buy, and sustain under conditions that leave very little room for error. MHSRS is the Department of War's foremost scientific meeting on military medicine. Thousands of attendees moved through the Gaylord Palms across hundreds of presentations and posters, spanning haemorrhage control, blood products, traumatic brain injury, burn care, autonomous evacuation, and biomanufacturing. The scale of research funded through the US defence health enterprise is hard to appreciate until you are standing inside it. The requirement collision Start with what makes military medtech unlike its civilian cousin. A device here has to satisfy clinical, operational, human, and industrial requirements at the same time. It must meet strict regulatory and quality expectations, move from concept to field quickly, keep working in an austere and contested environment, and remain usable by non-experts under stress. Civilian products rarely have to carry all of those at once. In this market it is the starting line, and every handoff that follows is where one of those requirements tends to get dropped. Handoff one: from automation to human control COL Conrad Wilmoski of the US Army Medical Center of Excellence set the operational stakes. He framed casualty evacuation as a priority capability gap for large-scale combat operations, driven by the prospect of unsustainable losses, and worked through it with a DOTmLPF-P analysis, the military's method for examining a problem across doctrine, organization, training, materiel, leadership and education, personnel, facilities, and policy rather than as a pure equipment buy. One distinction stuck with me. CASEVAC moves casualties on whatever non-medical platform is available and often without medical personnel aboard, while MEDEVAC uses dedicated, marked, staffed platforms. Much of what Ukraine has forced is the former, as contested airspace, shrinking evacuation capacity, and fewer medical formations forward push units to move casualties on whatever will roll or fly. That is the setting for the talk that reframed the topic for me, from Maj. (Res.) Ariel Braverman of Ben-Gurion University and the IDF Medical Corps, on the human factors of unmanned medical evacuation. His argument was that an unmanned system is not one machine and one operator. It is a distributed cognitive system spanning frontline medics, remote vehicle operators, remote clinicians, and commanders, with the automation contributing monitoring, data fusion, decision support, and navigation. He laid automation out on a spectrum from teleoperation through supervised and conditional autonomy up to full autonomy, and located the risk at the handovers, when control and responsibility pass between person and machine. He was direct about the variables that decide whether any of this survives contact with the field: trust, workload, situational awareness, and accountability. Remote operators lose direct perceptual access to the scene. They drift toward complacency in quiet stretches, then face sudden workload spikes when something fails. And the accountability question has no clean answer yet. He asked who is responsible for a patient's condition during autonomous transport, and the room had no framework to offer. The line I keep returning to, because it maps so closely to how we work at Inertia, was this: "Human-centered design is a safety requirement, not an option." A device that non-experts have to operate while under fire, injured, and afraid cannot treat usability as polish added at the end. The clear behavioural cues, the simplified operation, the fail-safe handover, and the transparency that lets an operator calibrate trust are the product. Braverman went further and paired each human factor with a design response, matching workload to adaptive levels of automation and building operator competence through scenario-based training. That turns human factors from a talking point into an engineering specification. That way of thinking is second nature in medical device development, where human factors and use-related risk are design inputs rather than finishing touches. It is far less common among teams building autonomy, where the platform gets the attention and the person using it comes later. Coming at these systems from a regulated-device background, that is the difference I notice first, and it is where a medtech lens reads them differently than a pure autonomy one does. A second layer of autonomy It is not only the vehicles. The most striking autonomy at MHSRS was not moving the casualty but managing them. Closed-loop systems now titrate inspired oxygen to a target saturation on their own, and autonomous ventilators adjust support continuously without a clinician at the bedside. These are aimed squarely at prolonged casualty care in austere settings, where oxygen is a scarce resource, evacuation is slow, and there may be no respiratory therapist forward. One closed-loop system reported making several hundred oxygenation adjustments in the time a clinician would make a handful. That is a sharper version of the same handoff. When a machine makes hundreds of decisions an hour, the clinician's job shifts from doing to supervising, and the risk moves with it: complacency in the quiet stretches, trust that is hard to calibrate, and no clean answer to who is accountable when the system runs unattended and something drifts. The clinical-autonomy teams are wrestling with this directly. It is the wider autonomy world, the one fixated on the platform, that still tends to wave the question off. Handoff two: from objective signal to clinical action Traumatic brain injury ran through the program as its own track, and it exposes a quieter handoff. Concussion and blast injury still lean heavily on self-reported symptoms, and service members underreport their symptoms, often substantially. That pushes the field toward objective measures, including eye-tracking and pupillometry at or near the point of care, and toward better blast exposure monitoring. A comparison of three eye-tracking devices, published in the MHSRS proceedings, found the strongest performer reached an AUC of 0.95 on acute injury in training data, then fell to between 0.60 and 0.75 on a withheld validation set, and to chance on chronic cases. The signal is real and it is not yet stable. Look at the shape of the problem. The technology can produce an objective signal. Whether a clinician trusts that signal enough to act on it, and to make a return-to-duty call, is a human factors question, the same one Braverman raised about autonomous transport. A signal that the user does not understand or believe does not change the decision. The handoff from data to action is where the value is either captured or lost. Handoff three: from funded prototype to fielded capability The next handoff is the one companies feel most sharply, and it was the subject of some unusually frank acquisition sessions. Speakers kept returning to the "valley of death," the gap where a technology has been developed but has no clear path into a program of record. One official described the risk of the government behaving as a poor business partner, asking industry to build something and then stepping back when it is time to buy. Another floated accepting a good-enough joint solution now over a perfect service-specific one later. This is the seam between a working prototype and a program that will actually procure, field, and sustain it, and a promising device can die in that gap for reasons that have nothing to do with whether it works. Handoff four: from engineering intent to manufacturable scale The handoff that decides whether any of this reaches a warfighter at volume was also the one MHSRS talked about least. Biomanufacturing had a real presence on the poster floor, but most of that work is about producing a biologic or a blood product, not about industrializing a device so that the thousandth unit performs like the first. This is a research meeting, so that emphasis is expected. It is still a gap worth naming, because it is where a great deal of promising technology quietly stalls. A prototype proves that something can work once, in trained hands, under controlled conditions. It says very little about whether that performance survives tooling, tolerance stack-ups, supplier variation, process capability, and the test and inspection regime a fielded medical device demands. In a market where the device has to hold up in an austere environment and be operated by non-experts under stress, manufacturing variation is not only a cost problem. It is a readiness and safety problem. A unit that drifts out of specification at scale fails at exactly the moment the requirement collision is least forgiving. And these outcomes are largely set early, by decisions about architecture, materials, tolerances, suppliers, and testability that are made long before anyone files them under manufacturing. By the time a program reaches transfer to manufacturing, the expensive choices are already locked. It is the same pattern that runs through every other handoff here. The risk is created early and discovered late. For dual-use medtech companies, including Canadian ones Canadian companies were well represented at MHSRS, and the technical quality was high. Deep Breathe, Thornhill Medical, MY01, Moonrise Medical, and Xpan were all there, a strong showing for a country our size. The structural challenge is not the technology. Canadian medtech and defence companies are, as a sector, stronger at research and prototypes than at industrialization, which makes the manufacturing-and-scale handoff the one that most often decides whether strong technology becomes a fielded product or stops at a successful demonstration. Strong technology alone does not create a US defence-health opportunity either. The product has to be translated into an operational requirement, connected to the right acquisition pathway, and designed around the restrictions that affect foreign participation, manufacturing, data, and export-controlled technology. Funding and teaming are the questions companies ask about first. The Medical Technology Enterprise Consortium is one important route into the US military medical ecosystem, working across USAMRDC, the Defense Health Agency, and other government partners to move prototypes toward capability, but it is not a simple grant program. Each solicitation sets its own maturity, teaming, cost-sharing, regulatory, and contracting requirements, and its membership spans more than twenty countries, so the right structure is opportunity-specific. It may mean direct membership, a US partner, a prime-subcontractor relationship, or another route entirely. Reading the individual solicitation matters more than any general rule. The part worth emphasizing is timing. None of this work can wait until the prototype is finished. By then some of the most consequential architecture, supply-chain, and evidence decisions may already be hard to reverse. In this market, as in complex hardware generally, the costly risks are created early and discovered late. Where Inertia fits MHSRS reinforced a belief that is central to how we work at Inertia. In complex, high-consequence hardware, the hardest failures are usually structural rather than purely technical. Military medtech intensifies that. Clinical intent, human factors, autonomy, regulatory evidence, ruggedization, manufacturability, and acquisition strategy cannot be run as separate workstreams that eventually meet at the end. The critical decisions have to stay coherent as the product crosses from concept to verification, field evaluation, transfer, and production. Every one of those transitions is a handoff, and each is a place where intent can quietly leak out of the program. We are not a military operator, and we should not pretend to be one. Our contribution is different. Designing for the person at the seam, treating human factors as a design discipline rather than a finishing touch, is what medical device development teaches, and it is a lens still uncommon among teams building autonomy. We bring that together with the manufacturing side, translating demanding operational and clinical requirements into systems that can be verified, built at scale, and used reliably, and keeping those requirements intact across the interfaces where they usually fragment. The lasting lesson from MHSRS was about coherence. Military medical technology has to cross its handoffs without losing the intent that made it valuable in the first place. Questions this raises What is MHSRS? MHSRS is the Department of War's foremost scientific meeting on military medicine. Thousands of attendees move through hundreds of presentations and posters spanning haemorrhage control, blood products, traumatic brain injury, burn care, autonomous evacuation, and biomanufacturing. What were the main themes at MHSRS 2026? The technology on display was impressive. The harder problem was building systems that people can trust, field, buy, and sustain under conditions that leave very little room for error. Military medical innovation keeps running into trouble at its handoffs rather than in the technology itself. What are the four handoffs in military medical innovation? From automation to human control, when responsibility passes between operator and machine. From an objective signal to a clinical action, when a clinician has to trust a measurement enough to act on it. From a funded prototype to a fielded capability, the valley of death before a program of record. And from engineering intent to manufacturable scale, where the thousandth unit has to perform like the first. If you are adapting a civilian medical technology for far-forward care, or moving a funded military-medical prototype toward something fieldable and manufacturable, I would be glad to compare notes on where transition risk is accumulating.

Aug 12, 2026

72 Views

Product Development 11 min read

Firmware Complexity Doesn’t Disappear. It Just Gets Hidden.

And in regulated hardware, hidden complexity is the most dangerous kind. Most hardware programmes reach a point where the firmware team gets pulled into a conversation that starts like this: "The software is the simple part. We just need the hardware to work first." It's a reasonable-sounding instinct. In early development, firmware can often be scaffolded quickly enough that it doesn't feel like the long pole. Hardware has lead times, tolerances, regulatory implications. Firmware seems malleable — something you iterate on until it works. That assumption is expensive. It is how teams end up discovering concurrency bugs at verification. It is how architecture decisions made implicitly in month two become technical debt that takes months to untangle in month fourteen. And in regulated products — medical devices, life science diagnostics, defence systems, industrial platforms — where software process documentation, traceability, and verification evidence are not optional, the cost of a weak firmware architecture is not just schedule. It can compromise the evidence base needed for regulatory submission, clearance, certification, and post-market change control. The deeper problem is not that firmware is difficult. It is that one of the most common development paradigms — threading models built on traditional real-time operating systems — allows teams to write code that appears to work while hiding structural fragility underneath. What is firmware architecture in medical devices? Firmware architecture for medical devices defines how embedded software is structured across subsystems, how concurrent behaviour is managed, and how system state is modelled and traced to requirements. In regulated products where IEC 62304 defines the software development lifecycle, architecture decisions directly determine what verification evidence can be generated, how requirements trace to code, and how much post-market design changes cost. It is a programme-level decision with regulatory consequences — not a technical implementation detail. The RTOS Illusion Traditional RTOS-based firmware development offers a seductive model. Threads are organized around functions or peripherals. Within a thread, you write sequential, imperative code. When you need to wait for something — an I²C transfer to complete, a sensor to respond, a mechanical operation to finish — you call a blocking function. The RTOS suspends your thread, hands execution to something else, and resumes you when the result arrives. From the programmer's perspective, it feels clean. The code is readable. The logic is linear. Blocking functions read almost like synchronous pseudocode. But the RTOS isn't eliminating the concurrent behaviour. It is abstracting it. Underneath the surface, multiple threads are executing, sharing resources, waiting on semaphores, and competing for access to buses and peripherals. The complexity is real. The RTOS just makes it invisible. The invisibility is the problem. Race conditions in RTOS-based systems are among the most notoriously difficult bugs to find and eliminate. Priority inversion — where a lower-priority thread holding a resource ends up blocking a higher-priority thread that needs it — can stall a system in ways that don't surface during normal testing. Deadlocks can emerge from patterns that look perfectly reasonable in isolation. The latent bug exists in the code for weeks or months before a specific sequence of events in a specific operating condition exposes it. In a consumer product, a latent concurrency bug is a quality problem. In a regulated medical device or a diagnostic instrument, it is a design control failure. Your verification plan didn't catch it because the failure mode wasn't explicitly modelled. Your design history file doesn't explain it because you didn't know it existed. The traditional RTOS model doesn't give you complexity for free. It loans it to you with interest, and the bill arrives at the worst possible time. Making Complexity Visible None of this means RTOS-based systems are inherently poor architectures. Well-designed thread-based systems can be robust. The issue is that the model makes it easy for architectural coupling and concurrency risk to remain implicit — unless the team deliberately exposes and governs it. There is an alternative architectural pattern that inverts this dynamic. Rather than hiding concurrent behaviour behind threads and blocking primitives, it makes that behaviour explicit in the structure of the code itself. This is what systems design looks like when applied seriously to the firmware layer — not just defining subsystem interfaces at the hardware boundary, but governing how state, events, and concurrency are modelled across the entire embedded stack. One mature embedded implementation of this pattern is Quantum Leaps' QP framework, which organises firmware around active objects: independent entities that each run in their own execution context, and that communicate through asynchronous events. At the application layer, active objects communicate through asynchronous events rather than shared state, mutexes, semaphores, or blocking calls — the patterns that make thread-based designs difficult to reason about and harder to verify. Critical application behaviours are expressed as state machines. Every state is explicitly defined. Every transition is explicit. Every asynchronous operation — waiting for a sensor response, waiting for a mechanical operation to complete, waiting for a bus acknowledgement — is a state that appears in the model, not a hidden pause buried inside a function call. This has an important consequence: the complexity of the system is no longer hidden in the runtime behaviour of concurrent threads. It is visible in the architecture. On a recent point-of-care blood analyzer development programme — a cartridge-based diagnostic instrument with multiple precision electromechanical subsystems, an optical measurement chain, and a real-time control system — Inertia's firmware team used the QP framework to structure the entire application layer. The director object coordinated high-level instrument workflow. Each major subsystem — cartridge handling, sensor management, optical measurement, display control, communications — was its own active object, with a clean interface and an explicitly modelled state machine. The cartridge-cinching subsystem alone had a meaningful hierarchy of states. At the top level, the instrument workflow needed to know one thing: is a cartridge ready? But beneath that, the cinching subsystem managed a sequence of motor actuation, mechanical position sensing, cartridge identification, and error handling, each with its own internal states and transitions. The parent state machine didn't need to know any of that. It received a single event when the subsystem was ready — or a different event if it wasn't, with enough information to inform the user and decide how to proceed. That clean interface was only possible because the internal complexity of the subsystem was explicitly modelled, not hidden inside a thread that the rest of the system had to trust. Mitch English, Inertia's Manager of Mechatronic Systems, discussed this programme in depth on the Agile Embedded Podcast — including the QP framework adoption, the architectural decisions made along the way, and what the team would approach differently on the next programme. IEC 62304 and the Verification Dividend The downstream effects of an explicit, event-driven architecture are not limited to code quality. They show up directly in verification and validation — and for teams building under IEC 62304-aligned software development processes, this is where architecture decisions made months earlier either pay forward or come due. When firmware behaviour is expressed as state machines, it can be inspected, reviewed, and verified against requirements at an architectural level. You can show a customer — or a regulatory auditor — a state diagram that represents actual system behaviour, not an abstraction of it. You can trace requirements to specific states and transitions. You can demonstrate that every defined input to a state is handled explicitly, and that every unhandled event fails in a defined way. For medical-device software developed under an IEC 62304-aligned process, that traceability is not merely a documentation exercise. It is a design input. Unit tests for active objects can be written on the host against the state machine logic, without hardware in the loop, because the application behaviour is decoupled from the hardware layer by design. Those tests generate the software unit verification records that the quality system requires. The architecture makes verification evidence easier to produce, inspect, and maintain. In practice, this matters in ways teams don't always anticipate until they're deep in a verification campaign. When a software unit test catches a state transition that doesn't match the requirement, fixing it is a contained change. When a concurrency bug surfaces during system-level testing in an RTOS-based architecture — when you don't know which thread is involved, which shared resource is in contention, or under what exact sequence of events the problem reproduces — you're not fixing a unit. You're re-examining architectural assumptions. One honest post-mortem from the QP programme is worth naming here. Early in the work, the team made a structural choice to use direct posting between active objects in a number of places rather than the publish-subscribe model the framework supports. The reasoning was intuitive: if the director depends on the cartridge subsystem, why not post directly? The coupling is logical. It exists whether you acknowledge it or not. What that decision produced was unit tests that had to mock the specific partner object in every test scenario. As the system grew and the number of inter-object interactions increased, the test setup overhead grew with it. In retrospect, using the pub-sub model from the beginning — where objects publish events to a kernel without knowing who is subscribing — would have kept the test surface clean. It would also have made adding a system-level event logger trivially easy instead of requiring a structural change. It was premature optimization in the wrong direction, and the team recognized it. That kind of post-mortem is only possible when the architecture is explicit enough to reason about. In a complex RTOS system, it is often not obvious which coupling decisions produced which test complexity. You can see the symptoms. The root cause is buried in the threading model. Why This Matters More in Regulated Domains The stakes are asymmetric in regulated hardware in a way that makes firmware architecture decisions consequential far beyond their immediate cost. In medical devices and life science diagnostics, the software is part of the regulatory submission. IEC 62304 software classes determine the rigour required for each unit. Risk controls tied to software functions must be verified and traced. Design changes post-clearance trigger regulatory processes. A firmware architecture that produces clean, traceable, testable software units doesn't just reduce development cost — it reduces the cost and risk of every subsequent change, every post-market modification, every next-generation derivative. In defence applications, where system reliability under adverse conditions is a hard requirement and software documentation must support through-life support and modification, explainability of system behaviour at the architectural level is not a preference. It is a programme requirement. In industrial robotics and automation, where complex multi-axis coordination and safety-critical control loops must be demonstrably correct, the ability to reason about system state at any point in time — not as an after-the-fact debug exercise, but as a first-order design property — is what separates architectures that scale from architectures that become intractable at the edges of their operating envelope. The argument for event-driven, actor-model firmware architecture is not that it eliminates complexity. Complex systems are complex. The argument is that it puts the complexity where you can see it, reason about it, test against it, and trace it to requirements. For products that have to be verified, cleared, and trusted in real operating environments, the difference between visible complexity and hidden complexity is not academic. The Architectural Decision Is a Programme Decision If there is a single practical implication here, it is this: firmware architecture is not a decision that should be deferred until the firmware team is ready to start writing code. It is a programme-level decision that should be made during systems design, when the consequences are still visible and the options are still open. That decision determines how the software development plan is structured. It determines what unit test strategy is feasible. It determines how requirements trace to code. It determines how design changes propagate through the system. It determines what the verification evidence looks like and how much it costs to generate. Made late, or made implicitly by defaulting to the path of least resistance, it also determines how much of the development budget goes into untangling problems that a different architectural choice would have prevented. Firmware complexity doesn't disappear. In a traditional RTOS-based system, it is loaned to you at favourable early terms. In event-driven, explicitly modelled architectures, it appears up front — in the state diagrams, the event tables, the active object interfaces. That upfront visibility feels like more work. It is actually less, because you are doing the work once, in the place where it can be governed, instead of repeatedly, in the places where it surfaces as failure. Inertia Group is a Toronto-based product strategy, engineering, and manufacturing partner for complex hardware, medical devices, life science diagnostics, defence systems, and advanced electromechanical products. We work with scaling hardware companies, regulated product manufacturers, and OEMs to turn complex product challenges into manufacturable, launch-ready outcomes. If firmware architecture decisions are on your critical path, we should talk.

Jul 6, 2026

2259 Views

Product Development 16 min read

Canada’s Robotics Moment: What the People Building and Buying Defence UAVs and UGVs Are Actually Saying

Reflections from ROAR East 2026 - York University, Toronto There is a version of the Canadian defence robotics story that sounds like a press release. Increased NATO spending commitments. Dual-use technology opportunities. A booming domestic UAV and UGV sector ready to supply both the Canadian Armed Forces and the first responder community. A generation of entrepreneurs finally permitted to take defence seriously. That version is true. It is also incomplete. We recently attended ROAR East - the Remote Operated and Autonomous Robotics Conference- held at York University's Schulich School of Business in Toronto. ROAR is Canada's premier conference series dedicated to unmanned systems, drones, and autonomous technologies, bringing together buyers, operators, manufacturers, and policy makers across public safety, defence, energy, mining, and government. This particular edition was one of the more concentrated gatherings of people actually building, buying, deploying, and funding defence and dual-use robotics in Canada. The room included serving and former military leaders, drone company founders, first responder units, counter-UAS specialists, venture investors, a Ukrainian battlefield adviser, and a Croatian drone manufacturer who has shipped hardware to active conflict zones. What emerged over two days was a more complicated, more useful picture than the press release version. One with structural implications for any hardware company - or manufacturing partner - trying to serve this market seriously. The Battlefield Has Already Moved The most important framing came from General Wayne Eyre, former Commander of the Canadian Armed Forces. His message was precise: the military has a long history of being fascinated by new technology and then struggling to turn it into battlefield advantage. Robotics will be no different unless development is disciplined around operational need rather than technological novelty. He identified the mission areas where unmanned systems can make an immediate difference - logistics, casualty evacuation, ISR, explosive ordnance disposal, perimeter security, urban reconnaissance, maritime surveillance. For Canada specifically, he noted that our vast geography and relatively small population density make robotics not just useful but strategically necessary. We need systems that can operate in harsh, remote, and contested environments. Then he made a point that should land hard for anyone designing or manufacturing these systems: a platform that performs well on a demonstration range but fails when GPS is denied, communications are jammed, batteries are cold, or mud clogs its tracks is not operational capability. It is a trade show exhibit. This is not a peripheral concern. It is the core design requirement. Ukraine reinforced this. Olena Kryzhanivska, who advises on Ukrainian battlefield innovation, described the pace of change on the ground - hardware iteration cycles of four to six weeks, software cycles as short as seven days, and frontline R&D labs making final modifications to equipment as close to the line of contact as safely possible. She described how units have moved from experimentation to large-scale deployment of unmanned ground vehicles for logistics, engineering, and fire support, and how the forces that adopted most successfully were those that stayed close to operators, iterated continuously, and treated the operational environment as the real test bed. She was also clear about what international observers consistently misunderstand: autonomy is not replacing the human. Drone operators, crews, engineers, and support personnel are the system. The hardware is only as effective as the people trained to use and maintain it - and the integration of that hardware into broader combined arms doctrine. General Eyre made the same point from a military strategy perspective. The lesson from Ukraine is not that numbers alone win. It is integration - systems that plug into the broader fight, reduce human exposure to the most dangerous tasks, and allow commanders to generate effects more precisely. Dual Use Is Not a Feature. It Is the Business Model. One of the clearest strategic themes across both the defence and public safety streams was the value - and the commercial logic - of dual-use positioning. Kevin Todrel's opening keynote laid out the structural shift: drones originated as hobbyist technology, moved into commercial and industrial applications, and have now pivoted hard into defence. That pivot brought significantly more funding, more rigorous technical requirements, and a faster iteration cycle. The result is a class of technology that is genuinely useful across forestry, infrastructure, natural resource extraction, search and rescue, ISR, logistics, and frontline operations - often with the same or very similar hardware. From an investor's perspective, this matters enormously. One panellist at the Canadian ecosystem session made the point directly: a dual-use product in search and rescue or infrastructure inspection has commercial customers who pay today, which means a supplier serving a defence contract that runs three months late does not go broke waiting. There are other places to sell, other places to test, and other revenue streams to sustain the company. From a product development and manufacturing perspective, dual-use positioning creates different but equally important pressure. A system designed only for military procurement can be over-engineered for its commercial equivalent, or under-designed for actual operational conditions, because neither requirement fully disciplines the architecture. Systems that must perform across both domains - RCMP drone docking stations, DFR platforms, ISR drones used in both public safety and defence ISR roles - tend to force better engineering decisions earlier. The drone-as-first-responder deployments discussed in the public safety stream illustrated this concretely. Durham Region Police, RCMP, and others described response times dropping from twenty to thirty minutes to under four minutes through pre-positioned docking stations and remote piloting. Launch times as low as thirty-five seconds. Drones on-scene before responding officers, transmitting thermal imaging in real time, coordinating arrests, locating missing persons in dangerous conditions. These are not military missions, but the hardware requirements - reliability in cold weather, GPS accuracy, low-light imaging, communications resilience, autonomous return-to base - are effectively the same. The Supply Chain Problem Is Structural, Not Logistical Across multiple panels, the conversation kept returning to supply chain - and what was said was more honest than the usual talking points. Ivan Jelusic, CEO of ORQA FPV, gave the most direct account. His company started building FPV racing goggles. When Russia invaded Ukraine in early 2022, he shipped thirty drones in a diplomatic pouch because someone he knew needed them. That moment became the pivot point for ORQA's transformation into a Western defence supply chain company. His diagnosis of why the West cannot simply compete with DJI on technology features was blunt: DJI dominates because it owns its entire technology stack, from propellers to motors to flight controller firmware to radio systems. System integrators assembling products from off-the-shelf components cannot reach that level of performance or cost efficiency. Western companies that want to compete cannot chase DJI's technical superiority - they will lose. What they can do is own the software and AI layer, build sovereign manufacturing capabilities, and compete on compliance, reliability, and interoperability rather than on raw specification. He described ORQA's current strategy in Canada as building exactly that: a manufacturing hub that enables Western companies to build drone solutions using a supply chain independent from Chinese mission-critical components, with sovereign software and AI capabilities developed locally. That last point echoes what Canadian drone manufacturers on the CEO panel said about their own supply chain decisions. One company described walking across the street to a GTA manufacturer rather than sourcing from overseas, designing for component interchangeability from the start, and investing in in-house sewing capacity, CNC equipment, and injection moulding specifically to reduce dependency and enable rapid design changes without waiting on external suppliers. When COVID hit, that vertical integration let them navigate chip shortages and supplier disruptions better than their competitors. The underlying principle is the same in both cases: supply chain resilience is not a procurement problem. It is a product architecture decision. It is made - or not made - during design. The Gap Between Prototype and Fielded System Is Where Things Break Across all the sessions, a consistent failure pattern emerged - one that defence procurement veterans, battlefield advisers, and venture investors described from different angles but arrived at the same diagnosis. Companies build capable prototypes. They demonstrate them at conferences, submit them to procurement processes, and sometimes win contracts. Then the hard part begins: producing them reliably, at volume, in configurations that survive operational environments, with supply chains that do not collapse under pressure, and with the ability to iterate quickly based on user feedback. Most companies are not structurally prepared for that transition. Olena Kryzhanivska described Ukrainian forces rejecting a supplier not because the product was technically inadequate, but because the company was not flexible enough to iterate when field conditions changed. The product team believed their solution was finished. The military unit moved on. General Eyre described the same dynamic from a procurement perspective. The speed at which Ukrainian frontline units are incorporating field feedback into production - ideas from the front line appearing in the production line within days - is the standard that matters. Canada's procurement processes are not designed for that. But hardware companies that want to serve serious defence buyers have to be able to move at something closer to that tempo, at least in their development and manufacturing processes. Investors on the funding panel raised the parallel problem from a capital perspective. Canadian companies that win early defence-adjacent contracts - grants, pilot programs, government trials - often hit a ceiling when it comes to scaling. Either they lack the manufacturing capacity to fulfil larger orders, or their product has not been built for volume production, or their supply chain depends on single sources that cannot ramp. The "missing middle" between early-stage demonstration and scalable production is where many companies stall. This is not primarily a funding problem. It is a product development and manufacturing readiness problem that appears as a funding problem. What Investors Actually Said - and What They Are Not Going to Say Publicly The funding panel at ROAR - which included Devon Galloway of Garage Capital, Matt Lombardi of On9 Ventures, and Michael Langlais of Canadian Corps of Commissionaires - was more candid than these conversations usually are. A few things said in that room are worth repeating outside it. The IDEaS problem is real and specific. Lombardi named it without softening: founders have won IDEaS challenges, celebrated the grant, and then discovered two things. First, there is no reliable pathway from winning a challenge to an actual procurement contract. Second, in a number of cases, winning an IDEaS grant effectively bars the company from bidding on related future work - because the government classifies it as a conflict of interest. The correct response to learning this, as someone in the audience noted, is laughter. But it is expensive laughter for the companies it happens to. The broader point is that government innovation programs, however well-intentioned, are not a substitute for commercial market discipline. Founders who build their strategy around grant funding without a parallel path to real customers are building on unstable ground. The domestic market will not scale your business. Lombardi was direct on this too: Canadian government buyers are valuable early customers, but they will never buy at the volume required to build a serious company. The Five Eyes and NATO allied markets - the US, UK, Australia, and European partners - are where the real volume lives. Canadian defence companies should treat the domestic market as the validation stage, not the growth stage. Companies that internalize this early build products and supply chains capable of meeting allied procurement standards from the start, rather than retrofitting compliance after the fact. Secrecy is killing companies that do not know it yet. Galloway made an observation that should be uncomfortable for a significant portion of the companies in the room. Founders who treat their product as too confidential to put into the hands of end users - who insist on NDAs before showing a design, who believe their IP is so sensitive it cannot be tested in the field - are consistently the ones who fail. The companies that win, by contrast, are the ones that find a way to get hardware in front of real operators under real conditions as early as possible, even when that is hard. He cited Sentinel R&D, which got on a plane to Estonia early in the Ukraine conflict and put their drones directly into the hands of warfighters when it was still difficult to do so. They got validation. They iterated. They built credibility that no trade show demonstration can replicate. The lesson is not that IP does not matter. It is that an untested product with tight secrecy is worth less than a field-validated product with a known iteration record. Hardware has a strategic window that software does not. Galloway pushed back on the standard VC narrative that hardware is a harder investment than software. His point: in an AI environment where software moats are eroding faster than ever, hardware companies still have genuine technical differentiation that is difficult to replicate quickly. That window will not last forever, but it exists now - and it is one reason why defence hardware companies, specifically, are attracting more serious institutional capital than they were three years ago. The communication gap is the deepest structural problem. Langlais identified what he called the core constraint in Canadian defence readiness: operational problems evolve in weeks, but procurement and development cycles run in years. Getting feedback from the operator on the ground all the way up through command structures to a procurement decision and back down to a production change is a process measured in years, not weeks. Until that loop shortens, the only companies that will succeed in Canadian defence robotics are the ones that find informal pathways to operator feedback - that go directly to the end user, in the field, before they have a contract, before they have permission, before it is easy. The MINERVA Initiative- launched by the Canadian Army in December 2025 to accelerate general purpose uncrewed systems at the tactical level - is a deliberate attempt to shorten exactly this loop, by embedding soldiers as co-developers alongside industry from the start. It is worth watching closely. The investors were not pessimistic about Canada's trajectory. Galloway noted that Garage Capital has been investing in defence companies since 2014 and sees Canada as genuinely positioned to be a technology vendor to the world in this sector. But the message underneath the optimism was consistent: the opportunity is real, the barriers are structural, and companies that wait for the system to clear a path for them will be waiting a long time. What This Means for Hardware Companies Entering the Defence and Dual-Use Market The picture that emerged across ROAR is not discouraging. Canada's defence spending trajectory - moving from roughly 1.5% of GDP toward 3.5% over the next several years - represents a structural increase in available capital. The dual-use market across public safety, critical infrastructure, natural resources, and defence is real and growing. The regulatory environment is evolving. The talent is here. New ecosystem infrastructure is taking shape alongside the spending increases. BOREALIS- the Bureau of Research, Engineering and Advanced Leadership in Innovation and Science - is now active as Canada's multi-departmental defence innovation coordination mechanism, with its Defence Innovation Secure Hubs (DISH) program offering up to $50 million to create secure, mission-focused environments where industry, academia, and government can co-develop and test uncrewed systems and quantum technologies. These are not small signals. They represent a structural shift in how Canada intends to connect its innovation ecosystem to operational capability - and they create real entry points for companies that are ready to engage seriously. But the structural risk in this market is the same structural risk in any complex hardware sector: the gap between a working prototype and a manufactured, fielded, maintained, iterated product is far larger than it appears at the demonstration stage. The companies that will build durable positions in Canadian defence robotics - in UAV and UGV platforms, in counter-UAS systems, in drone-as-first-responder programs, in ISR payloads, in ground logistics robots - are the ones that treat manufacturing readiness, supply chain resilience, and operational robustness as first-order design requirements rather than downstream considerations. That means selecting materials and architectures that survive field conditions, not just test ranges. It means designing for component-level repairability and modularity rather than platform-level replacement. It means building supply chains with redundancy from the start, not after the first disruption. It means understanding that the thermal, vibration, ingress, and communications requirements of a system deployed in Canada's Arctic are not the same as a system deployed indoors or in moderate climates - and that those differences need to be addressed in the engineering, not managed around in the field. And it means being honest about the difference between a prototype that demonstrates capability and a product that survives volume production, operator use, environmental stress, and continuous iteration. What Comes Next The ROAR Conference series continues with its next event on November 18-19, 2026 in Ottawa at the Ottawa Convention Centre, focused on Defence and Government. If you are building or procuring unmanned systems for the Canadian government or defence market, it is the right room to be in. Where Inertia Fits Canada's defence ecosystem has no shortage of innovative technology. What it lacks are organizations that can turn that technology into something deployable, manufacturable, and scalable. Inertia occupies that gap. We are a Defence Capability Acceleration Partner - a Toronto-based engineering and manufacturing firm with 20 years of experience moving complex hardware from concept to field-ready product. We work across the full stack: requirements, system architecture, ruggedized design, embedded software, sensor integration, manufacturing readiness, and production. Not as a consulting firm. Not as a contract manufacturer. As an integrated execution partner. What sets us apart is how we work. Inertia was built on venture-backed product development - clients with real capital pressure, hard deadlines, and no tolerance for scope drift. That operating rhythm is embedded in how we run every engagement. We move with the urgency of a startup and the engineering rigour of a prime, without the overhead of either. Where most organizations can prototype, Inertia can industrialize. Where most defence innovators stall between a promising TRL and a deployable system, Inertia closes that gap - in Canada, at pace. The Canadian defence and dual-use robotics sector is moving from the demonstration phase into the production phase. The companies that win the next five years will not be the ones with the most impressive concept vehicles. They will be the ones that can produce reliably, iterate quickly, and build hardware that holds together under real operational conditions. If that is the transition you are navigating, we would be glad to talk. .single__blog__content .img-right{ float:right; margin-left:15px; margin-bottom:10px; } @media screen and (max-width: 768px) { .single__blog__content .img-right{ float:none; margin-left:0px; margin-bottom:10px; margin-top:15px; } }

Jun 23, 2026

1139 Views

We Design, Build, and Ship Complex Hardware That Holds Up in the Real World