18649 - Runtime Monitoring Overview

This page describes the runtime monitoring framework provided by the simulator.  With this framework, you can observe the operation of the entire elevator and use that information to verify and improve the behavior of your elevator.

Your runtime monitor will subclass simulator.framework.RuntimeMonitor.  This class provides event-triggered access to the physical state of the entire system. You can think of the monitor as a module that is physically wired into the entire system and that uses interrupts to respond very quickly to changes in system state. Read the javadoc comments in RuntimeMonitor.java for specific information about the implementation. 

The RuntimeMonitor creates and registers ReadablePayload objects for every physical Payload in the system.  These Payloads are registered using a special interface to the PhysicalNetwork called registerEventTriggered.  When registered this way, a callback to the receive() method is generated every time a Payload object is sent.  Note that there are multiple receive method signatures, one for each type of payload.  The 'msg' argument to the receive method tells you which payload was updated.  This can be useful in distinguishing between callbacks for different replicated instances of the Payloads.  For example, the receive(AtFloorPayload msg) method will be called every time the AtFloorPayload object from any floor/hallway combination is updated.  In addition to physical payload values, RuntimeMonitor also provides access to the mDesiredFloor network message via the DesiredFloorCanPayloadTranslator.

Because your monitor uses event-triggered semantics, if you need to check for a sequence of events, you may need to create some state variables to keep track of events of interest that occurred in the past.  For example. the Boolean field fastSpeedReached  in SampleDispatchMonitor is set true whenever the drive is commanded to fast speed, and then checked when the car comes to stop at a different floor. The SamplePerformanceMonitor class demonstrates a state machine design pattern, which uses a utility class to define a state machine for the door.  This state machine receives a low-level door messages and calls high-level door events (like doorOpening, doorClosing).  Working with events can be tricky, especially since you are used to thinking about time-triggered, but this design pattern can help you organize your monitor design. 

The RuntimeMonitor also provides a SystemTimer object.  SystemTimer objects differ from the regular Timer objects in that they do not affect the pseudorandom behavior of the system (so any bugs or strange behaviors you observe that are due to system jitter are not disturbed by the addition of the monitor to the system). 

Note:  You may NOT use SystemTimer objects in any code other than your runtime monitors.  In your controller classes, you must use the Timer object provided by the Controller superclass.  Failure to follow these rules will result in severe penalties.

We have also provided two stripped-down example monitors (in elevatorcontrol.java):
You should place your monitor classes in the simulator.elevatorcontrol package.  You can instantiate a runtime monitor during acceptance testing using the -monitor commandline option. 

Back to Project 7