The demands of an increasingly data-driven world mean that your IoT device will require robust and reliable software. For that, you’ll need a real-time operating system (RTOS).
As discussed in Part 2: The Thing, at Micrium we think of IoT devices as embedded systems that transmit and receive information over a network. And while many embedded systems manage well with less sophisticated software, networked devices require more capable systems.
The software for your IoT device must be:
Linux certainly is a robust, developer-friendly OS that has been getting attention as a platform for IoT devices. Linux has matured into a mainstream embedded operating system for many applications.
Yet Linux has a disadvantage when compared to a real-time operating system: Memory footprint. Even though Linux can be trimmed down by removing tools and system services that are not needed in embedded systems, it still remains a large piece of software. It simply will not run on 8 or 16-bit MCUs, and even many newer 32-bit MCUs do not have enough onboard RAM for the Linux kernel. The ARM Cortex-M series is a good example: There are hundreds of different MCUs that are based on the popular Cortex-M architecture, which typically have only a few hundred kilobytes of onboard memory. Linux will never run on these chips.
Linux will certainly have many uses in embedded devices, particularly ones that provide graphically rich user interfaces. But there are thousands of applications for which Linux is ill suited.
The software requirements for industrial and consumer IoT devices can differ quite a bit. Although they might share a common kernel and low-level services, the middleware required by their applications can be radically different.
In the illustration above, on the left we see a software stack for an industrial IoT device, such as a wireless sensor node. This is a low-power, low-cost device that may run entirely on battery. Such a device might typically use a Cortex M0 or Cortex M3/M4 MCU. It would make use of a highly efficient network protocol such as 6LoWPAN to reduce transmission time and save power. And it would communicate over short distances wirelessly using Bluetooth or low-power Wi-Fi, or else use Ethernet.
On the right, we see a software stack for a consumer IoT device. The software requirements for this device are much greater. It might need a Java VM, and may well make use of a vertical market protocol such as AllSeen, HomePlug/HomeGrid, Continua Alliance, or 2net. Such a device typically might use a Cortex-M3/M4 or a Cortex-A processor.
These requirements will drive your choice of RTOS. You don’t want to be in the position of having your choice of platform dictating the functionality of your device.
A flexible, scalable RTOS can help you increase your return on investment, cut development costs, and reduce your time to market.
Although embedded systems have historically been built entirely around 8 and 16-bit MCUs, the price of 32-bit MCUs has been dropping rapidly, making them commodity products. And so their popularity for embedded devices has skyrocketed.
A common engineering solution for networked embedded systems is to use two processors in the device. In this arrangement, an 8 or 16-bit MCU is used for the sensor or actuator, while a 32-bit processor is used for the network interface. That second processor runs a real-time operating system (RTOS).
Sales of 32-bit MCUs have exploded in the last several years, and have become the largest segment of the MCU market. The 32-bit MCU segment alone is expected to grow to $19.2 billion by 2017.
IoT devices will still contain a mixture of small and large MCUs for years to come. A scalable RTOS that runs on a variety of 16 and 32-bit MCUs will allow you to meet tight memory requirements and reduce processor demands, saving you money.
Your IoT device will require a modular operating system that separates the core kernel from middleware, protocols, and applications. The reasons are ease of development, and keeping the memory footprint of the software to a minimum.
Using a modular RTOS simplifies your development process, especially if you are developing a family of devices with different capabilities. Relying on a common core allows the entire family of devices to share a common code base, while each device is customized with only the middleware and protocol stacks required by the application.
This approach also allows for a smaller memory footprint in your device. Unlike a monolithic operating system that bundles an entire suite of software together, a modular RTOS allows you to tailor the embedded software for your device, requiring less RAM and flash memory, reducing your costs.
Network connectivity is essential to the Internet of Things. Whether we are talking about wireless sensor nodes in a factory, or networked medical devices in a hospital, the industry now expects embedded devices to be connected to each other, and to communicate with corporate or public networks.
Your RTOS of choice needs to support communications standards and protocols such as IEE 802.15.4, Wi-Fi, and Bluetooth. Your device must be able to connect to IP networks using bandwidth-efficient protocols such as 6LoWPAN.
An RTOS will allow you to select the specific protocol stacks you need, saving memory on the device, and reducing your costs. And it can help you retrofit existing devices with new connectivity options without reworking the core of your embedded software.
Many IoT systems will be deployed in safety-critical environments, or in locations where repair and replacement are difficult. IoT devices will need to be faultlessly reliable.
You may need your RTOS to have safety-critical certification. This is vital in order to demonstrate the reliability and safety of your device. Certifications that you may need include:
If you are building your product for use in a safety-critical environment, using software that is already certified can reduce certification time for your device, and reduce costs. Every part of your device will require certification and extensive documentation. Validation suites and certification kits, typically available from third parties, provide thousands of pages of documentation that you would have to otherwise create for your product.
Even if you don’t require certification for your device, knowing that the OS running within it has been certified can provide confidence and peace of mind that your product will perform reliably.