The TMO (Time-triggered Message-triggered Object) model, previously referred to as the RTO.k model, was introduced and developed by Kane Kim and his collaborators. This model supports real-time object-oriented programming efficiently due to its syntactic structure and execution semantics. Further information on the TMO model can be found on the Internet at


[Figure 1] Structure of a TMO


used for storage of properties and states of the TMO such as a simple variable or a complex class object. For example, in our simulator, as will be shown later, an airplane simulator object stores in this location information regarding its state and properties such as position, velocity, etc. Data members in the ODS are grouped into harmoniously sharable data store units called object data store segments (ODSSs) in a TMO. Each ODSS is thus a group of data members and is a unit that can be locked for exclusive use by one method execution at a time as well as for shared use by multiple concurrent method executions which perform read-only operations on the data members contained.
list of gates (access points) to remote object methods, logical multicast channels, etc., as shown in Figure 1. These gates provide efficient call paths to remote object methods, logical communication channels, and I/O interfaces.
a time-triggered method, which may be executed in a complex periodic manner. An SpM may represent a real-time periodic task. A part of the SpM is the autonomous activation condition (AAC), which defines the time windows for the execution of that SpM, the completion deadline, and the iteration period. The application level scheduler examines the AAC section to select the next running thread (a detailed description of scheduling is covered in Section 2.2). In the airplane simulator the state of an airplane, such as position, velocity, etc., must be updated during each period. A TMO can have multiple SpMs, and each one can have its own period.
Service Methods (SvM) a message-triggered method, which responds to external service requests. In the airplane simulator, an airplane TMO needs to make a request for an available runway to the control tower TMO. Then, when an appropriate runway is found by the control tower object, it responds to the airplane object by using another SvM.


Distributed computing object model The TMO model supports a distributed computing environment. TMOs can be distributed among multiple nodes. TMOs can communicate with each other using remote method calls, which are also referred to as service requests. To increase concurrency, client TMOs can make non-blocking requests to server TMOs. TMOs can also communicate with each other using logical multicast channels.
Clear Separation of two types of methods
The TMO makes a clear separation between SpMs(spontaneous methods) and SvMs (service methods). An SpM is a method which is triggered by the global time base, which is represented by the internal real-time clock; it is also called a time-triggered method. On the other hand, an SvM is a method which is triggered by the external service request of another TMO. Since this external service request occurs through a message, an SvM is a message-triggered method.
Basic concurrency constraints (BCCs) This rule prevents potential conflicts between SpM's and SvM's and reduces the designers efforts in guaranteeing timely service capabilities of TMO's. Basically, activation of an SvM triggered by a message form 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 store segments(ODSS's) to be accessed by this SvM has an execution time-window that will overlap with the execution time-window of this SvM.
Guaranteed completion time for method execution and deadline for result
As in other RT object models, the TMO incorporates deadlines and it does so in the most general form. Basically, for output actions and method completions of a TMO, the designer guarantees and advertises execution time windows bounded by start times and completion times. Deadlines are also specified in the client?ôs call for service methods for the return of the service results. Triggering times for SpM's must be fully specified as constants during the design time. Those RT constants appear in the first clause of an SpM specification called the autonomous activation condition
(AAC) section. An example of an AAC is

"for t = from 10am to 10:30am
         every 30min
         start-during (t, t+5min)
         finish-by t+10min"

This specifies: "The associated computation unit must be executed every 30 minutes starting at 10 am until 10:50 am and each execution must start at any time within the 5 minute interval (t, t+5min) and must be completed by t+10min." So, it has the same effect as

{"start-during (10am, 10:50am) finish-by 10:10am",
"start-during (10:30am, 10:35am) finish-by 10:40am"}.

Recently, the TMO model is applied to military affairs, factory control, traffic, multimedia and real-time simulation field that need real-time processing. The research about TMO is actively in progress.


// Example of a TMO
#include <TMOSL.h>
// Definition of TMO1
class TMOClass1: public TMOBaseClass
     ODSSClass1 m_ODSS1;
     SpMClass1 m_SpM1;
     SvMClass1 m_SvM1;
     TMOClass1(const char* TMO_Name, TMOGateClass& Gate1, const tms& TMO_start_time) : m_SpM1("SpM1", gate1, m_ODSS1, RO), m_SvM1("SvM1", m_ODSS1, RW)
          //Register this TMO to TMOSM
          activate(TMO_Name, TMO_start_time);