Developing Battery-Powered Devices Using Windows Embedded Standard

As 32-bit RISC systems become more powerful, the desktop x86 architecture is also gradually reducing its power requirements. Today, both platforms can be used to design battery-powered mobile devices. However, when desktop applications are actually used in mobile devices, some special considerations are required, and the emergence of the Window Embedded STandard operating system solves this problem.

Window Embedded Standard (WES) is not just a remake of the desktop operating system, it is a different environment with new features designed specifically for low power, mobile, and discontinuous operation. This article will show you how to use these features effectively.

Desktop and mobile devices are different

From a security perspective, people can lose their mobile devices, which can compromise the data on them. A cell phone can have many phone numbers. A WES device might contain the U.S. national phone book. And one type of data is particularly important: biometric data. If an account number or phone number is stolen, it can be modified; but if a biometric database is compromised, it can be a serious problem.

For the security of "data at rest", WES provides disk-level, directory-level or file-level data encryption technology, because EFS (Encrypted File System) is an integral part of the basic NTFS file system. Although WES does not use Vista-level "Bitlocker" encryption, it uses other methods to establish an equivalent security system.

In addition, the system also provides a variety of third-party 'whole disk' encryption solutions, some of which even meet the FIP140-2 standard, and some are integrated with hard disk technology.

All of these security solutions start with authentication, and identity spoofing on mobile devices is a real threat. We expect mobile devices to be used outside of secure areas, so we need to know if it is really the device that is 'phoning home'.

There is another possible 'spoof' for mobile devices - a clone or twin device that can be swapped with the target device. Perhaps an unwitting partner accidentally brings this 'evil twin' into a secure area, or the hard drive in the mobile device can be removed and placed in another computer for analysis and attack.

It is important to note that a good user security triad (something you have - a badge, who you are - biometrics, something you know - a password) is not enough to defeat this type of spoofing threat. A legitimately authenticated user can still log into the network through a compromised device (e.g., using an installed keylogger), thereby compromising security. The device itself (not just the software on the hard drive) needs to be part of the secure path for data to be sent over the network. This is best achieved using some of the hardware solutions specified by the TCG (Trusted Computer Group).

Hardware components like Atmel's TPM (Trusted Platform Module) perform important functions, especially "secure boot", which is supported by third-party whole-disk encrypted file systems. The idea here is that as the boot software is loaded, a unique software and device identity hash is generated. This hash is stored deep in the module, even the user or administrator cannot know it. Only the system knows what software to boot, and the software knows to only run on this hardware.

The TPM module also provides a secure repository for passwords, hashed passwords, keys, and certificates. Data stored 'at rest' in RAM or on disk sectors (such as passwords) can be extracted and restored to their original form using commercial tools such as WINHEX. If this data is located in sectors that are not encrypted by basic NTFS (such as offline processing, temporary, swap, or print areas), it may be in plain text.

But even with encryption, millions of plaintext strings can be hashed using a fast offline computer until they 'match the hash result', thereby revealing the password or key. The best way to keep important key data safe is to store it deep inside the chip, where tamper detection and response circuitry protects the data from intrusion.

Even for applications other than national security, strong data protection is often required, such as high-definition media. Many mobile x86 devices are being planned, and playback of high-definition video is often one of the target applications for these devices.

Virtually all commercial HD video content is protected by strong DRM (such as Sony’s Blu-ray technology), but it is common to see content owners “fighting” in the lab and in the courtroom against those who copy and distribute their content without paying royalties. So far, HD content owners appear to be winning, through the use of smart and easily updated secure VMs (virtual machines), and laws such as the WIPO Copyright Treaty (1996)1. For software built into embedded devices that must be used across borders, the battle is not over yet. Downloaded “cracked” software that can run on a PC may still be a bone of contention in a Norwegian court2. An injunction could well stop devices with infringing software at national borders, but this would cause serious cash flow problems for manufacturers and importers.

While examining the scribe lane on a Digital MicroVAX computer, Florida State University's Molecular Express team stumbled upon a message that read, "VAX - if you really care, steal the best," a phrase that frequently appeared in black-hat and white-hat hacker battles of the 1970s.

These DRM schemes usually require multi-faceted device authentication, from the media to the player, to the computer, and then to the display device that shows the picture. Chip-protected identities (such as TCG-approved modules) are necessary for such systems. WES like Vista can work with such software and is compatible with DMC1998. Microsoft is working to prevent Linux from being "Tivo-ized"3.

Designers of mobile WES devices should carefully consider human machine interface (HMI) issues. Even with the graphics processing power of the Atom chipset, and strong support from Microsoft's off-the-shelf drivers, the device may still require some HMI redesign due to display size limitations. Of course, the normal "XP" desktop is available and can be given different color themes and significantly modified in graphics and functionality if necessary.

Anyone who wants to completely design a custom interface for their device should take a good look at Silverlight. Silverlight is primarily used for what Microsoft calls RIA (Rich Interactive Applications). Silverlight was developed in Visual studio under .NET 3.5 and provides direct interfaces to databases and programming languages ​​in a single IDE. .NET 3.5 is a new feature provided by WES and is not part of the old XP embedded version.

But Silverlight is a browser-based technology, so it may not be suitable for mobile handheld devices. In this case, the preferred interface may be Windows Presentation Foundation (WPF). WPF can provide all the features of Silverlight - embedded video, animation, scalable vector graphics, etc., but all of these features do not require the use of a browser.

Finally, one more detail about mobile devices: they generally use resistive touch screens, not mice or trackballs. It's a different interface - there's no 'hover' feature, for example. Windows Mobile and Windows CE both used to provide the required functionality with tap-and-hold, tap-and-drag, and double-click on the screen, but these features had to be built into the touch screen drivers, which were different for each touch screen vendor and were not part of the off-the-shelf WES. You had to create this driver yourself, or get it from the OEM vendor.

A word of caution, this type of driver can be extremely resource and power hungry if not done properly. It is best to use good low power, interrupt driven design techniques to create these drivers.

Networking

There are differences in networking capabilities for a truly mobile device. Laptops, while also mobile, typically work from a fixed location and maintain a link to a single WiFi access point. However, a handheld WES device may need to be used on the move (such as a worker carrying an RFID reader/tablet in a warehouse), potentially 'hopping' from one access point to another while maintaining session connectivity and security.

Windows Communication Foundation (WCF) can provide this flexibility. WCF is part of the .NET framework and can be used to build applications that communicate with each other. WCF is built into Vista and can be downloaded and installed by OEMs who develop WCF devices.

WCF is Microsoft's comprehensive solution for communications, but Microsoft is not the only major company in this field. Cisco has a near monopoly on the access point market, and their various standards (the famous CCX) are also a factor in the OEM device development environment. Fortunately, these communication technologies are based on a common point of compatibility with XP/Vista, so they can be installed as plug-and-play drivers with WES systems.

OEMs should be aware that vendor standards may not be enough for mobile devices. There are stringent industry and government standards for different types of medical devices, DoD information, and various security (economic) matters. Also fortunately, all of these standards were developed and validated with Windows PC devices, so it is generally easy for OEMs to adapt to WES devices.

However, all the answers are not in software. The mobile device designer in particular needs to understand where his device fits into the communication scenario. For example, a laptop is almost always a USB host. However, a mobile device may be a USB slave or may have both host and slave capabilities. Such changes may require adjustments to the BIOS.

Power consumption

Power usage, more specifically energy consumed per unit operation, is critical for battery powered devices. Ultimately, what we want is "Days of Use (DOU)" at minimal battery cost and size. Clock rate or MIPS measurements are not a good indicator of a device's 'DOU'. Power consumption measurements are not strictly related to DOU. MIPS per Watt has some relevance, but only if usage is constant and continuous - which is rarely the case for mobile devices. But what really counts is Watt-seconds (ergs) per operation.

Mobile applications are interrupt and event driven. For example, a mobile device may have a built-in RFID reader. Its battery life may not be measured in hours, but in the number of reads. If designed properly, such a device should consume almost no power unless it is required to read a tag. It should then trigger the work, send out the RF pulse, read the returned data, eliminate false readings, apply some business logic, and then transmit the data to a local or remote database, perhaps starting a network connection.

As you can see, the integration efforts of hardware, operating system and application software can achieve the best erg per operation. Further erg/operation optimization depends directly on the operation performed and the network used. For example, a short SMS message may be very energy efficient (erg per byte) when sent over CDMA or GPRS. Larger documents, such as emails or graphics, may be most efficient (erg per megabyte) when sent over Wi-Fi. WES provides the platform for application designers to selectively use the network based on the required bandwidth, security and quality of service.

Power Management with ACPI

The existing WES provides the same Advanced Configuration and Power Interface (ACPI) found on XP Pro computers. With this built-in, ready-made ACPI, you get many basic features like hibernation. And you can implement additional power management features from the application layer. ACPI-level power management is based on simple monitoring of runtime idleness, as shown in Table 14.

This basic ACPI function included in WES is the same as that used in laptops and is only the starting point for power management in mobile devices. The 'timers' that control ACPI are usually set to values ​​much larger than the intervals used to characterize event-driven operations of real-time devices.

Extended Power Management

WES 2009 has a new feature called Hibernate Once, Restart Many (HORM). HORM allows the system to quickly (nominally 1 second) boot into a pre-created hibernation file. For example, this feature allows an automation system to quickly resume operation after a brief power failure.

For some devices, OEMs should be prepared to move past basic ACPI-level power management functions and integrate them into the application. The OEM, or its first-tier supplier, can extend the BIOS to provide an API to switch the CPU and even the associated electronics to a lower power state.

Interestingly, there is plenty of room for power savings during the brief milliseconds of continuous operation that we see. For example, each frame of MPEG playback requires multiple power draws: one to send the data to disk, one to decode it, one to fill the frame buffer, and then a very low power (but screen backlight is always on) to wait for the next frame.

This variable power consumption from MPEG frame to frame is truly visible on a high-speed current measurement oscilloscope.

Battery Charging

Energy consumption is only half the problem, first the battery must be charged. Lithium chemistry is somewhat hazardous, and smart batteries are generally used. Controlling battery charging requires access to I2C or SPI bus interfaces, and is from the application layer to manage the battery charging and discharging process. Battery management is a difficult hardware and software design challenge, and integration with the operating system is fundamental to the success of any mobile device.

Figure 1: Comparison of “laptop” and “mobile device” design criteria.

Figure 2: Bad actors will work hard to undermine the security picture.

Figure 3: Runtime Idle Detection. This basic ACPI function included in WES is the same as that used in laptops and is just the starting point for power management in mobile devices. The 'timers' that control ACPI are usually set to values ​​much larger than the intervals used to characterize event-driven operations of real-time devices.

Figure 4: Power consumption. $ = power consumption, magenta = current, stable $ = power supply. MPEG-1 playback, Linux OS on top, WES on bottom. Platform is Catalyst EC.

Table 1: ACPI-level power management is based on simple monitoring of runtime idleness.