Most connected products don’t fail because of hardware. They fail months after launch, when updates slow down, defects accumulate, or a new feature breaks three others.
And almost always, the root cause traces back to a decision made early in development: What software foundation was the device built on?
Bare-metal firmware, RTOS, or embedded Linux—the software foundation determines how a product behaves after customers start using it. That’s when reliability, scalability, and maintainability become business problems instead of technical ones.
The Illusion of a “Technical” Decision
Early operating system (OS) decisions are often treated as implementation details. Teams choose software foundations to optimize for boot speed, memory usage, or what engineers already know.
But connected products rarely stay static. Features grow. Connectivity expands. Security expectations change. Remote updates become mandatory. What looked like a technical shortcut can become a long-term operational constraint.
So, OS choice is a foundational engineering decision that shapes product quality long after release.
Three Paths: Three Product Futures
1. Embedded Linux: Building a Device That Can Grow
In the embedded world, choosing general-purpose OS usually means choosing Linux. Linux turns an embedded device into a scalable computing platform. Networking, security tooling, and modern development workflows already exist.
This dramatically accelerates innovation—if the organization is ready to operate a complex system. And that is a crucial if. Complexity means higher cost, not just in hardware, but in design and maintenance as well.
At Orion, we have developed all kinds of Linux-based devices from automotive IVI systems to fleet management tracking devices, from smart home gateways to IP phones. And in all cases, it was always a different kind of Linux: Automotive Grade Linux, Red Hat, minimalistic Yocto builds. You can even place Android-based devices in this category.
Choosing Linux as your OS is just a start. You also need to choose the right kind of Linux, and then you need to configure it correctly, and then you need to maintain it. Linux demands discipline: system integration, maintenance pipelines, and long-term ownership. Without them, teams inherit complexity they aren’t prepared to manage.
2. RTOS: Predictability With Structure
RTOS platforms are designed for products that must be reliable, responsive, and resource-efficient, without the operational weight of a full Linux system. Their defining advantage is deterministic behavior: critical tasks execute within known timing boundaries, which is essential for industrial, medical, automotive, and IoT devices.
The disadvantage: Linux usually has more options and features. With RTOS, you need to develop more from scratch or make do with what the system gives you.
Unlike bare-metal systems, RTOS environments introduce scheduling, synchronization, and abstraction layers that make growing complexity manageable. Unlike Linux, they remain lightweight enough for constrained hardware.
Today, several RTOS ecosystems dominate embedded development:
- FreeRTOS has become the industry baseline for microcontroller-based devices. Its simplicity, small footprint, and broad vendor support make it attractive for connected sensors, gateways, and consumer IoT products, and is often adopted as a first step away from bare-metal development. At, Orion, we’ve used FreeRTOS to develop multiple products: smart meters, cameras, HVAC controllers, even automotive devices. It runs on practically every MCU, but its limited feature set can increase initial development effort.
- Zephyr OS represents a newer generation of RTOS design. Backed by a strong open-source community, it emphasizes modularity, security features, and modern development practices. Zephyr integrates well with contemporary tooling, connectivity stacks, and long-term maintainability requirements—making it increasingly popular for scalable IoT platforms. Orion regularly develops Zephyr‑based solutions across IoT, fleet management, and traffic control projects, and we actively contribute drivers and subsystems to the open‑source community.
The world of RTOS is not limited to these two systems. In the Automotive world, QNX is a popular choice, and our team developed several IVIs and head units based on it. In the telecom and IP telephony world, we often work with VxVorks. There is also NuttX, ThreadX (Azure RTOS), Keil, and Integrity. Choosing the right one requires experience, but can be crucial for the long-term success of your project.
3. Bare-Metal: Maximum Control, Minimum Margin for Change
Bare-metal development delivers unmatched efficiency and hardware control. For narrowly scoped devices, it can be the right choice. But complexity rarely stays small.
As connectivity, updates, or analytics appear, teams start rebuilding OS-like capabilities themselves — scheduling, abstraction layers, diagnostics — often without realizing it. Still, if your device is really constraint on BOM cost or power consumption, doing everything without any “real” OS might be the best and only option. And it’s not limited to something simplistic – like a sensor or detector. Our team once developed firmware for a smart buoy, and when your device is supposed to be floating a few miles offshore in the ocean the power efficiency of bare-metal device is practically a must.
Your Path to Connected Product Success
For connected products, each software foundation carries long‑term implications for cost, maintenance, scalability, and reliability.
There is no universally correct choice. The right OS is the one that aligns with your product’s lifecycle, operational model, and business goals. Making that decision deliberately, with a clear understanding of future trade‑offs, is one of the most important steps in building a connected product that lasts.
For decades, Orion has been helping enterprises build what matters in connected product engineering. Learn more about our Engineering offerings.
This means developers receive precise, actionable feedback, while senior engineers focus on complex logic and design decisions.
