Automation Portals
- Automatic Identification
- Design & Simulation
- Digital Factory
- Electrical & Control Panels
- Embedded Automation
- Factory Automation
- Fieldbus Networks
- Flow, Level & Process Inst.
- Fluid Power, Valves & Pumps
- HMI & Operator Interfaces
- Industrial Communications
- Industrial Computers
- Industrial I/O
- Machine Control
- Machine Safety
- Manufacturing Intelligence
- Motion Control
- OPC
- Plant Management & Maint.
- PLCopen
- Process Control
- Process Safety
- Programmable Controllers
- Robots & Robot Controllers
- SCADA & RTU
- Security
- Sensors
- Systems Integration
- Test, Measurement & LIMS
- Vision
- Wireless Connectivity
- Network Portals
- EtherCAT
- EtherNet/IP
- PROFINET
- Industry Portals
- Building Automation
- Chemical
- Food & Beverage
- Machine Tools, CNC & DNC
- Material Handling
- Oil & Gas
- Packaging
- Pharmaceutical
- Power & Energy
- Transportation (Microsite)
- Water & Wastewater
- Event Portals
- Hannover Messe
- Industrial Automation NA
- ISA Automation Week
Thinking of Using Microsoft Windows NT or XP Embedded?
A report for OEMs and manufacturers who are considering the use of Microsoft Windows NT or XP Embedded in their manufacturing equipment and processes.
The use of Microsoft Windows NT and XP Embedded operating systems offers many attractive benefits while providing rich functionality that can be added to an embedded application. It is important to recognize that to effectively utilize these operating systems, some very important issues must be considered that will affect the way your application runs today and into the future.
Understanding the Use of an Application is Essential to Successful Implementation
How is the system going to be used today and in the Future?
Electronic devices with intelligence all use an operating system of some nature. For this reason there is literally thousands of operating systems. Many of these are considered embedded because they are highly specific and dedicated to one platform and/or application. Microsoft Windows NT and XP are commonly used in commercial PCs, medical applications, factory automation, and many other applications around the world. These feature rich and broadly supported operating systems have become the universal favorite for many applications. The advantages of using these systems are appealing for many applications. However, with their comparatively larger size (footprint) and overhead, some applications cannot effectively use these operating systems.
Microsoft
offers Embedded versions that can overcome the size and overhead issues.
Chart A (Page 8) describes
some of the advantages of using these embedded operating systems in an
application. With the use of these
versions a solid understanding of the application and its future uses is
essential to the successful implementation of the system.
The
benefits and features associated with the Microsoft Embedded operating systems
make the choice to investigate the use of this option in an application an easy
one. When considering the use of
one of these operating systems there are some hidden issues and concerns that
need to be understood. The
remainder of this paper is dedicated to presenting these issues and concerns so
that the decision and implementation plans will be successful.
The intent is not to provide a step by step process for implementation
but rather to provide a checklist of issues and concerns that can be utilized to
make an educated and successful decision.
"I need Embedded NT on
a cost effective solid-state device so that the hard drive can be eliminated,"
is one of the most frequently requested options heard from Xycom Automation
customers. It becomes very obvious
that many times the entire nature of this request is not completely understood.
Windows NT or XP Embedded in its full form can easily be loaded on a
system. To address the second part
of this request (elimination of the hard drive), the customer needs to
understand what reducing the size of the operating system means both to the
application and to the supplier of the system.
This leads to an important question: "How
is the system going to be used today and in the future?"
As much as many suppliers wish they could answer this for the customer,
the use of the proposed system needs to be determined by the customer and/or the
end user.
Understanding
the Image Development Process
The
first step in deciding to use these operating systems is the understanding of
the image development process associated with the implementation of a reduced
size image for the system. To
reduce the size of the image, features and/or services need to be eliminated.
Without a clear understanding of which devices and applications are going
to be used with the system, a reliable and successful system cannot be
developed. Microsoft supplies a
toolkit for customizing the embedded operating system image called Windows
Embedded Studio. Included in the
Windows Embedded Studio toolkit are Target Designer, Component Designer, a
Component Database and Manager, and Platform-specific tools.
An understanding of the process and each of these tools is crucial to the
success of the decision to use one of these embedded operating systems.
A development process overview, footprint configuration overview, and product datasheets are available at http://www.microsoft.com/windows/embedded/. The steps in the development process as presented by Microsoft are as follows:
1.
Identify the hardware on your target device.
2.
Choose the features and functionality required in your run-time image.
3.
Identify the embedded system-specific features that need to be included
in your target device.
4.
Include custom components.
5.
Build your run-time image.
6.
Deploy your run-time image.
Example
issues and concerns associated with each of these steps are discussed
individually in the following paragraphs and are not to be construed as
instructions.
Hardware
The device supplier, unless
supplying the entire system, cannot determine the additional devices that will
be added to the system. Items such as additional I/O device network connections,
programmable controllers, vision systems, motion control systems, scanners, data
acquisition boards, and many others can only be decided by the OEM and/or end
user of the device. When making a
smaller footprint operating system, support for these may not be available if
not included in the original image. For
example, Xycom can supply an industrial computer with a solid-state storage
device and a reduced size operating system, but if the system has one of the
previously mentioned hardware devices added, it might cause the system to
function improperly. For this
reason it is important that the OEM and/or the end-user be involved in the
development of the original run-time image.
Features and Functionality Embedded operating systems offer a vast array of features to choose from, unlike full system installations that offer fewer choices of selectable features. While a normal NT or XP installation allows the user to decide whether or not to install Internet ExplorerÔ, the home page and title bar can be set for the browser using Microsoft Target Designer. The OEM or end-user will be ultimately responsible for what applications will be added after receipt of the base system. If an application that requires browser support is added and the browser was not included in the run-time image, then the application might not run properly. This is another example of the importance of the OEM and/or end-user's involvement in the development of the original run-time image.
Embedded
System-specific Features In some
cases, the embedded operating system is intended to run on a standard personal
computer. However, many times embedded devices have different requirements,
including no display capabilities or no writeable hard drive.
The use of smaller solid-state media to store the image is another
consideration often included in an embedded application.
With reduced sized media, data may be unable to be stored for extended
periods or swap files may be unable to be utilized.
The size of the media and how the system is intended to be used are key
in making the correct image. A
failure due to insufficient storage space after implementation will not be an
acceptable scenario.
Custom
Components
If the extensive list of available components supplied with these embedded
operating systems need to be supplemented, it can be done during the development
phase. These embedded operating
systems, unlike a normal desktop system, are intended to be very dedicated to
specific tasks and not continually altered after implementation.
Adding components after the image is made may cause the system to
improperly function if a feature/service is unavailable.
Third party vendor components, INF files, and other utilities can be
directly added to the run-time image before deployment by using Microsoft Target
and Component Designers.
Build
the Run-time Image
Building the image for these embedded operating systems differs from building an
image from source code. By using
Target Designer, the image is generated by reassembling the individual
components to create the operating system.
With the use of Windows Embedded Studio, dependencies can be checked and
resolved before building the run-time image.
Files and resources can be assembled, directory structures generated,
files copied to the appropriate directories, and registry hives can all be
accomplished before the image has been finalized.
This process may require multiple attempts if all devices, features, and
services needed by the end-user have not been addressed completely.
Deployment
of the Run-time Image
The image created on the development system will then need to be transferred to
the target platform or device. Once the target device has been deployed, it may
be difficult to add software and/or additional hardware without using Windows
Embedded Studio. Examples of problems that can be associated with adding
devices, software, or services are:
·
No CD-ROM support How will
software be installed?
·
No network services included
How will the unit be connected to the enterprise network in the future?
·
No user interface (display)
capability How will the end-user work with the system?
·
Did not load Internet Explorer
How will software be added that requires it?
Once
the run-time image has been determined, many suppliers can provide a target
device with the developed run-time image included.
Hardware
Selection
Now
that the development process is understood, selecting the hardware platform or
target device is important. The
requirements for an application will most likely control the type of hardware to
be selected. Once the hardware
platform is selected, all auxiliary devices and application software
requirements need to be determined.
One
consideration in selecting the hardware is the use of a hard drive. Solid-state,
or CompactFlashÔ
memory devices in some cases, are significantly more reliable than the
traditional rotating media hard drive. Applications
that require significant levels of shock and vibration may require the hard
drive to be eliminated and replaced with solid-state media.
If a hard drive can be eliminated, then the use of the Microsoft Embedded
operating systems may prove to be very beneficial.
The single most important item that will affect the system is the use of
swap files. The standard NT and XP
operating systems use swap files that can significantly increase the amount of
storage required. With standard
operating systems, the size of the swap files can be reduced but not effectively
disabled. However, with Microsoft
Windows NT or XP Embedded, this function can be disabled if desired.
Unlike hard drives, most solid-state media have a limited number of
"writes" and "re-writes". The number is usually very large and
corresponds to one segment of the media. CompactFlash, for example, has built-in
software, which distributes each "write" so that one area is not
overburdened. A good understanding
of the application and how it will be used is essential to successful
implementation.
The
decision to store data on solid-state media for future reference is a major area
of concern. 256 MB of CompactFlash
storage will be filled more quickly as compared to the capacity of a 20 GB hard
drive. The use of networks to store
the data elsewhere, or the use of a hard drive only for storing data, are both
options that may be available for the application.
To emphasize the importance of the storage device choice, when a
solid-state media (hard drive) fills up, the system and application may
terminate unexpectedly. This is an
unacceptable situation in today's manufacturing environment.
Procurement
of the hardware is another concern. Asking
a hardware supplier for a system with Windows NT or XP Embedded on CompactFlash
is not enough information for the embedded system.
For instance, Xycom could create images and ship product, but if
additional hardware and/or software are added that is not fully supported by the
image, then the hardware may not function properly.
On the other hand, Xycom could pre-install a customer-supplied image on
the hardware platform of choice. Often times, there are several layers of
suppliers, distributors, and/or manufacturers that may not entirely understand
the application, decreasing the probability of successful implementation.
When the end-user plays an active role in determining the run-time image,
the probability of successful implementation of hardware and software is
significantly greater.
Application
Software Selection
There
is a multitude of applications to select from supported by Microsoft Windows NT
and XP. This is one of the major
advantages to considering Microsoft Windows NT or XP Embedded. Selecting the one(s) for the application is important.
Once all have been selected, it is mandatory to investigate and analyze
the image to assure that all functions of the package(s) selected are supported.
Microsoft supplies tools in the Windows Embedded Studio toolkit to aid in
this process.
It
is recommended to include your application in the image so that every unit is
set up exactly the same. This is
another example of how important the OEM and/or end-user is in the image
generation process. Hardware
suppliers can pre-install the image as supplied by the customer, but asking the
hardware supplier to load an Embedded operating system without pre-determining
this information may result in a less satisfactory solution for both parties.
Component
Selection
With
the hardware platform and the application software selected any additional items
need to be determined. These
include serial devices, expansion cards, separate controllers, external devices,
and additional software that may be required.
These all need to be supported by the generated image.
The Windows Embedded Studio toolkit needs to be utilized to check for
dependencies and support.
Any
software, drivers, or files that are needed for support should be included in
the image. These support files can
be pre-loaded, but without knowledge of any additional items, the image may
prove to be unsuccessful. A good
example is when the creation of an original run-time image did not include
parallel port services because a printer was not required. Later on, when a
software application is added that requires a parallel port hardware key, the
added software will not work.
The
Future
Now
that the current application has been determined, the question, "How will this
device be used in the future?" needs to be answered.
Although the system may run the current application successfully, it may
not run correctly when different components or software are added in the future.
Understanding and including all devices and software for the application is
important, so too are future additions to the application.
Many Windows NT or XP Embedded devices will be deployed as dedicated
computers. But in the future, these
devices may be perceived as typical computers that allow software and other
devices to be added relatively easily. These
new devices or software will need to be re-evaluated using the Windows Embedded
Studio toolkit and a new run-time image downloaded to the platform.
Summary
Microsoft
Windows NT or XP Embedded operating systems are very appealing choices for many
applications. With their many
features and benefits, time to market can be significantly reduced over the
development and introduction of a proprietary operating system. The use of these Embedded operating systems requires more
understanding of the application than the implementation of a more traditional
commercial operating system.
Many
concerns and issues have been discussed throughout this paper and are summarized
in Chart B (Page 9). It is hoped
that this chart can be utilized as an aid in a decision to implement an embedded
operating system into an application successfully.
If all issues and concerns are thoroughly considered and the Microsoft
Windows Embedded Studio toolkit utilized, then the probability of successful
implementation will be greatly increased.
Before
deciding to use these Embedded operating systems, the issues and concerns
presented here, as well as a complete understanding of the Microsoft Windows
Embedded Studio toolkit and development process should be addressed.
Additional information is available about the embedded operating systems
on the Microsoft web site at http://www.microsoft.com/windows/embedded/.
Guide to Developing with Embedded
Windows and several other resources are available at http://www.bsquare.com.
Xycom
Automation welcomes customers to work closely with us for integrated hardware
with preloaded Windows NT or XP Embedded run-time images. Our combined efforts
will pay off with successful implementation for today and tomorrow.
Chart
A: Features & Benefits of NT and XP Embedded
|
·
Scalability |
·
The overall size of the operating system can be condensed by
removing unneeded features and services ·
Allows the use of smaller solid-state storage media to be utilized
(eliminate hard drive and rotating media) |
|
·
Built-in networking and communication services |
·
Allows use of TCP/IP, DHCP, WinSock, RPC, RRAS, FTP, etc. |
|
·
Interoperability with existing PC and
server hardware |
·
Provides greater choices and flexibility when choosing your
platform |
|
·
Win32 API support |
·
Provides consistent development environment |
|
·
Windows services support |
·
Allows greater manageability |
|
·
C2-level security |
·
Supports applications that demand secure environments |
|
·
Systematic multiprocessing support |
·
One solution provides a system that can be used for simple and very
demanding applications |
|
·
Reduces time to market |
·
Powerful authoring tools allow easy integration into your platform ·
Less time developing and supporting proprietary OS code ·
Less time developing drivers, services, applications, and getting
them to work |
|
·
Broad range of productive Windows-based development tools |
·
Many trained and experienced developers ·
Multitude of off-the-shelf hardware and device drivers ·
Large number of existing Win32 applications ·
Microsoft BackOfficeÒ
family applications |
|
·
Easy enterprise connectivity |
·
Allows easy integration of new opportunities with an existing IT
infrastructure ·
Devices that can be introduced and managed like other Windows-based
systems ·
Next generation devices can participate in enhanced management
environments (examples: Microsoft Systems Management Server, HP OpenView,
IBM Tivoli, CA Unicenter TNG, etc.) |
|
Source:
Microsoft Corporation |
|
Chart
B: Issues & Concerns for Successful Implementation
|
·
Microsoft Windows NT or XP Embedded |
·
Do you have a complete understanding of your application today and
in the future? ·
Do you have the right software expertise to access? ·
Do you have the Windows Embedded Studio toolkit? If not, how can it be accessed? |
|
·
Implement an Application Software Package(s) |
·
Is all required functionality in the run-time image? ·
Will any functionality be added in the future?
If so, is it supported in the image? ·
Have you utilized the tools included in Windows Embedded Studio
toolkit? |
|
·
Eliminate rotating media (hard drive) |
·
Can operating system image be reduced? ·
Is all functionality included in the run-time image? ·
What size solid-state device will be required? ·
Are swap files being used? If
so, is the solid-state media correctly sized? ·
Are you going to store data? If so, where? ·
How many "writes" will be required of the solid-state device in
the normal use of the application? |
|
·
Additional hardware added to the platform |
·
Is the hardware supported by your image? ·
Are all required drivers in the run-time image? ·
Will anything be added in the future?
If so, is it supported in the image? ·
Have you utilized the tools included in Windows Embedded Studio
toolkit? |
|
·
Additional software added to the platform |
·
Is the Software supported by your image? ·
Will anything be added in the future?
If so, is it supported in the run-time image? ·
Have you utilized the tools included in Windows Embedded Studio
toolkit? |
|
·
Procurement of a hardware platform with Windows NT or XP Embedded
pre-installed |
·
Has everything been considered and included in the creation of the
image? ·
Who will be responsible for the image? ·
Have you utilized the tools included in Windows Embedded Studio
toolkit? |
|
·
Additional software or hardware in the Future |
·
Does the original image need to support these? ·
Who will create and verify a new image when items are added? ·
Are you expecting your system to be a typical computer? If so, maybe use of an embedded operating system is not the
right choice. |
This article is written and provided by Ralph James Damato, Business Unit
Manager at Xycom Automation. Xycom Automation is recognized as the market leader in providing industrial computer products designed specifically to operate with maximum reliability in a wide variety of manufacturing and process control environments. For more information about Xycom, please visit their website at www.xycom.com.