Rail Traffic System Adaptation Rules (continued)

C: select Display.access
   where Display.access = true
A: update Crossing.crsng_delay := current_delay
   where part-of(Crossing,train_location)

C: select Display.access
   where Display.access = true
A: update Crossing.crsng_delay := 0
   where NOT part-of(Crossing,train_location)

The first of these two rules says that the crossing delay should be updated to the current delay time if the crossing is part of the current train location. In other words, if the train is occupying the crossing, then the delay time should be updated to the current delay time. The current delay time is calculated from the simulator's information. This calculation is handled in the adaptation engine.

The second rule is the converse of the previous. It captures the case where the crossing is not currently occupied by a train. This rule simply says that the crossing delay time should be set to zero is there is no train occupying the crossing.

C: select Display.access
   where Display.access = true
A: update Crossing.crsng_block := time_till_block
   where NOT part-of(Crossing,train_location)

C: select Display.access
   where Display.access = true
A: update Crossing.crsng_block := 0
   where part-of(Crossing,train_location)

The first of these two rules says that the crsng_block attribute should be set to the time until block if the crossing is not part of the current train location. In other words, if the train is not occupying the crossing, then the time until block should be updated to reflect the current time until the delay. The time_till_blcok is calculated from the simulator's information. This calculation is handled in the adaptation engine.

The second rule is the converse of the previous. It captures the case where the crossing is currently occupied by a train. This rule simply says that the time until crossing block should be set to zero any time there is a train occupying the crossing. This makes sense because if there is a train blocking the crossing, then there would be no wait time until the crossing is blocked.

The Adaptation Engine

• The software environment for this project is PHP
• Since PHP code is processed on the server-side, it prevents the problems encountered with other implementations that require the client to complete processing
• The PHP code takes the adapted media and brings it all together into the page that is viewed by the user
• Additionally, the PHP code handles the calculations for train locations, delay times, etc.

The Rail Traffic System Execution Model

• The Rail Traffic Notification System's execution model follows the four phase AHAM execution model
• First the domain and user model are loaded first
• Next the page selection phase occurs when the user requests rail traffic information, and after the domain and user models have loaded.
• The update user model phase occurs upon the detection of the device display and user type
• Finally the generate adaptation phase occurs to adapt the information for the device and situation of the emergency personnel

The Rail Traffic System Run-Time Layer

• This layer describes mechanisms supporting the user's interaction with the hypertext
• The Rail Traffic Notification System has limited interaction with the user due to the nature of emergency type jobs. Users cannot afford to have extensive interaction at the time of the request for information as a result. This simply means the system must log user interaction over a longer period of time unlike an educational system which will have constant interaction from the user.