Service Tasks

Service Tasks are background workers that watch sites, alarm areas and jobs, and perform actions when certain things happen. They are the core of the monitoring system as they determine what actions occur in response to incoming signals. They can also be used to trigger actions for any job, including a manually-entered job.

Service Task Maintenance

Service Task Maintenance can be found in Maintenance->Monitoring->Service Tasks.

The service task is a set of numbered rules. When evaluating them, GDS starts at the top works its way down until it either reaches the end, or matches a rule with the STOP flag set. Note that if a rule matches but STOP is not set, GDS will continue processing after applying that rule. This allows you to trigger several rules off the same signal or event.

A service task has a state. This is used to record the current state of the entity the task is watching, and to trigger certain rules at certain times. For example, the state can be used to track whether an alarm is set or unset. You can add states using the Maintain States button. In there you can also assign each state an icon and colour, which will show on the client record while that state is active. This way you can show special icons against the client when, for example, the alarm is in activation.

Each service task can be tied to a site, an area, subscriber or a job. Typical alarm monitoring is tied to an area: we track whether that area is set or unset, and the area generally determines the best response to an activation. No Signals Received tracking we tie to the subscriber: each alarm panel should regularly report to us, even if there are several. Site is used for special services like welfare and tracking.

Regular service tasks are automatically created for each site, area or subscriber that exists and has the correct service assigned. You can tell GDS which services generate which tasks by listing the tasks in Service Maintenance (Maintenance->Client Servicing->Service->Details). The service task automatically stops when the service attached to the client expires.

A job-tied service task is a little different. One of these is spawned for every single job in the system that has a given Event. The service task is created when the job is created and stops when the job is closed.

Service tasks can trigger off either signal events or new job lines being added to jobs. For job lines, we look at the status of the newly-added line, for signals we look at the signal type. You can also add rules which trigger automatically by leaving the event blank. In this case the rule will trigger based on the current state of the task and attached job, and any conditions applied to the rule.

Each zone, client and task has a key/value store attached to it. Think of it as a set of pigeon-holes. Each pigeon hole has a name (the key), and we can put a value into it by specifying the key of the pigeon hole to put it into. We can also retrieve the value later by specifying the correct key. We can set values, retrieve them, and also use them in conditions when deciding which rules to apply.

Set key may take some special values:

The value also has substitutions:

Actions

Actions define actions that can be triggered by service tasks. Permitted actions can also be triggered manually by operators from the actions button on the Client Maintenance screen.