.KEYWORD autopc
.FLYINGHEAD PRODUCT PREVIEW
.TITLE A survey of Auto PC 2.0 for software developers
.OTHER
.SUMMARY At this year’s Consumer Electronics Show, Microsoft formally announced Microsoft Windows CE for Automotive 2.0. This month, Contributing Editor Mark Moeller takes a look at the insides of Auto PC 2.0 and examines what new design changes and programming interfaces are in this new product.
.AUTHOR Mark Moeller
At this year’s Consumer Electronics Show, Microsoft formally announced Microsoft Windows CE for Automotive 2.0 (check out the press release at http://www.microsoft.com/presspass/press/2000/Jan00/WinCEAutoPR.asp). This rather lengthy name is what was formerly called Microsoft Auto PC 2.0. For the sake of brevity, I’ll call it Auto PC 2.0 in this article. While there wasn’t as much fanfare from Microsoft as when the first version was rolled out, the actual demonstration of the software in action by various OEMs producing Auto PCs was far more substantial (see last month’s article). This month I want to take a look at the insides of Auto PC 2.0 and examine what new design changes and programming interfaces are in this new product.
.H1 Upgrading the foundation
Just as with Auto PC version 1.0, Auto PC version 2.0 is based on the Windows CE operating system. Auto PC version 2.0 uses Windows CE version 2.12 versus the Windows CE version 2.01 used on Auto PC 1.0. As you might surmise from the relatively minor version number change, there isn’t a great deal of difference between the two operating systems from a functional standpoint. However, there are some key differences that allow the Auto PC 2.0 software to be more reliable and secure.
Windows CE 2.12 adds some important new APIs to give finer control of how the kernel’s scheduler operates and query the resource usage of threads. Of course, a number of important bugs were found and fixed between the two versions of the OS. Windows CE also got a considerable shot in the arm with regard to documentation. Windows CE 2.12 is far better documented than any previous version, particularly in regard to device driver, video, and file system development.
Another key feature of Windows CE 2.12 is its support for the Intel x86 processor and the Hitachi SH-4 processor. These are the two processors of choice for Auto PC 2.0 manufacturers, as they’re significantly faster than the SH-3 processor used in Auto PC 1.0. For example, the SH-3 had a maximum throughput of 60 million instructions per second. Compare that to the SH-4 processor at 300 million instructions per second,. then do the math. The SH-4 smokes the SH-3, and that doesn’t even take into account the fact that the memory on the version 1.0 Auto PC was far slower and the processor cache much smaller than on the version 2.0 Auto PCs.
.H1 Listening to customers
Auto PC 1.0 was a great stake in the ground for Microsoft to get in place. It demonstrated that Windows CE was up to the task, and that a consumer electronics product could be manufactured and brought to market for the automobile based on the technology. Auto PC 1.0 wasn’t the blow out success that others, or I, had hoped for, but it drew the attention of most every major player in the automotive industry. Since Auto PC 1.0 was originally developed in close cooperation with Clarion, little outside of Microsoft or Clarion affected the design of the Auto PC. As David Wright mentioned in my published interview with him in December’s Windows CE Power, Microsoft spent much of the last year working closely with other OEMs to incorporate their feedback into the Auto PC’s design. This was critical in getting broad acceptance of the Auto PC platform. From this collaborative effort, Auto PC 2.0 was born.
.H1 Tightly control installation
The concept of having a purely open computing platform built into a car is an anathema to many automobile manufacturers. In an environment where reliability is super important and avoiding the need for warrantee repair is important to the bottom line as well as customer perception, heavily controlling what goes into a vehicle is pretty important. If auto manufacturers put an Auto PC in their vehicle and the end user installs some bogus software that breaks their Auto PC, it’s the user pointing their finger at the auto manufacturer and telling them their car broke. This example and numerous variations on the theme drove the need for a tightly controlled software installation process to be incorporated into Auto PC 2.0.
The Auto PC 2.0 installation process allows Auto PC manufacturers to specify just how open their platform is. Level 0 allows any software developer to install their software onto the platform. Level 1 obliges a software developer to obtain a special key from the Auto PC manufacturer for generating a certificate to attach to their application using a special tool supplied with Microsoft’s Windows CE for Automotive 2.0 development tools. Only if the software has this certificate will the OEM’s Auto PC run the software. Level 2 means the platform is closed and can only run software provided by the OEM.
Additionally, Auto PC software vendors will be able to obtain a Microsoft Logo Key that indicates to any platform, open or restricted, that the software running complies with Auto PC logo certification requirements. Auto PC 2.0 software queries for certification, even on open platforms, and warns the user with an OEM supplied message if the software isn’t certified. This is to help users avoid installing software that might have viruses or otherwise behaves poorly on any Auto PC.
To accomplish this, several changes were made to the CEI builder tool as well as to the loader/installation tool on the Auto PC. Rigorous version control is also maintained to avoid one application clobbering another or having uninstalls break your Auto PC. Additionally, AutoRun’s security has been beefed up to prevent software that wouldn’t otherwise be allowed to install from being run directly by an AutoRun file.
.H1 Large screen support
A platform like the Auto PC needs a large screen to do a great job displaying information. The version 1.0 product suffered because it lacked such a large screen. There’s often information you want to have on the screen at all times, regardless of the primary task you might be performing with the Auto PC. Examples of this sort of information might include the current radio station, your direction of travel, your current speed, and the outside temperature or time. When I’m running my navigation system or address book, I still want this information on the screen. Auto PC 2.0 supports all of this with display resolutions up to 640×480.
The baseline for navigation systems today is to have at least a 3" x 3" color display with a moving map, and Auto PC 1.0 couldn’t offer that. While innovative companies like Infogation and TravRoute were able to do admirable jobs of getting a moving map on to the 3 1/4" x 7/8" display on the Auto PC, no amount of innovation can replace that much missing screen real estate. Since the Auto PC is priced along the same lines as mid- to high-end navigation systems, it really needs the hardware resources to perform as well as or better than them.
However, large screens cost a bunch of money. If the Auto PC manufacturer’s cost for a 5" display is several hundred dollars, the cost to the consumer can then be over one thousand dollars. These displays are very expensive because of the temperature range they must operate in and endure without breaking. The car is an incredibly brutal environment. This is why you don’t want to leave your nice laptop with the 14.1" display sitting in your ungaraged car during a Minnesota winter — you’ll be getting your display replaced. To help keep entry level prices semi-reasonable, it’s still desirable to make an Auto PC with a small screen. So Microsoft did some work to help the application developer support large and small screens using a single application.
The forms manager, which is used for displaying information on the Auto PC, now supports scalable forms and constraint based layout. The standard controls that come with the Auto PC also scale themselves based on display size, and will take advantage of the extra screen real estate by showing more information than on the smaller screen, not just using larger fonts. The constraint-based layout in the forms manager allows the developer to position his or her controls relative to areas of the screen versus simple X/Y coordinates using control positions such as Lower Left, Center Top, Left to Right of Control, and fractional locations based on the size of the form (like 20 percent down from top of form).
.H1 The region manager API
The large display in Auto PC 2.0 is a natural surface for showing a digital dashboard. However, Auto PC 1.0 would only allow one application at a time to control the display surface. Since a digital dashboard typically aggregates together information from a multitude of sources for presentation to the user, more than one application needs access to the screen. As I mentioned earlier, you’d typically want your digital dashboard available regardless of the primary task you’re performing with the Auto PC. Because the Auto PC is a multimedia, information, entertainment, and communication device, often times there’s no one primary task. From a usability standpoint, it’s very desirable to have the information for each of the applications being used to appear in exactly the same place on the display all the time. This prevents the need for the driver to search the screen for the information they’re looking for, which would be distracting. Imagine for a moment that the speedometer on your car moved to a different location based on the last switch you turned or pressed in your car. You get the picture.
The region manager allows an Auto PC OEM to define one or more "regions" of the screen and associate applications with those regions, as shown in Figure A. Each of the regions that the OEM defines is called an "OEM area". There’s also a "default region" that the primary application appears in. The default region has a minimum size of 256×64 pixels, but can be as large as the whole display and is defined by the OEM. Regions may not overlap, be larger than the primary display surface, or have an irregular shape for the default region.
.FIGPAIR A The region manager allows an Auto PC OEM to define one or more "regions" of the screen and associate applications with those regions, so the information for each of the applications being used appears in exactly the same place on the display all the time.
Applications running in OEM areas are second class citizens with regard to UI access compared to applications running in the default region. Applications in the default region "own" the keyboard and speech recognizer. Applications in OEM areas only get keystrokes if the OEM has hard coded that specific keys get sent to specific OEM areas or if the OEM implements soft keys for an OEM area. Applications in the OEM areas can only register global grammar with the speech recognizer instead of being able to change the grammar that the speech recognizer uses based on user input. However, applications in an OEM area can also expose user interface through the default region of the user selects the application.
The rectangles defined by an OEM as regions on the screen can’t be changed by applications, but applications may request that they run in "full screen" mode. This typically requires a security code to be passed to the region manager to prove the application has permission to take over the screen. Even then, an OEM may choose to only allow those parts of the screen that aren’t being used for soft keys to be used by a "full screen" application.
.H1 The soft keys API
One downside of a large screen is that it takes up valuable space in the vehicle, space that could otherwise be used for controls and buttons. Also, since many buttons or controls need to be used infrequently, it’s wasteful to take up valuable space with such controls. Enter the soft key API. The soft key API is a COM style interface for building, managing, and freeing soft key menus, and for positioning the soft key menus on the screen. The new soft key API allows an Auto PC OEM to define soft key regions on the display and to present and manage soft keys that are either based on a touch screen type model or an "ATM style," where hard buttons have soft labels that are shown on the display. The soft keys generate key press messages similar to the way physical keyboard keys do, but the function of the key is communicated to the user by a label on the screen.
A new feature in the forms manager called the Key Router can be used to route hard or soft keystrokes to a specific application, in any region, or the current application in the default region. Using various configuration parameters of the soft key API, keys can be defined to behave as a typical button that responds to press, hold and release, or as a toggle button that has a depressed and released stated.
.H1 Other user interface improvements
It’s important to automobile manufacturers to differentiate their products and to communicate a consistent look and feel. The version 1.0 Auto PC had one look and feel that wasn’t really alterable. Version 2.0 completely allows the Auto PC OEM to redefine any user interface element on the Auto PC. Configurable items include color scheme, system font, application colors, application font, message box, password verification, shell view, speech recognition state, power off form, and even the wait cursor. The code and parameters that define these elements reside in a collection of DLLs that the Auto PC OEM defines. While they could theoretically be replaced by independent software vendors, it would take close cooperation with the Auto PC OEM.
.H1 Other APIs
The Auto PC 2.0 software includes a handful of other new or improved APIs. Here they are:
.H2 The CD Control API
Another COM interface type API that makes it much easier for a software vendor to write their own CD player application. The CD control API abstracts out the hardware involved in loading and playing CDs from the application and creates a hierarchical representation of CD drives, discs, and tracks.
.H2 Vehicle I/O API
This API, while part of the Auto PC 1.0 specification, didn’t really ship until Vetronix recently released their CarPort device, which acts as a communication bridge between the Auto PC and the vehicle’s on-board diagnostic computer. This API, also COM based, allows applications to get information about the vehicle and even control certain items in the vehicle, such as power door locks and windows.
.H2 Position and Navigation API
This API has been expanded and improved with new COM interfaces to allow for efficient access to and processing of data from dead reckoning sensors used for navigation and location based calculations. In addition to the existing IPosNav interface, which gives access to GPS, several new interfaces have been added. These interfaces include something called INavSourceMgr which, as the name suggests, helps an application identify and access various sources of navigation data. Another interface, InavTap, manages the receipt and processing of readings from navigation peripherals. This interface works with the new interface INavReadingMgr to receive the data from the InavTap, and helps manage what can be a huge volume of information.
.H2 Extraneous Driver Distraction Control
This API and messaging system is used to allow applications writers to know whether the current state of the vehicle is safe to show what could be considered distracting information to the operator of the vehicle. For instance, a navigation system will want to show its moving map display while the vehicle is in operation, but only allow the entry of an address if the vehicle is stopped and has the emergency break on. Understandably, Microsoft leaves defining this state entirely up to the Auto PC OEM and the actual use of the information entirely up to each application vendor.
.H2 Asynchronous Audio APIs and Event Notification
The audio manager API and tuner control APIs have been enhanced to provide asynchronous notification to interested applications of events that affect the audio system, including but not limited to volume up/down, tuner frequency change, EQ change, and mute on/off. This is an important addition if you’re writing an application suite to control the CD player or tuner. For example, it was previously difficult to find out if application A changed the tuner frequency set by application B.
.H1 Final thoughts
So how do you get started developing for Auto PC 2.0? For starters, most any application you write for Auto PC 1.0 can be easily ported to Auto PC 2.0; in most cases just a recompile for the new target processors that are available is necessary. You can read my earlier article on getting started programming for the Auto PC for information on developing for the 1.0 product. Microsoft has yet to release any formal statement on obtaining the tools to develop for the Auto PC 2.0 product. My sources suggest that Windows CE Platform Builder 2.12 will be the development platform of choice for the Auto PC. As soon as I get official word from Microsoft on getting the tools you need to write for Auto PC 2.0, I’ll let you know in my next article. Until then, since nobody is actually shipping Auto PC 2.0 products, you’ll need to strike up a relationship with one of the Auto PC 2.0 OEMs, such as Clarion, Visteon, or Delco to get information on writing for their platform.
While you can see that there isn’t a lot of exciting new end-user features in Auto PC 2.0, it’s clear that Microsoft has been focused on their immediate customer first, the OEMs who build Auto PCs. Without their support, the Auto PC won’t go anywhere. From what I saw at the Consumer Electronics Show, these OEMs are going to be offering us, the end users, some great new products that take advantage of the new features of Auto PC 2.0.
.BEGIN_SIDEBAR
.H1 Product availability and resources
You can read the press release on Microsoft’s formal announcement of Windows CE for Automotive 2.0 at http://www.microsoft.com/presspass/press/2000/Jan00/WinCEAutoPR.asp.
Read last month’s Windows CE Power article on the Auto PC at http://www.windowscepower.com/issues/issue200002/ces001.html.
Check out David Wright’s comments in the published interview with him in December’s Windows CE Power at http://www.windowscepower.com/issues/issue199912/autopc1299001.html.
You can read Mark’s earlier article on getting started programming for the Auto PC and for information on developing for the 1.0 product at http://www.windowscepower.com/issues/issue199907/autodevelop001.html.
.H1 Bulk reprints
Bulk reprints of this article (in quantities of 100 or more) are available for a fee from Reprint Services, a ZATZ business partner. Contact them at reprints@zatz.com or by calling 1-800-217-7874.
.END_SIDEBAR
.BIO Mark Moeller is a 14 year veteran of Microsoft. After shipping the first version of the Auto PC, he left Microsoft to found AutoPCWare, a company focused on helping manufacturers and software vendors build Auto PCs or products for the Auto PC. Mark was the design architect of the first version of the Auto PC and has a number of patents pending or awarded on the Auto PC. You can visit his Web site at http://www.autopcware.com, or email him at markmo@autopcware.com.
