Moving from WinCE to RT Linux

• 
• Tweet
• Pin It
• Condividi per email

The real-time versions of Microsoft’s Windows OS are becoming obsolete as there are no real drop-in replacements for the installed basis of Windows CE, Windows Embedded Compact 7 and Windows Embedded Compact 2013. As a consequence, engineers are facing a huge migration challenge.

The RTOS segment in the embedded software market is projected to register a healthy growth with a CAGR of more than 11% from 2017 to 2024[i]. But the real-time Windows-based OSes – namely Windows CE (WinCE), Windows Embedded Compact 7 and Windows Embedded Compact 2013 – are struggling due to a lack of long-term roadmap perspectives. Even though those OSes have been quite popular in both mobile and industrial markets due to native Microsoft APIs and hard real-time capabilities, they are no longer supported by Microsoft –- at least if one relies on roadmaps from Intel and other silicon                    Hubert Hafner, Vice President Business Development, RTSoft    vendors in that the impression is given that the new CPUs/chipsets no longer support these OSes. The consequence is that they can’t be used for new designs and there are also problems with the maintenance of older designs.

Real-time with Windows is a dead-end road

Customers’ feedback is that the compiler for C/C++ seems to be very old, for example, and consequently quite confining compared to latest state-of-the-art tools and lacking support of the latest processor and connectivity enhancements. .NET Compact looks to them old fashioned as well. In effect, customers’ engineers think that Windows-based real-time systems are blocked from gaining access to and interoperability with modern connectivity frameworks especially as regards IoT, IIoT and Industry 4.0. To generalize the point: The development tools for Windows-based RTOS systems seem to get the reputation that they are obsolete. Engineers thinking about adapting open source frameworks to get round this problem, should be aware that they have to spend huge efforts to achieve Windows Embedded Compact 2013 compatibility; and even if engineers overcome this hurdle, they are facing the additional challenge that Microsoft does not support the use of their own RTOSes in its Azure ecosystem.

Engineers who don’t want to get stuck with their design roadmaps in recent capabilities and the limited development options they offer for new business models, have to evaluate the right migration path now. To be honest, this is not an easy task but one thing is clear today: Neither migration option offered by Microsoft is a real-time option. While the feature-rich, full-scale MS Windows 10 has of course a huge application stack, it supports only x86 and is not optimized for the embedded market and embedded versions are no longer supported. What is most important is the fact that it is not real-time capable. MS Windows 10 IoT Core is by far better for most embedded designs. It offers both x86 and – limited – ARM support and is compatible with standard Windows APIs, is free of charge for prototyping, the common .NET development environment can be used, and long term commitment from Microsoft is available as well. So for all Windows-based IoT and IIoT solutions, the Window 10 IoT Core is great. Even an on-the-air (OTA) update service is available for it, which is also great. But does this help when engineers need a real-time OS? Not at all!

Migration options

Engineers coming from the real-time Windows world and continuing to require real-time must therefore look for alternatives. They have three major options: Staying with their recent OS, which appears to be a dead-end road in the long term; migrating from those old-fashioned real-time Windows OSes to COTS OSes such as VxWorks offered by Wind River; or driving the open source road by utilizing real-time (RT) Linux. For the latter two options, companies such as RTSoft offer comprehensive migration support so that OEM engineers can concentrate on the development of the new functions enabled by the new OSes. The VxWorks is a well-known platform, of course, but for many projects originally designed for real-time Windows it is often too complex and has limited hardware support. Engineers therefore consider RT Linux as migration efforts are more manageable plus there is a huge trend to open source software everywhere. But what do they need to know to migrate?

Linux is a highly flexible solution, as both RTOS and GPOS options are supported. It is also attractive because it is a full-scale OS with large open source and commercial community support. It has distributions and infrastructures that are optimized for embedded, e.g. Yocto. Other compelling advantages include the fact that there are no licensing fees to be paid, and that the community can often share interest and development efforts, making a Linux runtime quite cost effective. But the Linux migration path is not easy. It is for example extremely important to understand that modern OS requirements include an OTA update for firmware, kernel and applications, which is not supported out-of-the box in most Linux solutions. On the other hand, a production-ready OTA solution will again lead to a vendor lock-in – for example Ubuntu core or Wind River Linux. As this is likely to lead to another bottleneck, decisions need to be made carefully.

What is needed in any case is a board support package (BSP) that supports all required drivers. Here, engineers can benefit from developments on the community kernel which most of the time are ready to use. The majority of x86 interfaces will work out of the box. ARM will require more work as each core has its own setup. But one needs to keep in mind that Linux is not an off-the-shelf real-time solution. Engineers must therefore rely on real-time kernel patches that offer modified kernel interrupt handling and scheduling mechanisms to reduce latencies and to ensure determinism. But not all kernel versions have this capability, and of course each new kernel variant needs to be ported to ensure the real-time capabilities for its latest versions. The result is that Linux is basically only a soft-real time OS with reduced latencies, and real-time behaviors have to be tested in each new configuration as in most cases there is as of yet no guarantee for the maximum values of jitter and determinism.

Xenomai eliminates real-time uncertainties

To eliminate the real-time uncertainties of Linux OSes, the Xenomai project was initiated. Xenomai[ii] brings POSIX and other common RTOS APIs for porting time-critical applications to Linux-based platforms. When the native Linux kernel cannot meet the response time requirements of the application, Xenomai supplements it with Cobalt, a small real-time infrastructure which schedules time-critical activities independently from the main kernel logic. The Cobalt real-time core depends on a patch to the mainline Linux kernel, which introduces a separate, high-priority execution stage for running out-of-band interrupt handlers immediately upon IRQ (interrupt request) receipt, which cannot be delayed by the regular kernel work. Such a setup seems to be a perfect fit for many distributed services required in real-time and thus ideally suited for IIoT and Industry 4.0 appliances.

So it looks like the Linux road for real-time operations is fairly solid. If engineers now use cross-platform development tools that are capable to port C# code to both Windows and Linux, then only the right OS and BSP configuration needs to be compiled. Such cross-platform applications may run on legacy WinCE as well as new Linux systems and will have the same look-and-feel with less coding for application, but potentially more testing and bug-fixing for the hardware-near glue logic for the target platform. Suitable tools to manage this challenge could eventually even include Xamarin/Mono for porting of C# code as well as Java, which runs on all OSes, and LLVM with its modular and reusable compiler and toolchain technologies. Finally, Qt, the cross-platform software development tool for embedded and desktop, is a recommended tool to tackle the migration challenge. With such a setup, engineers can work entirely with open source software and will never depend on any specific company. But there are many tasks that OEM software developers are not familiar with.

Device-near software programming services

OEM engineers do not need to be left alone within such a migration process. Software service providers such as RTSoft, who have a high level of expertise in device-near software programming, can provide comprehensive help. They support OEMs during migration from requirement engineering to debugging and all services needed throughout the entire porting process. If required, they also provide individual runtime BSPs to support OEMs with tailored OTA services for their devices. And the good point is: Their services are not limited to RT Linux. They can also code everything demanded for OSes such as Windows or VxWorks and many other hardware-near software and protocols. With hardware-near software service providers such as RTSoft, OEMs always also have a consultant at hand who will help them find the right solution for their next software design challenge.

Picture of Hubert Hafner with quote:

“Linux offers some real-time extensions, which RTSoft helped to develop, and engineers have their eye on RT Linux particularly because there is a huge general trend towards open source software. However, anyone who finds the capabilities of Linux inadequate – which is very rare – can switch to VxWorks with RTSoft, as we support all relevant RTOSes plus – not to forget – Windows.”

In the above picture: Hubert Hafner, Vice President Business Development, RTSoft GmbH

[i] https://www.gminsights.com/pressrelease/embedded-software-market

[ii] https://xenomai.org/

• 
• Tweet
• Pin It
• Condividi per email