Modularity and standardization represent two major strategies for dealing with complexity. If a given function can be contained within a defined physical or abstract (read: software) space and be defined by its interfaces and their functions, it and others can be used to build very large systems, which remain manageable and understandable. The internet of things provides a perfect example. It is almost infinitely complex yet remains accessible to average users and can be expanded with innovative additions almost beyond limit.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.
While IoT can appear daunting in its variety and complexity, it also displays a structure and modularity that make it quite comprehensible. This structure and modularity also greatly facilitates the development of systems and the software that controls them, making the development process quite manageable if approached with the same ideas of modularity, structure, compatibility and flexibility.
IoT consists of four major components: the low-level sensors and actuators, the edge routers or gateway devices, the internet itself, and the cloud. The actual ways these components interact and the amount of software needed by each can vary greatly depending on the needs of the application (Figure 1).
Figure 1: The four major levels of the internet of things. An RTOS with a standard POSIX API can greatly enhance adaptability across the different levels.
For example, the first two levels — the edge devices and the gateway devices — are the points where data collection and control actually take place. These can be small sensors and actuators or private networks of intelligent control devices, all of which eventually link to the internet and the cloud. These are also typically the layers at which we find embedded devices linked in what were previously known as machine-to-machine configurations. So multiple sensors and actuators can be located in a single machine which is itself at the edge of the system, and they can either be accessible from outside via IP addresses or controlled by software internal to that machine, which is itself connected to the edge router. Complexity is no stranger to connected embedded devices, and the use of modularity and standardization can be indispensable at this level as well. And modularity and standardization can be applied to the development process as well, based on the structure of the system under development.
It is important to think of the internet, the systems that compose it and their components as a modular structure, but also to approach the process of development as a modular activity that can be assigned to specific teams and individuals who can work out a solution to their assigned component within the context of defined interfaces with other components and through communication with their own team members and the members of other cooperating teams. Fortunately, there are development methodologies that can act as a guide for exactly this approach. This also applies to the very earliest stages of development at what can be called the “platform.”
A platform is nothing esoteric but consists of ready-made components that can be assembled into a focused functional environment for the addition of unique functionality that represents the actual value of the device to the customer. Typically, a platform for embedded devices would consist of a selected microcontroller or microprocessor along with an operating system that could supply the needed functions, communication protocols and driver support for both on- and off-chip peripherals. The hardware interfaces as well as the software interfaces of the operating system should all adhere to well-known standards. Developers can then start at that point to add value in terms of the desired application and its various functions along with adding needed OS modules, communication protocols, off-chip peripherals and their drivers (Figure 2).
Figure 2: This single-board development platform from Freescale includes an ARM Cortex-M4 processor with a set of on-chip peripherals and interfaces that allow connection of further peripherals. Supplied with a configurable Unison RTOS package, it is ready for the developer to set up for his target system’s needs and begin almost immediately developing a specific application.
The characteristics of the selected operating system are important. It is a big advantage if it works with a well-known API such as POSIX for two reasons. First, the POSIX API, being similar to Linux, is familiar to a large number of developers. Second, there is a great deal of POSIX-compatible third-party open-source software available that could be adaptable to the needs of the system under development. A selected RTOS should also support a good selection of different MCU and MPU architectures to make it easier for developers who have already selected one for other projects to adapt that RTOS. And for each supported architecture, the RTOS should support the different members of a device family, which is important for future upgrades, product versions or families of products a customer may wish to build.
Another issue is that while there may be myriad software components for different application needs, only a few of these tend to be selected for a given project. They can include the various communication protocols as well as functional modules like storage system, floating point math or video modules. Does this RTOS have all the components you’ll need for your project? If not, will the ones you do find work with this kernel? You’d have to test them — and at what cost in time and cash? The same if you write your own. The more pretested and documented modules that come with the RTOS, the more confidence you have that you can use them without thorough testing and qualification, which can result in huge savings of time and money. That means less time spent in searching for and qualifying open-source components. You can be sure the RTOS has all (or most of) the components you need before committing to it.
From components to lean process
All these issues of compatibility and qualification involve more than just the ability to put the pieces together. They form the basis of a perception of the project and a process that can expand to influence an entire organization. The approach of using a platform not only forms the foundation for a design, it also provides the basis for what is known as lean product design. Pioneered by Toyota, the lean development approach combines the use of a standards-based platform of necessary software components along with integrated work teams made up of persons with individual complementary competences. These team members communicate constantly with one another, yet plan their own work and work their own plans. The same applies to the different work teams, each of which has its own assignment, or “module,” to work on, but which also communicate with the other work teams. Since these modules share standard interfaces, they can be assembled into a complete system toward the end of the project as in the automotive example in Figure 3.
Figure 3: In lean product development different groups 1-3 work on progressively more advanced engines and brake systems. At the last possible time for a given model year, the technology insertion happens, creating progressive improvement and technology insertion as early as possible. Versions not used in a current model year may be used in subsequent years or abandoned; for example, Engine2 group’s engine could be used on the basic model the following year. The various components are standardized for mix and match options making the chassis the platform.
The lean approach with its platform-based modularity and compatibility therefore lends itself easily to adaptability. Designs are almost never static, but must react to customer demands for enhancements and added features. As noted, a line of microcontrollers and microprocessors with common hardware interfaces should also offer varying features to substantially enhance adaptability. With such an approach, core MCUs or MPUs can be swapped out and new layouts achieved quickly and easily, knowing that the application software will run without change and that device drivers are tested, proven and ready to go. The ability to reduce power with a new part, increase memory, increase performance or add new connectivity, focusing only on the part of the system that needs to change rather than a complete new design reduces time to market and total cost of ownership.
It becomes apparent that a key design decision lies not only in the choice of an RTOS and a processor, but more importantly in the selection of a platform that combines the two with dimensions for scalability, adaptability and expandability for the long haul. This consists of a processor family (or families) that have those characteristics along with an RTOS with similar abilities to adapt to the needs of the target system along with the ability to adapt and expand smoothly with future requirements.
In addition to standard functions like a file system, communication protocols, wireless support, video support and more, there should be robust support for security. Security is an issue that spans from the lowest-level device driver all the way up through the coding standards for the application. Just as a solid hardware/software platform is the foundation for the device design, it is also the base rock for security. It affects both the selection of add-on components as well as the basic design of the RTOS.
An RTOS supplied with a complement of security components that are prequalified and can be selectively attached and integrated into the OS image can go a great distance toward putting together a secure system that can also securely interact with both the elements within its networked environment and outside systems with which it must communicate. In terms of communication, this includes Transport Layer Security (TLS), which replaces Secure Socket Layer (SSL), IPSec/VPN, secure wireless links and encryption/decryption, among others. Other inherent characteristics of a securable RTOS include the combination of a secure boot service combined with secure remote field service with encryption and automatic fallback to the original state if an unsuccessful attempt or an attack is detected.
We have already noted a number of characteristics that come more easily with a platform approach, including a lean process, adaptability and security. Others include safety, which depends on security as well as functional safeguards. Two main features of real-time systems that assist with safety are determinism and instant-on with emergency stop (estop). Determinism provides predictability that can be tested and estop allows a system to be stopped and restarted quickly to deal with emergencies.
With IoT, we have a new set of criteria for connected systems. With a very broad set of sensors and sensors used in a much broader set of systems, connectivity has a far broader meaning. Wireless means any subset of wireless modulation schemes and the protocols used have also grown substantially. They now include wireless: Wi-Fi, Wi-Fi mesh, Bluetooth Classic and Bluetooth Smart/Smart Ready, 802.15.4 with 6LoWPAN, 3G, 4G and UHF. The wireline connectivity solutions are also extensive. Serial I/O, both asynchronous and synchronous, SPI, SDIO, I2C, I2S, USB, CAN and internet connectivity are expected to be tried, proven and tested.
To make systems that are complete, additional protocols should be available to cover control and connection of mechanical, memory, display, camera and sensor systems as well as advanced storage devices like flash, RAM and MMC interfaces. And, of course, these systems will all connect to the cloud, often passing large amounts of data.
The admonition to “start with a firm foundation” applies to the design of connected embedded systems as surely as it does to the construction trade. Starting with a modular, standards-based, yet adaptable and configurable combination of RTOS and processor and one that is focused on future expansion and enhancement can be the key to success. This applies in terms of time to market, initial development expenses maintainability and the ability to meet future customer needs.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.
