| DARTs (Diagnosis, Analysis, and Resolution Tools) are a collection of issue-specific solutions that represents the known detection, diagnosis, and resolution information of the universe of support issues. Practically any procedure or operation that is a series of commands or instructions directed to software, and is executed by software, can be implemented as a DART. Initially, DARTs are written in the C language but Device Healthcare architecture allows us to use a variety of languages to write DARTs by designing a standard DART-client interface. DARTs do not directly interface to the system. Instead, they use a well-defined utility interface provided by the engine. The size of a DART typically ranges between two and five Kbytes. This means that the size of a 3,000 DARTs database won’t be more than 5 Mbytes. Every DART is completely independent of every other DART, even though the engine is highly multi-threaded and multiple DARTs can be running at the same time. There is never a need to worry about synchronization between two DARTs because they are not interdependent. This also relieves the DART designer, and the engine structure, the burden of issues concerning the ordering of DARTs, their initialization, and their dependencies. DARTs can be loaded, unloaded, scheduled, and triggered using relatively simple mechanisms. Each DART can be debugged and tested in isolation with a high degree of confidence that it will operate correctly in a production environment. DARTs are divided into three parts: - Initialization - Here, DART tells the engine about configuration, trigger conditions and local storage
- Symptom - Provides a 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 - Engine runs the DART and solution implements the action that the DART takes
DARTs can have parameters that control their operation. 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. In summary, DARTs provide the capability to incorporate relatively sophisticated logic in driving local support automation tasks, while keeping the complexity of the implementation at a reasonable level. There are actually several different classes of DARTs. These classes are not rigidly enforced, and are more of a notational convenience for understanding the structure of the client. - Issue Resolution - backbone for automated support
- System - critical local processing support
- Utility - tools for remote diagnosis and support
- Application - entire major solution features
|
|
| 
| 
| 
| 
| 
Designed by HFN