Improving Device Control and Status within Ground Systems
Device control should be easy and transparent. There are some basic tasks that need to be performed with any device, namely setting the configuration and obtaining the device status. If the device supports it, you might also find it convenient to save and restore configurations. But, when it comes down to it, you just want the device to perform its intended job.
For a single device, this is normally straightforward. Your developers might need to write an interface library or application, but even for a complicated device, this effort is normally tractable. The problems typically start when you are integrating large suites of equipment from different vendors. This is especially true if your application is generic in nature and used on many programs. The cost often derives from the fact that vendors do not all choose the same transport mechanisms, protocols and platforms.
The frustration and cost isn’t unique to the end customer. From the vendor’s perspective, providing an easy-to-use control and status interface is often secondary to the device functionality. Unfortunately, device vendors are confronted with numerous end-system architectures. Whether or not they support them all is a choice each vendor needs to make.
The end result is added cost and complexity. Ground systems contain many devices and must be adapted to accommodate numerous interfaces. When standards are used by the device, they are not always native to the end-system’s architecture. System integrators must learn multiple APIs and develop application libraries to account for them. Unless the vendor is particularly generous, the customer pays for it in the end.
This is the problem GEMS is attempting to solve. GEMS seeks to define a simple solution for what should be a simple problem. It bases the solution around the OMG MDA approach using a standard model for device control and then maps that model to specific protocols and platforms. The real value in GEMS is the standard model and the mappings to specific protocols. The standard Platform Independent Model – or PIM provides the abstract device control concepts. It defines the use cases, message classes, parameters types and expected behaviors for setting and getting parameters, invoking directives and saving and restoring configurations.
The GEMS Platform Independent Model (PIM)
The GEMS PIM defines the basic message structure and interaction between a user and a GEMS device. This includes messages that allow users to set and get the current device configuration, save and restore parameters and even some basic connection logic. The messages are defined in UML and contain only the information the we found to be necessary for controlling a device.
The PIM represents the abstract, or high-level design, for GEMS. By itself, it isn't directly implementable. Instead, it is meant to be the reference point for actual implementations of the GEMS specification to map to (such as ASCII, XML and in the future CORBA, SNMP etc). This provides several key benefits. First, as implementable mappings of the GEMS PIM are developed, automatic translations from one mapping to another can be created. So, if you like to use XML, but your device vendor only wants to use ASCII, don't worry. A translator can be created that converts from one protocol to another. Another benefit is that by following the GEMS model, all devices take a similar shape. In other words, they all allow for parameters to be set and get in a similar fashion. For more sophisticated capabilities, GEMS devices provide directives and save/restore capability using common message types and behaviors.
It is important to keep in mind that the GEMS specification does not specify the exact parameters, types or ranges for any specific device or device type. That is beyond the scope of this specification. Instead, the GEMS PIM defines the approach to use when defining device specific parameters. The device vendor provides custom device information in a format compliant with the PIM and PSM used.