Case Study: Computer Aided Dispatch (CAD) System Product Line

1. CAD overview

2. CAD default system

3. Variants in CAD product line

4. Applying XVCL to handle variants in CAD product line

    4.1 CAD runtime software architecture

    4.2 CAD product line architecture

5. Summary of the experiments

1. CAD overview

CAD systems are mission-critical systems that are used by police, fire & rescue, health service, port and other organizations. Figure 1 depicts a basic operational scenario and roles in a CAD system for police.

Figure 1. A basic scenario in a CAD system for police

Once a Caller reports an incident, a Call Taker in command and control center captures the details about the incident and the Caller, and creates a task for the incident. The system shows the Dispatcher a list of un-dispatched tasks. The Dispatcher examines the situation, selects suitable Resources (e.g. police units) and dispatches them to execute the task. The Resources carry out the task instructions and report to the Task Manager. The Task Manager monitors the situation and at the end - closes the task.

2. CAD default system

3. Variants in CAD product line

At the basic operational level, all CAD systems are similar - they support the dispatch of units to handle incidents. However, there are also many differences across CAD systems. The specific context of the operation (such as police or fire & rescue) results in many variations on the basic operational scheme. 

Some of the variants (functional variants, design decisions, implementation-level variants) that we have identified are as follows:

Functional variants

1.      Call Taker and Dispatcher roles (referred to as CT-DISP variant). In some CAD systems, Call Taker and Dispatcher roles are separated (played by two different people), while in other CAD systems the Call Taker and Dispatcher roles are played by the same person.  The CT-DISP variant has impact on system functionalities. For example, in the former case, the Call Taker needs to inform Dispatcher of the newly created task, but in the latter case, once the Call Taker creates a task, she/he can straightway dispatch resources (e.g., Police Units) for this new task.

2.      Validation of caller and task information differs across CAD systems. In some CAD systems, a basic validation check (i.e., checking the completeness of the Caller and Task info) is sufficient; in other CAD systems, validation includes duplicate task checking, VIP place checking, etc.; in yet other CAD systems, no validation is required at all.

3.      Dispatch Algorithm. There are different ways to dispatch Resources, using shortest distance search algorithm or location code search algorithm.

Variant design decisions

4.      Database. The database used in CAD systems could be either centralized database or distributed database.

5.      Encryption, which indicates whether or not to encrypt the data sent between clients and servers.

Implementation-level variants

6.      Package. CAD components for different systems may belong to different Java packages.

7.      New attributes/methods. We include the default class attributes/methods, as well as anticipated variant attributes/methods into the classes. However, there may be additional class attributes/methods needed by a specific system, due to the possible changes of the requirements.

Besides the above variants, we have also identified other variants. Here, we shall not describe all the variants in detail.

Feature diagrams are often used to model common and variant product line requirements. Figure 8 below shows a fragment of feature diagram for CAD product line.

 Figure 8. CAD feature diagram (partial)

4. Applying XVCL to Handle Variants in CAD Product Line

4.1 CAD runtime software architecture

Having understood common and variant requirements for CAD product line, we design a runtime software architecture for CAD systems. A runtime software architecture defines overall system structures (working at system runtime) that are common to product line members.  Following Shaw and Garlan (1996), we describe a runtime software architecture as a set of interacting components. Figure 9 shows the component diagram of CAD runtime architecture.

At architecture level, to address a given variant, we may need change allocation of system functions to components, include new components into the system and/or modify components’ interfaces. For example, for the CT-DISP variant, if the Dispatcher and Call Taker roles are played by one person, then the CallTaker UI and Dispatcher UI components in Figure 9 can be merged into a single user interface component.

Figure 9. The CAD runtime software architecture (component diagram)

In most cases, addressing a variant also requires us to do certain changes to components’ implementation. We also analyze the impact of variants on the CAD components. Table 1 shows the impact of variants on CAD components (partial). From Table 1, we can see that one component could be affected by many variants, and one variant may also affect many components.

Table 1. The impact of variants on CAD components (partial)

4.2 CAD product line architecture

We develop CAD product line architecture based on the CAD runtime software architecture (Figure 9). Using XVCL, we design generic, adaptable components as x-frames that incorporate both domain defaults and variants. The resulting x-frames are meta-components, from which concrete components can be constructed. We realize a product line architecture as a set of layered x-frames (x-framework). Being built of x-frames, the product line architecture has the ability to accommodate both commonality and variability in a domain. During application engineering, specific systems, members of product line, can be constructed from the product line architecture.

The CAD x-framework is shown in Figure 10.

 Figure 10. CAD x-framework

The CAD SPC is the specification x-frame, which specifies the composition and adaptation of lower-level x-frames, and records a configuration of required variants (such as the choice of database, validation type, Call Taker and Dispatcher role, etc.).  Given the SPC, the XVCL processor adapts the CAD x-framework, customizes it according to the instructions given as XVCL commands, and generates specific components that meets the specific requirements (such as “basic validation” and “separated Call Taker & Dispatcher roles”) of a CAD system. Figure 11 illustrates the process of constructing custom CAD components from x-framework.