POSIX RTOS attacks SWaP and time-to-deployment issues

Story

June 08, 2010

Choosing a standard set of SoC Microcontroller Unit (MCU)-based hardware and a standards-based RTOS opens the door to fast and flexible development of tools and sensors for use in the battlefield. Millions of lines of Linux code are available, and now they can be applied to help warfighters quickly and easily – and without significant SWaP requirements. This is a lean product development approach that will minimize Total Cost of Ownership (TCO).

The key to reducing SWaP for portable electronics is:

• Minimizing total parts count
• Building with die instead of packaged components
• Utilizing multichip modules
• Exploiting consumer and automotive parts
• Exploiting IP
• Utilizing a POSIX-based RTOS

Using this approach, existing applications can be quickly shrunk onto COTS SoC MCUs, saving money, time, power, and weight.

How can a POSIX RTOS make such a difference to the hardware design? By allowing the use of SoC MCUs to replace power-hungry discrete implementations, electronics’ operating life can be increased significantly while reducing size, weight, power, and cost. At the same time, the POSIX compatibility allows rapid injection of standard applications into devices, ensuring that software capabilities are not compromised. This discussion explores how modern MCUs and power electronics increase SWaP, and where software and standards-based RTOSs fit in. An ultra-tiny POSIX RTOS example is also presented.

Reducing power and weight increases survival

A few years ago, MCUs were tiny eight-bit machines with very limited memory that were clocked at a few MHz. Today, that has all changed. SoC MCUs run up to 200 MHz and have more than 2 MB of flash, 128 KB of RAM, and all peripherals onboard. High-performance floating-point hardware is available on SoC MCUs, speeding DSP applications, video processing, and automatic detection algorithms. The vastly increased computing power of these devices in tiny packages allows battlefield computers to shrink from notebook sizes to handheld devices with corresponding savings in weight.

The power consumption of MCUs has also dropped drastically. As little as one year ago, common thinking would have an 8-bit processor consuming less power than a 32-bit CPU. Today, using a 32-bit processor to replace the 8-bit processor and powering the processor down when it is idle is more effective. Today’s 32-bit MCUs use a stunning 85 microwatts/MHz. On the battlefield, this means increased operational time, greater mobility, and less weight.

Power electronics that enable MCUs have also shown significant improvement. Today Field Effect Transistors (FETs) run at 900 V, providing better switching characteristics at higher voltages and reducing the power lost during switching compared to Insulated Gate Bipolar Transistors (IGBTs). Using soft switching techniques to minimize IGBT losses (1/3 factor) makes this trade-off very application dependent. High-voltage FETs offer fewer components while IGBTs offer smaller packages. Either approach means less weight, improved reliability, and greater mobility – increasing both effectiveness and survival.

Software and standards-based RTOSs are key

Previously, MCU software was 20 percent of the problem, and the main issues were getting the hardware to work effectively. Now, 80 percent of the problem in developing an MCU system is software. The SoC MCU represents a complete system on a chip with analog and digital I/O, file systems and databases, network connectivity, and user interfaces. Further complexity comes as these MCUs are networked together to solve larger problems using less power, with less weight and greater design reliability. A portable solar converter, for example, would have 1/6 of the power consumption, 1/10 of the weight, and greater than six times the reliability for the control electronics.

The approach used to implement the software for these systems is also changing. The four approaches that users typically select are:

• Single loop of control or timer-based scheduler
• Small scheduling kernel
• RTOS (kernel plus I/O)
• Standards-based RTOS (POSIX)

The confusing part for designers is that each of these approaches can be effective depending on how complex the problem is. By minimizing the TCO for the software development and maintenance over the product line’s lifetime, substantial savings are generated that are not readily apparent to traditional engineers. Figure 1 shows these four approaches and when they are most effectively used.

 

Figure 1: A single loop of control or a simple scheduler was acceptable in the past; however, with increased complexity, MCU systems require standards-based RTOS products with commercial support.

(Click graphic to zoom by 1.9x)

 

If systems are trivial, such as those that monitor a single analog value and flag an out-of-range condition, the old-school single loop of control is best. As complexity grows, though, the advantages of having a separate stack for each thread, thread priorities, standard APIs, and a standard I/O model grows. For complex applications, a standards-based RTOS is the only way to effectively solve the problem. Proprietary kernels require invention of I/O models and driver development while complete proprietary RTOS solutions eliminate software reuse, cause training problems, slow field deployment, and can limit real-time response.

An alternative approach to a proprietary RTOS is to utilize a POSIX-based RTOS. However, many of the benefits of a POSIX RTOS are hidden. Application portability, elimination of training, real-time response, and reduced time to deployment in theater are required to achieve the optimum savings over the life cycle of a product line. POSIX delivers these variables, while proprietary RTOSs and other standards do not.

As developers of military systems, we must be cognizant of the immediate demands of warfighters in the field by choosing a POSIX platform application that can be immediately and easily adapted to fielded systems. On the surface, adding a podcast feature to a military radio using off-the-shelf software is a nonessential feature; however, if it is used to listen to messages from families far away, its morale boost could be substantial. Being able to quickly add features to systems using off-the-shelf software is a key feature to meet new battlefield demands.

POSIX and Linux-compatible RTOSs are optimal

As mentioned, use of a standards-based RTOS is optimal for other than nontrivial systems. By making the selected standard POSIX, substantially more benefits are accrued to the user by virtue of available applications, number of knowledgeable programmers, and training savings. The POSIX-based, Linux-compatible, 32-bit ultra tiny Unison POSIX RTOS (Figure 2), for example, utilizes the same architectural design as its nano-kernel 8/16-bit version: DSPnano.

 

Figure 2: The ultra-tiny Unison and nano-kernel DSPnano offer a nano-kernel architecture with an ultra-tiny memory footprint, POSIX APIs, and a modular structure.

(Click graphic to zoom by 1.9x)

 

By moving to a nano-kernel architecture, the size of the system is kept very small. Unlike other Linux variants, the tiny POSIX RTOS and its nano-kernel version can run in 2 KB RAM and 10 KB flash for an entire application including I/O. As more features are used, the kernel grows. The modularity of the nano-kernel architecture contributes substantially to the reduction in size of the system. In addition, elimination of memory management support, lightning fast interrupt handling, and embedded safety features make the POSIX RTOS highly effective on SoC MCU architectures. With its tiny memory footprint and POSIX APIs, the POSIX RTOS allows many applications to run on tiny, low-power, and low-weight SoC MCU systems where it was not possible before.

Thus, the complexity of the system is significantly reduced using the nano-kernel with a layered POSIX and Linux-compatible I/O layer in comparison to any Linux alternatives. Any engineer can understand the basic kernel and I/O model in a few minutes due to its modular architecture and isolated interfaces. Servers (or drivers plus software glue) can be added for device specific uses quickly and easily. Additionally, if a specific algorithm has a limitation in theater, adaptation can be fast and easy.

Flexible devices save lives

Using lean product development for military hardware based on SoC MCU technologies, new power technologies, and an ultra-tiny, POSIX-based RTOS or nano-kernel RTOS increases flexibility and reduces total cost of ownership. This benefits the manufacturer and the military. Additionally, the ability to adapt an RTOS quickly in theater – coupled with lowered power consumption, smaller sizes, and reduced weight – maximizes survivability for the troops in the field.

Kim Rowe is CTO and founder of RoweBots Research Inc. and has more than 30 years of experience in business management and systems engineering. He has been instrumental in the startup of several companies and several business units in the computer systems and services areas. He has extensive international experience, having taken a broad set of software and hardware products to market in more than 20 countries. He has published approximately 35 papers and articles in various journals and magazines. Kim holds both an MBA from the University of Ottawa and an MEng from Carleton University. He can be contacted at [email protected]

RoweBots Research Inc. 519-208-0189 www.rowebots.com