Adding Hard Real-Time Capabilities to CORBA

Transcription

1 Adding Hard Real-Time Capabilities to CORBA Thomas Losert 1 1 Institute for Computer Engineering, Vienna University of Technology, Vienna, Austria losert@vmars.tuwien.ac.at Abstract Control systems are often software-intensive applications that are becoming extremely complex as new functionality is required. Complexity is a real engineering challenge and distributed object technology has proved useful for dealing with this problem. Since silicon area becomes cheaper, using CORBA in an embedded system becomes viable. One of the leading technologies in this field is the object request brokering model proposed by the CORBA specification of the Object Management Group. But, while present CORBA specifications do address real-time issues they deal only with soft real-time systems, and this is not enough for certain types of distributed systems (namely controllers). This paper presents an approach of making CORBA usable in distributed control applications where timeliness is crucial for the stability and thus dependability of the closed control loop. 1 Introduction Nowadays large control systems, e. g. chemical plants or a petrol refinery, consist of several thousands of sensors and actuators. Most of them are embedded systems with a microcontroller. As technology evolves in near future most of them will be capable of running CORBA. The CORBA specification is one of the most successful specifications of the Object Management Group (OMG) and it has been published in October 1991 first. It included the CORBA Object model, Interface Definition Language (IDL), and the core set of application programming interfaces (APIs) for dynamic request management, invocation (DII) and the Interface Repository. The C language mapping has been the only language mapping available. In the current version, CORBA 3.0 (see [1]), several extensions have been added that allow to use CORBA in a more general way. Among them are: The specification of mappings for further programming languages (e. g. C++, Java, COBOL, Smalltalk, Ada, or Lisp) allows choosing any of these programming languages for implementing a CORBAobject. The mandatory Internet Inter-ORB Protocol (IIOP) allows interoperability among all systems compliant to this specification.

2 LOSERT Nowadays CORBA is not only used as middleware for temporal uncritical systems like travel-agencies or online shopping but also in time critical systems like control applications. The remainder of this paper is structured as follows: Section 2 introduces to the principles of CORBA while section 3 provides a short overview to real-time CORBA. In Section 4 the basic concepts of the Time Triggered Architecture are presented as well as the Time Triggered Protocol. Section 5 presents two approaches that will be evaluated in the case-study and section 6 concludes this paper. 2 CORBA In general, the invocation of a method in a CORBA object (server) by another CORBA object (client) requires the parts outlined in figure 1. Client (Reference) Server (Object Implementation) Static IDL Stubs Dynamic Invocation Interface ORB Interface Static Dynamic IDL Skeleton Skeleton Interface Object Adapter Object Request Broker (GIOP / IIOP) OS Kernel (I/O Subsystem, Network Interface) OS Kernel (I/O Subsystem, Network Interface) Network Figure 1: CORBA Overview A CORBA-system consists of the following components: client object, ORB, POA, and application objects, and the stubs/skeletons for the objects. The interface of a CORBA object is expressed in a standardized way by using the Interface Definition Language (IDL). The code for the stubs and skeletons is generated by a vendor specific tool. The interfaces between the ORB and the stubs and skeletons, via the POA (see section 2.2), are not standardized. Thus every vendor can create its own set of ORB, POA, and generator-tool (called IDL-compiler) for the stubs and skeletons that is optimized, e. g. for a specific platform.

3 ADDING HARD REAL-TIME CAPABILITIES TO CORBA 2.1 ORB The Object Request Broker (ORB) is the central building block in this architecture and encapsulates internal details of the operating system regarding communication over a network. Each service request is routed to the proper application object and the result back to the destination (usually the client), thus providing location transparency (i. e. there is no difference for the client of using a local or a remote object). In the case of remote objects this requires the ORB to communicate with other ORBs. This takes place via the standardized General Inter-ORB Protocol (GIOP) and thus allows interoperability between ORBs from different vendors. The interface of the ORB that allows, e. g. initialization of the object adapter (see section 2.2) is defined in [1, chapter 11]. For addressing a CORBA object an Interoperable Object Reference (IOR) is used. The IOR is usually stored by a CORBA object as a string containing primarily a hex-dump of the internal representation and it is valid until the object is destroyed (and it never becomes valid again, once the object has been destroyed). The meaning of the IOR is opaque to the developer, i. e. no information can be extracted from an IOR. The naming-service can be used to retrieve the IOR of a particular object by using a more natural name. This still leaves the problem of bootstrapping since the IOR for the naming-service is required. This can be solved by transmitting the IOR by or storing it in an a priori known file. This has been made easier by introducing another more human-readable form of an IOR that is based on the syntax of a Uniform Resource Identifier in the World Wide Web (see [2]). The temporal predictability of the ORB s behavior can be obscured by buffers and threads within the ORB as well as by the behavior of the underlying network/os. 2.2 OA The Object Adapter (OA) receives the client s request and translates it into a representation that is understood by the server object implementation. The first approach has been the Basic Object Adapter (BOA) which is deprecated now. Instead the Portable Object Adapter (POA) as described in [1, chapter 11] should be used. In order to allow scalability it is impossible to have all objects running at the same time but it is necessary to store the state of unused objects to persistent memory and load them on demand. The servant contains the methods for an object, where a method is defined in CORBA as the programming language code that implements an operation defined in an IDL interface (see [3, chapter 5.3]). The servant is inherited from the servant base class (also called skeleton) generated by the IDL-compiler and is not touched by the programmer since it provides logic for interface-specific details of the ORB. From a client s point of view the server object is running always and waiting for an invocation of the client until it is destroyed. The server s point of view differs but the difference does not matter since the invocation is encapsulated by the OA that creates an instance of the servant and invokes the method. The temporal predictability of the OA s behavior can be obscured by the task of demul-

4 LOSERT tiplexing all the incoming requests. 2.3 Extensible Transport Framework The Extensible Transport Framework (formerly called Pluggable Transport) is still work in progress. At the time of writing this document the most recent interim version is [4]. This Request for Proposal has the intention that the transport is decoupled from the ORB. This allows changing the transport layer without any modification of the ORB. The interface consists of two parts: the remote operation component that takes care of the inter-orb communication by defining the Inter-ORB Protocol (IOP) and the message transfer component that is responsible for the implementation of the mapping to the communication protocol In the case-study (see section 5) we will consider the Open Communication Interface (OCI) [5] that is an intermediate result from earlier stages of the standardization process. Since the principles have remained the same and there is already an implementation of an ORB supporting the OCI it fits our needs for a case-study. 3 RT-CORBA Originally CORBA has not been planned for hard real-time systems. Therefore several sources of indeterminism can be identified that could cause the system to miss its deadline: marshalling of parameters at the clients side, the protocol queues of the client, delays on the transport media, the protocol queues on the server, dispatching of threads and requests, and unmarshalling of parameters at the servers side. Real-Time CORBA (see [6] and [7]) tries to overcome these problems by defining priorities and binding the duration of thread priority inversions as well as of operation invocations. End-to-end predictability can be reached if the scheduling mechanisms in the OS, the Real-Time ORB, the communication transport, and the application are designed and implemented in order to support it. The RT-CORBA specification extends the standard CORBA specification by some new interfaces, e. g. RT-POA, RT-ORB, Priority-Mappings, and Scheduling Disciplines (thus the interface is a superset of standard CORBA). Nevertheless there is no viable possibility of reducing complexity by dividing a system into subsystems. Thus the implementer is left with the complexity of the whole system. Introducing composability (see section 4.3) while preserving end-to-end predictability is the major goal of this work. 4 Time Triggered Architecture The Time Triggered Architecture (TTA) has been developed in the last twenty years at the Institute of Computer-Science at the Vienna University of Technology (see [8]). It provides a computer infrastructure for the design and implementation of dependable distributed embedded systems by allowing the decomposition of large real-time applications into nearly autonomous clusters and nodes.

5 ADDING HARD REAL-TIME CAPABILITIES TO CORBA 4.1 Event Triggered vs. Time Triggered A trigger is an event that initiates some further action, e. g. the execution of a task or the transmission of a message. Depending on the triggering mechanism for the start of communication and processing activities in each node of a computer system, two distinctly different approaches to the design of real-time computer applications can be identified: the Time-Triggered (ET) and the Event-Triggered (TT) approach. In the event-triggered approach, all communication and processing activities are initiated whenever a significant change of state of an event other than the regular event of a clock tick, is noted (e. g. another piece is added to the basket). In the time-triggered approach, all communication and processing activities are initiated at predetermined instants by the progression of time. In ET systems only the transmission of the difference to the previous value is required which leads to a more compact representation and thus consumes less bandwidth on the communication channel. As a drawback this requires an exactly-once semantics and the loosing a single message leads to loss of synchronization which is can be detected at the possibly malfunctioning sender only since no message could also be caused by the absence of a significant change of state. On the other hand TT systems periodically transmit the full state. Because of its idempotent nature an at-least-once semantics is sufficient. Missing messages result in a loss of synchronization for one period and it can be detected at the receiver because the instant of transmission of a message is a priori known. While ET systems are flexible, TT systems are temporally predictable (see [9]). 4.2 Principles of Communication In the most simple case we define two communication partners interacting with each other in a way that a piece of information is communicated from one particular partner to the other. We refer to the sender of the information as producer while the receiver is called consumer. The flow of data is from the producer to the consumer always (plain lines in the following figures). The transport of the information is initiated by the trigger source (one of the two communication partners or an external source). Thus the exact instant when the communication takes place depends only from the trigger source, i. e. the instant of the communication is in the sphere of control of the trigger source. We define the flow of control in a way that it origins from the trigger source always (dashed lines in figure 2). Producer Consumer Producer Consumer (a) Push (b) Pull Figure 2: Communication Push-Principle (a) and Pull-Principle (b)

6 LOSERT In [10] two basic ways of communicating information are identified: push communication and pull communication. The push communication is characterized by a flow of control from the producer to the consumer (see figure 2(a)). Since the producer can communicate the information immediately after it has been sensed this model allows the shortest possible latencies for dealing with an event detected by the producer. The pull communication can be identified because of the flow of control from the consumer to the producer (see figure 2(b)). It is the ideal model for the consumer since the instant of communication is in the sphere of control of the consumer but it can cause problems on the producer s side. In [11] another principle of communication is presented: decoupled time-triggered communication. The time-triggered communication uses neither the producer nor the consumer as the trigger source for the instant of communication but an external clock. Thus both communication partners, the producer as well as the consumer, require a global view of time in order to transport information. This is a compromise between push communication and pull communication since both communication partners are interrupted in an a priori known schedule. Producer Memory Memory Consumer Push Time-Triggered Communication Pull Figure 3: Time-Triggered Communication Principle The TTA communicates information as outlined in figure 3: The producer writes its information into a memory element located nearby the producer by using push communication that is known to be the ideal way of communication for the producer. A timetriggered transport layer communicates the information in the memory element over the network to another memory element located nearby the consumer in a deterministic way with known latency and minimal jitter. Then the consumer can read the information from the memory element by using pull communication that is known to be the ideal way of communication for the consumer. Since no flow of control passes the boundary of the memory elements this way of communication fulfills the requirements of a temporal firewall (see section 4.4) and allows isolation of errors in the temporal domain. 4.3 Composability We call an architecture composable with respect to a specified property, if the system integration will not invalidate this property provided it has been established at the subsystem level, e. g. timeliness properties should follow from subsystem properties.

7 ADDING HARD REAL-TIME CAPABILITIES TO CORBA Otherwise the system integrator is left with the challenging task to find out why the system does not work, although all subsystems work according to their specifications (see [12]). 4.4 Temporal Firewall According to [13] a temporal firewall is defined as a unidirectional, data-sharing interface with state-data semantics where at least one of the interfacing subsystems accesses the temporal firewall according to an a priori known schedule and where at all points in time the information contained in the temporal firewall is temporally accurate for at least d acc time units (the temporal accuracy interval) into the future. Since a temporal firewall is free of control signals there is no possibility of a controlerror propagation accross the temporal firewall. The unidirectional data-flow allows dataerrors to propagate from the producer to the consumer only. Thus it encapsulates a subsystem and acts as an error containment interface. Each subsystem receives its parameters from the input-firewall, that establishes a priori known pre-conditions, and writes its results into the output-firewall, thus establishing a priori known post-conditions. Validating a system consisting of several subsystems is performed by validating, if the post-conditions are fulfilled under the assumption that the pre-conditions are fulfilled. This allows validating nearly independent subsystems instead of the whole system which reduces complexity significantly and allows composability as described in the previous section. 4.5 Time Triggered Protocol In the Time Triggered Protocol for SAE Class C applications (TTP/C) each node contains a dual ported RAM that temporally decouples the host computer from the communication controller. This RAM ist called Communication Network Interface (CNI) and constitutes a temporal firewall as outlined in the previous section. All nodes in a cluster are connected by two redundant communication channels with each other. Communication takes place according to an a priori known TDMA schedule, were each node is assigned to its unique sending slot. In this sending slot the communication controller sends a particular region of the CNI to the bus while the other nodes read the data and store the information in their CNI. After one TDMA round each node has the same data in its CNI (see figure 4). Node 0 Node 1 Node 2 Node 3 round n-1 round n round n+1 Figure 4: An example for a TTP/C TDMA Schedule

8 LOSERT This type of communication requires a global time base in order to allow all nodes to integrate into the common TDMA schedule. This global time base is provided to the application also. Due to the static offline scheduling the communication is performed nearly autonomous. The application can exploit the a priori knowledge of the instants of communication and read the values from the CNI. 5 Case-Study In complex systems built of smart embedded systems as described in [14] the constraints of traditional CORBA and RT-CORBA become obvious. For overcoming these limitations several solutions have been elaborated (see [15]). The two most promising ones are: The pluggable data interface and the active server. The following sections describe both approaches in detail. 5.1 Pluggable Data Interface This approach preserves the TTP communication mechanism in the sense that only values (and no GIOP messages) are exchanged between client and server CNI memory endpoints. Thus the implementation of the transport plugin on the client side must preprocess the GIOP message and write the value into the local CNI memory of the client (assumed that the client sends periodically the value to the server). After the TTP has transferred the value to the local CNI at the server side, the value from the CNI memory must be encoded into a GIOP message to be passed to the ORB. This is necessary in order to maintain ORB interoperability. It is possible to match a value with a CORBA request on the server side as in TTP each value is stored in a predefined memory position. Hence a value can be matched to a request. The advantages of this approach are as follows: Only the transport plugin must be modified. No changes are necessary at the ORB. Resources in the TTP hardware are scarce (mainly the CNI memory). This option has the advantage that it is memory efficient because only values are written into the CNI memory. On the other hand the following disadvantages have to be considered: This solution is application dependent. A new plugin must be developed for every TTP application. This is due to the fact that the plugin must know the certain area of the CNI memory that matches a CORBA request. So it is able to build a GIOP request and pass it to the broker in order to invoke the code of the servant at the server side. Less CORBA compliant. Only state values are exchanged between client and server endpoints. It is not possible to specify policies at the client side to be applied at the server side or the other way round. This option requires more computanional resources to parse GIOP in the transport plugin. There is more processing overhead as GIOP messages are processed twice. Performance depends on relationship of host speed and network bandwidth

9 ADDING HARD REAL-TIME CAPABILITIES TO CORBA 5.2 Active Server Usually CORBA-objects are passive entities that react only upon requests from clients. In hard real-time applications, sampling of values (e. g. a temperature sensor) is commonly done on a periodic basis. This means that values must be available at the server side for clients to use them. In a TTP application, state values can be copied from the server to the client endpoint periodically. So clients need only to read the value locally in order to get the last sample. The Active Server approach is based on the principle that the transport plugin at the server side is responsible for building the request and passing it to the ORB at predefined instants to receive from the ORB the new value for the sampled data. Thus the application at the server side is driven from the communcation layer and the server code is initiated at predetermined instants of the global time. In this approach the communication system takes the role of a client for a passive server. The advantages of this approach are as follows: Provides better temporal behavior since the a priori knowledge is exploited and the requests are issued synchronous to the TTP. This option supports the notion of global state variables as server values which are spread by TTP across the system are received locally by the client objects. On the other hand the following disadvantages have to be considered: Requires changes to the OCI, ORB, and probably to the IDL compiler. Thus interoperability with other CORBA systems is a more complex task. It is more complex and thus will require more effort to implement. 6 Conclusion This paper presents two ways of adding hard real-time capabilities to a CORBA equipped embedded system. Although both approaches are based on application dependent parts this does not necessarily mean that the programmer has to do additional work since it is possible to write a code-generator that creates most of the application dependent code. The active server approach will be the better approach concerning the temporal behavior but requires more effort since, additional to the changes in the OCI, also changes in the ORB and the IDL-Compiler are required. Thus the further experiments will emphasize on the Pluggable Data Interface because it should be easier to gain interoperability with other CORBA systems. Compared to the existing RT-CORBA specifications these approaches provide end-toend predictability while retaining composability in the temporal domain that allows to construct a complex intelligent system out of prevalidated building blocks of easily manageable complexity since stability and dependability of control loops depend on, e. g. the jitter. It is not only limited to local networks based on wires but can be used on any transport layer that provides the necessary temporal properties and allows to establish a global time-base (also wireless as discussed in [16]).

10 LOSERT Acknowledgements This work has been supported by the HRTC project (contract No IST ) which is funded under FP5 of the IST Programme (see ist-fp5.html) by the European Community. References [1] OMG. CORBA 3.0 Specification. Available Specification document number formal/ , Object Management Group, Needham, MA, U.S.A., December available at omg.org/formal/ [2] Tim Berners-Lee. Universal Resource Identifiers in WWW. RFC 1630, CERN, Geneva, Switzerland, June [3] Jon Siegel. CORBA 3: Fundamentals and Programming. John Wiley & Sons, New York, NY, U.S.A., ISBN [4] OMG. Extensible Transport Framework. Revised Submission document number mars/ , Borland, OIS, Vertel, U.S.A., February available at [5] OMG. The Open Communications Interface (OCI). Submission document number orbos/ , Iona, U.S.A, Object Oriented Concepts, Australia, available at orbos/ [6] OMG. Real-Time CORBA. Joint Revised Submission document number orbos/ , Object Management Group, Needham, MA, U.S.A., December available at org/orbos/ [7] OMG. Real-Time CORBA 2.0: Dynamic Scheduling Specification. Final Adopted specification document number ptc/ , Object Management Group, Needham, MA, U.S.A., August available at [8] Hermann Kopetz and Günther Bauer. The time-triggered architecture. In Proceedings of the IEEE, volume 91, issue 1, pages , January [9] Hermann Kopetz. Real-Time Systems: Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, Boston, Dordrecht, London, January ISBN [10] Robert DeLine. Resolving Packaging Mismatch. PhD thesis, Computer Science Department, Carnegie Mellon University, Pittsburgh, U.S.A., June [11] Wilfried Elmenreich, Wolfgang Haidinger, and Hermann Kopetz. Interface design for smart transducers. In IEEE Instrumentation and Measurement Technology Conference (IMTC), volume 3, pages , May [12] Hermann Kopetz and Roman Obermaisser. Temporal composability. In Computing & Control Engineering Journal, volume 13, issue 4, pages , August [13] Hermann Kopetz and Roman Nossal. Temporal firewalls in large distributed real-time systems. In Proceedings of the Sixth IEEE Computer Society Workshop on Future Trends of Distributed Computing Systems, pages , Tunis, Tunesia, October [14] Philipp Peti, Roman Obermaisser, Wilfried Elmenreich, and Thomas Losert. An Architecture supporting Monitoring and Configuration in Real-Time Smart Transducer Networks. In Proceedings of the IEEE Sensors 2002, volume 2, pages , June available at http: //ieeexplore.ieee.org/. [15] Miguel Segarra, Thomas Losert, and Roman Obermaisser. TTP Transport Definition: For HRTC pluggable Transports. HRTC Project Report document number IST37652/008, May [16] Thomas Losert and Roman Obermaisser. Wireless Real-Time Communication Technologies: A Comparative Study. In Proceedings of the IEEE Workshop on Real-Time Embedded Systems, London, United Kingdom, December 2001.