Rick Lee and Jack Chuang, ADLINK Technology Inc.

General Embedded Controllers (GEC) respond to the needs of typical Industrial Computer (IPC) monitoring applications by providing a development platform on PC-based architectures. General represents the essential functions provided by the controller required for standard IPC administration (such as motion control, vision processing and capturing, analog and digital I/O control, RS-232/422/458 support, etc.). Embedded describes how the GEC is well-suited as a central controller for nearly every type of system with its minimum space requirements and exceptional design. And Controller symbolizes how system designers can utilize software tools to develop applications because of the GEC's ability to execute controller logic programs. Programmable Logic Controllers (PLCs), while widely used, are unsuitable for computer software and networking applications due to expandability issues and expensive modules. However, next generation GEC controllers offer high speed and simple operation at a low cost to easily connect to various data systems (administration systems, HMI, databases, etc.) for efficient performance. This article will reveal the GEC architecture and characteristics as well as discuss practical applications.

 GEC System Architecture

In a nutshell, a GEC controller is simply a PC-based controller. Therefore, we can separate it into two parts: software and hardware (see Figure 1). Its hardware is comprised of the CPU and I/O interface. CPU and I/O requirements vary from application to application. As for the software, the selected OS is the most important factor to ensure that the controller will meet the needs of the application.

 CPU

Because the CPU is the core of the system's hardware, GEC systems are built with the application requirements in mind when selecting its CPU. Because industrial computer controllers have uses in a wide variety of applications, from simple digital/analog signal controllers to complicated motion controllers and vision monitoring systems, its required computing power can vary greatly. For example, a Pentium-grade CPU would probably be sufficient for typical digital/analog signal or small (1-3 axes) motion controller applications. However, the same CPU would be horribly insufficient for complex video capturing and monitoring, or multi-axis motion controllers, etc., where a Pentium III would suffice. Solutions should be built up at reasonable costs to meet the needs of system developers by selecting an appropriate CPU. GEC is developed under this concept.

Figure 1: GEC System Block Diagram

 Form Factor

Typical embedded industrial controller applications have space limitations and cannot use standard IPC form factors. In view of this, GEC was especially design stressing compactness and heat dispensation ability. Even though GEC fits tightly in a little box, it still standard buses (PC-104 (ISA) and PMC-PCI) to ensure flexibility and expandability for integration with peripheral interface cards.

 IO

Because GEC is a general embedded controller, how can its interfaces (PMC and PC-104) and limited space be utilized to meet the needs of the greatest number of customers possible? Simple! By offering multiple types of I/O interfaces that offer the best configuration flexibility for virtually every application need:

• Motion Control Interface Module
• Video Capture Interface Module
• RS-232/422/485 Communication Interface Module
• CAN bus Communication Interface Module
• High Speed Link Interface Module for DI/O and AI/O signal
• Digital I/O Control Interface Module
• Remote Control Interface Module

 Operating System Selection

If you liken the GEC hardware to a human body, the I/O would be the eyes, ears, hands, and feet; the CPU and bus are like the nervous system; and the software is like the brain, a complex procedure coordinating every operation of the controller. Hence, the OS's importance is beyond compare as it is responsible for managing core tasks and resource allocations of the PC. It not only affects future system execution time and efficiency, but also resource requirements during software development for the whole application. Selecting a suitable OS aimed at different application requirements is an important topic for system developers. When choosing an OS, they need to consider a few points: stability, real-time capability, multitasking, human-machine interface (or GUI), memory size, total cost (including application development costs, licensing costs for multiple copies, software engineering manpower, maintenance costs, etc.). There isn't, necessarily, a right and wrong or good and bad. System developers should look at the overall picture of the application and focus on what provides the optimal solution for the developed system when considering this issue. In this respect, GEC is compatible with several operating systems, including the ones shown below:

 Embedded NT/ Embedded XP

Windows NT is a multitasking OS known for its stability. As a result of its overwhelming popularity, human-machine interfaces, and development tools are plentiful, making developing applications in Embedded NT comparatively simple. Microsoft carried over the advantages of Embedded NT when releasing Embedded XP. Generally speaking, the concept behind the design of Embedded NT/XP is simply a modularized Windows NT/XP. System developers only select the needed NT/XP components and functions and then organize them together to construct an Embedded NT/XP OS. As for the concept of architecture modularization, system integrators can readily reduce the storage space requirements of Embedded XP to 256MB or lower. The only factor in selecting storage space size is determined by the number of needed function modules. Because Embedded XP is completely compatible with Windows XP, developers can simply compile controller software in Windows XP, and then copy over to Embedded XP for immediate use. System developers do not need to learn any new tools and experience on Windows XP can be directly transferred-lowering software development costs. The only major issue lies in the cost of licensing Embedded XP.

 Windows CE

With the release of Windows CE 3.0, you can see that it inherits the Windows GUI. Even Windows CE 4.2 sports a fresh new look. Because Windows CE is designed with embedded systems in mind, its required storage space is much less than Embedded XP. 64MB of storage is the typical size need for a Windows CE system. However, it is still possible to use less storage space if needed. Windows CE impressively supports important real-time functions, and holds true to the familiar Windows GUI. Microsoft has tried to keep API naming conventions and development time consistent between Windows CE and Windows XP. However, because Windows CE is an embedded architecture, unlike Windows XP's desktop system concept, the software development process will still have differences. Newcomers to the embedded world must keep this in mind. Nevertheless, Windows CE licensing costs, thanks to Microsoft's recent promotions, is much less than Embedded XP.

 Linux

Linux is well known for its stability and free licensing. In server and networking applications, Linux holds 30% of the market. But in the PC-based controller arena, Linux support is still in the early stages. Linux's real-time ability is not very apparent. Its high level user interface is not common with what software engineers may be accustomed to. As for development issues, its numerous kernel versions can create a headache for engineers. Compared to Windows, finding bugs or performing maintenance can be more difficult. However, because Linux systems use open licensing methods, system developers can save lots of money by not having to buy Windows CE or Embedded XP licenses. From a technology standpoint, as long as the software engineers have kernel development and maintenance experience, Linux can be a very cost-effective solution.

GEC Application Example - Remote Administration System for Tunnels

 Background

In Taiwan, tunnels are a vital part of the transportation network because of the mountainous geography and emphasis on efficient metropolis land use. Consequently, there are numerous large-scale long tunnels, and more on the way. With a humid environment and exhaust accumulation from passing vehicles, inadequate air quality regulation can become a safety issue to travelers and road workers. Long tunnels can make it difficult to achieve adequate airflow. Previous monitoring solutions used a PLC to implement a fixed timed inner-tunnel air quality monitoring and regulation system. This "fixed" method cannot truly monitor and control the tunnel environment and make timely adjustments. Once the system is set, it runs continuously. Some day, if the air flow needs to be adjusted, then the whole box must be swapped out, making expansion costs extremely expensive. Even to update a traditional PLC system to use Ethernet or the latest networking technologies to connect the monitoring system to a centralized control station will require a large establishment cost. In comparison, because of the horrible tunnel environment (humidity, poor air, vibrations from traffic, etc.) a standard industrial computing (IPC) solution would not be a suitable replacement for the PLC. Standard IPCs would have a difficult time surviving for an extended period of time.

 Solution

After describing a marketplace problem, we will discuss GEC as the solution. First, we need to understand the overall monitor system requirements and design around the information system (Honeywell EBI controller software) and its signaling and timing requirements. Separate the tunnel monitoring system into 10 sub-systems. Each sub-system is centrally controlled with a GEC (the ADLINK GEME-1000), and data collection is provided by the ADLINK NuDAM-6000 remote monitoring module series. GEME-1000 and NuDAM-6000 communicate via its serial COM port.

Now that the low-level monitoring equipment connection is established, we can then tie-in communication with a central control center by using Microsoft's leading OPC Server/Client (TCP/IP) protocol over a 100MBps Ethernet line. We installed Embedded XP on a CompactFlash (CF) card for GEC's OS. A CF card was selected be cause of the severe environment inside the tunnel. The CF's slot style is very reliable and is not prone to failure under vibration like hard disks. Embedded XP was built from the various main Windows software functions (OPC, Network Neighborhood, File Sharing, etc.) and selected for optimal compatibility (the control center uses Windows 2000 and up).

Important advantages to this system setup include total cost savings, and low maintenance costs (compared to traditional PLC systems). If you need to add more monitoring points in the future, you don't need to change out the distributor box, just add another NuDAM-6000 control module. Moreover, GEC uses Embedded XP's network file sharing utility, making controller application updates a breeze for system developers. You can easily update the system's software from the control center without having to subject personnel to the dangerous and difficult environment inside the tunnel.

Figure 2: The Tunnel's Remote Controller System Architecture

 Conclusion

Following the progression of software and networking technologies, many ideal solutions, previously thought to be impossible, are now gradually becoming reality; therefore leading to the GEC (General Embedded Controller) concept, a direct product resulting from recent technology development trends. The compact GEC design is derived from the concept of embedded applications, and its practical applications come from a diverse selection of CPUs (Pentium to Pentium III) and storage devices (HDD or CompactFlash cards), and a complete line of hardware interfaces (motion control, video capture, serial bus, CAN bus, high-speed serial I/O, digital signal control, and remote monitoring modules)-all based on meeting cost and hardware requirements. Additionally, embedded OS technology utilizes familiar Embedded XP, Windows CE, Linux, etc. software development environments. The technology has already matured. Restrictions of the past are no longer relevant. All you need to do is determine what hardware equipment is appropriate for your application.