Our framework for rapid hardware-software development

The challenge of agile hardware-software development

When it comes to rapid prototyping, we usually don't talk about simple “paper prototypes” but complex hardware-software systems. These systems have many moving parts: Sensors, actuators, CPUs, interfaces, and so on. To test new product ideas, we simply piece together what it takes to bring the idea to life. If another component is added to the bread board at a later point, we often have to make adjustments to the software layers to make the new functionality available in the user interface.

If a new feauture that has to communicate with the hardware is added to the user interface, code must be adapted on many levels and communication channels. This naturally leads to unintentional errors, an increased need for team coordination and ultimately, what is known as spagetti code and shotgun surgery among developers.

These are the layers we usually have to deal with:

• User Interface
• Process Communication
• High Level Logic
• Submodules
• Hardware Controls
• Hardware

A framework for rapid hardware-software development

To enable our developers to focus on what to implement and less on how to do it, we have defined a ruleset that allows for a uniform architecture and reduces the cognitive load of programming.

The synthesis of rules based on coding experience is a common process in software development, which led to magic formulas like KISS (Keep It Simple, Stupid), DRY (Don't Repeat Yourself), YAGNI (You Aren't Gonna Need It), SOC (Separation of Concerns), or SOLID (Separation of Concerns).

Our own magic formula for fast, straightforward hardware-software development consists of the following set of rules:

• We keep the number of programming languages and external libraries low and use synergy effects. For example, we often work with Typescript in frontend and backend, resulting in shared type definitions and similar setup and configuration.
• We use uniform templates for modules with clearly defined responsibilities and predefined methods.
• Standards for communication channels using a consistent convention, e.g.:

[GET]  /module/<module_name>/<request>
[POST] /module/<module_name>/<command>

[WS]   /subscribe/<module_name>/<event>
[WS]   /unsubscribe/<module_name>/<event>

• Automatic publish/subscribe mechanisms for commands, requests and events eliminate the need for deep wiring of new modules. Through a central registry modules can be added or exchanged quickly.
• Framework code is independent of external libraries and not mandatory. If necessary, developers can switch to other languages and structures.

Loosely based on Conway's Law, this architecture is also a reflection of our team topology, in which we work best. The combination of design patterns, lean code templates, and an agile team structure provides us with an optimal foundation for successful hardware-software development.

What does this mean in detail in a project?

We already applied this approach to our Minimic. The framework made it easy to experiment with many different hardware features and forms of representation to find the ideal fit:

• 3 different computing units
• 4 different cameras
• 3 different machine learning backends
• Cloud-based vs. local data storage
• Countless iterations of the user interface

Such experiments are essential in early development phases for the validation of functionality and use cases. By using our framework, we were able to maintain a stable code quality despite this exploratory approach and reduce about 60% of the code for commands, requests and signals.

Complexity by simplicity

The hardware products of our customers are complex arrangements of sensors, actuators, user interfaces and special algorithms, which constantly change in the course of development. The challenge is to master the balancing act between customer needs, an ideal infrastructure and innovative functionality. Furthermore excellent products hide the high degree of complexity from its users and provide an intuitive way of human-machine interaction. Only if we take all this into account in the experimental development phases, we gain valuable insights early.

The definition of best practices, simple building blocks and proven communication channels enables us to react quickly and dynamically to changes. A consistent language convention and focus on simplicity makes discussions about processes and features easier, accelerates the ramp-up phase of new developers and reduces the documentation effort.