Consolidation of hardware platforms, or “boxes,” is a goal for many companies needing to update one or both pieces of hardware. Consolidation without massive change to legacy software can be a tricky job. Intel’s Virtualization Technology can ease the migration process.
“Time and tides wait for no man”(1) – and neither does concrete.
Making concrete is one of those amazing chemical reactions that we often take for granted. That is, unless your job is to work with concrete, then organized chaos results. Pourable concrete is a perishable commodity that starts its limited life as soon as water is added to make the mixture. Not only does an individual batch of concrete “spoil” if it’s left in the cement mixer too long, but concrete pours often must be completed in a single, multi-truck pour - that also has a limited life span.
In comparison to realtime control of higher frequency rate processes like controlling the ignition of an automotive engine, concrete seems like a slow process to manage. But the entire process from concrete production, quality control, and delivery is deceptively complex with control of critical mixing valves just one part of the process.
Command Alkon, a redimix concrete systems supplier , uses a proprietary system to manage its software and materials handling products, including entire integrated concrete system. Subsystems of the software manage a wide variety of services, including disparate functions:
- Common Master Files
- User Definable Forms
- Comprehensive Scheduling and Tracking Tools
- Order Modeling
- Windows-style Order Tree
- Concrete Mix Design Interface
- Field Level Security
- Dual Units of Measure
- Time Analysis Capabilities
- Driver Utilization Management
- Comprehensive Executive, Operational, and Financial Reporting Capabilities
- Customizable Pricing Levels
- Price Change Utilities
- Cement Content Pricing
- Accounting functions
- Language Translation
- Batch Panel Interfaces
- Geographic Mapping Interfaces
- Signaling Interfaces including complete Autostatusing
- Color Dispensing Interfaces
- Quality Control System Interface
- Caller ID Interface
As is often the case involving legacy code in large scale systems, changing the software operating environment can be a huge undertaking. The complexity and difficulty explodes when the system is split across multiple non-homogeneous hardware platforms. In the case of Command Alkon, the proprietary software system was partitioned between two hardware boxes – one to manage the realtime control aspects of a concrete plant automation and another to deal with the non-realtime aspects of the system including the User Interface and management functions. These two systems communicated through an ethernet link connecting the two boxes.
At first glance, upgrading either one of the hardware platforms seems like a straightforward task. But the decision of what to do was complicated by the thousands of plant installations around the world.
Maintenance and provisioning spares in general argues in favor of implementing systems with the minimal number of pieces of hardware necessary. There are examples where adding redundant hardware improves systems reliability <link to my blog post> and availability, but that isn’t the case with a system made up of disparate entire hardware boxes and operating software. Command Alkon’s concrete management system relies on Microsoft® Windows (2) for management and accounting functions. A separate hardware and software system operates the realtime aspects of the system. Both systems function well, but many computer systems have a limited lifespan. Thus there is a future date when today’s hardware is no longer available.
Ideally, both the realtime subsystem and the Windows-based User Interface and management functions would run on a single platform.
Intel’s virtualization technology provides the base for companies like TenAsys (3) to field combined Microsoft Windows and a realtime operating system.
The TenAsys approach employs Intel virtualization to simultaneously host two operating systems on a single hardware platform. TenAsys’ eVM for Windows embedded virtualization platform creates a virtual machine environment that hosts an embedded or real-time operating system alongside Windows. eVM partitions the input and output interfaces to the right virtual machine partition to ensure that critical hardware interfaces are given first priority to the most critical operating system kernel. Doing so guarantees deterministic response to real-time events.
What makes TenAsys approach different is the ability to simultaneously host a wide variety of realtime operating systems (RTOS) alongside Windows on a single platform. eVM permits a guest RTOS to be configured and controlled by a user interface running on the Windows operating system. TenAsys’ approach permits an RTOS of choice to be selected as the guest OS. eVM can manage guest OS configurations for Wind River Systems (4) vxWorks RTOS, QNX Software Solutions Ltd (5) QNX, Microsoft Windows CE, Linux, and legacy RTOSes.
Using the virtualization approach protects one of the most valuable assets in large legacy systems – the proprietary software. But if both the Windows and RTOS systems have been merged into a single hardware platform, how do you communicate between the two logically separate systems without modifying the legacy link that previously connected the two hardware platforms?
eVM creates a virtualization environment to allow both a Windows system and an RTOS to operate in the same physical hardware. It accomplishes this by removing one hardware thread from Windows control during installation. This hardware thread is dedicated to the guest RTOS. Windows employs its standard configuration mechanism to perform this piece of systems configuration – for a multi-core processor this is accomplished by dedicating one core to Windows and another to the guest RTOS. eVM relies on Intel VT-x support to perform realtime memory mapping between each OS’s logical memory map and the physical memory map. Competing use of the memory mapping hardware is one area that developers must pay close attention to since competition between Windows and guest OSes may limit systems performance.
During systems installation, a fixed partition is established to contain the eVM software and the room needed for the guest OS. This locks the dedicated memory from control by Windows and is one of the basic mechanisms used to ensure deterministic RTOS behavior. The next critical configuration task is to separate interrupt serving into two categories: those that are required to be served by the guest OS and those that may be served by Windows. This is accomplished by establishing eVM as the interrupt service for interrupts associated with the realtime devices. eVM then passes control to the guest OS. By maintaining control over critical resources, eVM ensures that realtime functions do not become entangled in Windows non-realtime operation.
There are other classes of “realtime” devices such as a realtime clock, disc controller, PCI bus, bridge on the PCI bus, and interrupt controller. All of these signals are generated by eVM as virtual devices that are resident in the guest OS space.
In this architecture, device A is a PCI device driver that supports MSI, device B is handled by a normal Windows driver, device C and D share an interrupt but eVM routes a virtual interrupt for device D that may be polled by the guest OS while device C functions a normal Windows device, device E is handled by eVM and a virtual IRQ is delivered to the guest OS, lastly device F is an MSI device that is handled by eVM and passed a virtual IRQ to the guest OS.
With control over the interrupt structure established, eVM can create a virtual Ethernet link between the Windows operations and the guest OS operations. This is accomplished by Windows using its standard NDIS drivers and the guest OS employing an NE2000 interface. Thus eVM creates a virtual Ethernet link using shared memory that can be accessed by both Windows and the guest OS as if the virtual link were physical. Consequently, the Command Alkon Windows software and the RTOS hosted-software behave in the same manner as they did when operating on two separate boxes without modification.
TenAsys’ eVM provides an elegant way to marry two previously separate hardware platforms to achieve lower hardware complexity on a single piece of hardware. It does this through an elegant use of Windows installation techniques, eVM-based interrupt handlers, and Intel Virtualization Technology.
What’s in your future platform?
1. 1. Cesar Chavez
2. 2. Microsoft® Corporation is an Associate member of the Intel Embedded Alliance
3. 3. TenAsys is an Affiliate Member of the Intel Embedded Alliance
4. 4. Wind River Systems is an Associate member of the Intel Embedded Alliance
5. 5. QNX Software Solutions Ltd is an Associate member of the Intel Embedded Alliance