4.4.3 System Services

The system services that will comprise CHART II all have characteristics that will enable CHART II to be a flexible, self-healing and highly automated system.

4.4.3.1 System Service Characteristics

CHART II system services are: small, process-independent, table-driven, and machine-independent. These characteristics are further defined below. These characteristics, when combined, describe processes that form the building blocks of a resilient, distributed, and customizable system. When each of the processes required for CHART II are designed and built with these principles in mind, the resulting system will meet expectations for robustness, flexibility and reliability.

Small – Each service will be responsible for a single task or small group of tightly coupled tasks. Small, simple processes are less complicated to develop and maintain than large multi-purpose processes. If a process is performing a small number of tasks, there are fewer places for things to go wrong. Well-constructed smaller processes tend to fail less frequently than larger, more complicated processes. Additionally, if a small process does have problems, the causes can generally be detected more easily than for large processes, simply because there are fewer places to check for failures. Finally, in the worst case, if a small process completely fails, the rest of the system can keep working. The system as a whole will have just a small piece of missing functionality.

Process-Independent – Independent processes can perform their tasks without affecting other processes. If an independent process fails, it can be restarted without causing other processes to fail. If an independent process needs to be changed, it can often be modified without affecting other tasks at all. If additional functionality is added to the system as a whole, only those processes directly affected by the modifications need to be changed. Other processes are unaffected.

Table-Driven – Well-designed table-driven processes are highly configurable. Basic CHART II system modifications such as adding data feeds, or changing a user’s area of responsibility during a specified time period, are accomplished by changing records in a database. As an example, the system monitoring process benefits highly from the table-driven approach. If a new process is added to the CHART II system, the system monitor service can manage it if a new record is added to the SystemProcess table. This table will be described in detail later in the System Controller subsection.

Machine-Independent – Machine-Independent processes can be run on any machine with enough resources to handle the workload. If specific machines become overloaded, or need to be shut down for service, a machine-independent process can be configured to run on any similarly configured machine. Machine-independent processes can also be configured to run on multiple machines simultaneously. Therefore, if a particular process, such as sending out multiple pages or faxes, needs to be run quickly, the process can be configured to run on multiple machines. A database can be used to manage individual process requests to ensure each request is executed the proper number of times. Running a process on multiple machines also protects against hardware failure. If one of the machines fails, the remaining machines will keep running, with no significant impact on operators. Obviously, significant analysis will have to be undertaken to ensure processes are not running in locations where data requests would overload the network. However, that is a matter of establishing proper configuration rules and requirements.

4.4.3.2 System Service Descriptions

The following describes the proposed CHART II System Services. Many of the service descriptions will contain tables utilized by the process to perform their functions. The tables described are not necessarily complete. Only the most salient fields have been included in order to focus on the primary task of each service.

4.4.3.2.1 System Controller

The System Controller is responsible for starting, stopping and monitoring the services and programs of CHART II. On a continual basis, the System Controller will look for failed processes, attempt to correct the failure, and restart them. If the System Controller is unable to restart a failed process, it will mark the process as failed and perform predefined notification procedures. The System Controller Service uses the SystemProcess table to determine what processes to monitor, how to determine if a failure has occurred, and how to respond to the failure. The System Controller will use the Notification table to perform the correct notification steps. The System Controller will also manage user requests to start and stop other processes.

The requirements document includes device arbitration in the System Controller. This requirement did not follow our design concept of small, single-purpose system services. Managing the health of all processes in the system and arbitrating device control are not similar services. In order to insure that only one process arbitrates control of a device, the arbitration should be performed by a process as close to the device as possible. Since this project does not want to modify the controllers for all signs and TARs under the state’s jurisdiction, the next closest process to the devices is the Field Management Station. This design, therefore, recommends device arbitration be performed in the FMS. Since the development of the FMS is not part of this project, this design will not address device arbitration. However, the FMS sub-section of this document does include a discussion of how device arbitration might be incorporated into the FMS.

SystemProcess Table

Field

Type

Description

ProcessID

Integer

Unique number identifying a system process

MaxTimeBetweenLogs

Integer

Maximum time between system logs. Each process monitored by the system controller, will periodically log its status. If the system controller detects that the log has not been updated for longer than MaxTimeBetweenLogs, then it will assume the process has failed

RestartProcedure

FileName

A command procedure to run in order to restart the process

NotificationID

ID

ID of a notification procedure to run if the restart fails (See the Notification Table)

ProcessStatus

Integer

A code that determines the current status of the process. Possible values are Running, Restarting, Failed, Suspended, and Inactive

LastUpdateTime

Time

The time when the process status last changed.

Notification Table

Field

Type

Description

NotificationID

Integer

Unique Number identifying a notification procedure

NotificationStep

Integer

Sequential Number identifying the step within the notification procedure

NotificationType

Integer

Code indicating the type of notification. Possible values are page, fax or e-mail

RecipientList

String

List of recipients to receive notifications

NotificationDetails

String

Name of file containing details of problems

 

4.4.3.2.2 Transaction Server

The Transaction Server is a system service that routes requests from the GUI and background processes to either another remote Transaction Server or a local service that will fulfill the request. At least one Transaction Server will be running at each district, and operation center. Each GUI will have knowledge of its local Transaction Server and how to route requests to it. All requests for services will be received by the local Transaction Server. The local Transaction Server will determine whether to service the request using a local service, or whether to route it to a remote Transaction Server. The Transaction Server that will service the request routes the request to the desired local service. The Transaction Server will also have the capability of managing groups of services. A group of services is defined as two or more identical processes running on different machines. Process groups can be created for the purpose of load balancing or providing failure resiliency. For CHART II, failure resiliency is defined as the ability to recover from process failures by routing requests around failed servers to equally capable alternative servers. When the System Controller determines that a process has failed, it will mark appropriate records in the ServiceRouting and ServiceGroup tables. The Transaction Server can route a request to any server in a process group on a random, round robin or customizable basis. The Transaction Server uses the ServiceRouting Table to properly manage service requests.

To illustrate this concept, assume a process is associated with a service (e.g., fax). Then, separate, identical copies of that process can be run on multiple machines. A Transaction Server would have the option of (1) distributing multiple requests for service in total to these multiple machines (say in round-robin fashion), and/or (2) partitioning a particular request for service into multiple requests, that could be dispatched to one or more of these machines/processes. For example, a request to fax something to 50 people could be broken into 2 requests to 25 people. The rules for partitioning requests could be put in a database table. The number and location of these duplicate processes would be dictated by the desired performance weighed against the distribution of available machine resources and network capacity. Given the attributes described previously, the decision on the number and location of these duplicate processes has been reduced to a configuration issue.

The functionality of the described Transaction Server is very similar to commercially available Object Request Brokers (ORB). Prior to completing the design of the Transaction Server, COTS products will be evaluated for inclusion. Our understanding of the requirements, and the state of evolution of our design at that time, will permit us to select products that can be most effectively incorporated into the final system.

ServiceRouting Table

Field

Type

Description

RequestingHost

IP Address

IP Address of machine hosting the Transaction Server that handles the request. The combination of the RequestingHost and the ServiceID will make up the unique key for this table

ServiceID

Integer

Unique Number Identifying a system service

ServiceHost

IP Address

IP Address of machine hosting service

ServiceProcess

Network Pointer

A pointer to the actual service that will accept requests

ServiceGroupID

Integer

Unique number identifying a service group that can service a request (ignored if ServiceHost and ServiceProcess are not blank)

ServiceSelectionType

Integer

A code that determines how the Transaction Processor will select a service from a service group. Options are Use ServiceHost, Random, Round-robin and any number custom service selection methods.

Available

Boolean

A true or false value indicating whether the service is available anywhere in the network.

ServiceGroup Table

Field

Type

Description

ServiceGroupID

Integer

Unique Number Identifying a service group

ServiceGroupIndex

Integer

The number of the actual service host within the group

ServiceHost

IP Address

IP Address of machine hosting service

ServiceProcess

Network Pointer

A pointer to the actual service that will accept requests

Available

Boolean

A true or false value indicating whether this specific service is available.

4.4.3.2.3 Legacy Import Process

On a scheduled or event-driven basis, the Legacy Import Process will query legacy systems for data. If data is found, it is loaded and made available to other systems. The LegacyImport Table manages this process.

LegacyImport Table

Field

Type

Description

Legacy System Name

String

Unique Name of a Legacy System from which to import data

Frequency of Import

Integer

Code indicating frequency of import. e.g. hourly, daily, etc.

Time of Import

Time

Based on Frequency of Import, the time when the import will be initiated

Import Event

Integer

If set, the type of event that will trigger and import. e. g. appearance of a file, mail message, user request, etc.

Import Area

String

Location of data to be imported

Import Procedure

String

Name of procedure to be run when importing data

Status

Integer

Code representing the Current Status of the Legacy System Import Process. Status codes include Available, Importing, and Disabled.

4.4.3.2.4 External Systems Import

The External Systems Import Process is very similar to the Legacy Systems Import. On a scheduled or event-driven basis, the External Systems Import service will query external systems for data. If data is found, it will be loaded into system tables and made available to other processes and services. The mechanism of importing data on a scheduled basis is straightforward to implement. However, if incidents occur in external systems, the ideal import method is to look for an event (sometimes called a signal) that is raised by the external system whenever an incident occurs. Otherwise, there might be a significant time delay between the time of an external incident and CHART II becoming aware of it.

As described in the System Architecture section, a protocol translation is performed when importing data from external systems. The Import Procedure field in the ExternalImport table contains the name of a procedure that will translate the message from the external system into a format that can be read into related areas of the CHART II databases.

The ExternalImport Table drives this service and is functionally equivalent to the LegacyImport Table.

 

External Import Table

Field

Type

Description

ExternalSystemName

String

Unique Name of an External System from which to import data

Frequency of Import

Integer

Code indicating frequency of import. e.g. hourly, daily, etc.

Time of Import

Time

Based on Frequency of Import, the time when the import will be initiated

Import Event

Integer

If set, a code indicating the type of event that will trigger and import. e. g. appearance of a file, mail message, user request, etc.

Import Area

String

Location of data to be imported

Import Procedure

String

Name of procedure to be run when importing data

Status

Integer

Code representing the Current Status of the External System Import Process. Status codes include Available, Importing, and Disabled.

 

4.4.3.2.5 External System Export

On a scheduled and/or event-driven basis, the External System Export Process will export data to external systems. For example, data could be exported on a daily basis, and or whenever an incident occurs. Data could be sent directly to the external system, or left in a posting area for the external system to collect. It is possible for multiple data feeds to be exported to a single external system or multiple systems.

As described in the System Architecture section, a protocol translation is performed when exporting data to external systems. The Export Procedure field in the ExternalImport table contains the name of a procedure that will translate a message such as an incident notification from the CHART II databases into a format required by external systems.

The ExternalExport Table manages the exporting process.

ExternalExport Table

Field

Type

Description

ExternalSystemName

String

Name of an External System to receive exported data

Frequency of Export

Integer

Code indicating frequency of import. e.g. hourly, daily, etc.

Time of Export

Time

Based on Frequency of Export, the time when the export will be initiated

Export Event

Integer

If set, the type of event that will trigger an export. e. g. an incident or construction

Export Area

String

Location of data to be exported

Export Procedure

String

Name of procedure to be run to export data

Status

Integer

Code representing the Current Status of the External System Export Process. Status codes include Available, Running, and Disabled.

4.4.3.2.6 Map Update Service

The Map Update Service will run on a timed and/or event driven basis. When an update event is scheduled to run, the Map Update service queries a data source for requested data. If the requested data is found, the update service will run a procedure to extract the data and add it to the map’s underlying database. At the same time, it will associate the data with the appropriate map layer. If necessary, affected portions of the map will be redrawn to reflect the latest data. Usually this will run on a timed basis. However, immediate data requests can be sent to the Map Update service either from the Mapping Subsystem based on user request or a system event such as a detected incident.

4.4.3.2.7 VMS Server

The VMS Server is a System Service that will accept requests to put messages on signs. It will communicate with the FMS Server using predefined SNMP commands. The user can request that messages be put on a sign immediately, or scheduled for a future time. Using a distributed service for managing VMS messages will allow applications to send VMS requests in a single format, though many of the signs have different protocols. The VMS Server will also allow a uniform method for defining message schedules. If a particular sign supports message scheduling, the VMS Server can download an entire schedule to a sign. If the sign does not support schedules, then the VMS server will act as a scheduler, changing messages according to the schedule request. The VMS Server will respond to the calling application indicating whether a request was valid or invalid. Later, the server will issue another status message when the message is successfully placed on the sign or all attempts failed.

Although the FMS will include controlling signs, the VMS Server is still needed in order to remove the need for detailed knowledge of sign protocols or SNMP from most CHART II applications. The VMS Server will translate the requests into SNMP commands and forward them to the FMS. The FMS will perform the sign manipulation and respond via SNMP to the VMS Server. The VMS Server will respond to the application. This Object Oriented approach encapsulates device specific knowledge only into the processes that actually communicate with devices.

The VMS Server will not be responsible for understanding and applying the device relationship rules. These rules include the order of blanking or setting messages on devices. These rules will be understood by the application that is requesting the changes, namely the Map and Incident Handler programs. The VMS Server will apply the rules for how a message is displayed on a sign including all the Text Priority and Text positioning. For efficiency’s sake (in order to traverse the network only once), it would be wise to co-locate the VMS and FMS Servers, either on the same machine or on the same local area network.

4.4.3.2.8 Archive Service

The CHART II Archive process will be responsible for the timely removal and storage of aged data from the on-line data stores. The Archive will be a highly configurable, highly automated background process. The SystemArchive Table will drive the process. System Administrators will be responsible for maintaining the driver tables, but the process will initiate itself whenever required by its schedule, and perform the prescribed tasks.

SystemArchive Table

Field

Type

Description

ArchiveName

String

Name of the Archive to be run

ScheduledArchiveTime

Time

The date and time the next archive is scheduled

Frequency

Integer

Code representing the type of frequency. Possible values are hourly, daily, weekly or monthly. It is also possible to schedule a one-time only archive

Frequency Duration

Integer

Number of "Frequency Units" to wait between archives. If Frequency is Daily and Frequency Duration is 3, the archive will run every 3 days

MinimumDataAge

Integer

Minimum age of data in "Frequency Units" to be archived. If data is at least this old, it will be archived off of the system.

ArchiveProcedure

String

Name of Archive Procedure to run

DataStoreType

Integer

Code representing the type of data to be archived. Possible values may include Oracle Database, local database, or log file.

File

String

Either the physical database name or the name of file containing data.

TableName

String

If DataStoreType is a database, this is the name of the table within the database to archive

ArchiveFile

String

Physical location and name of the resulting archive file

4.4.3.2.9 Reporting Services

The Reporting Service will periodically check the ScheduledReports table to determine if any reports need to be run. If any reports need to be run, they are submitted and monitored. If they need to be printed, the service monitors the printing and notifies recipients when they are completed.

ScheduledReports Table

Field

Type

Description

ReportName

String

Name of the Report to be run

NextReportTime

Time

The time when the next report is scheduled to run

ReportingFrequency

Integer

Number of hours between reporting runs

Printer

String

Name of printer to print report on

NotificationID

Integer

ID of a notification procedure to run when the report is complete, or if it fails (See the Notification Table)

4.4.3.2.10 Web Feed Server

On a scheduled and/or event-driven basis, the web feed server will copy data to CHART II Web server. At periodic intervals, the web feed server will initiate a process that will collect all data required by the web server. Because this service has a fairly low priority, the system administrator will have the ability to not run the feed, or run it less frequently when system load is heavy. In addition, the web feed server could run when specific system events occur. For example, if an incident is detected which will have any impact on traffic flow, the incident management system could raise a system event which the Web feed server will detect. The server would then run a web feed procedure associated with that type of event. The WebFeed table will drive this process.

WebFeed Table

Field

Type

Description

WebFeedName

String

Name of the Web Feed procedure to run

ActivationType

Integer

Code indicating whether the feed is activated by a schedule or an event.

Frequency

Integer

Code representing the type of frequency. Possible values are by minute, hourly or daily. It is also possible to schedule a one-time only feed

Frequency Duration

Integer

Number of "Frequency Units" to wait between archives. If Frequency is by minute and Frequency Duration is 3, the web feed will run every 3 minutes

Event

Integer

If activation type is event, this will indicate the type of event that will trigger a web feed

4.4.3.2.11 AVL Server

The AVL Server is a system service that performs communication activities between CHART II processes and vehicles equipped with AVL communication devices. The AVL Server will perform three basic functions. On a scheduled basis, it will attempt to find the location of every active vehicle in the system and store the location data and vehicle status in the AVL database. The AVL will also listen for messages coming from vehicles reporting their status. Finally, it will fulfill requests from other processes to send messages to vehicles in the fleet. Because the specific AVL system has not been selected, this section will not talk about the specific method used to communicate with the vehicles. Existing commercial AVL systems use two-way radios, cellular and paging protocols among others to facilitate communication between the vehicles and a central location.

The VehicleLocation table listed below will drive the AVL Server process. The vehicle polling frequency will remain constant for all vehicles in the system so it will not. The System Administrator will be able to add, remove, activate or deactivate vehicles within the system.

 

VehicleLocation Table

Field

Type

Description

VehicleID

Integer

Unique number identifying the vehicle

VehicleType

Integer

Code indicating what type of vehicle. Possible values are snow plow, police car, or maintenance truck.

EquipmentType

Integer

Code indicating what type of communications equipment is in the vehicle. This field will determine the mechanism used to communicate with the vehicle

CommunicationsID

Integer

ID required for communications, i.e. cell phone number, pager number, radio device id.

VehicleStatus

Integer

Code indicating current status of vehicle. Possible values include active, reporting, inactive or error

VehicleLocation

Location

Coordinates of vehicle

LastReport

Time

Last date and time of successful communications with vehicle

4.4.3.2.12 Incident Detection Service

The Incident Detection Service will run on a frequent, timed basis. Other services will periodically gather data from detection devices and store it in a database easily accessible to the incident detection service. When the incident detection service runs, it will load all data needed to run its incident detection algorithms. In order to defer the need to consider boundary-crossing algorithms, the initial incident detection algorithm will be detector based. That is, only individual detectors will be considered when attempting to discover incidents. If an incident is discovered, then an event will be raised so the incident handling system can begin to process the incident.

The initial part of the proposed incident detection algorithm is based on difference from expected for a specified time period. For example, if the speed detected by a single detector is x % less than expected for y consecutive periods, an incident is suspected. Additional logic will be run after the initial part of the algorithm determines that there might be an incident. That logic will look at data upstream and downstream from the suspected incident. If downstream volume is a specified percentage less than expected and upstream speed is a specified percentage less than expected, an incident is likely. The final part of the proposed algorithm is to compare the detected incident with ongoing incidents. If the incident is in the vicinity of any ongoing incident, it is considered part of the original report, and no additional incident in opened. Industry experience indicates that there is no reliable way to automatically detect a secondary incident within a primary event, so the proposed algorithm will not attempt to discover secondary incidents.

4.4.3.2.13 AVCM

The AVCM is being built by the CSC/PBFI Team as part of the Maryland Network Management Services contract. The AVCM will respond to requests to route signals from camera to various display or record devices. It will also arbitrate requests from different parties to obtain control of a camera. This document will not describe this service in any more detail. The AVCM is included here for completeness and because descriptions of other system components refer to it.

4.4.3.2.14 FMS

Also being built as part of the Maryland Network Management Services contract by the CSC/PBFI Team, the FMS manages communications with a variety of traffic devices. The FMS acts as an agent between on-line and system services, and several types of devices. The first delivery of the FMS will include automated polling of detectors and storage of polled data. This data will primarily be used by the incident detection service. Future device types will include Variable Message Signs, Traffic Advisory Radio and weather stations. The FMS will communicate with each device in its native format, but respond to networked requests via SNMP. This document will not describe this service in any more detail. The FMS is included here for completeness and because descriptions of other system components refer to it.

The requirements document included device arbitration in the System Controller. As explained in the System Controller sub-section, this design calls for device arbitration to be included in the FMS. Although the FMS is not part of this proposal, basic arbitration is described as follows:

An operator decides to change a message on a device. The GUI issues a command to change the message. The message is routed to the FMS through the VMS or TAR server. If no message is currently active on the device, the new message is made current. If another message is current, the priorities of the message and requestors are compared, if the new message has a higher priority, it becomes the current message. If the new message has a lower priority, the request fails and a failure message is routed back to the GUI. The GUI informs the operator of the failure including the content and sender of the current message.

4.4.3.2.15 Operator Area of Responsibility Service

The Operator Area of Responsibility (AOR) Service runs on a continuous basis and assigns areas of responsibility to operators based on the time of day, AORConfig table and the operators logged into the system. The System Administrator will have the ability to override the assignments of the Operator Area of Responsibility service, and keep the assignment static for any amount of time. This will allow operators to temporarily leave their stations or temporarily reassign responsibility for training or a demonstration. The Operator Area of Responsibility Service will modify the AssignedAOR table whenever if determines that the area of responsibility operator needs to be changed. The AssignedAOR table is the table that the Incident Handler process uses to determine which operator is responsible for responding to an incident.

AORConfig Table

Field

Type

Description

AORID

Integer

The ID of the Area of Responsibility

EventType

Integer

Code representing type of incident operator is responsible for. One possible value is ALL incidents.

StartTime, EndTime

Time

The time of day during which this record is used to assign the area of responsibility to the operator

DayOfWeek

Flags

A series of seven flags, one for each day of the week, that indicate which days of the week this record should be used to assign an area of responsibility.

Priority

Integer

The priority order for assigning this area of responsibility to this operator. If more than one operator can be assigned to an area of responsibility during a given time period, the Operator Area of Responsibility service will assign the area of responsibility to the operator who has the highest priority of all logged in operators

Operator

String

Login name of user

 

AssignedAOR Table

Field

Type

Description

AORID

Integer

The ID of the Area of Responsibility

Operator

String

The Operator assigned to the AOR

AssigningEntity

String

Name of the entity that assigned the operator to the Area of Responsibility. It can be either the Operator Area of Responsibility service, or the name of the operator who manually assigned the operator to the area of responsibility

AssignmentTime

Date

The time when the user was assigned to the area of responsibility

AssignmentStatus

Integer

Code describing the status of the assignment. It can be static or dynamic. If static, then the Operator Area of Responsibility service will not change the assignment until StaticEndTime

StaticEndTime

Time

If the assignment status is static, this will be the time when the area of responsibility will be eligible to be automatically changed

4.4.3.2.16 Operator Area of Interest Service

The Operator Area of Interest (AOI) Service is nearly identical to the Operator Area of Responsibility Service. The primary difference is that the AOI provides operators a read-only view into areas outside their area of responsibility so that they could see incidents that might affect them. The AOR and AOI services are so similar that more than likely they will become one service that can assign both levels to an operator. They are both described here in order to identify two distinct capabilities and the difference between them.

4.4.3.2.17 Operator Security Service

The CHART II GUI will rely upon native NT security to determine what privileges operators have before allowing them to perform tasks.

The Operator Security Service is responsible for maintaining the proper security levels for operators based on a number of factors. It will do this using Windows NT system security and database access control lists. The main Map GUI will check the NT Security System every time an operator requests access to a privileged function. Using this method, the GUI does not need to be concerned with calculating an operator’s rights or role.

Though the Operator Security Service is responsible for setting operator security, System Administrators with proper privileges can override system settings. An operator privilege utility program will allow a System Administrator to change current settings for a selectable amount of time. In this way, unforeseen circumstances can be addressed when necessary, but normally little administrator intervention will be required to manage user security on a day to day basis.

4.4.3.2.18 Data Replication Service

Data replication is the process of ensuring remote databases are kept in synch with each other. Essentially, data replication copies database changes from a master database to a defined list of slave databases. It is also possible to copy data from a slave to a master provided conflicts do not arise. If conflicts ever occur, the data in the master database is usually assumed correct. In a distributed environment, using replicated databases is one method of sharing data between various locations. Selecting databases to replicate is an activity that requires careful consideration of a number of factors. The basic tradeoff is whether to use network bandwidth to replicate data or keep data local and use the bandwidth to service requests as they are made. That decision is usually based on the frequency of updates, the number of data changes, the frequency of data requests, and the amount of data requested. Because Data Replication is such an important capability of distributed systems, most databases, including the recommended database Oracle8, have database replication capabilities. Database replication is one of the primary reasons that CSC/PBFI is recommending that MDSHA upgrade its Oracle licensing from 7.3 to 8 including replication services for CHART II. However, if the database selected for CHART II does not have replication capabilities, a replication service will be developed for CHART II.

4.4.3.2.19 Fax Service

The CHART II Fax service processes operator requests to send faxes. Each fax request will be added to a Fax Request table by the requesting process, usually the Map GUI. The user can request a fax to be sent immediately, or at a scheduled time in the future. The user may send a fax to an individual, a list of recipients, or a predefined group. The maintenance of fax groups is independent of the faxing process, and therefore fax groups can be edited at any time without affecting the faxing process. The faxing service can be configured to attempt to deliver a fax a preset number of times before marking a fax request as failed. The success or failure of the fax will be logged, and the requesting process can optionally be notified of the fax status.

4.4.3.2.20 Paging Service

The Paging Service processes operator requests to send pages. Each paging request will be added to a Page Request table by a requesting process. The user can request a page to be sent to an individual, a list of recipients, or a predefined group. The maintenance of paging groups is independent of the paging process, and therefore paging groups can be edited at any time without affecting the paging process.