Claiming Software Development in Hardware Projects

The intersection of hardware and software—such as Internet of Things (IoT) devices, robotics, and industrial automation—produces some of the strongest SR&ED claims. However, correctly separating the hardware R&D from the software R&D is critical for a smooth audit.

The Hardware-Software Barrier

A common mistake companies make is assuming that because the hardware is experimental, the software controlling it must also be experimental. This is not necessarily true.

If you invent a revolutionary new robotic arm (hardware SR&ED), but the software required to move that arm uses standard, well-documented kinematics libraries that work exactly as expected on the first try, the software development is not SR&ED. It is simply routine programming supporting an experimental device.

When Software Becomes SR&ED in a Hardware Context

Software development only qualifies for SR&ED in a hardware context when the software itself faces a technological uncertainty. This frequently occurs in the following areas:

1. Unique Hardware Constraints

If the hardware device has severe limitations (e.g., extremely low power, minimal RAM, unreliable network connectivity), writing software for it might require novel solutions. Example: Developing a custom, hyper-compressed communication protocol because standard TCP/IP overhead drains the IoT device's battery in hours instead of years.

2. Sensor Fusion and Signal Processing

Hardware sensors (lidar, accelerometers, optical) rarely output perfect data. If standard noise-reduction algorithms fail in your specific application environment, the experimental development of custom signal processing algorithms to filter and interpret the raw sensor data is classic SR&ED.

3. Timing and Latency

In automation and robotics, software must often act in hard real-time. If standard operating systems or drivers introduce unacceptable latency that threatens the physical operation of the machine, writing custom, low-level drivers or rewriting the OS kernel scheduler constitutes SR&ED.

Structuring the Claim

When both hardware and software involve technological uncertainties, it is generally safer to structure them as separate SR&ED projects on your T661 form (e.g., "Project A: Robotic Arm Actuation R&D" and "Project B: Real-Time Constraint Software Engine R&D").

This allows the CRA to review the mechanical engineering separately from the software engineering, ensuring that a weakness in one area does not jeopardize the entire claim.