NOTE: The ArcGIS GeoEvent Processor team updates the product tutorials frequently to reflect the latest version

of the software. Depending on

the product version you are using, there may be inconsistencies between your environment and illustrations or specific steps in the exercises. The
concepts outlined in the exercises, however, should be applicable across product versions.

Introduction to GeoEvent Processor Module 5

GEP 10.2.x / Rev B

Introduction to ArcGIS GeoEvent Processor

Introduction & Module 5 Overview .............................................................................................................. 3
Objectives for Module 5 ........................................................................................................................... 3
Getting Started.......................................................................................................................................... 3
The Incident Detector Processor .................................................................................................................. 4
Detecting point-in-time incidents based on attribute conditions ............................................................ 5
Detecting cumulative incidents based on a spatial condition ................................................................ 22
Resetting the incident detection simulation........................................................................................... 32
The Track Gap Detector Processor ............................................................................................................. 34
The GeoTagger Processor ........................................................................................................................... 41

Introduction to GeoEvent Processor Module 5

March 2014

Page 2 of 48

Introduction & Module 5 Overview

The Introduction to GeoEvent Processor tutorial the first in a series of tutorials developed to introduce
the many different capabilities of ArcGIS GeoEvent Processor for Server has been divided into five
separate modules. The scope and material covered in each module is described in Module 1.
This fifth module builds upon the concepts of event processing presented earlier in Module 4. Exercises
in this module will introduce the Incident Detector, the Track Gap Detector, and the GeoTagger more
advanced processors enabling event monitoring and enrichment based on spatial proximity.
The modules in this tutorial were designed to complement one another by presenting different functional
areas of the product and exploring the functionality through exercises. While exercises in this module do
not generally require that students complete the exercises from a previous module, you are encouraged
to work through the tutorial beginning with Module 1 and continuing through Module 5. This is especially
true for exercises in this module, Module 5, in which readers can expect the narrative and illustrations in
an exercise to replace some of the step-by-step instruction presented in earlier modules.
At the start of each module, and occasionally within a module, a product configuration will be referenced
which can be imported to update and/or create configurable items such as an input, output, GeoEvent
Definition or GeoEvent Service. Carefully review the notes which identify what the product configuration
contains as it may update or reset items you created and modified as part of a previous exercise or
product exploration you have completed on your own.

Objectives for Module 5

Once you have completed the exercises in this tutorial you should be able to explain the purpose and
demonstrate how the processors listed below are used.

Incident Detector Monitor incidents based on the spatial proximity and changing attributes of
events in real-time as they are received for an area of interest defined by a GeoFence.

Track Gap Detector Monitor an event feed in order to detect the absence of expected data for
an asset being tracked.

GeoTagger Enrich events with properties retrieved from a GeoFence based on the spatial
proximity of the events Geometry to the area of interest defined by the GeoFence.

Getting Started
If you are just getting started with this tutorial, a GeoEvent Processor configuration file is included to
help you quickly get started with the exercises in this module. Importing this product configuration will
create the items listed below if they do not already exist if items with the same names already exist,
importing the product configuration will update them and overwrite any changes you may have made in
a previous module.
Follow the steps outlined below to import a product configuration designed to help you quickly get
started with this first exercise.

Introduction to GeoEvent Processor Module 5

March 2014

Page 3 of 48

1. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > Configuration Store.
2. Click Import Configuration.
3. Locate the Module5_IncidentDetection.xml file in the \configurations folder.
4. Click Import to import the configuration.
The Module5_IncidentDetection.xml contains the following components:

AVL-TcpTextIn input configured to receive simulated vehicle event data via TCP.

AVL-Vehicle-Report GeoEvent Definition used to interpret simulated vehicle event data.

VehiclePositions-FeatureUpdate output which will update a published a feature layer used to

display vehicle positions.

TruckAlerts-FeatureUpdate output which will update a feature layer to display alerts derived
from an Incident Detector Processor.

VehicleTracker GeoEvent Service incorporating the input and outputs listed above.

Registered data store named LOCALHOST_AGS.

The registered data store, LOCALHOST_AGS, assumes ArcGIS for Server has been installed on the
localhost and is reachable at http://localhost:6080/arcgis/. The output service elements have been
configured to use a feature service, IncidentDetection, expected in a service folder named IntroToGEP.
The targeted feature service is part of the output configuration and uses the registered server data store
to locate the service.
The input, AVL-TcpTextIn, and both outputs have been imported in a STOPPED state. You may find that
importing components such as inputs, outputs, and GeoEvent Services as STOPPED is a good practice. A
running component has the potential to begin processing data immediately or conflict with other
running components. You can start and stop components yourself using GeoEvent Processor Manager.
5. In GeoEvent Processor Manager, navigate to Services > Inputs.
6. Click

to start the right AVL-TcpTextIn input.

7. Navigate to Services > Outputs.

8. Click to start the TruckAlerts-FeatureUpdate output and the VehiclePositions-FeatureUpdate
output.
The VehicleTracker GeoEvent Service should already be started. There is little a GeoEvent Service can do
if its inputs and outputs are not running.

The Incident Detector Processor

Suppose an analyst wants to know when an asset or sensor leaves an assigned work area, enters an area
associated with some hazard, or exceeds a specified speed or operational temperature. The detection
and notification of such incidents are supported by an Incident Detector Processor.

Introduction to GeoEvent Processor Module 5

March 2014

Page 4 of 48

In order to detect and monitor an incident, you must be able to establish criteria, referred to as an
opening condition and closing condition, used to identify an incidents origination and termination. An
opening and closing condition can be spatial or attribute based and are created in the same way as filter
expressions are configured when creating a filter.
An Incident Detector Processor uses the specified opening and closing conditions to detect incidents and
monitor their development as the incident unfolds in real-time. The processor can be configured to either
periodically report while an incident is active or report just when an incident is detected, when its closing
condition has been met, and at the same time report the incidents duration. The exercises in this section
will illustrate how an Incident Detector Processor is configured to accomplish this.
You will again be working with the GeoEvent Simulator to simulate position reports for assets this time
ground vehicles rather than aircraft. You will configure an Incident Detector Processor with an attribute
expression to open an incident when a vehicles speed exceeds a specified rate of travel. Later you will
reconfigure the processor to identify when a vehicle has exited an area of interest, represented by a
GeoFence.
Note: You will need to have published the IncidentDetection.mpk map package as a feature service
prior to starting this exercise. The map packages necessary to complete the exercises are in the
\data folder included with this tutorial.

Refer to the Publishing a feature service to ArcGIS Server section found in Module 2 for information on
publishing feature services.

Detecting point-in-time incidents based on attribute conditions

Before starting this exercise, follow the steps below to review the feature service you will use.
1. Open the ArcGIS REST Services Directory at http://localhost:6080/arcgis/rest/services.
2. Navigate to the service page for the IncidentDetection (FeatureServer) service.
http://localhost:6080/arcgis/rest/services/IntroToGEP/IncidentDetection/FeatureServer

Introduction to GeoEvent Processor Module 5

March 2014

Page 5 of 48

The published IncidentDetection feature service should contain three feature layers as illustrated below:
TruckAlerts, Trucks, and Depots.

It is important that the feature service exist in a service folder named IntoToGEP. The GeoEvent Service
used for this exercise (see illustration below) incorporates outputs configured to expect an
IncidentDetection feature service in an IntroToGEP service folder. Notice the outputs assume the
availability of a LOCALHOST_AGS server data store and that the feature layer targeted by each output is
identified using a layer index (0, 1, or 2) as illustrated above.

3. From the IncidentDetection (FeatureServer) page, click TruckAlerts (0) and compare the list of
attribute fields for this feature layer with the illustration below.

Introduction to GeoEvent Processor Module 5

March 2014

Page 6 of 48

Notice the highlighted field named id. The alias for this field is IncidentId. In a moment, when we examine
how the TruckAlerts-FeatureUpdate output was configured, you will notice GeoEvent Processor lists field
aliases as choices for the Unique Feature Identifier Field. The difference between this and the actual field
name, displayed when reviewing the GeoEvent Service in the illustration above, has been a source of
confusion for some.
Remember, while you will sometimes specify a layer or field using an alias name, you may see the layer
or fields actual name or index displayed later.
Now, lets take a look at how the TruckAlerts-FeatureUpdate output was configured.
4. In GeoEvent Processor Manager, navigate to Services > Outputs.
5. Click the TruckAlerts-FeatureUpdate output to begin editing.

Introduction to GeoEvent Processor Module 5

March 2014

Page 7 of 48

The outputs targeted feature layer is specified using a registered server data store to locate a feature
service in a specified service folder. You can select the feature layer by name (not index) and select the
field used to uniquely identify features in the layer by field alias name (not the fields actual name).
6. Click Cancel without making any changes to the TruckAlerts-FeatureUpdate output.
7. In GeoEvent Processor Manager, navigate to Services > GeoEvent Services.
8. Click the VehicleTracker GeoEvent Service to begin editing.
9. Click the IncidentDetector processor to review its properties.
The IncidentDetector processor is configured with an attribute-based opening condition. When an event
is received whose speed is greater-or-equal to 70, a new PointInTime incident will be created. This type
of incident is assumed to be instantaneous and has no closing condition. As you will see in the exercise,
a new alert feature will be mapped for every event received whose speed matches the IncidentDetector
processors opening condition.

Introduction to GeoEvent Processor Module 5

March 2014

Page 8 of 48

10. Double-click the IncidentDetector processor to open the properties.

As an Incident Detector Processor receives events, if an event satisfies the Opening Condition, a new
GeoEvent will be created. An Incident Detector Processor is different from other processors in that it
does not output a derivative or copy of the event it received. It instead monitors events received and
generates entirely new GeoEvents to alert that an opening or closing condition has been observed.
Incidents will be named according to the Incident Name (e.g. SpeedingVehicle). The GeoEvent Definition
for these new GeoEvents will be discussed in a moment.

Introduction to GeoEvent Processor Module 5

March 2014

Page 9 of 48

11. Click Opening Condition to open the properties.

This is the same expression builder you used in Module 4 to define attribute and spatial expressions. For
more information on how to create filter expressions and define an opening and closing conditions for
an Incident Detector Processor refer to exercises in Module 4.
12. Click Cancel to dismiss the Filter Properties dialog without making any changes.
In the illustration in Step 10 above, notice the four properties at the bottom of the Processor Properties
dialog: Severity, Incident Type, Geometry Type, and Expiry Time (seconds). These settings are described
in the following bulleted list.

Severity Specifies the level of urgency for incidents generated by the processor. One of three
levels can be selected, Notification, Warning, or Urgent.

Incident Type Either Cumulative or PointInTime, this property specifies whether the processor
will treat an incident created as a continuous event to be updated based on event data the
processor receives, or whether an incident is instantaneous (not subject to update).Geometry
Type An Incident Detector Processor can be configured to associate a point, multipoint, or
polyline geometry with incidents it creates. The exercise you will work through shortly will use
PointInTime type incidents, so the processor has been configured to associate point geometries
with incidents it creates. If you wanted to update a continuous series of events, you would have
to have the processor update a multipoint geometry or track incidents along a polyline.

13. Expiry Time (seconds) Incidents created by the Incident Detector Processor will automatically close
or expire after a period of time if their closing condition has not been satisfied. This parameter does
not apply to PointInTime incidents, which are instantaneous and have no closing condition.Click
Cancel to dismiss the Filter Properties dialog without making any changes.
Notice how the components in this GeoEvent Service are connected.

Introduction to GeoEvent Processor Module 5

March 2014

Page 10 of 48

The AVL-TcpTextIn input connects directly to the VehiclePositions-FeatureUpdate output so that vehicles
can be observed moving on a web map.
The TruckAlerts-FeatureUpdate output will only update the feature layer, with PointInTime incidents sent
from the IncidentDetector processor, when the processor detects a speeding vehicle.
Below, you will use the GeoEvent Simulator to simulate a series of vehicle reports. Before you do that,
you need to make sure the structure the GeoEvent Definition of the events sent to each of the
outputs is compatible with the feature layer they will be updating.
14. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > GeoEvent Definitions.

15. Click the incident GeoEvent Definition to open its properties.

Introduction to GeoEvent Processor Module 5

March 2014

Page 11 of 48

Notice the incident GeoEvent Definition is owned by the IncidentDetector. Events produced by an
Incident Detector Processor use the incident GeoEvent Definition.
Compare the illustration above with the illustration of the TruckAlerts feature layer fields after Step 3
above. Notice the fields present in the GeoEvent Definition match the fields of the published feature
service.
The TruckAlerts-FeatureUpdate output will use the incident GeoEvent Definition to deconstruct events
generated by the Incident Detector Processor. The data from the GeoEvents will be used to update the
feature service and, for this exercise, to display alerts as features.
The table below describes of some of the key fields of in the incident GeoEvent Definition. The example
values shown are consistent with values you will see later in this exercise.
Incident Field Name

Field Description (and example values)

id

The unique ID of an incident.

Example value: 93c88c85-1fa3-44c7-883b-1b97e304728a

name

The name of the incident.

Example value: SpeedingNotifier

type

The type of incident: PointInTime or Cumulative.

Example value: PointInTime

Introduction to GeoEvent Processor Module 5

March 2014

Page 12 of 48

alertType

The type of alert: Notification, Warning, or Urgent.

Example value: Notification

openCondition

The condition that causes the incident to be opened.

Example value: Speed >= 70

closeCondition

The condition that causes the incident to be closed.

Example value: NOT(Speed >= 70)

description

A description of the incident: Started, Ongoing, Ended.

Example value: Started at Tue Jun 12 08:04:00 PDT 2012

timestamp

The timestamp on the GeoEvent that caused the Incident.

Example value: 1339513440000

definitionName

GeoEvent Definition name of the GeoEvent that caused the incident.

Example value: Truck

definitionOwner

GeoEvent Definition owner of the GeoEvent that caused incident.

Example value: arcgis

trackId

The TRACK_ID of the GeoEvent (as defined in its GeoEvent Definition) that
caused the incident.
Example value: 1000

shape

The Geometry of the Event that caused the incident.

Example value: -117.1947,34.0592099997,0.0

duration

The duration (end/latest time start time) of the incident (in

milliseconds).
Example value: 0

16. After reviewing the incident GeoEvent Definition, click Cancel without making any changes.

The AVL-Vehicle-Report GeoEvent Definition is used to interpret the simulated vehicle report events
sent as comma separated text from the GeoEvent Simulator. The AVL-TcpTextIn input was configured to
use this GeoEvent Definition; it contains the fields found in the vehicle location reports which will be
sent to GeoEvent Processor using the GeoEvent Simulator.

Introduction to GeoEvent Processor Module 5

March 2014

Page 13 of 48

So far, we have examined the GeoEvent Definitions that support the TruckAlerts-FeatureUpdate output
and the AVL-TcpTextIn input. We do not yet have a GeoEvent Definition for the last output
VehiclePositions-FeatureUpdate which is responsible for updating features in the Trucks feature layer.
Follow the steps below to import the necessary GeoEvent Definition.
17. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > GeoEvent Definitions.
18. Click Import GeoEvent Definitions to import a GeoEvent Definition for the feature layer to be
updated.
19. Configure the Import GeoEvent Definitions properties as illustrated below.

Introduction to GeoEvent Processor Module 5

March 2014

Page 14 of 48

20. Click Import to import the new GeoEvent Definition.

Remember, before a GeoEvent Definition can be coupled with an output to update features, a field in
the GeoEvent Definition must be tagged as the TRACK_ID.
21. Click the Trucks GeoEvent Definition to open the properties.
22. Using the illustrations below as a guide, apply the TRACK_ID tag to the VehicleId field.

Introduction to GeoEvent Processor Module 5

March 2014

Page 15 of 48

Recall from the Field Mapper Processor section in Module 4, the schema of event data received by an
input often does not match the schema of event data needed to update a target feature layer. This is
exactly the case here the field names in the AVL-Vehicle-Report GeoEvent Definition do not match those
in the Trucks GeoEvent Definition you just imported.
23. Navigate to Services > GeoEvent Services.
24. Click the VehicleTracker to open the GeoEvent Service.
25. From the menu, add a new Processor element and configure a Field Mapper Processor as follows:

Introduction to GeoEvent Processor Module 5

March 2014

Page 16 of 48

The Panic field can be left blank. Modeling a drivers request for assistance is not included in the
simulation file used in this exercise.
26. Click Ok to add the new processor.
27. Connect the new Field Mapper in the GeoEvent Service as illustrated below.

28. Click Publish to publish the updated GeoEvent Service.

The Trucks feature layer in the IncidentDetection feature service may contain a couple of features which
GeoEvent Processor will update as simulated event data is received. The TruckAlerts feature layer should
be empty, since the VehicleTracker GeoEvent Service has not yet been utilized to produce any alerts.
29. Confirm the TruckAlerts feature layer contains no features:
a. In a browser, navigate to the feature services REST endpoint.
http://localhost:6080/arcgis/rest/services/IntroToGEP/IncidentDetection/FeatureServer/0
b. At the bottom of the Layer: TruckAlerts (ID: 0) page, click Query and enter the following values:

Where:

1=1

(no spaces)

Introduction to GeoEvent Processor Module 5

March 2014

Page 17 of 48

Out Fields:

(wildcard indicating all fields should be shown)

c. At the bottom of the page, select JSON as the output format.

d. Click Query (GET) and confirm on the page which opens no features exist.

You are now ready to begin simulating event data using the GeoEvent Simulator. Your simulated vehicle
reports will include several reports in which a vehicles speed is greater than 70.
The VehicleTracker GeoEvent Service does not send data to a TCP port, so the TCP Console application
will not be used in this exercise. Instead, web maps will be used to display the results.
You will need to create a web map that includes the TruckAlerts, Trucks, and Depots feature layers from
the IncidentDetection feature service if you intend to complete the following exercise. For more
information on how to add feature layers to a web map and configure the web map layers to
automatically refresh, refer to the exercises in Module 2.
30. Open the GeoEvent Simulator and configure as follows:

Click Load File and browse to the IncidentDetection.csv file in the \simulations folder
included with this tutorial.

Change the Time Field # property to field 0 and click Load.

Check the Set value to Current Time checkbox to simulate real-time data.

Uncheck the Continuous Loop checkbox.

Set the rate to send 2 messages every 2500 ms.

Click Click to Connect to establish your server connection.

Refer to the illustration below and the exercises in Module 1 for help configuring the GeoEvent
Simulator.

Introduction to GeoEvent Processor Module 5

March 2014

Page 18 of 48

31. Click Step

once to send two events to GeoEvent Processor.

32. Confirm the Trucks feature layer was updated with the simulated event data.
If you configured a web map, click the web map to see the EventTime of the vehicle feature matches
your systems current date.

You could also query the feature layers REST endpoint and use a conversion utility such as the one
found at http://www.epochconverter.com/ to convert the timestamp displayed in the REST query to a
human-readable time.

Introduction to GeoEvent Processor Module 5

March 2014

Page 19 of 48

33. Click Play

and allow GeoEvent Simulator to play for 15 seconds so that between 14 and 18 total
events are sent.
If the feature service layers, GeoEvent Service, and GeoEvent Definitions have been correctly configured
you should see three new alert features (red triangles) displayed in the web map. The green circle,
representing the van with Track_ID 1000, will be slightly further down the road if you end up simulating
more than 14 vehicle reports.

By selecting an alert (red triangle) in the web map, you can review the features attributes in a pop-up
window as illustrated below. The accompanying table illustrates all of the attributes that are not visible
in the pop-up window.

Introduction to GeoEvent Processor Module 5

March 2014

Page 20 of 48

Recall the IncidentDetector processor you worked with earlier was configured to create PointInTime
incidents. When configuring an Incident Detector to create PointInTime incidents, a closing condition
is not applicable. Since the Incident Detector configured for this exercise did not specify a closing
condition, the default the logical negation of the opening condition was assumed.
The Status reported for each incident is Ended because PointInTime incidents are instantaneous and are
considered closed the instant they occur. Each PointInTime incident will have a unique IncidentId. They
cannot be updated over time as subsequent events are received.
If you are unable to use the Operations Dashboard for ArcGIS and/or you decided not to configure a web
map for this exercise, you can query the TruckAlerts REST endpoint to obtain the results illustrated
above.

Introduction to GeoEvent Processor Module 5

March 2014

Page 21 of 48

Detecting cumulative incidents based on a spatial condition

In this exercise you will modify the VehicleTracker GeoEvent Service used in the previous exercise. You
will reconfigure the existing IncidentDetector processor to recognize when a vehicle has left an area of
interest defined by a GeoFence. Unlike the previous exercise, which generated PointInTime incidents, this
exercise will use Cumulative incidents which have the ability to track incident duration. You will use the
same IncidentDetection.csv simulation file and IncidentDetection feature service with its three feature
layers: TruckAlerts, Trucks, and Depots.
Before beginning, you should clear any old incidents from the TruckAlerts feature layer to avoid
confusion. Follow the steps below to delete the unwanted incidents.
1. In the ArcGIS REST Services Directory, open the TruckAlerts layers REST endpoint
http://localhost:6080/arcgis/rest/services/IntroToGEP/IncidentDetection/FeatureServer/0
2. Click Delete Features at the bottom of the TruckAlerts (ID: 0) page.
3. For the Where clause, enter the 1=1 (no quotes and no spaces).
4. Click Delete Features.
5. Verify a message displays which reads: {"success": true}.
You now have deleted the features created in the previous exercise. It is safe to do this because, as
PointInTime incidents, their status is ended and they are no longer being tracked by GeoEvent
Processor.
6. In GeoEvent Simulator, review your configuration. The properties should not have changed if you
are continuing from the previous exercise.

The IncidentDetection.csv file from the \simulations folder is loaded.

The Time Field # property is set to 0.

The Set value to Current Time checkbox is checked.

The Continuous Loop checkbox is unchecked.

The rate to send 2 messages every 2500 ms.

The GeoEvent Simulator is connected to the server.

Introduction to GeoEvent Processor Module 5

March 2014

Page 22 of 48

7. Click Go To Start
8. Click Step

and click Clear Sent Events

once to send a two events to GeoEvent Processor.

Before you reconfigure the IncidentDetector processor to detect when a vehicle has exited its assigned
area, you must import the operational area as a GeoFence. The Depots feature layer will provide the
polygon geometry.
GeoFences are used by any GeoEvent Service component which relies on a spatial expression to test
whether an event is INSIDE, OUTSIDE, ENTERING, or EXITING an area of interest.
9. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > GeoFences.
10. Click Import GeoFences and configure the properties as illustrated below.

Introduction to GeoEvent Processor Module 5

March 2014

Page 23 of 48

11. Click Import to import the Depots feature layer geometry as a new GeoFence.
12. Confirm a new Esri GeoFence is listed in a Category called OperationalArea.

Additional information on creating and configuring GeoFences can be found in Module 3 of this tutorial.
You may have other GeoFences imported as part of other exercises or as part of your own exploration of
the product. The IncidentDetector processor you will reconfigure below will ensure other GeoFences will
not interfere with the analysis you will be performing.
13. In GeoEvent Processor Manager, navigate to Services > GeoEvent Services.
14. Click VehicleTracker to open the GeoEvent Service.
15. Double-click the IncidentDetector processor to edit its properties.

Introduction to GeoEvent Processor Module 5

March 2014

Page 24 of 48

16. Change Incident Name to Vehicle Outside Assigned Area.

17. Change Severity to Notification.
18. Change Incident Type to Cumulative.
19. Click Opening Condition to edit the filter expression.
Note: For users on version 10.2.1 and earlier, remember to click
list of criteria.

to add the filter expression to the

20. Click Ok to save the filter expression.

21. Click Ok to save the updated IncidentDetector processor.
22. Click the IncidentDetector processor to review the reconfigured properties.

Introduction to GeoEvent Processor Module 5

March 2014

Page 25 of 48

23. Click Publish to publish the GeoEvent Service.

24. In the GeoEvent Simulator, drag the event slider to 70 using the arrows to make small adjustments.

Follow the narrative below using the simulator to send event data to GeoEvent Processor. Illustrations
are included to show what you should see if you prepared a web map to work along with the exercise.

Introduction to GeoEvent Processor Module 5

March 2014

Page 26 of 48

Be aware that if you wait more than 300 seconds (five minutes) from the time any particular incident is
last updated, the Incident Detector will expire the incident, placing the incident in an ENDED state and
preventing further updates when simulated vehicle reports are received.
25. Click Step

once to send events 70 and 71.

The vehicles positions should move to the locations indicated in the illustration below.

Remember symbols are overlaid onto a web map according

to the layer order. If a vehicles symbol appears overtop of
the incident (obscuring the incident), check the layer order
in your web map against the illustration to the right. The
correct order from top to bottom is TruckAlerts, Trucks,
Depots.
If you are using the Operations Dashboard for ArcGIS and
need to change the layer order of the web map used in
your operation view, you may need to remove the web
map from the operation view and add the updated map
back into the operation view as part of a new map widget.

26. Click Play

and allow the simulation to play until 36 vehicle reports have been sent. This should
take about 38 seconds.
The GeoEvent Simulators event slider should now be positioned at 104 and the vehicle on Lugonia St
should be close to exiting the area of interest defined by the GeoFence.

Introduction to GeoEvent Processor Module 5

March 2014

Page 27 of 48

27. Click Step

once to send events 104 and 105.

The green circle should move outside the GeoFence, triggering the creation of a new incident.

Introduction to GeoEvent Processor Module 5

March 2014

Page 28 of 48

Clicking the newly created incident in your web map will display a pop-up with details on the incident.
Notice the Incident Name in the pop-up reflects the
value specified in the IncidentDetector processor.
The Description includes the date and time the
incident was detected and the Status indicates that
the incident is Started.
Incidents which are Cumulative are updated as the
incident develop in real-time. The incident will
remain active/open until either the timer
maintained by the IncidentDetector processor
expires with no updates made to the incident or the
specified closing condition is met.

By default, incidents expire after 300 seconds (5 minutes) if a new event associated with the current
incident has not been received.

Introduction to GeoEvent Processor Module 5

March 2014

Page 29 of 48

When a closing condition is not specified, as is the case in this exercise, the logical negation of the
opening condition is an assumed default closing condition. In the illustration above, the default closing
condition is the vehicle no longer OUTSIDE the specified GeoFence.
28. Click Play

and allow the simulation data to play the rest of the event data.

In the illustrations below, notice the incident tracks with the moving vehicle. The incident will remain
with the vehicle until the incident is closed either because the truck has re-entered the defined
operations area or because the incidents expiry time elapsed without an update.

As the GeoEvent Simulator event slider passes 226, you should see the vehicle re-enter the GeoFence.
The incident being maintained by the IncidentDetector processor will be closed (its Status marked as
Ended) since its closing condition was met. The incident duration is persisted as part of the processors
output, which has been stored in the TruckAlerts feature layer.
The incident data provides an analyst with information on how long the vehicle was outside of its assigned
operational area. Once the incident has been closed by the IncidentDetector processor, it will no longer
track along with the vehicle as the vehicle continues to move away.

Introduction to GeoEvent Processor Module 5

March 2014

Page 30 of 48

When the vehicle again leaves the area defined by the GeoFence, a new incident will be created and the
new incident will track with the vehicle until that incident is closed. Notice in the illustration below that
a different IncidentId has been assigned to the new incident.

Introduction to GeoEvent Processor Module 5

March 2014

Page 31 of 48

Resetting the incident detection simulation

You can restart the simulation by stopping/pausing the GeoEvent Simulator event stream and deleting
any existing features from the TruckAlerts feature layer using the layers REST endpoint.
Note: Deleting the features from a published feature layer does not delete the incidents managed by
the Incident Detector Processor that is running in a GeoEvent Service. If an incident remains open
either because its closing condition has not been met or the incident has not expired and the
feature that represents the open incident is deleted, a new feature with the same IncidentId will
be created when the simulated event stream is restarted.
Below are the steps to reset the simulation.
1. Stop the GeoEvent Simulator to halt the streaming event data.
2. Click Go To Start

and Clear Sent Events

Introduction to GeoEvent Processor Module 5

to reset it to the beginning of the simulation file.

March 2014

Page 32 of 48

3. Click Step
once to send a single pair of events within the specified GeoFence to guarantee any
open incidents are closed.
4. Delete any existing features from the TruckAlerts feature layer using the REST endpoint.
Congratulations! You have successfully demonstrated how an Incident Detector Processor can be used to
report PointInTime incidents as well as monitor and update Cumulative incidents in GeoEvent Processor.
This exercise brought together a number of concepts. Events output from a GeoEvent Service were used
to update features in a published feature layer making features come alive to represent real-time data.
The properties of an Incident Detector Processor were introduced including the concepts of an opening
condition, closing condition, and incident expiration. The exercise also introduced you to the concept of a
processor which monitors an event stream and generates an entirely new set of GeoEvents, enabling
more advanced analysis than simply calculating derivative values or enhancing events with data from an
external table.
The exercise gave you a chance to review how to build both attribute and spatial expressions which you
now understand can be used by filters as well as processors. Both of these elements are incorporated
into a GeoEvent Service to facilitate analysis.
The exercise reviewed the importance of GeoEvent Definitions. Through illustrations you examined the
properties of a TruckAlerts feature layer and compared the feature layers fields with those in the
incident GeoEvent Definition. You revisited the steps used to import a GeoEvent Definition from a
feature layer and used a Field Mapper Processor to map GeoEvents from an input schema to a schema
expected by an output.
The exercise gave you a chance to manage the content of feature services through the ArcGIS Services
REST endpoint as well as build a web maps to visualize the output from GeoEvent Processor.
Several important take-aways from this exercise include:

An Incident Detector Processor has the ability to generate alerts with different severity levels,
and either update incidents or report incidents as instantaneous events with no duration or
closing condition.

Incidents can be associated with point geometry, as was shown in this exercise, but an Incident
Detector can also be configured to update a polyline with new vertices or a multi-point
geometry with new points. If you want to experiment with this you will need to publish a
feature service with a layer whose geometry matches the type of geometry being output by the
Incident Detector.

You should now understand how incidents are managed in GeoEvent Processor, including how
incidents are opened, updated, and eventually closed.

Introduction to GeoEvent Processor Module 5

March 2014

Page 33 of 48

The Track Gap Detector Processor

Next, you will explore another type of processor, the Track Gap Detector Processor. This processors also
monitors an event stream in order to produce alerts this time alerting when expected data is not
received.
Suppose an analyst is using GeoEvent Processor to monitor hazardous material sensors on a network.
Regular reports from the sensors are critical to staff safety, and the analyst needs to be alerted if one or
more sensors is not reporting data as expected.
The individual sensors all have assigned serial numbers which are being used as identifiers to track and
correlate the reports from individual sensors. Each sensor is configured to periodically report its metrics,
and analysts can reasonably expect to receive a report from a given sensor every 60 seconds. If a sensor
fails to report within two minutes, the analyst wants to be alerted.
Detection and notification of missing event data is supported by the Track Gap Detector Processor
Like an Incident Detector, a Track Gap Detector monitors an event stream and generates an entirely
new set of GeoEvents. The processor can be configured to generate an initial alert when it observes
that events associated with a track are no longer being received, with a second alert when the
expected event flow has been restored. It can also be configured to continuously generate alerts for
the period in which expected data is not being received.
An analyst must specify a pair of Gap Detection Interval timer values when configuring a Track Gap
Detector. The first timer, reset every time an event associated with a given TRACK_ID is received, is
used to detect the absence of events. At least one event with a given TRACK_ID must be received by
the processor in order for the TRACK_ID to be registered with the Track Gap Detector. If the processor
does not receive one or more subsequent events before the timer expires, an alert that a gap has
been detected is generated. The second timer is a polling timer once a gap has been detected the
processor will periodically check its cache to see if events for each registered track has been received.
When a Track Gap Detector has been configured for Continuous notification, an alert is generated each
time the Gap Detection Interval timer expires, with separate alerts created for each track currently
experiencing a gap in expected reports. When configured for OnChange notification, the polling timer is
only used to check if a gap still exists; the gap detection alert is closed when the processors cache is
polled and it discovers that a gap in expected reports no longer exists.
The following exercise was designed to model a hazardous materials sensor network with simulated
data. Follow the steps to first import a GeoEvent Processor configuration containing several
components which will help you quickly get started. You will then configure a Track Gap Detector
Processor to monitor the simulated data and explore the behavior described above.
1. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > Configuration Store.
2. Click Import Configuration.
3. Browse to the Module5_TrackGapDetection.xml file in the \configurations folder.
Introduction to GeoEvent Processor Module 5

March 2014

Page 34 of 48

4. Click Import to import the configuration.

The Module5_ TrackGapDetection.xml contains the following:

HazMat-Sensor-Report GeoEvent Definition used to interpret simulated sensor event data.

HazMat-TcpTextIn input configured to receive simulated sensor event data via TCP.

HazMat-TcpTextOut output which will post event data to a specified TCP socket.

HazMatAlerts-TcpTextOut output which will post event data to a second TCP socket.

HazardousMaterials GeoEvent Service incorporating the input and outputs above.

Refer to the illustrations and follow the steps below to quickly review the components just imported and
ensure you have completed the setup for the exercise.

The HazMat-Sensor-Report GeoEvent Definition illustrated above was designed to match the commaseparated fields of the simulation data for this exercise. The actual values being reported in the
simulated event data are not significant. What is important is that each event will have a SensorId,
tagged as the TRACK_ID, in the GeoEvent Definition. Without a TRACK_ID, a Track Gap Detector cannot
monitor events.

Introduction to GeoEvent Processor Module 5

March 2014

Page 35 of 48

The HazMat-TcpTextIn input illustrated on the above is configured to use the imported GeoEvent
Definition rather than trying to create one based on discovery of the data structure it receives. If you
review the simulated event data you, will see that each sensor reports a static location expressed as a
quoted pair of values in decimal degrees. This allows the input to assume a geographic coordinate system
and generate a geometry without needing to build one using values from individual fields.
The input uses the default port 5565 and has been imported in a stopped state. Components that are
running have the potential to begin processing data immediately and could conflict with other running
components in your GeoEvent Services. You can start and stop components using GeoEvent Processor
Manager.
5. In GeoEvent Processor Manager, navigate to Services > Inputs.
6. Stop any inputs configured to use the default TCP port 5565.
Remember, no two GeoEvent Service components can connect to the same port at the same time,
so you must first stop any inputs which use that default TCP port.
7. Click

to start the HazMat-TcpTextIn input.

The HazMat-TcpTextOut and HazMatAlerts-TcpTextOut outputs illustrated above are simple Publish text
to a TCP Socket Output Connectors, similar to those you have been using throughout the exercises in
this tutorial. You will again be using the TCP Console application you introduced to in Module 1 to
display event data.
Notice that each output above has been configured to use a different TCP port. You may have to adjust
the shortcuts you use to launch the TCP Console application to ensure you are seeing the event data
from the output you intend to observe.

Introduction to GeoEvent Processor Module 5

March 2014

Page 36 of 48

8. In GeoEvent Processor Manager, navigate to Services > Outputs.

9. Stop any outputs configured to using TCP ports 5570 or 5575.
10. Click

to start the HazMat-TcpTextOut and HazMatAlerts-TcpTextOut outputs.

The HazardousMaterials GeoEvent Service illustrated above incorporates the inputs and outputs imported
for this exercise. You will reconfigure the No Operation Processor to be a Track Gap Detector Processor.
This will allow you to observe the alerts generated by the Track Gap Detector in one TCP Console, while
observing the simulated event data in a second TCP Console.
11. In GeoEvent Processor Manager, navigate to Services > GeoEvent Services.
12. Click HazardousMaterials to edit the GeoEvent Service.
13. Double-click the existing No Operation processor to open its properties.
14. Using the illustration below as a guide, reconfigure the processor as a Track Gap Detector.

15. Click Ok to save the changes made to the processor.

16. Click Publish to publish the reconfigured GeoEvent Service.
The Track Gap Detector you configured above will check every 10 seconds to see if events previously
received for a given TRACK_ID are still being received. If events for a registered track have not been
received in 30 seconds, the processor will create and begin monitoring a track gap event. A new event

Introduction to GeoEvent Processor Module 5

March 2014

Page 37 of 48

will be generated every 10 seconds until the processor observes that events are again being received for
the registered TRACK_ID.
The Track Gap GeoEvent Definition, illustrated below, specifies the schema of a track gap event. Like an
Incident Detector, a Track Gap Detector monitors an event stream and generates an entirely new set of
GeoEvents as alerts to communicate the incidents it is monitoring.

Follow the steps below to use the GeoEvent Simulator to simulate sensor events and the TCP Console
application to observe events processed by the HazardousMaterials GeoEvent Service. You will actually
be using three separate GeoEvent Simulators and two different TCP Console applications to observe the
scenario described in this exercise.
17. Open and configure the first GeoEvent Simulator as follows:

Click Load File and browse to the TrackGap_Sensor1.csv file in the \simulations folder.

Change the Time Field # property to field 0 and click Load.

Check the Set value to Current Time checkbox to simulate real-time data.

Leave the default rate setting of 1 message every 1000 ms.

Click Click to Connect to establish your server connection.

18. Repeat Step 17 above twice to open a second and third GeoEvent Simulator and load the simulation
files below.

Load the TrackGap_Sensor2.csv from the \simulations folder into the second GeoEvent
Simulator.

Load the TrackGap_Sensor3.csv from the \simulations folder into the second GeoEvent
Simulator.

In the illustrations below, notice that all three GeoEvent Simulators are sending event data to the
same default TCP socket 5565. This has no effect on GeoEvent Processor; its input is listening for
event data posted to a TCP socket and does not care that multiple GeoEvent Simulators are being
used to simulate different data streams.

Introduction to GeoEvent Processor Module 5

March 2014

Page 38 of 48

19. Click Play

Processor.

on each GeoEvent Simulator, allowing the simulated data to stream to GeoEvent

By checking the Continuous Loop checkbox, you ensure an uninterrupted flow of event data.
20. In GeoEvent Processor Manager, navigate to Services > Monitor.
Notice the GeoEvent Service, the HazMat-TcpTextIn input, and the HazMat-TcpTextOut output are each
handling events at a rate of about three events per second.

Introduction to GeoEvent Processor Module 5

March 2014

Page 39 of 48

The HazMatAlerts-TcpTextOut outputs event count should not be incrementing. That output will not
receive events from the Track Gap Detector Processor until the event stream from one of the GeoEvent
Simulators is interrupted or suspended.
21. Use your desktop shortcut, batch script, or command line invocation to launch a TCP Console
application listening for events on port 5570.
22. Launch a second TCP Console listening for events on port 5575.

Notice that events using the HazMat-Sensor-Report GeoEvent Definition are being sent to the TCP port
5570 and are being displayed, but no events are being received or displayed for the TCP port 5575.
23. In any one of the three GeoEvent Simulators, click Pause

to suspend its simulation.

After about 30 seconds, the Track Gap Detector will recognize that data for the suspended simulators
events has stopped and a new track gap event will display in the TCP Console monitoring port 5575.
Because the processor was configured with Continuous notification, every 10 seconds another track gap
event will be displayed as illustrated below.

Introduction to GeoEvent Processor Module 5

March 2014

Page 40 of 48

Notifications will continue, indicated by a Boolean value of true displayed for each event and a timestamp
the last event was received, until Play is clicked in the GeoEvent Simulator to resume the stream of events
to GeoEvent Processor.

A rough estimation of the duration the sensor was offline, in our simulated scenario, can be made by
realizing that the first track gap was received 30 seconds after events stopped streaming and that four
Continuous notifications followed that initial notification as illustrated above. Since each subsequent
notification is posted 10 seconds after the initial, the sensor was offline approximately 70 seconds (30 +
(4 x 10)).

The GeoTagger Processor

Now you will work the GeoTagger Processor. This processor provides a specialized combination of event
proximity detection and enrichment, enabling event data to be tagged with attributes from a GeoFence.
Suppose you are an analyst contracting with a national retailer. The retailer has a Customer Loyalty
program in which customers who promote the business through social media receive discounts.
Through some clever filtering and processing of the retailers subscription to the social media feed, you
are able to isolate a customers loyalty account number and geographic location (latitude and longitude).
You have been told that if you can provide the Marketing Department with information such as the city,
state, and zip code from which the customer posts are made, they will be able to use a business analytics
package to retrieve household demographics, average age, and income statistics they can then use to
prepare more focused advertising campaigns.

Introduction to GeoEvent Processor Module 5

March 2014

Page 41 of 48

GeoEvent Processor can help you with this task. You can use a GeoTagger Processor to use the location
associated with each event to determine the GeoFences each event lies within. Follow the steps below
to import a GeoEvent Processor configuration to help you quickly get started.
1. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > Configuration Store.
2. Click Import Configuration.
3. Browse to the Module5_Geotagger.xml file in the \configurations folder.
4. Click Import to import the configuration.
The Module5_Geotagger.xml contains the following:

Customer-Report GeoEvent Definition used to interpret simulated customer event data.

CustomerReport-TcpTextIn input used to receive simulated customer data via TCP.

GeoTaggedReport-TcpTextOut output used to post event data to a TCP socket.

GeoTag-CustomerReports GeoEvent Service that incorporates the input and outputs above as
well as a series of GeoTagger Processors configured for this exercise.

GeoFences for a few selected U.S. states, cities, and zip codes.

Refer to the illustrations and follow the steps below to quickly review the components just imported and
ensure you have completed the setup for the exercise.
A new GeoEvent Definition named Customer-Report, illustrated on the next page, contains just a few
named fields representing the format of the simulation data. The CustomerId and TimeStamp of each
event are not significant, what is important are the coordinate values associated with each event.
If you review the simulated data you will see that each customer report includes a location expressed as
a quoted pair of values in decimal degrees. This allows the input to assume a geographic coordinate
system and generate a geometry without needing to build one using values from individual fields.

The CustomerReport-TcpTextIn input, illustrated below, is configured to retrieve the name of the
GeoEvent Definition from the event data received. The simulated customer reports will include the
name of the GeoEvent Definition above in the first field of each event. Notice this input is configured

Introduction to GeoEvent Processor Module 5

March 2014

Page 42 of 48

to not attempt to create a GeoEvent Definition if the GeoEvent Definition named in each event
does not exist, the received event will be discarded.

The input uses the default port 5565 and has been imported in a stopped state. GeoEvent Service
components that are running have the potential to begin processing data immediately and conflict with
other running components. You can start and stop components using GeoEvent Processor Manager.
5. In GeoEvent Processor Manager, navigate to Services > Inputs.
6. Stop any inputs that may be using the default TCP port 5565.
Remember, no two GeoEvent Service components can connect to the same port at the same time,
so you must first stop any inputs which use the same TCP port.
7. Click

to start the CustomerReport-TcpTextIn input.

The GeoTaggedReport-TcpTextOut output illustrated below is a simple Publish text to a TCP Socket
Output Connector similar to those used in the last exercise. You will again be using the TCP Console
application to display event data.

8. In GeoEvent Processor Manager, navigate to Services > Outputs.

9. Stop any outputs that are configured to use TCP ports 5570.
10. Click

to start the GeoTaggedReport-TcpTextOut output.

Introduction to GeoEvent Processor Module 5

March 2014

Page 43 of 48

The GeoTag-CustomerReports GeoEvent Service imported for this exercise contains three GeoTagger
Processors, as illustrated below.

This GeoEvent Service has been designed with the processors placed in a series to ensure each event will
be enriched first with the City, then the State, and finally the zip code of the GeoFence it is located
within. This is simply one way to configure the processor for this scenario, they could have been
arranged in parallel, but designing the GeoEvent Service this way helps both to arrange the output nicely
for review and prepares the event data for further processing downstream, if necessary.
Using the illustration below, review the configuration of each GeoTagger Processor. Each processor will
consider exactly one category of GeoFence. The wildcard
at the end of the GeoFence(s) property
indicates that any named GeoFence in the specified category will be considered. The support for regular
expression pattern matching in a GeoTagger allows for powerful, dynamic proximity detection and event
enrichment.
Notice how each GeoTagger is essentially the same the only difference being the expression specifying
which set of GeoFences the processor will reference. The GeoEvent Service could have been designed
with a single processor element whose GeoFence(s) property was specified as / to consider all
GeoFences in all categories. This would not guarantee, however, the desired enrichment order of City,
State, zip code.

Introduction to GeoEvent Processor Module 5

March 2014

Page 44 of 48

A final set of components imported with the configuration is a collection of GeoFences.

11. In GeoEvent Processor Manager, navigate to Site > GeoEvent Processor > GeoFences.
Notice the three new GeoFence categories.

If you expand the different categories you will find that each category contains a number of named
GeoFences. Recall that GeoFences are imported from a published feature service which includes a
polygon feature layer. These GeoFences represent generalizations of four U.S. states, a sampling of
major metropolitan areas within those states, and zip codes within those metropolitan areas.
An important concept being illustrated by this exercise is that GeoFences can overlap and GeoEvent
Services you create can be configured to work with one or more GeoFence categories.
Lets explore the GeoTag-CustomerReports GeoEvent Service and take a look at the different properties
available with a GeoTagger Processor.
The illustration below shows the GeoTagger-City processor properties page.

In the illustration above, this processor has been configured to enrich an event if the events GEOMETRY
is INSIDE any GeoFence within the City GeoFence category. Enrichment values will be appended to the
event using the specified field name GeoTags. Because enrichment changes the events schema, a new
GeoEvent Definition will be needed the processor specifies that a GeoEvent Definition named

Introduction to GeoEvent Processor Module 5

March 2014

Page 45 of 48

Customer-GeoTagged will be created if a suitable GeoEvent Definition with that name cannot be found
and reused.
As the Include GeoFence Category in GeoTag property implies, you can configure a GeoTagger Processor
to either include or exclude the name of a GeoFences category in the enrichment. The default is to
include the category name in the enrichment.
The final property, GeoTag Format, has three possible values: Delimited Value, Group, or List. Because
the default Delimited Value is the best option for quickly reviewing the event data sent when using the
TCP Console application, it will be explored first. (The other two possible configurations for this property
will be explored later).
Proceed with the steps outlined on the next page to begin simulating customer records and observing
the event enrichment being performed by the GeoTagger Processor.
12. Open the GeoEvent Simulator and configure as follows:

Click Load File and browse to the CustomerReports-Geotagger.csv file in the \simulations
folder.

Change the Time Field # property to field 2 and click Load.

Uncheck the Set value to Current Time checkbox.

Uncheck the Continuous Loop checkbox.

Leave the default rate setting of 1 message every 1000 ms.

Click Click to Connect to establish your server connection.

13. Use your desktop shortcut, batch script, or command line invocation to launch a TCP Console
listening for events on port 5570.

Introduction to GeoEvent Processor Module 5

March 2014

Page 46 of 48

14. Click Play

to start the simulated stream of event data.

15. Review the event data displayed in the TCP Console application.

Notice that a single enrichment field has been appended to every event. The output contains a string of
comma-separated values with the categories and names of the GeoFences in which each event is found.
This sort of spatial analysis can be incredibly powerful. Using ArcGIS for Server and ArcGIS GeoEvent
Processor for Server, you are performing real-time spatial analysis without needing to configure a map,
launch a mapping client, or interactively run any geoprocessing tools.
Lets take a quick look at some of the options other than Delimited Value available when configuring a
GeoTagger Processor. The GeoTag Format property (refer to the illustration shown previously) specifies
how the information from the GeoFences will be represented. There are three options:
DelimitedValue

This option, the default, specifies the GeoFence name (and optionally
categories) should be added to the event as comma separated values. This is
the simplest form of enrichment and likely the best choice when working with
simple text.

Group

This option specifies the GeoFence names (and optionally categories) should be
added as a list of group elements. Each group element in the list will contain a
string for the GeoFence name and a second string for the GeoFence category (if
included).

List

This option specifies the GeoFence names (and optionally categories) should be
added as to a list element. This differs from a string in that a list is better
represented in JSON and individual list elements can be retrieved using an
index.

Introduction to GeoEvent Processor Module 5

March 2014

Page 47 of 48

Because the Group enrichment format relies on event schemas which are not flat, the Text Adapter used
by the GeoTaggedReport-TcpTextOut output is unable to represent the output as comma separated text
values. However, if you were to configure an output which uses a JSON Adapter such as writing to a JSON
file you could review the enrichment in a hierarchical structure to see the Group structure.
A JSON representation of the Customer-GeoTagged GeoEvent Definition using both the Group and List
output options is illustrated below.

GeoTags as a Group
{

GeoTags as a List
{

"CustomerId": "64-91913",
"TimeStamp": 1368391456000,
"Geometry": {
"x": -95.522691,
"y": 29.778511,
"z": 0,
"spatialReference": {
"wkid": 4326
}
},
"GeoTags": [
{
"Category": "City",
"Name": "Houston"
},
{
"Category": "State",
"Name": "Texas"
},
{
"Category": "ZipCode",
"Name": "77024"
}
]

"CustomerId": "64-91913",
"TimeStamp": 1368391456000,
"Geometry": {
"x": -95.522691,
"y": 29.778511,
"z": 0,
"spatialReference": {
"wkid": 4326
}
},
"GeoTags": [
"City/Houston",
"State/Texas",
"ZipCode/77024"
]
}

Introduction to GeoEvent Processor Module 5

March 2014

Page 48 of 48