18649 - Runtime Monitoring Overview

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.

• SamplePerformanceMonitor counts the number of times the car becomes overweight.  This monitor also highlights the use of the summarize() method to report results at the end of the acceptance test.  If you want to print out information during the monitor run, use the message() method provided.
  
• SampleDispatcherMonitor demonstrates how to use the runtime monitoring techniques to verify high level requirements (you will do this for project 11). The example monitor checks whether the elevator exceeds slow speed as it moves between floors.  Whenever a violation is detected, warning() method is used to print warnings.  The RuntimeMonitor parent class automatically keeps track of the warnings and prints the total at the end of the simulation run.  The high level requirements provided in project 7 (R-T1 through R-T4) are either emergent properties, or they are already verified by the simulation framework.  Project 8 introduces new high-level requirements that you will need to verify with runtime monitoring in Project 11.