- Email: [email protected]
Support for RTO.k Object Structured Programming in C++
Copyright © IFAC Real Time Programming. Gramado. RS. Brazil. 1997
SUPPORT FOR RTO.k OBJECT STRUCTURED PROGRAMMING IN C++ K. H. (Kane) Kim, Luiz Bacellart, and Chittur Subbaraman Oept. of Electrical and Computer Engineering University of California, Irvine, U.S.A. t
United Technologies Research Center East Hartford, CT, U.S.A. established recently by the first co-author together with his collaborating researchers. The new object structuring approach which has several unique features is called the RTO.k object structuring scheme [Kirn94]. The RTO.k object structuring scheme differs from other objectoriented structuring approaches which support real-time computer system (RTCS) design in that it is aimed at supporting the design-time guarantee of timely service capabilities of objects.
Abstract: In the past few years we have established a real-time object-oriented (00) structuring approach called the RTO.k object structuring scheme for the purpose of realizing real-time computing in the form of a generalization of non-real-time computing and yet allowing system engineers to confidently produce certifiable real-time systems for safety-critical applications. Also, a model of an operating system kernel named the DREAM kernel which can support both conventional real-time processes and RTO.k objects with guaranteed timely services, has been formulated. A user-friendly interface to DREAM kernel services for RTO.k-structured real-time application programs is provided by a collection of specific C++ classes called the DREAM library. In a sense, C++ augmented with the DREAM library can be viewed as an RTO.k object programming language although it does more than that. This paper discusses the essence of RTO.k object programming in C++ with the aid of the DREAM library.
A model of an operating system kernel which can support real-time processes with guaranteed timely services was formulated by the first co-author [Kirn95]. The model is called the DREAM (Distributed Real-time Ever Available Micro-computing) kernel. The DREAM kernel can support RTO.k object structured application software as well as conventional process-structured realtime application software. The DREAM kernel was formulated to accomplish the key property of providing guaranteed timely services to real-time applications with minimal loss of hardware utilization. Several prototype implementations of the DREAM kernel have been produced by the authors and their research collaborators to run on networks of PC' s connected by Ethernet. A prototype kernel (v.D3) has been used to run an RTO.k structured non-trivial defense C 3 application, together with an RTO.k structured real-time simulator of the application environment.
Keywords: GT design, DREAM library, C++, RTO.k object, real-time computing, object-oriented design
1. INTRODUCTION The necessity of a new methodology for real-time system structuring that eases the job of managing the system complexity and producing reliable real-time systems is becoming more acute than ever. We believe that time is ripe for pursuing the following paradigms, which may be called General-form Timelinessguaranteed (GTI design [Kim95] paradigms.
A user-friendly interface to the DREAM kernel can reduce the burden imposed on the RTO.k object implementers. To achieve this goal, the authors have designed a library, called the DREAM Library, which is a collection of several C++ classes. Each class functions as an interface between a component of an RTO.k object program and the kernel support for that component. The DREAM library hides various details of parameter passing between application and the DREAM kernel from the application progranuner.
(1) General-form design style: Future real-time computing must be realized in the form of a generalization of the non-real-time computing, rather than in a form looking like an esoteric specialization. (2) Design-time guarantee of timely service capabilities of subsystems: To meet the demands of the general public on the assured reliability of future real-time computing systems (RTCS's) in safety-critical applications, it is inevitable to require the system engineer to produce design-time guarantees for timely service capabilities of various subsystems (which will take the form of objects in object-oriented system designs).
The paper starts in Section 2 with a discussion on the essence of the RTO.k object structuring scheme. Section 3 discusses the majqr features of the DREAM kernel offered to real-time application programmers. In Section 4 we present the DREAM library support for RTO.k structured application programming. Section 5 summarizes the major features of the DREAM library and this paper concludes in Section 6.
2. OVERVIEW OF THE RTO.k OBJECT STRUCTURING SCHEME
With the purpose of facilitating GT design, a realtime object-oriented structuring approach has been
27
Several years ago, the fIrst author in collaboration with Hermann Kopetz of the Technical University of Vienna proposed an abstract precursor of the RTO.k object model for cost-effective development of hard-realtime systems [Kop90]. In recent years, the RTO.k object, also called the time-triggered real-time object CTT-RTO), has been formalized to possess a concrete syntactic structure and execution semantics.
NareotRTO
RlO's
The basic structure of the RTO.k object model is shown in Figure 1. It is an extension of the conventional object model(s) in four major ways: (a) Clear separation between two types of methods:
The RTO.k object model contains two types of methods, time-triggered CTT-) methods, (also called the spontaneous methods or SpM's) which are clearly separated from the conventional service methods (SvM's). The SpM executions are triggered on reaching of the real-time clock at specifIc values determined at design time whereas the SvM executions are triggered by service request messages from clients. Moreover, actions to be taken at real times which can be determined at the design time can appear only in SpM's.
•• Figure I . Structure of the RTO.k Object Model (Adapted from [Kim94]) which has the same effect as {"start-during (lOam, 1O:05am) fInish-by 10: lOam", "start-during (lO:30am, 1O:35am) fInish-by 10:40am"} .
(b) Basic concurrency constraint (BCC):
This rule, called the basic concurrency constraint (BCC), prevents potential conflicts between SpM's and SvM's and reduces the designer's efforts in guaranteeing timely service capabilities ofRTO.k objects. Basically, activation of an SvM triggered by a message from an external client is allowed only when potentially conflicting SpM executions are not in place. An SvM is allowed to execute only if no SpM that accesses the same object data space (ODS) to be accessed by this SvM has an execution time window that will overlap with the execution time window of this SvM. Thus SpM executions are given higher priority over SvM executions. However, the BCC does not stand in the way of either concurrent SpM executions or concurrent SvM executions.
Instead of specifying actual triggering times in the AAC section of an SpM, the designer may specify a set of candidate triggering times by starting the AAC with the declaration "if-demanded". A subset of these candidate triggering times may be chosen dynamically for actual triggering when an SvM within the same RTO.k object requests future executions of this specifIc SpM. In our view, any RTCS can be constructed as a network ofRTO.k objects. Client methods (SpM's or SvM's) request for service of SvM's in other RTO.k objects. To maximize the concurrent executions of client and server methods, client methods are allowed to make non-blocking (sometimes called asynchronous) types of service requests to SvM's.
(c) A deadline is imposed for each execution of a method of an RTO.k object;
The designer of each RTO.k object indicates the deadline for every output produced by each SvM (and each SpM which may be executed on requests from SvM's) in the specifIcation of the SvM (and some relevant SpM's) and advertises this to the designers of potential client objects. The designer of the server object thus guarantees the timely services of the object. Before determining the deadline specifIcation, the server object designer must convince himselflherself that with the object execution engine (hardware plus operating system) available, the server object can be implemented to always execute the SvM such that the output action is performed within the deadline. Again, the BCC contributes to major reduction of these burdens imposed on the designer.
(d) After an interval called the maximum validity duration passes, real-time data contained in the ODS of an RTO.k object become invalid. Extensions (a) and (b) are unique to the RTO.k object model in comparison with other object models [Att91, Ish90, Tak92]. In an RTO.k object, both types of methods, the SpM's and the SvM's, perform operations on the RTO.k object data space (defIned in the ODS section). The triggering times for SpM's should be defIned by the application designer as part of an SpM specifIcation. The defInition of these triggering times should be placed in the autonomous activation condition (AAC) section of an SpM. An example of an AAC is "for t = from 10am!Q 10 : 50am~ 30min start-during (t, t+5min) fInish-by t+IOmin"
28
The RTO.k object model is effective not only in the multiple-level abstraction of real-time (computer) control systems under design but also in the accurate representation and simulation of the application environments. In fact, it enables uniform structuring of control computer systems and application environment simulators [Kim94] and this presents considerable potential benefits to the system engineers.
The DREAM kernel thus executes RTO.k object components as follows (as shown in Figure 2) (1) ODS segments (ODSS's) as CREW monitors, (2) Both SpM's and SvM's as application-specific program bodies of processes (called method execution processes or MEP's), (3) Paths for accessing SvM's in the form of DFC' s monitored by the SvM's, and (4) Result-return paths to clients in the form of DFC's monitored by the clients, and (5) capabilities for accessing SvM's in other RTO's in the form ofID's of the DFC's monitored by the SvM's.
3. MAJOR FEATURES OF THE DREAM KERNEL In order for the RTO.k objects to provide guaranteed timely services to external clients, the engine that supports the execution of RTO.k objects must obviously provide guaranteed timely services to the requesting RTO.k objects. In addition to containing a hardware platform, such an execution engine should be formed by a timeliness-guaranteed operating system. Existing commercial operating systems are not yet capable of providing guaranteed timely services needed by a great deal of real-time application software.
4. DREAM LmRARY SUPPORT FOR RTO.k STRUCTURED PROGRAMMING IN C++ The DREAM library greatly reduces the burden of the C++ RTO.k application programmer in the construction ofRTO.k objects and in designing kernel service calls (KSC's) to the DREAM kernel. In order to create an RTO.k object, the user should first define an RTOClass that contains (1) an instance of RTOAccessCapabilityClass (representing access rights for SvM's in other RTO's), (2) instances of each ODSSClass (representing the ODS segments in this RTO), (3) instances of each SpMClass (representing the SpM's of this RTO), and (4) instances of each SvMClass (representing the SvM's of this RTO). The user then creates an instance of the RTOClass inside the application initial process (AlP). The AlP is the starting point of the entire application in a node.
The DREAM kernel has been formulated as a model of an operating system kernel that can support guaranteed timely services not only for RTO.k object structured real-time applications but also for conventional process-structured real-time applications . The DREAM kernel guarantees the timely response to service requests by adopting a unique approach for the layering of its components [Kim95]. This approach is based on the organizational principle called the timeleasing machine layering, which is of fundamental nature. Under the time-leasing machine layering principle, the bottom layer (LO in the DREAM kernel) owns the full power of the hardware machine. So, the bottom layer uses the hardware machine at its own will. The remainder of the hardware machine time after the bottom layer use of the hardware machine, is "leased" to the next upper layer (Ll in the DREAM kernel). The time leasing relationship is recursive, i.e., it is maintained through all the layers that compose the kernel (in the DREAM kemellayers LO-lA). Moreover, there is a tight bound on the amount of machine time that each layer uses. This sometimes implies a bound on the frequency of certain types of interrupts that are accepted.
In order to ease the creation of these user-defined RTO.k
............. -.
For supporting the components of RTO.k structured application programs, the DREAM kernel utilizes the same support provided to the components of conventional process-structured real-time application programs. In other words, the DREAM kernel uses the support provided for processes, concurrent-read-&-exclusivewrite (CREW) monitors which are shared data structure monitors for intra-node inter-process communication, and data field channels (DFC's) which are real-time logical multicast channels for both intra-node and internode inter-process-group message communication to execute the components of an RTO.k-structured application program.
DFC DREAM Kemel
Figure 2. Mapping of an RTO.k object to a conventional process-structured program
29
classes, the DREAM library provides a set of pre-defined classes (templates) which can be inherited by the userdefined classes. The set of pre-defined classes includes (1) the BasicRTOAccessCapabilityClass, (2) the BasicODSSClass for constructing an ODSS, (3) the BasicSpMClass, for creating an SpM, and (4) the BasicSvMClass, for creating an SvM. Thus, as wiII be shown in Section 4.2, a user-defined RTOAccessCapabilityClass can be created easily by inheriting the BasicRTOAccessCapabilityClass from the DREAM library and then adding a certain amount of application-specific program components. Other userdefined classes can also be created in similar manners.
method to an MEP, sharing an MEP among several methods, etc. The C++ RTO.k programmer first creates an instance of the RTOExecManClass inside the AlP. Then the programmer may create as many MEP's as necessary and may bind methods to MEP's. An SpM can be exclusively bound to an MEP, can share an MEP with other SpM's, or can be left unbound. However, an SvM is always left unbound. One reason for leaving an SvM unbound is that it may be executed in a pipe lined fashion , i.e. multiple invocations of the same SvM may progress concurrently to effect fast response to service requests.
The shared binding of multiple object methods to the same MEP enables a large number of object methods to be executed on the same local node which supports a moderate number of processes and hence results in increased resource utilization. However, all such methods must have non-overlapping timing constraints. It is up to the designer to ensure this.
In subsequent subsections, we will describe in detail the construction of the individual components of an RTO.k object using the DREAM library. But first, let us consider the manner in which the DREAM kernel executes SpM's and SvM's.
4.1 Execution of SvM's and SpM's as MEP's
4.2 Construction of RTO access capabilities
An RTO.k object method should be assigned to a method execution process (MEP) before the method can be executed. To give maximum flexibility to the application programmer, the DREAM kernel offers different types of method-to-MEP assignments. These include:
The access capability section in an RTO.k object determines access paths to the SvM's of other RTO objects. The access capability represented in the form of the DFC ID that should be used by a client RTO.k object (method) to request for execution of the corresponding SvM. The SvM can be viewed as the owner of the such service-request DFC and constantly monitors the DFC. In the approach adopted by the DREAM kernel, the creator of a server RTO.k should inform all potential clients about the creation of certain services by broadcasting the service-request DFC ID's of the SvM's of the server RTO.k via a special global broadcast DFC. This approach can be implemented efficiently in Ethernet-type local area networks since by broadcasting a single message the creator of an SvM can inform all potential clients about the service-request path. At a client site, the client RTO.k makes a KSC during initialization to obtain the DFC ID of the external server method.
(1) Exclusive binding of a method to an MEP: In this case, a long-term one-ta-one connection is established between a method and an MEP. The exclusively bound method cannot be executed by any other MEP and the MEP cannot be used to execute any other method. (2) Shared binding of multiple methods to the same MEP: In this case, multiple methods are assigned to the same MEP for long duration. Such an MEP can execute only the set of methods that are bound to it. One important restriction for sharing an MEP among multiple methods is that these methods cannot be active concurrently. This requirement has been imposed in order to reduce the complexity of implementation. The RTO.k designer who wishes to use the shared binding facility should ensure that the methods that share the same MEP do not have timing requirements that necessitate their concurrent execution.
The C++ RTO.k application programmer can use a DREAM library class called the BasicRTOAccessCapabilityClass for obtaining access capabilities for server RTO.k's. The programmer should design an RTOAccessCapabilityClass by inheriting this BasicRTOAccessCapabilityClass. The BasicRTOAccessCapabilityClass provides a friendly interface to the KSC RegisterRTOAccessCapabilityO. This KSC is made with the symbolic names of the server RTO.k and the corresponding SvM as parameters and if successful, it returns the DFC ID of the SvM. It is a good practice to define inside the RTOAccessCapabilityClass the parameters for each service request to be sent a server RTO from the host RTO. The following illustrates the construction of RTOAccessCapabilityClass:
(3) Unbound methods: In this case, the methods are not bound to any MEP during initialization. Rather, the methods are left unbound. When it is time to execute the method, the DREAM kernel automatically finds an unbound free MEP (i.e. an MEP that is neither bound to an object method nor is executing another unbound method at the time) and makes an one-shot assignment of the MEP to the method. Unbound methods may thus execute on different MEP's during different execution runs. The RTOExecManClass of the DREAM library offers functions for creating both generic MEP's (for which standard parameters such as stack size, priority, etc. are used) and custom MEP's (for which userspecified parameters are used), permanently binding a
class RTOAccessCapabilityClass: public BasicRTOAccessCapabilityClass
30
public: II parameter for access to SvM3 of RT02 struct ParType_RT02_SvM3 {
kernel, making service requests to SvM' s and obtaining the return-results, informing the kernel about the completion of one execution run, etc. The SpM body is defined as a member function of the SpMClass.
} Par_RT02_SvM3; II Service-request DFC ID of SvM3 ofRT02 int DFCID_RT02_SvM3; RTOAccessCapabilityClassO; II constructor
An SpM may make one of the following types of service requests to an SvM: (I) blocking service requests in which the client (SpM) is blocked after making a service request until either the result is obtained from the SvM or a pre-specified timeout occurs. (2) non-blocking service requests in which the client proceeds after making a service request and retrieves the result of the request later during its execution.
}; RTOAccessCapabilityClass: : RTOAccessCapabilityClassO RegisterRTOAccessCapability ("RT02", "SvM3", &DFCID_RT02_SvM3);
In order for the SpM to make the above calls, the owner RTO should already have obtained the servicerequest DFCID of the SvM as mentioned in section 4.1. The SpM should use this DFCID as an input parameter in the aforementioned service calls. Also, when an SpM is registered, the kernel assigns a unique result-return DFCID to the SpM and enables the SpM to receive return-results via this DFC. This result-return DFCID is passed on by the DREAM kernel automatically along with the service request so that the SvM may use this DFCID while returning its processed results. This DFCID is hidden from the RTO.k application programmer.
} II Instantiation of the RTOAccessCapability class RTOAccessCapabilityClass RAC;
4.3 Construction of ODSS The DREAM kernel treats the Object Data Space Segment (ODSS) of an RTO.k object as a special CREW monitor. A mechanism for concurrency control is necessary so as to maintain consistency of an ODSS which is typically accessed by multiple methods of the host RTO.k. The CREW monitor facilitates flexible and yet safe concurrency control. In order to construct an ODSS, the C++ RTO.k programmer can start designing the ODSSClass by inheriting the BasicODSSClass of the DREAM library. This BasicODSSClass in turn inherits the CREWMgtClass of the DREAM library. The BasicODSSClass provides a friendly interface to kernel services such as: creating and destroying ODSS (CREW) support and obtaining and releasing ODSS access rights. The following sample program shows the use of the ODSS class:
4.5 Construction of SvM's Figure 3 shows the construction of an SvMClass through an inheritance of the BasicSvMClass of the DREAM library. The BasicSvMClass provides functions for registering the SvM with the kernel, receiving a service request, replying to a service request, making service requests to other SvM's in either blocking or nonblocking manner, retrieving the results of non-blocking service requests, informing the kernel about the completion of one execution run, etc.
class ODSSClass:public BasicODSSClass { int X, .. . ; II private data area public: void MethodlO; II a member function
When an SvM is registered with the kernel, the kernel automatically assigns a service-request DFCID to the SvM, broadcasts the DFCID of the SvM on a special global broadcast DFC, and then enables the SvM to receive service-requests via this DFC. Also, the kernel assigns a unique result-return DFCID to an SvM so that the SvM may call for other SvM's and receive results via this DFC. Unlike in the SpM case, the assignment is done at each time of invoking the SvM rather than at the SvM registration time and thus if multiple invocations of the same SvM are concurrently active, each SvM invocation is assigned a unique result-return DFCID.
};
void ODSSClass::MethodIO { II Obtaining RW access rights to the CREW II monitor by calling the member function of the II CREWMgtClass of the DREAM library EnterCREW_RWO; ... ; II access the data area II Releasing RW access rights to the CREW monitor ExitCREW_RWO; } II Instantiation of the ODSS class ODSSClass ODSS I ;
5. SUMMARY OF MAJOR FEATURES OF THE DREAM LffiRARY
4.4 Construction of SpM's
(1) The DREAM library hides various details of passing parameters from the application layer to the DREAM kernel. Each DREAM library class houses a pre-defined set of data items that just need to be initialized by the application program before calling an appropriate
The C++ RTO.k programmer can start designing the SpMClass by inheriting the BasicSpMClass of the DREAM library. The functions provided by the BasicSpMClass include: registering the SpM with the
31
this direction . The authors are currently developing one such extension named the C++T language and RTO.k objects written in C++T will be processed by a combination of a C++T-to-C++ preprocessor and a commercial C++ compiler.
.,,.. mealS al
<~.1.ODSSl7t> .'
ClPI*:ation pOQIaill"lle It10Ud modify INs sIaIemenI 10 Slit each
~~
apc:jcatIon.
6. CONCLUSION
c C
[DeSij 1
::>
Reoor1ComPI9IIOI
;:,
~JXJD.F\:I'_I't.F\:I'_~
~DfCIO.F\:I'-"'t
)
~~ ~tjoc~~
at=iaOentDFOD_RR. F\:I')"I.) C~~ID-'IItPa_PIT. ) erentTrcntelCOII(SRQ DfelD. CIenI DFCD\ ~ PIT. Par SIZe. TIiTlesIar'rl)I - ~
The DREAM kernel offers guaranteed timely services to real-time applications. The DREAM library considerably reduces the efforts required for programming applications in the form of an RTO.k object network. We believe that this suite of tools represent a significant step forward in realizing the GT design paradigms. Nevertheless, it represents a very small portion of the desirable software engineering environment that will fully support GT design. Acknowledgment: The research work reported here was supported in part by US Navy, NSWC Dahlgren Division under Contract No. N60921-92-C0204, in part by the California Transportation Department via the UCI Institute for Transportation Studies, in part by Hitachi, Ltd, in part by mM, in part by Postech, and in part byETRl.
Figure 3. The SvMClass and the DREAM library support for SvM management function in the class. This function will correctly retrieve REFERENCES the parameters from the data area of the class, package them, and make the correct KSC. Any result-returns [Att91] Attoui, A. "An Object Oriented Model for from the kernel are saved in the data area of the class. Parallel and Reactive Systems", Proc. IEEE CS 12th (2) To ease the application programmer's task of Real-Time Systems Symp. , 1991 , pp. 84-93. designing the application interface to the DREAM [Ish92] Ishikawa, Y., Tokuda, H. , and Mercer, C. W., library, the data items in the DREAM library classes are "An Object-Oriented Real-Time Programming often initialized with default values. An application Language", IEEE Computer, October 1992, pp. 66-73. programmer may thus choose to pass these default values [Kim94] Kim, K.H. et aI., "Distinguishing Features and to the DREAM kernel when calling for a DREAM kernel Potential Roles of the RTO.k Object Model", Proc. 1994 service. In such a case, the application programmer IEEE CS Workshop on Object-oriented Real-time Depenneeds to just call the DREAM library function of the dable Systems (WORDS), Oct. 94, Dana Point, pp.36-45 . appropriate class without reinitializing any of the data [Kim95] Kim, K.H. et aI., "A Timeliness-Guaranteed items of the class. Kernel Model - DREAM Kernel and Implementation Techniques", Proc. 1995 1nt'l Workshop on Real-Time The power of the DREAM library in easing the Computing Systems and Applications (RTCSA 95), efforts for structuring C++ RTO.k objects has been Tokyo, Japan, Oct. 1995, pp.80-87. positively tested through several sizable distributed [Kop90] Kopetz, H. and Kim, K.H., "Temporal RTO.k application program developments. However, it Uncertainties in Interactions among Real-Time Objects", still burdens the application designer with the chore of Proc. IEEE CS 9th Symp. on Reliable Distributed dealing with some low-level details in redundant forms Systems, Huntsville, AL, Oct. 1990, pp.165-174. which could be automatically deduced from a high-level [Tak92] Takashio, K., and Tokoro, M., "DROL: An abstract and yet accurate representation of RTO.k objects. Object-Oriented Programming Language for Distributed An extension of the C++ language to support abstract Real-Time Systems", Proc. OOPSL4. , 1992, pp. 276-294. RTO.k programming is the most natural path to follow in
32
SUPPORT FOR RTO.k OBJECT STRUCTURED PROGRAMMING IN C++ K. H. (Kane) Kim, Luiz Bacellart, and Chittur Subbaraman Oept. of Electrical and Computer Engineering University of California, Irvine, U.S.A. t
United Technologies Research Center East Hartford, CT, U.S.A. established recently by the first co-author together with his collaborating researchers. The new object structuring approach which has several unique features is called the RTO.k object structuring scheme [Kirn94]. The RTO.k object structuring scheme differs from other objectoriented structuring approaches which support real-time computer system (RTCS) design in that it is aimed at supporting the design-time guarantee of timely service capabilities of objects.
Abstract: In the past few years we have established a real-time object-oriented (00) structuring approach called the RTO.k object structuring scheme for the purpose of realizing real-time computing in the form of a generalization of non-real-time computing and yet allowing system engineers to confidently produce certifiable real-time systems for safety-critical applications. Also, a model of an operating system kernel named the DREAM kernel which can support both conventional real-time processes and RTO.k objects with guaranteed timely services, has been formulated. A user-friendly interface to DREAM kernel services for RTO.k-structured real-time application programs is provided by a collection of specific C++ classes called the DREAM library. In a sense, C++ augmented with the DREAM library can be viewed as an RTO.k object programming language although it does more than that. This paper discusses the essence of RTO.k object programming in C++ with the aid of the DREAM library.
A model of an operating system kernel which can support real-time processes with guaranteed timely services was formulated by the first co-author [Kirn95]. The model is called the DREAM (Distributed Real-time Ever Available Micro-computing) kernel. The DREAM kernel can support RTO.k object structured application software as well as conventional process-structured realtime application software. The DREAM kernel was formulated to accomplish the key property of providing guaranteed timely services to real-time applications with minimal loss of hardware utilization. Several prototype implementations of the DREAM kernel have been produced by the authors and their research collaborators to run on networks of PC' s connected by Ethernet. A prototype kernel (v.D3) has been used to run an RTO.k structured non-trivial defense C 3 application, together with an RTO.k structured real-time simulator of the application environment.
Keywords: GT design, DREAM library, C++, RTO.k object, real-time computing, object-oriented design
1. INTRODUCTION The necessity of a new methodology for real-time system structuring that eases the job of managing the system complexity and producing reliable real-time systems is becoming more acute than ever. We believe that time is ripe for pursuing the following paradigms, which may be called General-form Timelinessguaranteed (GTI design [Kim95] paradigms.
A user-friendly interface to the DREAM kernel can reduce the burden imposed on the RTO.k object implementers. To achieve this goal, the authors have designed a library, called the DREAM Library, which is a collection of several C++ classes. Each class functions as an interface between a component of an RTO.k object program and the kernel support for that component. The DREAM library hides various details of parameter passing between application and the DREAM kernel from the application progranuner.
(1) General-form design style: Future real-time computing must be realized in the form of a generalization of the non-real-time computing, rather than in a form looking like an esoteric specialization. (2) Design-time guarantee of timely service capabilities of subsystems: To meet the demands of the general public on the assured reliability of future real-time computing systems (RTCS's) in safety-critical applications, it is inevitable to require the system engineer to produce design-time guarantees for timely service capabilities of various subsystems (which will take the form of objects in object-oriented system designs).
The paper starts in Section 2 with a discussion on the essence of the RTO.k object structuring scheme. Section 3 discusses the majqr features of the DREAM kernel offered to real-time application programmers. In Section 4 we present the DREAM library support for RTO.k structured application programming. Section 5 summarizes the major features of the DREAM library and this paper concludes in Section 6.
2. OVERVIEW OF THE RTO.k OBJECT STRUCTURING SCHEME
With the purpose of facilitating GT design, a realtime object-oriented structuring approach has been
27
Several years ago, the fIrst author in collaboration with Hermann Kopetz of the Technical University of Vienna proposed an abstract precursor of the RTO.k object model for cost-effective development of hard-realtime systems [Kop90]. In recent years, the RTO.k object, also called the time-triggered real-time object CTT-RTO), has been formalized to possess a concrete syntactic structure and execution semantics.
NareotRTO
RlO's
The basic structure of the RTO.k object model is shown in Figure 1. It is an extension of the conventional object model(s) in four major ways: (a) Clear separation between two types of methods:
The RTO.k object model contains two types of methods, time-triggered CTT-) methods, (also called the spontaneous methods or SpM's) which are clearly separated from the conventional service methods (SvM's). The SpM executions are triggered on reaching of the real-time clock at specifIc values determined at design time whereas the SvM executions are triggered by service request messages from clients. Moreover, actions to be taken at real times which can be determined at the design time can appear only in SpM's.
•• Figure I . Structure of the RTO.k Object Model (Adapted from [Kim94]) which has the same effect as {"start-during (lOam, 1O:05am) fInish-by 10: lOam", "start-during (lO:30am, 1O:35am) fInish-by 10:40am"} .
(b) Basic concurrency constraint (BCC):
This rule, called the basic concurrency constraint (BCC), prevents potential conflicts between SpM's and SvM's and reduces the designer's efforts in guaranteeing timely service capabilities ofRTO.k objects. Basically, activation of an SvM triggered by a message from an external client is allowed only when potentially conflicting SpM executions are not in place. An SvM is allowed to execute only if no SpM that accesses the same object data space (ODS) to be accessed by this SvM has an execution time window that will overlap with the execution time window of this SvM. Thus SpM executions are given higher priority over SvM executions. However, the BCC does not stand in the way of either concurrent SpM executions or concurrent SvM executions.
Instead of specifying actual triggering times in the AAC section of an SpM, the designer may specify a set of candidate triggering times by starting the AAC with the declaration "if-demanded". A subset of these candidate triggering times may be chosen dynamically for actual triggering when an SvM within the same RTO.k object requests future executions of this specifIc SpM. In our view, any RTCS can be constructed as a network ofRTO.k objects. Client methods (SpM's or SvM's) request for service of SvM's in other RTO.k objects. To maximize the concurrent executions of client and server methods, client methods are allowed to make non-blocking (sometimes called asynchronous) types of service requests to SvM's.
(c) A deadline is imposed for each execution of a method of an RTO.k object;
The designer of each RTO.k object indicates the deadline for every output produced by each SvM (and each SpM which may be executed on requests from SvM's) in the specifIcation of the SvM (and some relevant SpM's) and advertises this to the designers of potential client objects. The designer of the server object thus guarantees the timely services of the object. Before determining the deadline specifIcation, the server object designer must convince himselflherself that with the object execution engine (hardware plus operating system) available, the server object can be implemented to always execute the SvM such that the output action is performed within the deadline. Again, the BCC contributes to major reduction of these burdens imposed on the designer.
(d) After an interval called the maximum validity duration passes, real-time data contained in the ODS of an RTO.k object become invalid. Extensions (a) and (b) are unique to the RTO.k object model in comparison with other object models [Att91, Ish90, Tak92]. In an RTO.k object, both types of methods, the SpM's and the SvM's, perform operations on the RTO.k object data space (defIned in the ODS section). The triggering times for SpM's should be defIned by the application designer as part of an SpM specifIcation. The defInition of these triggering times should be placed in the autonomous activation condition (AAC) section of an SpM. An example of an AAC is "for t = from 10am!Q 10 : 50am~ 30min start-during (t, t+5min) fInish-by t+IOmin"
28
The RTO.k object model is effective not only in the multiple-level abstraction of real-time (computer) control systems under design but also in the accurate representation and simulation of the application environments. In fact, it enables uniform structuring of control computer systems and application environment simulators [Kim94] and this presents considerable potential benefits to the system engineers.
The DREAM kernel thus executes RTO.k object components as follows (as shown in Figure 2) (1) ODS segments (ODSS's) as CREW monitors, (2) Both SpM's and SvM's as application-specific program bodies of processes (called method execution processes or MEP's), (3) Paths for accessing SvM's in the form of DFC' s monitored by the SvM's, and (4) Result-return paths to clients in the form of DFC's monitored by the clients, and (5) capabilities for accessing SvM's in other RTO's in the form ofID's of the DFC's monitored by the SvM's.
3. MAJOR FEATURES OF THE DREAM KERNEL In order for the RTO.k objects to provide guaranteed timely services to external clients, the engine that supports the execution of RTO.k objects must obviously provide guaranteed timely services to the requesting RTO.k objects. In addition to containing a hardware platform, such an execution engine should be formed by a timeliness-guaranteed operating system. Existing commercial operating systems are not yet capable of providing guaranteed timely services needed by a great deal of real-time application software.
4. DREAM LmRARY SUPPORT FOR RTO.k STRUCTURED PROGRAMMING IN C++ The DREAM library greatly reduces the burden of the C++ RTO.k application programmer in the construction ofRTO.k objects and in designing kernel service calls (KSC's) to the DREAM kernel. In order to create an RTO.k object, the user should first define an RTOClass that contains (1) an instance of RTOAccessCapabilityClass (representing access rights for SvM's in other RTO's), (2) instances of each ODSSClass (representing the ODS segments in this RTO), (3) instances of each SpMClass (representing the SpM's of this RTO), and (4) instances of each SvMClass (representing the SvM's of this RTO). The user then creates an instance of the RTOClass inside the application initial process (AlP). The AlP is the starting point of the entire application in a node.
The DREAM kernel has been formulated as a model of an operating system kernel that can support guaranteed timely services not only for RTO.k object structured real-time applications but also for conventional process-structured real-time applications . The DREAM kernel guarantees the timely response to service requests by adopting a unique approach for the layering of its components [Kim95]. This approach is based on the organizational principle called the timeleasing machine layering, which is of fundamental nature. Under the time-leasing machine layering principle, the bottom layer (LO in the DREAM kernel) owns the full power of the hardware machine. So, the bottom layer uses the hardware machine at its own will. The remainder of the hardware machine time after the bottom layer use of the hardware machine, is "leased" to the next upper layer (Ll in the DREAM kernel). The time leasing relationship is recursive, i.e., it is maintained through all the layers that compose the kernel (in the DREAM kemellayers LO-lA). Moreover, there is a tight bound on the amount of machine time that each layer uses. This sometimes implies a bound on the frequency of certain types of interrupts that are accepted.
In order to ease the creation of these user-defined RTO.k
............. -.
For supporting the components of RTO.k structured application programs, the DREAM kernel utilizes the same support provided to the components of conventional process-structured real-time application programs. In other words, the DREAM kernel uses the support provided for processes, concurrent-read-&-exclusivewrite (CREW) monitors which are shared data structure monitors for intra-node inter-process communication, and data field channels (DFC's) which are real-time logical multicast channels for both intra-node and internode inter-process-group message communication to execute the components of an RTO.k-structured application program.
DFC DREAM Kemel
Figure 2. Mapping of an RTO.k object to a conventional process-structured program
29
classes, the DREAM library provides a set of pre-defined classes (templates) which can be inherited by the userdefined classes. The set of pre-defined classes includes (1) the BasicRTOAccessCapabilityClass, (2) the BasicODSSClass for constructing an ODSS, (3) the BasicSpMClass, for creating an SpM, and (4) the BasicSvMClass, for creating an SvM. Thus, as wiII be shown in Section 4.2, a user-defined RTOAccessCapabilityClass can be created easily by inheriting the BasicRTOAccessCapabilityClass from the DREAM library and then adding a certain amount of application-specific program components. Other userdefined classes can also be created in similar manners.
method to an MEP, sharing an MEP among several methods, etc. The C++ RTO.k programmer first creates an instance of the RTOExecManClass inside the AlP. Then the programmer may create as many MEP's as necessary and may bind methods to MEP's. An SpM can be exclusively bound to an MEP, can share an MEP with other SpM's, or can be left unbound. However, an SvM is always left unbound. One reason for leaving an SvM unbound is that it may be executed in a pipe lined fashion , i.e. multiple invocations of the same SvM may progress concurrently to effect fast response to service requests.
The shared binding of multiple object methods to the same MEP enables a large number of object methods to be executed on the same local node which supports a moderate number of processes and hence results in increased resource utilization. However, all such methods must have non-overlapping timing constraints. It is up to the designer to ensure this.
In subsequent subsections, we will describe in detail the construction of the individual components of an RTO.k object using the DREAM library. But first, let us consider the manner in which the DREAM kernel executes SpM's and SvM's.
4.1 Execution of SvM's and SpM's as MEP's
4.2 Construction of RTO access capabilities
An RTO.k object method should be assigned to a method execution process (MEP) before the method can be executed. To give maximum flexibility to the application programmer, the DREAM kernel offers different types of method-to-MEP assignments. These include:
The access capability section in an RTO.k object determines access paths to the SvM's of other RTO objects. The access capability represented in the form of the DFC ID that should be used by a client RTO.k object (method) to request for execution of the corresponding SvM. The SvM can be viewed as the owner of the such service-request DFC and constantly monitors the DFC. In the approach adopted by the DREAM kernel, the creator of a server RTO.k should inform all potential clients about the creation of certain services by broadcasting the service-request DFC ID's of the SvM's of the server RTO.k via a special global broadcast DFC. This approach can be implemented efficiently in Ethernet-type local area networks since by broadcasting a single message the creator of an SvM can inform all potential clients about the service-request path. At a client site, the client RTO.k makes a KSC during initialization to obtain the DFC ID of the external server method.
(1) Exclusive binding of a method to an MEP: In this case, a long-term one-ta-one connection is established between a method and an MEP. The exclusively bound method cannot be executed by any other MEP and the MEP cannot be used to execute any other method. (2) Shared binding of multiple methods to the same MEP: In this case, multiple methods are assigned to the same MEP for long duration. Such an MEP can execute only the set of methods that are bound to it. One important restriction for sharing an MEP among multiple methods is that these methods cannot be active concurrently. This requirement has been imposed in order to reduce the complexity of implementation. The RTO.k designer who wishes to use the shared binding facility should ensure that the methods that share the same MEP do not have timing requirements that necessitate their concurrent execution.
The C++ RTO.k application programmer can use a DREAM library class called the BasicRTOAccessCapabilityClass for obtaining access capabilities for server RTO.k's. The programmer should design an RTOAccessCapabilityClass by inheriting this BasicRTOAccessCapabilityClass. The BasicRTOAccessCapabilityClass provides a friendly interface to the KSC RegisterRTOAccessCapabilityO. This KSC is made with the symbolic names of the server RTO.k and the corresponding SvM as parameters and if successful, it returns the DFC ID of the SvM. It is a good practice to define inside the RTOAccessCapabilityClass the parameters for each service request to be sent a server RTO from the host RTO. The following illustrates the construction of RTOAccessCapabilityClass:
(3) Unbound methods: In this case, the methods are not bound to any MEP during initialization. Rather, the methods are left unbound. When it is time to execute the method, the DREAM kernel automatically finds an unbound free MEP (i.e. an MEP that is neither bound to an object method nor is executing another unbound method at the time) and makes an one-shot assignment of the MEP to the method. Unbound methods may thus execute on different MEP's during different execution runs. The RTOExecManClass of the DREAM library offers functions for creating both generic MEP's (for which standard parameters such as stack size, priority, etc. are used) and custom MEP's (for which userspecified parameters are used), permanently binding a
class RTOAccessCapabilityClass: public BasicRTOAccessCapabilityClass
30
public: II parameter for access to SvM3 of RT02 struct ParType_RT02_SvM3 {
kernel, making service requests to SvM' s and obtaining the return-results, informing the kernel about the completion of one execution run, etc. The SpM body is defined as a member function of the SpMClass.
} Par_RT02_SvM3; II Service-request DFC ID of SvM3 ofRT02 int DFCID_RT02_SvM3; RTOAccessCapabilityClassO; II constructor
An SpM may make one of the following types of service requests to an SvM: (I) blocking service requests in which the client (SpM) is blocked after making a service request until either the result is obtained from the SvM or a pre-specified timeout occurs. (2) non-blocking service requests in which the client proceeds after making a service request and retrieves the result of the request later during its execution.
}; RTOAccessCapabilityClass: : RTOAccessCapabilityClassO RegisterRTOAccessCapability ("RT02", "SvM3", &DFCID_RT02_SvM3);
In order for the SpM to make the above calls, the owner RTO should already have obtained the servicerequest DFCID of the SvM as mentioned in section 4.1. The SpM should use this DFCID as an input parameter in the aforementioned service calls. Also, when an SpM is registered, the kernel assigns a unique result-return DFCID to the SpM and enables the SpM to receive return-results via this DFC. This result-return DFCID is passed on by the DREAM kernel automatically along with the service request so that the SvM may use this DFCID while returning its processed results. This DFCID is hidden from the RTO.k application programmer.
} II Instantiation of the RTOAccessCapability class RTOAccessCapabilityClass RAC;
4.3 Construction of ODSS The DREAM kernel treats the Object Data Space Segment (ODSS) of an RTO.k object as a special CREW monitor. A mechanism for concurrency control is necessary so as to maintain consistency of an ODSS which is typically accessed by multiple methods of the host RTO.k. The CREW monitor facilitates flexible and yet safe concurrency control. In order to construct an ODSS, the C++ RTO.k programmer can start designing the ODSSClass by inheriting the BasicODSSClass of the DREAM library. This BasicODSSClass in turn inherits the CREWMgtClass of the DREAM library. The BasicODSSClass provides a friendly interface to kernel services such as: creating and destroying ODSS (CREW) support and obtaining and releasing ODSS access rights. The following sample program shows the use of the ODSS class:
4.5 Construction of SvM's Figure 3 shows the construction of an SvMClass through an inheritance of the BasicSvMClass of the DREAM library. The BasicSvMClass provides functions for registering the SvM with the kernel, receiving a service request, replying to a service request, making service requests to other SvM's in either blocking or nonblocking manner, retrieving the results of non-blocking service requests, informing the kernel about the completion of one execution run, etc.
class ODSSClass:public BasicODSSClass { int X, .. . ; II private data area public: void MethodlO; II a member function
When an SvM is registered with the kernel, the kernel automatically assigns a service-request DFCID to the SvM, broadcasts the DFCID of the SvM on a special global broadcast DFC, and then enables the SvM to receive service-requests via this DFC. Also, the kernel assigns a unique result-return DFCID to an SvM so that the SvM may call for other SvM's and receive results via this DFC. Unlike in the SpM case, the assignment is done at each time of invoking the SvM rather than at the SvM registration time and thus if multiple invocations of the same SvM are concurrently active, each SvM invocation is assigned a unique result-return DFCID.
};
void ODSSClass::MethodIO { II Obtaining RW access rights to the CREW II monitor by calling the member function of the II CREWMgtClass of the DREAM library EnterCREW_RWO; ... ; II access the data area II Releasing RW access rights to the CREW monitor ExitCREW_RWO; } II Instantiation of the ODSS class ODSSClass ODSS I ;
5. SUMMARY OF MAJOR FEATURES OF THE DREAM LffiRARY
4.4 Construction of SpM's
(1) The DREAM library hides various details of passing parameters from the application layer to the DREAM kernel. Each DREAM library class houses a pre-defined set of data items that just need to be initialized by the application program before calling an appropriate
The C++ RTO.k programmer can start designing the SpMClass by inheriting the BasicSpMClass of the DREAM library. The functions provided by the BasicSpMClass include: registering the SpM with the
31
this direction . The authors are currently developing one such extension named the C++T language and RTO.k objects written in C++T will be processed by a combination of a C++T-to-C++ preprocessor and a commercial C++ compiler.
.,,.. mealS al
<~.1.ODSSl7t> .'
ClPI*:ation pOQIaill"lle It10Ud modify INs sIaIemenI 10 Slit each
~~
apc:jcatIon.
6. CONCLUSION
c C
[DeSij 1
::>
Reoor1ComPI9IIOI
;:,
~JXJD.F\:I'_I't.F\:I'_~
~DfCIO.F\:I'-"'t
)
~~ ~tjoc~~
at=iaOentDFOD_RR. F\:I')"I.) C~~ID-'IItPa_PIT. ) erentTrcntelCOII(SRQ DfelD. CIenI DFCD\ ~ PIT. Par SIZe. TIiTlesIar'rl)I - ~
The DREAM kernel offers guaranteed timely services to real-time applications. The DREAM library considerably reduces the efforts required for programming applications in the form of an RTO.k object network. We believe that this suite of tools represent a significant step forward in realizing the GT design paradigms. Nevertheless, it represents a very small portion of the desirable software engineering environment that will fully support GT design. Acknowledgment: The research work reported here was supported in part by US Navy, NSWC Dahlgren Division under Contract No. N60921-92-C0204, in part by the California Transportation Department via the UCI Institute for Transportation Studies, in part by Hitachi, Ltd, in part by mM, in part by Postech, and in part byETRl.
Figure 3. The SvMClass and the DREAM library support for SvM management function in the class. This function will correctly retrieve REFERENCES the parameters from the data area of the class, package them, and make the correct KSC. Any result-returns [Att91] Attoui, A. "An Object Oriented Model for from the kernel are saved in the data area of the class. Parallel and Reactive Systems", Proc. IEEE CS 12th (2) To ease the application programmer's task of Real-Time Systems Symp. , 1991 , pp. 84-93. designing the application interface to the DREAM [Ish92] Ishikawa, Y., Tokuda, H. , and Mercer, C. W., library, the data items in the DREAM library classes are "An Object-Oriented Real-Time Programming often initialized with default values. An application Language", IEEE Computer, October 1992, pp. 66-73. programmer may thus choose to pass these default values [Kim94] Kim, K.H. et aI., "Distinguishing Features and to the DREAM kernel when calling for a DREAM kernel Potential Roles of the RTO.k Object Model", Proc. 1994 service. In such a case, the application programmer IEEE CS Workshop on Object-oriented Real-time Depenneeds to just call the DREAM library function of the dable Systems (WORDS), Oct. 94, Dana Point, pp.36-45 . appropriate class without reinitializing any of the data [Kim95] Kim, K.H. et aI., "A Timeliness-Guaranteed items of the class. Kernel Model - DREAM Kernel and Implementation Techniques", Proc. 1995 1nt'l Workshop on Real-Time The power of the DREAM library in easing the Computing Systems and Applications (RTCSA 95), efforts for structuring C++ RTO.k objects has been Tokyo, Japan, Oct. 1995, pp.80-87. positively tested through several sizable distributed [Kop90] Kopetz, H. and Kim, K.H., "Temporal RTO.k application program developments. However, it Uncertainties in Interactions among Real-Time Objects", still burdens the application designer with the chore of Proc. IEEE CS 9th Symp. on Reliable Distributed dealing with some low-level details in redundant forms Systems, Huntsville, AL, Oct. 1990, pp.165-174. which could be automatically deduced from a high-level [Tak92] Takashio, K., and Tokoro, M., "DROL: An abstract and yet accurate representation of RTO.k objects. Object-Oriented Programming Language for Distributed An extension of the C++ language to support abstract Real-Time Systems", Proc. OOPSL4. , 1992, pp. 276-294. RTO.k programming is the most natural path to follow in
32