With a strong enough engine, pigs can fly

Device support is inherently a local process, with a central database that can be loosely coupled. Distributed processing lends itself well to this, by using relatively powerful local processing.  The important key feature of the local processing architecture is to provide these required elements in the client software:

• Complex detection using multiple data sources
• Complex resolution using multiple low-level functions
• Sophisticated logic needed for diagnosis and resolution

The main way this is done is with a "divide and conquer" approach that maintains strict modularity. The main modular division of the client is into two parts:

• Engine - This is the piece that provides the interface to the operating system, manages all communications to the server and other clients, and manages all scheduling and timing.
• DARTs - (Diagnosis, Analysis, and Resolution Tools) This is the collection of issue-specific solutions that represent the known detection, diagnosis, and resolution information of the universe of support issues.

The third modular division of the client is the internal structure of a single DART. DARTs are divided into three parts. Device Healthcare Support Automation Distribution Support DART Architecture

• Initialization - Here, the DART tells the engine how it can be configured, what conditions should trigger it, and what kind of local storage it needs.

• Symptom - The engine runs this section of the DART when it is triggered, giving it detailed information about the trigger. The job of the symptom is to provide any more complex decision logic needed to decide whether or not the conditions for running the DART apply, and return that decision to the engine.

• Solution - If the symptom determines that the DART should run, the engine runs this section of the DART. The solution implements the action that the DART takes.

Characteristics of client

• Engine is multi-threaded and handles several DARTS at the same time
• PROCs are common routines to avoid duplicating parts of one DART in another
• DART Scheduler schedules, triggers and runs the DARTS and synchronizes data
• DARTs interface with the device through well defined utility interface of the engine
• DARTs can be loaded, unloaded, triggered, scheduled using simple mechanisms
• DARTs have parameters that control their operations

An example is a DART that acts based on a threshold on a free resource, where the threshold has a default value but can be configured. These configurations are managed by the engine, and can be configured for groups of devices on the server. The DART always has access to the configuration information as it runs. This mechanism is described in more detail in Pantographic Support.

Benefit

The flexibility and power of the modular client architecture provides the basis for a number of key advantages:

• Scaling to large numbers of devices
• Deep detection, diagnosis, and resolution capabilities
• Quick and responsive issue management
• Reduced network bandwidth requirements
• Service offerings can be customized
• Database architecture is open and extensible
• Modular architecture has low overhead

Uniqueness

Simply put, no other offering has this kind of powerful and sophisticated software running on the supported device. Some other simple architectures in use are:

• Modular architecture ensures scalability for large problem sets across number of devices
• Flexible architecture allows adding major new feature sets without bulky “add-ons”
• Small and efficient client avoids the “bloatware” plague of the software industry
• Event-based architecture doesn’t bog down with growth of number of support issues
• Triggered-DART architecture avoids major issues with “collections” of scripts or executables

• Triggering architecture extends to fit any future device support issue detection and resolution

Return To Top