The real-time tasks of CNC refer to the dis- posal of acceleration/deceleration, interpolation, position control, discrete logic control etc。 These hard real-time tasks must run in the RTX environ- ment to fill their time requirements。 RTX supports OO programming technology and provides a wizard kit in Visual C++ environment。 The hard real-time tasks are developed in RTDLL provided by RTX。

Similar to Windows’ DLL in conception, RTDLL  can  be  dynamically  loaded  in  RTX envi-

ronment。 By extending Windows’ operating systems, RTX enables application components or  modules that require deterministic and high-speed response times, and other non-real-time application compo- nents to work together in a common Windows’ sys- tem。

RTDLL’s real-time capability is guarantied by the real-time APIs provided by RTX。 RTX adds a real-time subsystem, known as RTSS, to Windows NT and Windows 2000, XP。 In conception, RTSS is like other Windows NT subsystems (such as Win32, POSIX, WOW, and DOS) in that it supports its own execution environment and APIs。  However, the main difference lies in that RTSS, obviating the Windows scheduler, performs its own real-time thread scheduling。 Furthermore, in a uni-processor environment, all RTSS thread scheduling occurs ahead of all Windows scheduling including Win- dows-managed interrupts and deferred procedure calls (DPCs)。 RTX supports various runtime librar- ies, and provides a 'C' runtime library based on MS Visual C++。 RTSS processes can be statically linked so as to include these libraries unless they do at- tempt to link to unsupported Win32 functions。 RTSS processes can also be linked into specialized ver- sions of dynamic link libraries (DLLs), which  can be used to modularize real-time application code or provide run-time customization of real-time soft- ware environments。

3。3 OMAC  and  its  API  in HIT-CNC

The OMAC users group is of an industry fo- rum aimed at advancing the controller technology[9]。 An effort has been made within OMAC to define API specification for the purpose of submitting it to an established standards body one day。

The OMAC API adopted a component-based approach to achieve plug-and-play modularization by making use of interface classes to specify the API[9]。 For distributed communication, compo- nent-based technology uses proxy agents to tackle method invocations that cross process boundaries。 OMAC API contains different “sizes”  and “types” of reusable  plug-and-play components  inclusive  of

· 276 · MA Xiong-bo et al。 / Chinese Journal of Aeronautics 20(2007) 272-281

component, module, and task—each containing a unique finite state machine (FSM) model to perform component collaboration in a definite manner。 The term “component” applies to reusable pieces of software acting as a building block in use, while the term “module” refers to a container of components。 Tasks amount to those that are used to an encapsu- late programmable functional behavior comprising a series of steps from start to finish supporting start- ing, stopping, restarting, halting, and resumption, and may run multiple times while the controller works。 Tasks can also be used to build up controller programs consisting of a series of tasks with ability to restart and navigate, or as standalone resident tasks to cope with specialized controller require- ments。

To integrate components, a framework is nec- essary to formalize the collaborations and other life cycle aspects in which components operate。 The OMAC API uses COM as the initial framework to develop components so that control vendors could concentrate on application or specific improvements to define their strategic market-share as opposed to spending valuable programming resources rein- venting and maintaining  software “plumbing”[1]。 The lack of hard, real-time preemptive scheduling once posed the primary problem with COM frame- work, especially for the Windows NT operating system, but it is resolved in HIT-CNC by third party extensions of Windows NT as RTX。