Yes Virginia, Windows CE .NET Does Handle Headless Systems
May 28, 2004
Download the Industrial_Automation_Device.exe
Microsoft® Windows® CE .NET
Summary: And you thought Windows CE .NET didn't support a headless system … Mike Hall and Steve Maillet explain that it does and show you just how easy it is to set up. (9 printed pages)
We've been hinting and promising to discuss headless systems for a while now. That time has finally arrived! A headless system, sometimes called a "Black Box" is a device that does not have a graphical user interface and may not have any display at all, other than the obligatory "Blinky Lights" we engineers are so fond of. Many people believe that Windows CE .NET doesn't support headless devices or isn't of any use in such types of systems. Let's set the record straight on that up front! Windows CE has supported headless systems since its very early days. Not only can it be used for headless systems Windows CE is already used in a variety of such systems from a diagnostics instrument that tests for anti-biotic residue in milk samples to HVAC and SCADA systems (and the Microsoft MN-700 Residential Gateway). So why is it, that after all this time there is still confusion on the issue? It turns out there are a couple of reasons. First is the name Windows CE .NET, and second is the success of the Windows Mobile and Pocket PC platforms.
When talking to people in the newsgroups, at training sessions, and conferences it becomes clear why users are confused about whether they can use Windows CE for "Black Box" devices. The fact that the operating system has "Windows" in the name just sticks in your head and you think: "GUI," and it's tough to let go of that idea. But Windows CE is an implementation of Win32® which supports a range of non-graphical applications. Even on Windows XP you have non-GUI applications and services going all the time (Internet Information Server for example).
The Pocket PC represents a hugely successful platform based on Windows CE. So much so, it is often difficult to separate the underlying operating systems and technologies from the products that use them. There is a very real large populace that equates Windows CE with Pocket PC as if they were one in the same. While this is great for Pocket PC it hides the broader capabilities of the operating system in the embedded systems space. Who would have thought that Pocket PC and Kuka robots would be running the same operating system. This article and others that will follow are focused on bringing those broader capabilities to light with insight from real-world projects created with Windows CE.
Let's examine a common scenario for using headless systems. Figure 1 is a diagram of a fictional system with an operator at a workstation managing a series of networked devices that provide a variety of monitor and control functions. These devices could control HVAC systems like fans, coolers, and heaters; they could monitor water levels and flow as part of the control system of a large shipping canal; or they could provide patient care monitoring in an assisted living facility. Despite the differences in each of these scenarios the core technologies and design challenges of each are quite similar.
Figure 1: Common Networked Headless Device Scenario
In this type of scenario the operator can monitor everything from a workstation on the network. The operator is not required to be present all the time, because the server also monitors, logs, and updates the system as needed. It is also possible for the Controller device to retrieve information directly from the Sensor device without any other intervening activity from the server or the operator. This is a very flexible arrangement. Let's take a look at what Windows CE offers to help make this possible.
Networking—this is an obvious one. For this scenario it's important to have networking capabilities such as TCP/IP. But there's more to it than that. If all you have as a developer is a Sockets style TCP/IP stack and API then you have a lot of work to do in building the software infrastructure to make these things happen. The good news is that Windows CE contains broad support for a variety of upper layer protocols right out of the box. The Web Server contained in Platform builder can provide dynamic information on the device to the operator via ASP Web pages. The Operator can use ASP pages to change parameters and settings for the device in the same manner.
What about other devices and the site server? There are a few options here depending on your developer's skill base and the nature of your system requirements. DCOM allows software components to run on the different devices, server, and workstation and remotely access one another. There is also Web services that use SOAP. Windows CE supports creating applications that access other Web services and also supports hosting Web services in native code (ASP .NET is not available for Windows CE at this point in time.) How about locating/discovery of the various devices on the network? Well there's the Windows Network naming and DNS if you have a Site server.
Another possibility is Universal Plug 'n Play (UPnP). UPnP was created to interconnect consumer devices, but it has not been adopted very widely there because the cost of the technology makes it impractical at this time (Does your coffee maker have a network connection?). Despite its lack of adoption in the consumer space, there is plenty of good use for UPnP in the embedded arena. UPnP provides a standards based system (based on HTTP, XML, SOAP, and Web services) for discovering and controlling devices on a network even if there is no central server. This allows the workstation, server, or any of the devices on the network to locate and identify one another and to utilize the capabilities each has in the form of Web services or dynamic Web page remote user interfaces. That's right up our alley for embedded systems like the one we are describing here.
Of course Headless devices don't HAVE to be on a network and there is no requirement that a Windows CE device needs to have networking abilities. As an example let's consider the basic design of that Milk testing device mentioned earlier. It's a real Windows CE–based device running Windows CE V2.11. The system has four separate motors, one for a centrifuge and sample read scan and 3 motors for sample preparation, mix, and fluidics. For its user interface, it has a 4x20 alphanumeric LCD and a 4x4 key pad matrix. Not the sort of thing you typically think of as a Windows CE device. However, the use of Win32 and in-process COM support was extremely valuable during the development of the device.
OK, we've dispelled some myths and set the stage for you to consider Windows CE as viable for "black box" devices, right? Let's dig into a build with a virtual Black box. No, we're not talking about more hand waving and theory here! We're going to build a "headless" OS image using the Windows CE Emulator that is shipped with platform builder. (Bet you never thought the emulator could be used for headless systems too!) So, without further ado, let's fire up Platform builder and start a new platform. From the file menu select New Platform. This brings up the new platform wizard, go ahead and click past the welcome screen to the BSP selection step
Figure 2: New Platform Wizard - Step 2
Select the x86 emulator BSP to build an OS image that runs under the Virtual environment. You can also select any other available BSPs for real hardware as well if you have actual hardware to play with. Click on next to continue with step 3 of the wizard.
Figure 3: New Platform Wizard - Step 3
Here is something a little different than what you will see on your system—if you are using Windows CE .NET 4.2., he highlighted Industrial Automation Device is not present. The default Wizard does include the Industrial Controller option, but this is not the "headless" option we are seeking. However we have already covered how to create new platform configurations to appear in this list in a previous article, Extending the Windows CE .NET Platform. We can easily adapt the one from earlier Platform Builder versions to work in version 4.2. The completed file is available as part of the source code for this article. Once you get the new configuration XML file in place, you can re-run the wizard to get back to this step and select Industrial Automation Device. Select a name for the device—we've chosen "horseman," (which would probably be funnier if this article came out in October, unless you are reading this article in November, in which case this is probably very funny). Ah well.
Moving on to step 4 gives us the important choice of an HMI panel device or Headless Programmable Logic Controller (PLC) type device, since we are talking all about headless systems the obvious choice is the headless PLC option.
We then get to select the networking components in step 5 as follows:
Figure 4: New Platform Wizard - Step 5
Select the wired LAN and Web server for options to use the Web server as a remote interface for the device.
The next step of the wizard is a security warning. Now, before you get too excited it's not saying the components mentioned are inherently insecure, but it is saying that if you are not careful in how you use them, they could end up exposing your device to some security risks. We'll dig deeper into security as it applies to headless devices in a later article. For now, just accept the warning and complete the wizard.
From the workspace window, select the parameter view tab and navigate to the emulator Platform.reg as shown below.
Figure 5: Navigating to the Emulater/platform.reg
Double-click Platform.reg to open it as we need to make a couple of small changes to get the emulator to correctly run in a headless configuration.
At line 394 the following lines appear:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\EMS] "SysIntr"=dword:1A "Prefix"="EMS" "Dll"="emulserv.dll" "Order"=dword:0
Change the order for the emulserv driver to 1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\EMS] "SysIntr"=dword:1A "Prefix"="EMS" "Dll"="emulserv.dll" "Order"=dword:1
This setting forces the emulserv driver to wait for all drivers marked as order 0 to init before it loads, thus establishing a dependency relationship. The emulserv needs the DMA bridge drivers to operate. On a full graphical build the timing works out, even though it's not guaranteed, and everything starts up OK. However with a headless build that doesn't work and a debug assert and system hang occurs.
While we've got the editor open we might as well fix another item. Just a little bit further down in the file at line 416 the following text appears.
[HKEY_LOCAL_MACHINE\Drivers\EMULSERV] "Dll"="EMULSERV.DLL" "Prefix"="DSK" Profile"="VCEFSD"
Add a leading quote to the Profile value name as shown
[HKEY_LOCAL_MACHINE\Drivers\EMULSERV] "Dll"="EMULSERV.DLL" "Prefix"="DSK" "Profile"="VCEFSD"
Now we're set to build the platform, so go ahead and select the debug configuration, and click Build to generate a new operating system image.
Set up the Workspace to download to the Emulation environment by selecting Target | Configure Remote Connection. This brings up the Configure Remote Connection settings dialog box. Select the Emulator for the download and KITL connection.
Figure 6: Configure Remote Connection dialog box
On the Configure Remote Connection dialog box, click the Configure button to the right of the Download drop-down box to configure the emulation system.
Figure 7: Configure Emulator Download Service dialog box
Set the screen size to 80x80 (the smallest size allowed) since the actual display won't be used. Under Communication, select the Virtual Switch from the Ethernet connection drop-down box to allow the emulator to provide network services to the outside world.
Now that you have it all configured you can download the image to the emulation by selecting Target | Download and Initialize.
Once the image starts up, it will use the emulated Ethernet Virtual switch as a network adapter and DHCP from the host system. The default network name for a device is WindowsCE, however, the networking system won't register that name as it would cause immediate problems for a set of new devices powering up at the same time all with the same name. So each device must be addressed by its IP address. It's possible to hard code a new name into the registry for the device so it is registered, but that has the name conflict problem of multiple devices. So, if names are desired, then you need to provide a way for the device user to set it: either via a keypad UI, serial portk, or a Web admin page of some sort. (We'll look at some options for these in a later article where we expand on the details of the different technologies discussed thus far). For this project just open the CE Target Control and enter "s ipconfig /d" to run the ipconfig utility and generate the output over the debug connection like the following:
17000 PID:c2f44cca TID:c2f44362 Windows IP configuration 17540 PID:c2f44cca TID:c2f44362 Ethernet adapter [DC211401]: 17540 PID:c2f44cca TID:c2f44362 IP Address ........ : 192.168.10.6 17540 PID:c2f44cca TID:c2f44362 Subnet Mask ....... : 255.255.255.0 17540 PID:c2f44cca TID:c2f44362 Default Gateway ... : 192.168.10.1 17540 PID:c2f44cca TID:c2f44362 17680 PID:c2f44cca TID:c2f44362 DNS Servers........ : 192.168.10.1 17680 PID:c2f44cca TID:c2f44362
You can now launch the browser on your workstation and point it to the IP address of your CE device, in this case it's http://192.168.10.6, and the basic default Web server page will appear:
|The Windows CE Web Server is enabled on this device.
This file is a placeholder and should be replaced. Please see your Platform Builder docs or our Web site at http://msdn.microsoft.com/embedded.
More information on the Windows CE is available at http://msdn.microsoft.com/embedded/ce.net.
Figure 8: The basic default Web server page
While this doesn't do much of anything at this point, it does show a lot of capability with little effort. We'll turn this basic configuration into something more exciting in future articles as we explore various aspects of headless devices, including putting in Web services, Telnet, and UPnP, and discuss security issues and best practices.
Steve Maillet is the CEO/Chief Software Architect for EmbeddedFusion. Steve has provided training and developed Windows CE solutions for clients since 1997, when CE was first introduced. Steve is a frequent contributor to the Microsoft Windows CE development newsgroups. When he's not at his computer burning up the keys, Steve can be found jumping out of airplanes at the nearest drop-zone.