Q&A: TenAsys’ Hartman Discusses Embedded Virtualization and Microsoft Windows

Can you mix real-time control and Microsoft Windows? The challenge is to preserve determinism for real-time and I/O intensive functions while delivering the flexible user interface provided by Windows. TenAsys INtime for Windows is one solution that can make this combination work.

I talked with Kim Hartman, Vice President of Sales & Marketing for TenAsys, about embedded virtualization and INtime for Windows.

Wong: Increasing processing efficiency with virtualization techniques is becoming a major topic in embedded-systems design. How does TenAsys see embedded virtualization being employed?

Hartman: With the right software platform, one multicore PC can perform the functions that would have required multiple computers in the past, often with different operating systems (Fig. 1). Typically with embedded computing, some of these functions require determinism—the ability to provide reliable and predictable results in a specific time window. We call the software environment that combines heterogeneous operating environments while ensuring determinism “embedded virtualization.”

The result of this workload consolidation is a reduction in computing hardware and typically a simplification of the software development and maintenance effort, translating into major cost savings for the OEM and its customer. 

Wong: Is a real-time OS necessary in all of these integrated applications?

Hartman: The real-time responsiveness afforded by an RTOS is obviously necessary if you are integrating a machine-directed application that must close control loops reliably in a pre-determined amount of time, say a millisecond or less.  But sometimes, the need for determinism stems not from the fact that high-speed devices are involved, but because of the pure proliferation of interfaces and the typical method used by systems to interface to the devices. 

One of our customers, Allied Electronics of Bristol, Pa., makes a software platform to combine all of the various computing applications that take place at a fueling center (Fig. 2). There’s the point-of-sale (POS) system, credit-card processor and fraud-management software, possibly a separate database processor that links purchases with the brand’s customer loyalty points program.  There’s also the control application that runs the pumps and the system that updates the gas prices, and controllers that interrogate tank gauges and truck RFID transponders. Add to these the controls that operate the car washes (if there are any). There may also be a convenience store associated with the fueling center and multiple computing functions associated with that, too, including “back office” accounting functions.

Some of the center’s hardware devices must be polled, meaning the central control system must repeatedly ask them if the system requires an action.  For example, credit/debit-card readers must be periodically asked if a card has been read since the last poll was done. The longer that it takes between polling contacts, the longer a customer must wait for his or her fueling transaction to be acted upon. At busy stations, this can create a customer service problem.

Reliable communications with system hardware in an expedient and time-predictable manner requires a deterministic operating environment.  Windows is not a deterministic operating system because its task-switching mechanism is not designed to give priority to handling external events. To provide the required determinism, the fueling-center software platform needs to combine a real-time OS with Windows. That means they need embedded virtualization.

Wong: Tell me more about the difference between embedded virtualization and server virtualization.

Hartman: The technique whereby the same platform simultaneously hosts real-time and general-purpose operating systems (GPOSs) is called embedded virtualization.  Whereas server virtualization makes OSs and their application software run on a simulated version of the underlying processor, generally including simulated I/O, embedded virtualization explicitly partitions the platform hardware. As a result, hosted operating systems have exclusive use of dedicated CPU and memory resources, and direct access to control their assigned I/O interfaces. So when a particular device needs to be serviced by application software running on the RTOS, it gets immediate attention without needing to compete with other tasks or applications running on the GPOS.

Wong: Does the PC architecture have any special advantages for implementing integrated applications?

Hartman: Yes, more than any other system architecture. In addition to being the industry-standard platform for POS-related applications, PCs are also the most popular platforms for software development. In the case of systems based on TenAsys’ INtime RTOS, the consolidation of applications on the PC benefits from the fact that both INtime and Windows applications can be developed using Microsoft Visual Studio, the most powerful and popular software development environment for the PC.

Wong: But can Windows really be run in such an environment without modification?

Hartman: Yes. With the proper operating environment, integrating the Windows platform with the real-time control system allows off-the-shelf Windows software to be run on the system without modification. TenAsys’ INtime for Windows allows this to happen.

There’s also the issue of allowing for future expandability or the addition of new features. In the fueling-station application discussed previously, the standard PC architecture enables our customer to run standard software such as SSL (Secure Socket Layer) or Web Services, and support all of the functionality that their customers want, now and in the future. 

In a broader application context, there’s a major movement in the embedded world toward supporting the “Internet of Things” (IoT).  The implications of Internet connectivity for embedded systems are still being discovered, and it is critical for embedded-system designers to base their products on platforms that are readily scalable to accommodate future developments without requiring significant software redesign.