Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Real-time Support in COM Deji Cheny? Aloysius Moky Mark Nixon? y ? Department of Computer Sciences Fisher-Rosemount Systems, Inc. University of Texas at Austin 8627 Mopac North Austin, TX 78712, USA Austin, Tx 78759 fcdj,
[email protected] Abstract While there has been substantial work on real-time CORBA — to offer real-time support in a distributed heterogeneous environment with standard real-time middle-ware, comparatively less work has been done to investigate support for real-time applications in COM, the direct competitor of CORBA. In this paper, we examine the COM technology and explore the possibility of providing real-time support in COM. We argue that real-time COM should provide a policy specification interface between the application and the underlying (real-time) operating systems that is as declarative as possible, and we conclude that COM can be extended to provide various real-time support services through this interface. We shall discuss an experimental prototype targeted for real applications along the line of our proposal.
1 Introduction Even though the concepts of abstract data types and object-oriented computing have been discussed in academia for quite some time, it is the growth of the Internet that has helped bring about a paradigm shift in industrial computing from homogeneous systems to heterogeneous objectoriented distributed systems. The key issue in a heterogeneous environment is inter-operability. In the new paradigm, an object in one node invokes an object in another node through a predefined interface. This interface allows an underlying run-time system to use a standard protocol to pass object invocations through the communication network. In the last few years, There has been a huge effort to standardize the way through which objects talk to one other. The two dominant standards are the Component Object Request Broker Architecture(CORBA) from Object Management Group(OMG) and the Component Object Model(COM) from Microsoft Corporation. These two competing standards have generated much debate between
the two camps. Interested readers can find some of the discussion in, for example [3]. While many application developers embrace this paradigm shift, the lack of real-time support in these standards has become obvious. In response, OMG formed a special interest group in 1995 to extend CORBA with realtime support, and there has been lots of research since then on real-time CORBA [4, 5, 6, 9, 15, 17]. Similarly, the lack of real-time support in COM has become an important issue, e.g., in the process control industry. From the first introduction of Distributed Control System (DCS) in the 1970’s, the control industry is progressing towards a second architectural shift towards Field-centric Control Systems. In the new architecture, the DCS moves from the center of the architecture to being, in effect, another node on a field-centric network. Intelligent devices become information servers in the field-based architecture. Other parts of the industrial plant that need to exchange information with field devices, such as maintenance or engineering, should be able to access these devices directly as objects. The OPC(OLE for Process Control) is a set of COM interfaces to standardize the mechanism for communicating with numerous data sources, either devices on the factory floor, or a database in a control room. The next-generation scalable distributed control systems are being built based on PC workstations utilizing COM technologies. The cost saving of the new architecture for end users can be phenomenal. According to a Canada-based chemical firm’s own figures, the new technology reduces typical installation costs by 30% and typical configuration costs by 60%. This kind of cost-saving will accelerate the shift to distributed object-oriented technologies. While a number of researchers are working on real-time CORBA, there is, to our knowledge, no comparable work done on extending COM with real-time support in the literature. Some of the real-time CORBA technology can be applied to extend COM. Nonetheless, CORBA and COM are competing technologies with different constituencies; for example, the real-time extension of CORBA seems to
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
1
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
be motivated heavily by avionics software. In considering COM for industrial control applications, we do not want to simply borrow real-time CORBA to fit COM. We want to take a top-down look at how to provide real-time support for industrial control with COM technology as a possible vehicle. We conclude that COM is well positioned for extension to accommodate real-time requirements in the process control industry. The paper is organized as follows. Section 2 summarizes the relevant features of the COM architecture, the OPC standard, and the need for real-time support in COM. Section 3 examines COM from the perspective of real-time process control. We discuss how to enhance COM and describe a proxy/stub design for the purpose. Section 4 discusses our implementation of the design. Finally, section 5 concludes the paper.
IUnknown IReadData COM Object
Figure 1. a COM Object
} And here we define an interface that has one method to read a float value.
2 COM and OPC
[
Since it is beyond the scope of this paper to explain all the technologies of COM [1, 2], we shall only talk about in this section the major parts of COM which are needed for real-time requirements analysis. Many special technologies of COM such as strong lock, moniker, etc. will not be addressed here. The general design principles for the real-time extension presented in this paper can be extended to cover the full scope of COM.
] interface IReadData : IUnknown { HRESULT Read( [out] float * pfltValue); }
2.1 COM Interface and COM Object Just as in CORBA, the interface between the client and the server is defined in an Interface Definition Language(IDL) file in COM. All COM interfaces are children of interface IUnknown: [ local, object, uuid(00000000-0000-0000C000-000000000046), pointer_default(unique) ] interface IUnknown { HRESULT QueryInterface( [in] REFIID riid, [out, iid_is(riid)] void **ppvObject); ULONG AddRef(); ULONG Release();
uuid(8CE62D90-C73E-11D1BC25-00A024074D2D), pointer_default(unique)
Once published, an interface can never change and takes a Universally Unique Identifier(UUID) defined by OSF/DCE(Open Software Foundation/Distributed Computing Environment). A UUID is a 128-bit integer that is virtually guaranteed to be unique in the world across space and time. The UIID of IUnknown is 00000000-0000-0000C000-000000000046. Through interface UUID, any client that understands a certain interface can talk to any COM object that supports the interface. In C or C++, the IDL compiler reads an IDL file and generates a header file for interface definition and a C file for UUID definition. A client application includes the files to access the interfaces; a server application includes the files to implement the interfaces. A client accesses a COM object only through interface pointers. A COM object supports a set of interfaces, and keeps count of outstanding interface pointers to it. If the counter goes to 0, the object terminates itself. The client calls IUnknown::AddRef() and/or IUnknown::Release() to increase and/or decrease the reference count on the server; the client calls IUnknown::QueryInterface() to get another interface pointer. All objects must support IUnknown. Figure 1 is the graphical representation of a COM object that supports IReadData and other interfaces.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
2
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Client
Server 8,9,10
Proxy
1
RPC Channel
7
Stub
5 4 3 6
COM
Client Machine
2
COM
Server Machine
10. When the client is done with the server, it calls IUnknown::Release(); the proxy notifies the stub and disconnect the RPC channel. Both proxy and stub are finished and wait for the containing process to discard them. If the client and server are at the same node, the client side COM and server side COM become one, and the RPC channel is reduced to lightweight RPC; if the server is a DLL, the server is loaded into the client space, and the client calls directly into the server. We will not address the last case in this paper. COM is also called DCOM(Distributed COM) when the client and server are on different nodes.
Figure 2. COM Architecture
2.3 OPC 2.2 COM Architecture COM is built on the OSF/DCE RPC(Remote Procedure Call) specification. Figure 2 depicts the common sequence of a client reading value through IReadData from a COM server. 1. The client calls CoCreateInstance(), passing in the server UUID and the IReadData UUID. 2. The client side COM locates the server node, passes the call to the server side COM. 3. The server side COM launches the server. 4. The server starts up, registers itself, creates the COM object, registers the COM object. 5. The server side COM injects the stub into the server space, gets standard marshalling packet of IReadData from the stub. 6. The server side COM returns necessary information to the clients side COM. 7. The client side COM injects the proxy into the client space. passes in the marshalling packet. 8. The proxy establishes RPC channel with the stub, returns proxy interface pointer to the client. At this point, the client and server are connected directly through the RPC channel. 9. The client calls IReadData::Read(); the proxy packs up the call and sends to the stub, which unpacks and calls the actual function in the server; The server executes IReadData::Read(); the stub packs the return info, sends back to the proxy, which unpacks the return value, and returns to the client.
OPC is a set of COM interfaces defined by the OPC Foundation which is supported by over a hundred companies in the process control industry. The architecture of OPC leverages the advantages of the COM interface. It standardizes the mechanism for communicating to numerous data sources, be it a device on the factory floor or a database in a control room. With OPC, system integration in a heterogeneous computing environment becomes simple. The hardware manufacturers only need to make one set of software components for customers to utilize in their applications. Software developers will not have to rewrite drivers because of feature changes or additions in a new hardware release; customers will have more choices with which to develop advanced integrated manufacturing systems. OPC Foundation has published two sets of interfaces: the Data Access Custom Interface and the Data Access Automation Interface. Functionality such as alarm, security, and historical data handling will be addressed in subsequent releases. There are already many OPC client/server vendors including for example, Fisher-Rosemount and Intellution Corporation. Their control systems can now communicate with one another through OPC interfaces.
2.4 Real-time Challenges for COM The need for real-time extension to COM is driven by industrial needs as well as market forces, with the aggressive push from the Wintel platform on one side and the control industry’s fast adoption of the field-centric control system paradigm on the other. Unfortunately, COM was originally motivated by non-real-time applications. There is no concept such as deadline, priority, etc. in COM which dictate efficiency considerations and guarantees. Table 1 lists the time(in millisecond) statistics of a COM client talking to a COM server using IReadData. We tested both client/server
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
3
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Local Remote
Connect Read() Connect Read()
minimum 250.0 15.0 28753 15.0
maximum 547.0 16.0 38422 16.0
average 379.7 15.6 36354 15.6
Table 1. COM Connection Time Statistics (in millisecond)
connection establishment(step 1 to step 8 in Figure 2) and the actual Read() method invocation(step 9 in Figure 2). Each case was tested 10 times. the Read() takes about 10 milliseconds to finish. Note once connected, the remote read is fairly fast. We use workstations with dual 200Mhz Pentium Pro running WindowsNT on the same NT domain connected with category 5 twisted pair. Take OPC for example. Even though data read from an OPC server bears timestamps, there is no guarantee when the client will receive it in reasonable time; when an OPC client issues a write command, there is no guarantee when the data will be actually written by the OPC server. Practically, the following reasons make a real-time extension to COM difficult. 1. COM is designed to be location transparent. The client does not need to know where the server is. The server can be a DLL, a local server, or a remote server running on another machine. While it simplifies application development, it poses problem for real-time applications. As is shown in Table 1, different locality conditions exhibit different timing behavior. There is also considerable variability in timing even for the same locality condition. 2. COM was developed by Microsoft mostly for commercial applications. It lacks a clear demarcation between architecture and implementation. As a result, it is difficult to place a real-time extension in the right place. 3. Even though Microsoft has volunteered COM to be an open standard, not all the COM internals are transparent. 4. COM is built on RPC, RPC is, by design, synchronous. COM+ promises to provide alternate transports such as UDP. We won’t address this issue in this paper.
3 Real-time Analysis of COM In this section, we first explicate the idea that a real-time extension for COM should be placed within the layer that
Client
Server
COM
COM
OS
OS Network
Figure 3. COM as a System Layer passes real-time information between the application and the underlying Operating System (OS). Then we look at the real-time issue of a COM session: the connection establishment and the ensuring data communication. We shall propose the design of a real-time COM architecture.
3.1 Real-time COM Like CORBA, COM is a middle-ware standard. It is a layer on top of the operating system to provide seamless connection between the client and the server, as is depicted in figure 3. In order to provide real-time support in the distributed client/server environment, each layer in the system should have real-time support. The three major layers are COM, the OS, and the network. The network is sometimes considered as part of the OS. There are generally two types of real-time requirement – hard real-time and soft real-time. In hard real-time a deadline missing will cause catastrophic consequence; whereas in soft real-time it only degrades the performance. COM should not and could not provide hard real-time support if the underlying OS does not; if the network does not have guaranteed message delivery, a client cannot get guaranteed real-time service from another node even though both nodes are running real-time OS. In other words, real-time extension to COM has to be limited within the COM layer. It should not take over the duty of the OS such as task scheduling and real-time event handling. Realtime COM on top of a non real-time platform can only provide limited soft real-time support like monitoring timing behavior of the system. Real-time COM is a conduit. It provides the real-time COM interfaces to applications. The applications access the real-time feature through these interfaces. If the OS has real-time support, the support is passed to the applications via real-time interfaces of the OS; if the OS has no realtime support, the application can only get limited support that the COM layer is able to offer. The real-time support provided by real-time COM should fully exploit and could not exceed that of the OS and network combined. The idea is to avoid the danger of inventing yet another real-time OS. The real-time COM will have different levels of real-time
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
4
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
support depending on the OS and the network. Yet the interfaces exposed by real-time COM have to be uniform. The intended real-time COM should be implementable on various platforms and it ought to be possible to determine the level of real-time support that a platform can provide. Real-time COM is designed with COM. It should not change the COM architecture. The real-time support is an add-on to COM. In other words, non-real-time applications use real-time COM just like normal COM. Any platform that supports real-time COM supports COM; any real-time platform that supports COM can be extended to support real-time COM by modifying the existing COM layer; any platform that supports COM can be extended to have limited real-time support by modifying the existing COM layer. In summary, real-time support in COM should be isolated from the OS, generic to all possible platforms, and conceptually simple. It should be able to match the level of real-time support available from the OS in one direction and pass real-time request to the OS in another direction. In the mean time, real-time COM provides certain auxiliary real-time features. There are two interfaces which need to be considered: the interface between COM and the applications, and the interface between COM and the underlying OS. The former defines the way to express real-time requirements by the applications and real-time events monitored by the applications. Since it is exposed to the applications, it has to be platform independent. The latter heavily depends on the OS. It is hidden from the application developers and covers different implementation details for different platforms. As such, it requires commitment from COM developers such as Microsoft and other vendors for different OS support.
3.2 Real-Time COM Session Let us Look at Figure 2. There are two stages of a COM session: the client/server connection and the real client/server communication. The connection is heavily COM involved. Once the connection is set up, COM switches from an active to a passive role. Communication is straightforward through the standard RPC channel. The real-time connection has semantic importance which may be safety-critical. In the process control industry, the timing requirements are usually less stringent but a violation must nevertheless be detected and remedial actions taken. In other words, a real-time extension to COM must eventually supply provisions for handling timing constraints dynamically. Note in COM the connection is established with a system call CoCreateInstance(). The call goes through sophisticated COM mechanisms including activating the server, injecting proxy/stub, etc., and finally connecting the client to the server. One approach for a real-time extension would
be to define a new system call that passes in additional realtime parameters. The real-time COM would then try to enforce the real-time requirement throughout the connection establishment. However, as we have argued in the previous sub-section, real-time COM should not take over the duty of the OS. Also note in Figure 3, the OS is exposed to the client application as well. The real-time connection responsibility of COM is on behalf of the client. We prefer that the real-time connection be negotiated between the client application and the OS. If the OS has real-time support, the client application is able to request it and, if accepted, get it for the COM connection. The real-time connection has not received much attention in real-time CORBA research. Just like the real-time COM connection, an application should also be able to depend on real-time behavior for the COM communication if both the OS and network support the real-time requirements and the client application acquires it. However, this only provides gross support and can not differentiate between individual COM method invocations. Method invocation may have different real-time requirements at different times. In COM client/server communication is done only through interface pointers. Realtime COM should not break this structure. The challenge is how to express real-time requirements for each COM call and how to interpret and pass on the requirement within COM. Recall that after establishing connection, COM falls almost entirely out of the picture; the client will communicate directly with the server via RPC channel. The proxy/stub belongs to COM. The RPC channel is standard DCE-RPC, independent of COM. The real-time support of COM reduces to real-time support in the proxy/stub. Unlike the standard proxy/stub, the real-time proxy/stub has to provide clients the relevant timing information and execute real-time interface calls. It must depend on the real-time OS and the real-time RPC channel in use.
3.3 COM Can be Extended for Real-time Recall that the level of real-time support from COM can not exceed the level provided by the OS, and all real-time COM services must eventually be realized through the OS. What we need is a real-time interface whose method takes a client’s real-time service request, such as priority assignment and deadline, as input parameters, and returns realtime results, such as a reason for denial of service or the execution time to the client. We shall propose such an interface in the next sub-section. In COM, events are realized with connection points. The server triggers an event by calling into the client through a sink — an interface pointer sent by the client to the server’s connection point. Likewise, real-time event support is just the reverse (from server to client) real-time support in COM, and no extra work is necessary. In summary,
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
5
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
RT CLient
RT Server
RT Proxy
1
8,9,10
RT RPC Channel
7
Client
Server
Proxy
Stub
RT Stub
5 4 3
RT
6
RT
COM
2
COM
Client Machine
RPC Channel
IRpcChannelBuffer
System RPC
Server Machine
RPC
RPC Channel System RPC
Figure 4. Real-time COM Architecture
Client Process COM can be extended for real-time support if we exploit the following observations. 1. COM does not need to invent real-time support. COM only needs to delegate real-time support. 2. COM is only minimally involved once the connection is established. The real-time COM communication only involves the proxy/stub pair. 3. COM interface does not need to change. A COM object can support multiple interfaces. A COM object supports real-time by supporting additional real-time interfaces Figure 4 depicts the architecture of real-time COM. It is almost identical to Figure 2. A non-real-time client goes through the same sequence as described in section 2.2; a real-time client sets up real-time request through the realtime interface each time before step 9 (please refer to section 2.2.)
3.4 Real-time Proxy/Stub In standard marshalling, the proxy/stub is generated automatically from the IDL file. In addition to the aforementioned two files used by the client/server applications, the IDL compiler also generates an interface marshaler definition file and an interface marshaler inprocess server code file. The source code is written in accordance to the COM specification. The four files together compile the proxy/stub. Figure 5 is the detailed picture of a COM RPC channel. The RPC Channel COM object is implemented as part of the COM architecture and comes with the system that supports COM. It exposes interface IRpcChannelbuffer to the proxy/stub. In Figure 5 the small circles are Microsoft convention to represent interfaces that a COM object supports.
Server Process
Figure 5. Proxy/Stub RPC Channel A arrow pointing to a circle means the object from thesource of the arrow holds a reference to the interface pointer. Let us look at the real-time proxy/stub. A real-time interface is a COM interface. It has to be generic to express all possible real-time features such that it can adjust easily to different real-time support levels of the OS and the RPC channel. If the OS does not provide real-time support, the call into the interface has no real-time guarantees. In other words, the real-time interface should be a no-op for nonreal-time applications. And finally, the interface should be easily merged into the COM architecture. We can define a base interface IRTUnknown. It is derived from IUnknown. All real-time interfaces are derived from IRTUnknown. For example, we define the real-time version of IReadData as follows: [ uuid(8CE62D90-C73E-11D1BC25-00A024074D2D), pointer_default(unique) ] interface IRTReadData : IRTUnknown { HRESULT Read( [out] float * pfltValue); } An real-time client calls a method in IRTUnknown to setup real-time requirements. It then calls IRTReadData::Read() as a normal COM function call. The realtime proxy/stub will enforce the constraints. A client without real-time requirement ignores IRTUnknown and uses IRTReadData as if it is derived directly from IUnknown. The architecture for a real-time connection is depicted in Figure 6. The real-time RPC Channel object exposes
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
6
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
We define IRTUnknown as follows.
RT Client
RT Server
RT Proxy
RT Stub IRpcChannelBuffer
RT RPC Channel
RT RPC Channel IRTRpcChannelBuffer
System RPC Client Process
RPC
System RPC Server Process
Figure 6. Real-time Proxy/Stub RPC Channel a new interface IRTRpcChannelbuffer. IRTRpcChannelbuffer is derived from IRpcChannelbuffer. If the RPC run time supports real-time, IRTRpcChannelbuffer will provide this capacity to the proxy/stub which in turn provides the support to the applications. The real-time proxy/stub will query for IRTRpcChannelbuffer first. If IRTRpcChannelbuffer is not supported by the RPC Channel object, the realtime proxy/stub will settle for IRpcChannelbuffer. Special proxy/stub code has to be generated by the IDL compiler for IRTUnknown. The COM architecture is designed such that the objects involved inside COM are also COM objects, such as class factory, XOID object, etc. They can be modified to support additional real-time interfaces. In this way we can also support real-time services during the connection establishment.
4 System Design and Implementation Since COM originates from Microsoft Corporation, whether or not COM will provide real-time support will be largely up to Microsoft. We believe that market pressure will lead to some form of real-time support, even though we do not expect it to materialize very soon. Despite this, our implementation is intended to prove the concept as well as to help real system development in general — the embracing of PC workstation and Windows (currently WindowsNT but an emerging candidate is WindowsCE which is more suitable for real-time embedded applications) by the process control industry is not waiting for any vendor to take action. Hopefully, our experimental work is aimed at providing data points to steer real-time COM development. For practical purpose, our prototype will not address creating real-time connections for practical. For now, we are concerned only with implementing the real-time proxy/stub.
[ uuid(4BDF8C8F-BC1E-11D1BC20-00A024074D2D), pointer_default(unique) ] interface IRTUnknown : IUnknown { HRESULT GetRTSupportLevel( // the overall support level: [out] RTLevel * pOverall, // the support level of // the server machine: [out] RTLevel * pServerOS, // the support level of // the server side COM: [out] RTLevel * pServerCOM, // the support level of // the network: [out] RTLevel * pNetwork, // the support level of // the client machine: [out] RTLevel * pClientOS, // the support level of // the client side COM [out] RTLevel * pClientCOM); HRESULT GetRTProperty( // the interface UUID: [in] REFIID riid, // the interface method name: [in] LPWSTR strMethodName, // the real-time property: [out] RTProperty * pRTProperty); HRESULT SetRTRequest( // the interface UUID: [in] REFIID riid, // the interface method name: [in] LPWSTR strMethodName, // the real-time request: [in]
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
7
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
RTRequest request); Local HRESULT GetRoundTripDelay( // the instance delay, // in microsecond: [out] DWORD * currentDelay, // the average delay, in microsecond: [out] DWORD * averageDelay); }; There are four methods of the interface IRTUnknown. GetRTSupportLevel() returns the level of real-time support by each layer. The server returns the support on the server side; the proxy supplies client-side information. The proxy caches data and will not go to the server for subsequent calls. GetRTAttribute() gets the real-time properties of an interface method. The proxy caches data and will not go to the server for subsequent calls. SetRTRequest() sets the real-time request for the next method invocations. The proxy will reject a method at the start if the request is not satisfiable. GetRoundTripDelay() pings the server, obtains the current network delay. This method, together with others, enable the client to adjust its real-time performance in accordance with the run-time environment. For our experiment, we define an real-time interface IRTCOMServer which has two methods — one to read and one to write an array of float values. [ uuid(4BDF8C8D-BC1E-11D1BC20-00A024074D2D), pointer_default(unique) ] interface IRTCOMServer : IRTUnknown { HRESULT ReadItems( // number of items to read: [in] DWORD dwNumItems, // the item names to be read: [in, size_is(dwNumItems)] LPWSTR * pstrItemNames, // the item values read: [out, size_is(,dwNumItems)] float ** ppfltValues, // the timestamps of the values:
Remote
Connect Read() Connect Read()
minimum 250.00 15.0 28753 15.0
maximum 578.00 16.0 39042 16.0
average 323.50 15.6 36354 15.6
Table 2. Real-time COM Connection Time Statistics (in millisecond)
[out, size_is(,dwNumItems)] FILETIME ** ppValueTimes); HRESULT WriteItems( // number of items to write: [in] DWORD dwNumItems, // the item names to be written: [in, size_is(dwNumItems)] LPWSTR * pstrItemNames, // the item values to be written: [in, size_is(dwNumItems)] float * pfltValues, // when the values are written: [out, size_is(,dwNumItems)] FILETIME ** ppValueTimes); }; The experiment is done on WindowsNT 4.0 running on workstations of dual Pentium Pro 200Mhz processors. The client machine and server machine are connected with category 5 twisted pair. They belong to the same WindowsNT domain. The real-time COM server supports both IRTReadData and IRTCOMServer. It accesses data from a distributed control system. Since we do not have access to the COM source code on NT. We cannot change the RPC channel object. We can, however, write a real-time proxy/stub with customized marshalling. Table 2 is the same test as in Table 1, only this time we use the real-time proxy/stub. Note that the time overhead introduced by the real-time proxy is nominal. In some occasion it even takes longer for a normal COM connection. All subsequent tests are done with the client running on a different machine than the server. The extra work in the real-time proxy/stub is for realtime task only; it should be constant over different calls. In Figure 7 we compare the overhead as a function of the number of item values read in one call. The real-time overhead is minimal and does not increase in the size of the parameter. In some applications, it is impossible to control the network traffic. In such a situation, a practical alternative is to
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
8
Milliseconds
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
500 450 400 350 300 250 200 150 100 50 0
Without RT Proxy With RT Proxy
0
5
10
15
20 25 30 Data Items
35
40
45
50
Figure 7. Time w.r.t. Size of Parameter 120
Round Trip Delay
message filter. In our experiment this is done by the client itself setting up a time event. We are unable to test the real-time scheduling and deadline enforcement because WindowsNT is not a real-time OS. We expect to have such data once a real-time OS (WindowsCE perhaps) has COM support. Our real-time proxy/stub is able to provide passive real-time support such as proposed by Microsoft [7, 8]. It can analyze past timing behavior and offer better services to the client. If we think of the real-time proxy as a gateway to the network, we can gain an additional important leverage: the proxy can serve as a cache. We could for example exploit the data similarity concept developed by Kuo&Mok [10, 11] to reduce the actual number of interface calls to the server, and thereby reduce the network traffic. This is especially important for the scalability of industrial process control systems.
Milliseconds
100
5 Conclusion
80
60
40
20
0 0
10
20
30
40
50
60
Instance
Figure 8. Roundtrip Delays
predict it by examining past statistics. The real-time proxy remembers the round trip delay whenever the client makes a call to the server, and the client can access this data through IRTUnknown::GetRoundTripDelay(). Figure 8 is the network delay our client gets within one hour period. A real client could make use of this to determine if a call should be made to the server. We should point out that WindowsNT is not a real-time OS. So our experiment can best be described as applicable to soft real-time systems. The test data is meant to compare the differences. Our work proves the idea and proves the way we should proceed. Also we do not preclude other realtime methods. The four IRTUnknown methods are those we consider important. There are two parts that can significantly benefit from support by Microsoft COM. One is the Microsoft IDL compiler that automatically generates the source code for interfaces derived from IRTUnknown. The other is an explicit way to set up the time-out value for a COM call. There is a time-out mechanism in COM for remote procedure calls, but the application cannot access the time-out value. A possible solution would be a new member function from the
In this paper, we examine what it takes to build a realtime extension to COM. In the process control industry, such a real-time extension is necessitated by the aggressive adoption of the Wintel architecture at the enterprise market level which will tie in real-time functionality with planning and other enterprise level activities. To achieve flexibility through a clean interface, we argue that real-time COM should be a conduit between the application and the underlying OS, and we investigate this idea experimentally by prototyping a real-time proxy/stub for COM that has practical applications. We believe the concepts developed here can be used to write a real-time COM layer for an OS targeted for embedded real-time applications such as Windows CE. It is important that a clean interface be defined to isolate the real-time COM from the OS since this is the key for providing flexibility. It would be interesting to see if the Windows CE platform can succeed in this regard [12]. WindowsNT already has the priority concept built in it; the CPU reservations and time constraints [8] techniques may be integrated into WindowsNT in the future [16]. The successful integration of these mechanisms, however, will require first of all a cleanly designed real-time COM extension.
References [1] D. Box. Essential COM. Addison Wesley, 1998. [2] K. Brockschmidt. Inside OLE. Microsoft Press, 1995. [3] P. E. Chung, Y. Huang, S.Yajnik, D.Liang, J. Shih, C.-Y. Wang, and Y.-M. Wang. Dcom and corba: Side by side, step by step, and layer by layer. C++ Report, 10(1):18–40, January 1998.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
9
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
[4] G. Cooper, L. C. DiPippo, L. Esibov, R. Ginis, R. Johnston, P. Kortman, P. Krupp, J. Mauer, M. Squadrito, B. Thurasignham, S. Wohlever, and V. F. Wolfe. Real-time corba development at mitre, nrad, tri-pacific, and uri. In IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, pages 69–74, December 1997. [5] W. Feng, U. Syyid, and J. W.-S. Liu. Providing for an open, real-time corba. In IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, pages 75–80, December 1997. [6] M. Gergeleit, E. Nett, and M. Mock. Supporting adaptive real-time behavior in corba. In IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, pages 61–68, December 1997. [7] M. B. Jones, J. S. B. III, A. Forin, P. J. Leach, D. Rosu, and M.-C. Rosu. An overview of the rialto real-time architecture. In the 7th ACM SIGOPS European Workshop, pages 249– 256, September 1996. [8] M. B. Jones, D. Rosu, and M.-C. Rosu. Cpu reservations and time constraints: Efficient, predictable scheduling of independent activities. In the 16th ACM Symposium on Operating Systems Principles, October 1997. [9] V. Kalogeraki, P. Melliar-Smith, and L. Moser. Soft realtime resource management in corba distributed systems. In IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, pages 46–51, December 1997. [10] T.-W. Kuo and A. K. Mok. Load adjustment in adaptive real-time systems. In IEEE Real-Time Systems Symposium, December 1991. [11] T.-W. Kuo and A. K. Mok. Real-time database - similarity semantics and resource scheduling. SIGMOND RECORD, 25(1):18–22, 1996. [12] Microsoft. http://www.microsoft.com/. [13] Microsoft. Dcom technical overview. In Micorsoft Professional Developers Conference, 1997. [14] OPC Fundation. OLE for Process Control Standard. [15] D. Schmidt, R. Bector, D. Levine, S. Mungee, and G. Parulkar. An orb endsystem architecture for statically scheduled real-time applications. In IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, pages 52–60, December 1997. [16] A. Wolfe. Windows turned on to real-time tasks. Electronic Engineering Times, February 1998. [17] V. F. Wolfe, L. C. DiPippo, R. Ginis, M. Squadrito, S. Wohlever, I. Zykh, and R. Johnston. Real-time corba. Technical Report TR97-256, University of Rhode Island Department of Computer Science and Statistics, 1997.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
10
