Specifies the access mode the device read write and the type data

CPL: A Language for

Real-Time Distributed Object Programming

single processor architectures, it is becoming more and more attractive to use

distributed computing with additional real-time capabilities. In several cases, traditional

language features are described. The new language provides an efficient solution for

especially command and control systems by embedding distribution and real-time issues

1 INTRODUCTION

A real-time computation is one in which the timeliness of a response to an event is as important as the correctness of the response. Parallel and distributed computing is useful for real-time systems for three fundamentally different reasons [1]. First, the processing and response requirements of some applications are so extreme that even the fastest uni- processors are inadequate. It is natural to apply multiple processors/computers to such problems. Second, such systems may use multiple copies of system components, thus providing fault-tolerance through redundancy. Third, some real-time applications are by nature geographically distributed. In all cases, the real-time application requires techniques for partitioning the problem, coordinating concurrent access, and communication within tight delay bounds. It is true that real-time distributed software can be developed in any language, but when conventional programming languages are considered, programming becomes difficult and time-

CPL uses the object-oriented programming approach. The essence of object-orientation is the unification of the type and module concept in the class construct. Thus, in CPL, a class is the

basic unit of development and compilation. An object is the unit of concurrency. A CPL application consists of a collection of objects distributed over multiple nodes, interacting via remote method calls. Being a syntactic and semantic extension of C++, CPL provides a “general high-level programming style” that enables programmers practice effective methods in distributed real-time programming. Distributed objects represent a higher-level structure for distributed applications. Communication between objects is transparent at the programming language level where there is no reference to the location of objects, thus providing the programmer with a single object space.

A growing class of real-time systems includes applications on manufacturing process control, videoconferencing, command and control, large-scale distributed interactive simulation, real-time storage and search for information and real-time communication and display of information. Of these, Distributed Command and Control (DC2) systems are in the main target domain of this study. Both industrial and military command and control systems require an efficient infrastructure capable of handling large amounts of high frequency data. Automated control systems collect data from various sensors or input devices, evaluate them and remotely control some actuators, preserving real-time constraints. In addition to efficient device control, fast and reliable access to shared data is also required. The design decisions related to the real-time features of CPL have been strongly guided by these requirements.

3 RELATED WORK

4 THE CORD SYSTEM

An efficient middleware architecture named CORD-RTS (Concurrent, Object-Oriented and Real-Time Distribution Run-Time System) has been developed to support CPL (Cord Programming Language). CORD-RTS allows development of distributed real-time applications that are independent of node hardware, operating system and network topology.

DISTRIBUTED CPL PROGRAM

tests, 200 to 800 microseconds of accuracy has been achieved in synchronizing workstation clocks on an ATM network by using the internal clock of one of the workstations as the main time reference.

5 CPL OVERVIEW

Distribution: CPL programs execute on a distributed environment. Objects can be initiated on local or remote nodes. Active objects residing on different nodes communicate in exactly the same way as those residing on the same node without requiring location information. Passive objects are accessed by the local active objects in order to provide fast data exchange. Device objects can be accessed from any location, providing remote device control.

Communication: Communication is through uniform method invocation on both local and remote active objects. Method calls are either synchronous or asynchronous, depending on the return type of parameters specified in the method declaration in the class specification. Methods that return any kind of information are called synchronously, forcing the caller to wait until execution is complete. Communication between active and passive objects that reside on the same node does not initiate a remote method call; instead a simple function call is used in the program context of an active object. In addition, publish-subscribe mechanism for method multicasting is a faster mode of communication as its implementation does not require a method call, but delivers data when available.

CPL enables efficient specification and execution control of the following features to meet real-time requirements of distributed object applications:

• Priority value assignment to active objects

• Execution of periodic and scheduled events, activated on real-time basis

• Iterative computations with time constraints

5.2.1 Active Objects

Active real-time objects, which are instances of the CPL-defined active classes, are the primary processing units of a distributed CPL program. An active object is, in opposition to a passive object, an object that is associated with an independent flow of execution. It is capable of calling methods of all other types of objects and provides a set of service methods that can be called from outside. Each active class has a server that creates instances of active objects with the exact functionality defined in the class. Each node has a copy of each active class server, ready to create new objects that differ from each other only in the contents of their data members. Active real-time objects can be distributed over the network both at run- time and off-line. They are implemented through Unix processes and their scheduling is handled by the operating system of the node on which they reside. The class declaration indicates a scheduling priority, in the range of 1 to 10. This value is mapped to the underlying operating system scheduling scheme during object creation.

it is declared as an inout parameter. A call to a method that has only in parameters, or no parameter at all, results in an asynchronous and unidirectional call from the caller to the callee. If the method called has at least one out or one inout parameter, then the result is a synchronous and bi-directional call, which causes the caller to suspend execution and wait for a reply from the callee.

Periodic-methods section: Active objects can specify time-triggered method invocations at regular intervals in millisecond domain. It is possible for an object instance to install any number of timers to trigger any number of events. The section marked with the keyword periodic and an integer value to represent a time interval in millisecond indicates a list of parameterless methods that are to be called periodically at each interval.

deviceclass Class_D; //Obj_D exists in the system activeclass Class_A {
uses Class_B, Class_D, SystemManager;
priority 5;
data:
Name own_name;
//a string-holder class int mem_size, num_elem;

int current_value, value; Boolean_Type ready;
SystemManager sys_mng;
dynamic1024:
Link_List
element_list; methods:
GetNumOfElem(out: int N);
SetMemSize(in: int S);
Compute(inout: int X);
Calculate(in: int Num, out: int Y); Insert(in: int Num);
SetValue(in: int Val);
periodic 3000:
SendNewData();
periodic 1000:
ReportHeartBeat();
publish:
NewData(int D);
subscribe:
SetValue to Class_D.Obj_D;
Insert to Class_B.Produce;
};

Calculate(in: int Num, out: int Y)
{ Y = Num * Value; }

Insert(in: int Num)
{ element_list.Insert(Num); }

class_main: //This part is activated once during the elaboration cout << “This is the class main.” << endl;
System_Manager sys_mng(“NODE_1”);
sys_mng.Report(own_name, STATUS_AVAILABLE); //initial report }

5.2.2 Passive Objects

body Class_P {
Insert(in: int Value) {
CPL_LOCK;
list[Index] = Value;
CPL_UNLOCK;
}
Get(in: int Index, out: int Value) {
CPL_LOCK;
Value = list[Index];
CPL_UNLOCK;
}
}

5.2.3 Device Objects

deviceclass Serial_Comm {
priority 6;
read int;
buffer 10;
speed 2400;
};

5.3 Object Manipulation

#define NODE_1 105.23.25.01
#define NODE_2 105.23.25.02

Class_A obj1 on “NODE_1”;
Class_A* obj2 = new Class_A; //on the current node
Class_A obj3(initial_value) on “NODE_2”;
Class_A *obj4 = new Class_A on “NODE_1”;
Class_A
*obj5 = new Class_A(“NODE_2”); Class_A *obj6 = new Class_A(the_node); //the_node is a variable //determined at run-time Class_A* obj7 = new Class_A(initial_value) on “NODE_1”;
Class_P *obj8 = new Class_P(initial_value); //passive object Class_D* obj9 = new Class_D(“ttya”) on “NODE_2”; //device object

Class_A();
Class_A(in: int Val);
Class_A(in: int X, in: float Y);

Deletion: A CPL object is destroyed when its default method Delete() is invoked by an active object or by the main module of the program. This call results in locating the node on which the object resides, deallocation of its resources and removal of the object representation from the system.

In a synchronous call, a CPL client object that issues a method call blocks and waits until the method of the destination object returns a result. A call to a method that possesses at least one

out or inout type of parameter initiates a synchronous communication. RTS suspends the execution of the caller object until the callee returns a value determined by the out or inout typed parameter. An out type of parameter causes a unidirectional data exchange from the callee to the caller while an inout type of parameter initiates a bi-directional data exchange between the participants of the communication.

Following method calls are examples of synchronous/asynchronous communication for the above declarations:

obj1.Set_Value(value);
obj1.Compute(value, result);
obj1.Extrapolate(old_value, new_value);

publish:

New_Data(int v1, int v2, float v3, char v4); Update(int v1, float v2);

5.5 Time-Related Constructs

Time-related constructs are primitives that supervise timed events. They are used to express the timing behavior of an application, as the timeliness of a response to an event. All time- related constructs take part in active object implementations since an active real-time object is the basic unit of execution of a CPL program.

//*** Do periodic processing here ***// current_time = Get_Current_Time();
next_time = next_time + period;
sleep_time = next_time - current_time; END LOOP

5.5.2 Timed Loops

CPL has extended regular C++ iteration statements with timing assertions, making it possible to explicitly express timing requirements on object behavior. Two types of timers are used in their implementation: one-shot timers and periodic timers. A one-shot timer fires off once at

do-until loop: This structure executes iteration starting with do until the current time exceeds the specified wall clock time after the keyword until. The time value is specified after the keyword until, in 24-hour format (hh:mm:ss.mmm). Any setting exceeding a day has to be handled by additional algorithms. There may be a blocking function call such as Sleep() inside the loop.

do {
obj1.Read(Value);
obj1.Write(Value);
CORD_RTS.Sleep(1000);
} until 20:45:00.00;

//at 12:00:00.0
{ value = 200;
Process_Data(value);
} at 12:30:00.0; //execute block of statements at time 12:30:00.0

5.5.4 Exception Handling

obj1.Get_Data(data, CORD_PRIORITY_3, 100) timeout { Alert(); }

In this example, the method has a priority of value 3 and the deadline for result return is 100 milliseconds after calling time. If timeout occurs before the reply is received, the statements in the timeout block are executed. If a call does not specify a timeout value, then the system default priority (five) and an infinite time interval is assumed.

kind occurs, an implicit counter is incremented and the call is issued again if the number of trials denoted by retry has not been reached yet. Otherwise, control passes to the statements in the retry block.

A CPL program consists of one or more CPL modules, classes and their bodies. CPL modules are compiled with the CPL compiler, which includes a C preprocessor, the CPL Preprocessor and a C++ compiler. Compiling the main module results in a header and body file, which are then linked with appropriate files to form a single executable. Compiling an active class produces client stub code as a header and a body file, a server header and a body file. After linking, the server files construct an executable. Compiling a passive or a device class produces header and body files, which are to be linked to an executable, such as an active class or the main module. Figure 3 illustrates a standard application development

Preprocessing