Dear WP1, WP4, WP5, WP6

This is to inform you that the simulated time support service in OSIMIS
is now realised and tested, you can get it from the QMW server and the
directory archive/osimis as simtime-1.0.tar.Z . This works fine with
OSIMIS-3.2 but another patch is needed for a bug revealed in RMIB -
this is osimis-3.2-patch-6.tar.Z in the same place.

There is no documentation yet, there will be available soon. The model
for this realisation is exactly as stated in the initial design document
(reference ICM/WP3/UCL/9310111200) with one small addition. I highlight
the most important aspects of the model below.


THE MODEL

At the Q-Adaptor level, simulators' Q-Adapters should have as top of
the MIT an instance of class systemSim, allomorphically derived from
the ISO system. This includes the attributes "simulatedTime",
"reportingInterval" and the notification "attributeValueChange" for
simulatedTime.

At all the other levels of the TMN hierarchy, an Operations System (OS),
Mediation Device (MD) or Workstation OS (WS-OS) should instantiate
an internal ("application") object of class TimeManagerForward for OS
and TimeManager for WS-OS (inheritance: TimeManager <- TimeManagerForward).

This should be told at start-up time the application title of at least one
peer or subordinate OS/MD/QA. It will then try to retrieve the systemSim
attributes through CMIS/P and register for the attributeValueChange
event report.  If it fails, the application will operate in real-time
while if it succeeds the application will work in simulated time.

Note that all this is totally transparent to other application objects
that request polling support through the fundamental OSIMIS KS class.
As a result, an application can operate in only real or only simulated
time. This complies with the WP1 requirement of possibly identical applications
for the simulator and real networks.

The only deviation from the initial model was the introduction of the
TimeManagerForward class which will relay the received event report to peer
or superior TMN OS/WS-OSs so that e.g. service level OSs do not have to
talk directly to a QA as it was stated in the initial model.


IMPLEMENTATION GUIDELINES

Simulator QA implementors should make sure that the top MIT instance
is of class systemSim and to update the simulated time consistently
with the reportingInterval.

Implementors of MDs, OSs and WS-OSs should make sure that they instantiate
an object of class TimeManagerForward (MD/OSs) or TimeManager (WS-OS/SimQAs)
and pass to it the address of an already initialised RMIBAgent object
that talks to one subordinate/peer OS/MD/QA. After that, everything is
taken care by the infrastructure.

In case the transparent time facility is used in reality, specialised
application KSs should make sure they request wake-ups in multiples
of the reportingInterval. The latter is available at run-time from
the TimeManager class.

Finally, the order in which libraries are linked is very important
as the simtime one re-implements the methods of the KS class and
HAS to be linked-in before the kernel library. An example order for
an Operations System is:

<os>	- the OS MOs and intelligence, these could be more than one libraries
simtime	- the simulated time support service
stdmib	- contains the ISO system MO
rmib	- the RMIB support service
gms	- the GMS
smisntx	- the SMI/DMI standard syntaxes
kernel	- the coordination support / OO ASN.1 support services
util	- general utilities, including useful objects (strings, lists, arrays)
	  and the GDBM database support service
msap	- the CMIS/P realisation
lt	- the location transparency support service
sntx	- support for oidtable management, needed by the OO ASN.1 support
dsap	- the directory access service/protocol
isode	- ACS, ROS and the rest of the OSI stack

Note that even WS-OSs will need the gms library to link as it is used
by the simtime one (code will be not actually linked in though).


Enjoy,

George


P.S. The functionality of the simtime library is shown in an example agent
     which operates in real time but implements the systemSim class.
     This reports simulatedTime changes every 5 real time seconds, pretending
     these are 10 units of simulated time.

     Then an example WS-OS requests wake-ups every 60 units:
     if this connects to any other agent, it will operate in real time being
     awaken-up every 1 min (60 secs). If it connects to the agent above,
     it will operate in simulated time and will be awaken-up every 30 secs
     as simulated time runs faster than real time in this example
     (not in practice I'm afraid...)

