At the present time Windows NT is being deployed in a high speed manufacturing factory floor setting at my site. There is a continuous need to improve automation manufacturing processes at assembly stations, test stations, automated data collection and distributing cross resource sharing of information between a variety of legacy systems, UNIX and Windows NT servers and workstations at different locations. Some workcells have real-time requirements to perform a specific function. The factory floor applications that run at workcells need to be designed to support true distributed applications. We need to develop best practices and innovative ways and techniques of using DCOM and COBRA capabilities with multimedia information and to share it between manufacturing work cells, raw material supply and product distribution material chains. Another issue is some developers of custom factory applications have requested a diskless version of Windows NT workstation client being supported.

Often a discussion will develop among Engineers when to use Windows NT and not to use Windows NT and how to customize it when building application software for manufacturing assembly and test workcells that have "soft" and "hard" real-time requirements. Some of the perceived short comings of using Windows NT for "hard" real-time are in adding more priority levels, solving priority inversion, configurable third party device drivers, timing of the OS when interrupts are masked and the time system calls take (context switcing). These type issues can seriously affect using Windows NT making it a less than desirable candidate to support "hard" real time software applications.

For instance priority inversion occurs for example when the lowest priority thread has a locked resource (shared with the highest one) while the middle priority thread is running, the highest priority thread is then suspended until the locked resource is released and the middle priority thread stops running. In such a case the time needed to complete a high priority level thread depend on a lower priority level - "priority inversion". To fix this problem the real time OS (Windows NT) should allow priority inheritance in order to boost the lowest priority thread above the middle thread up to the requester. Priority inheritance means that the blocking thread inherits the priority of the thread it blocks. This is only the case if the blocked thread has a higher priority. An argument against this is that a correct design should avoid the problem. While this may be the true, for complex applications these issues are real and need to be addressed.

Alan Burch
E-Mail: aburch@vcd.hp.com