Developing and deploying IoT-enabled  products requires changes to the embedded software that is shipped with the device and to the development process.

In the past, embedded development has primarily focused on implementing features required for the device to operate functionally on the OEM's custom hardware and scant thought has been given to what is needed to add IoT capability and security to the device. With IoT-enabled devices the tables are turned as device services are as important as device features because it is the services that drive the IoT benefits to the OEM.

Developers have to design for maintenance to ease maintenance services with modular components. This implies selecting a component-driven software development environment and system runtime environment that support modular software construction and update.

For example, designing for over-the-air software update mechanisms (like Android smartphone updates) changes what support software you need in the device, especially if you want failsafe and secure updates. Issues arise like how you handle system updates versus application updates and whether updates can be done on running systems or only when the system is not operational. What do you do if the update fails and how do you make sure the update file is secure and the update operation is done securely?  These operations require extensive support from the underlying operating system be it an RTOS or Embedded Linux.

The same issues apply to any kind of software update including critical security updates and bug-fixes depending on whether the patch/fix is a system or application update.

It is very important for IoT devices to remain connected and running in an IoT ecosystem otherwise valuable device data and BI can be lost. If the OEM is designing with a SoC device that supports Memory Protection Unit (MPU) such as provided by ARM Cortex-M architectures or a Memory Management Unit (MMU) such as provided by ARM Cortex-A architectures, it is highly desirable that one task cannot take down the system or interfere with other tasks. For this you need an RTOS that supports MPU and MMU operations to protect the system kernel from erroneous tasks. Nucleus RTOS supports both MPU and MMU-based memory protection schemes based on ARM architectures, and Mentor Embedded Linux supports MMU operations on ARM Cortex-A architectures.

Device safety and availability for IoT operations are both important factors when selecting your runtime platforms.

When an IoT device is deployed and initially switched on, it typically has to be provisioned into the device management system and configured for correct operation; this process could include downloading and installing the exact software features the customer ordered into the device. The same process would apply if the OEM wants to be able to sell new software features to its customers as add-ons - the customer orders the new feature which is then downloaded and installed into a running system. Again the RTOS/OS has to have the ability to dynamically download and install new "processes" into running systems to add the additional feature set.

More and more OEMs are reporting their custom hardware is becoming a commodity and they have to differentiate using software. Being able to quickly deploy new software features to a test set of customers and get immediate insights into how these new features are operating in real-world situations offers OEMs a major competitive edge in terms of ability to quickly launch new products and reduce time-to-revenue.

The types of device (telemetry) data being collected and ingested by the IoT Platform will change as individual OEM products evolve and for different OEM products. Do you collect and communicate every possible device datapoint of interest, which will cause network congestion and additional data storage costs, and add data filters at key points? Can telemetry data "scenarios" be easily accomodated to switch device monitored data points on/off to tune overall system performance and value to the business?