Why We Build Our Own Hardware

When I joined Tulip 5 years ago, the startup looked very much like what you might imagine a tech startup looks like. We were a group of engineers, researchers, and hackers just out of grad school with an MVP and a few customers who saw the value of what we were building.

A lot has changed since then. But just as much hasn’t.

In the early days at Tulip, we set out a vision for the company that we stick to today. We envisioned a highly configurable manufacturing platform priced so that every manufacturer could benefit.

For our platform to truly work for all manufacturers over time, we needed to build hardware that supported everything we imagined for the platform. So from the beginning, we’ve been as invested in hardware as software.

Five years ago, truly human-centered manufacturing technology didn’t exist. IoT didn’t have a physical form. So we built it.

Our decision to make hardware a fundamental part of our company was motivated by a number of factors.

First: We could. The first folks to join Tulip all had maker/hacker roots. So we had the technical expertise necessary to build hardware robust enough to function in industrial contexts. We were all young enough to see an opportunity, and confident enough to ignore all of the reasons people told us it would be hard.

Second: We quickly realized that there would be no way to make good on our vision for IoT in manufacturing without building hardware that was resilient, reliable, and extensible. If all things worth doing are worth doing right, the only way to build Tulip right was to fully own every aspect of the product design and experience. That meant putting our full capabilities behind hardware from day one.

Perhaps more importantly, we were working with a set of observations about the IoT market. Here’s what we saw at the time:

1. ARM-based, mobile-grade silicon was lowering the cost of computing around the world. Except in factories.
2. There were no affordably priced industrial ARM targets available to manufacturers. At the time, a few large vendors priced their offerings for well-heeled, large-scale manufacturers. This made it impossible for most manufacturers to participate.
3. Manufacturing is hard on hardware. Component failure is not an option. We couldn’t find any extant ARM boards that could hold up in industrial contexts.
4. There were few products that integrated Industrial-strength GPIO/ADC to save wiring cost and time.
5. Vendors didn’t understand what manufacturers actually needed from IoT hardware. Fewer still understood the importance of integrating systems on a chip (SoC), peripheral integrated chips (IC), and mainline Linux kernels into devices and gateways.
6. Existing products didn’t give manufacturers a customizable experience. Often, engineers had to contort their operations to conform to their new technology.

So from this list of observations, we put together a set of axioms to guide us:

1. The barrier to entry for adopting IoT should not be cost. No manufacturer should be priced out of innovation.
2. If you don’t control your hardware, you don’t control your future. This is as true for us as it is for the manufacturers who use 3rd party products. Vendors can change, phase out, or cancel support to their products at any time. What will happen to your processes when they do?
3. Hardware and software are symbiotic. Building a better, more complete product will require embracing a dialogue between hardware and software from the start.
4. Hardware is a vessel for carrying our vision of IoT from the lab to the shop floor. It’s a way of multiplying the value of our core software offering.
5. For IoT to work in the real world, it has to be self-serve. You don’t want to call a systems integrator every time you use your Roomba in new a room or make an adjustment to your smart thermostat. Why should factory life be any different?
6. Building hardware requires understanding your customer. You need to understand their pain points, their needs, and their processes. You have to take a manufacturer’s needs and distill them into a physical device as the laws of physics permit. Designing functional hardware solutions takes a very different sensibility than software. So it’s better to be proactive than reactive.

The logical conclusion of these beliefs was that Tulip needed to be a hardware company.

We needed to be architects of our own future, from the ground to the cloud.

Building an IoT product is complex. That complexity cuts across the tech stack. You can’t build an IoT product without dealing with both hardware and software. You can’t build an IoT platform without doing the same.

Our first hardware offering, the Tulip Gateway, embodied this ideal.

The Gateway was built on a low-cost ARM board, and included all of the ADC, GPIO, I/O integrations we wanted in an IoT product. With the Gateway, manufacturers could connect sensors and devices, convert machine protocols, and interface with other Tulip hardware like our Light Kit and break beams.

To make this work, we built our own operating system using Yocto (an open-source, hardware-agnostic tool for building Linux-based systems for IoT). We wrote our own runtime to help facilitate a larger edge logic.

So the first product we shipped was a fully functional IoT Gateway, a ground-up device with home-grown hardware, software, and firmware.

All of our releases since have extended this philosophy. With each iteration of the Gateway, we’ve been able to lower the cost and extend the functionality. We were able to do this precisely because we control the product in every dimension.

For us, these decisions made sense from operational and technological perspectives. Engineering doesn’t always scale linearly. Building hardware was a way to introduce predictability into a chaotic system.

But more importantly, building our own hardware was a way of giving our customers exactly what they needed.

There are some concrete takeaways for Tulip customers.

1. Our hardware will always support our software — Every new feature to our cloud platform will always be compatible with our hardware in perpetuity. The functionality of our platform won’t be subject to the vicissitudes of the market or the caprices of vendors
2. Our platform is hardware agnostic — Building things this way has enabled us to design a hardware-agnostic platform as a service offering. We know that not all manufacturers will want or need our hardware. But because we have that expertise in physical systems, we’ve been able to design software that will work on whatever hardware you use in your factory.
3. Configurability — We built Tulip’s OS and runtime knowing that manufacturers would need to open up the hood and make changes to fit their operations. We wanted them to be able to do this without needing to enlist systems integrators and experts for every update, and to enable them to make changes as frequently as production required. Building a full-stack hardware product was the only way to ensure our platform was truly self-serve.
4. We can offer hardware at a price that doesn’t exist anywhere else in the manufacturing market. With more functionality than exists anywhere else on the market. This point speaks for itself.

While this last point might not require any elaboration, I would like to provide some context.

This month we’re releasing the Tulip Edge Machine Connect, an edge device that represents the next logical extension of our hardware philosophy. This is the first device that runs our OS on extant hardware.

This device can be used as a protocol converter, to connect sensors and machines, and as a means of transmitting information from a variety of sources to a central location.

Tulip edge devices will be offered at price points unheard of for industrial IoT hardware. But we can do it, so we are.

We’re realizing the vision we outlined five years ago. Now, low-cost, shop floor-ready hardware is available to all manufacturers.

No more future tense.