Event Service Adapter Testing

34 Copyright © 2011 Open Geospatial Consortium. The schedule data received from the SUA data feed contains reservation schedules for a wide range of special activity airspace, not all of which were applicable to the Pilot Study. Therefore, the Snowflake Event Service adapter was configured to publish only Events relating to the airspaces relevant to the pilot. All other reservation schedules were ignored by GO Publisher Agent. Due to resource constraints, Snowflake was not able to develop the processes required to detect schedules that had disappeared from the schedule file between downloads. This would be important for a real-world implementation as AIXM 5.1 requires that any change to a feature is explicitly published.

7.2.3 Event Service Adapter Testing

As the scenario demonstrations are based on predefined events and not on the input of the Event Service Adapters, IfGI developed a tool to test the adapters separately. This tool is designed as a web service, accepting WS-Notification Notify requests. This way no changes at the adapters need to be made in order to perform the tests. The main purpose of the test is to verify that both the IfGI and the Snowflake Event Service Adapters provide the same information during a fixed time frame. To accomplish this, each received event is analyzed to identify its affected airspace using the gml:identifier, the valid time, the activation status, the vertical limits and the reservation phase. Ideally, one event from each adapter identified via the timeslice metadata is received for each set of the above mentioned properties. The test results can be displayed in a browser showing the number of events received from both adapters, and those only from either IfGI or Snowflake. In addition, the time since the start of the test is displayed, and every received event can be accessed. In order to ensure that the events that are received should have a counterpart from the other adapter, the testing tool has to ignore inputs as long as only one adapter is online. Also, when an adapter begins sending events, the tool has to ignore the first set of messages. This is because in the first iteration, the adapters generate events for every entry in the SUA feed, which means they generate events for activations that were defined already in the past. If both adapters do not start in exactly the same moment, the events that are received will most likely not match. To avoid this and to generate meaningful comparisons, all input in the first few minutes after both adapters are started are ignored. The first runs of the test program identified some differences in the behavior of the two Event Service Adapters. The vertical limits were interpreted differently resolution: interpret as flight level and the status was set differently for pending activations resolution: use ACTIVE. In the later runs with updated event service adapters and an updated event monitor the events produced by the two adapters were matched successfully. However, the monitoring reports show a number of matched events and a number of events produced by ifgi only. The reason is that the adapters behave differently when the activation status is changed from W waiting to H hot activated. The ifgi adapter is designed to produce an event for every change in the activation feed. As the ststus is changed, a new event is generated and published. The advantage is that every change in the feed is published. Copyright © 2011 Open Geospatial Consortium. 35 The disadvantage is that this results in two events with the same content. This happens due to the fact that the three possible states in the activation feed namely P for pending, W for waiting and H for hot activated are translated to only two reservation phase values in AIXM. P is translated to PENDING, whereas W and H are translated to APPROVED. When an activation is changed from W to H this happens when the start time is reached the same event would be generated. As most clients already received this information and check for the start time themselves, the Snowflake Event Service Adapter suppresses these duplicate events. Below, test results for a period of over 48 hours are shown: Events received from both adapters: 911 Events received from ifgi only: 1,994 Events received from Snowflake only: 10 As you can see, there were 911 new activations and activation that were approved. In addition, 1,994 schedules switched to hot during the testing period. The ten events that were produced by the Snowflake adapter only as for the affected airspaces no AIXM designator is given in the airspace mapping file. Thus, the ifgi-adapter cannot build events for these entries. All in all, the adapter testing showed that the two event service adapters work properly and produce the same output. All differences are either intended or a result of incomplete base data. The program used to perform the above mentioned tests is available at 52°North: https:wiki.52north.orgpubSensornetSensorEventServiceSAAEventMonitor.war

7.3 Snowflake WFS