Welcome to the GEMS homepage. The GEMS (Ground Equipment Monitoring Service) specification was developed within the OMG Space Domain Task Force. It focuses on standardizing the model for device control and defines simple protocols that will hopefully reduce system integration costs.
The latest version of GEMS is 1.4. This version has been approved by the OMG AB and the final version will be available online shortly.
All versions of the GEMS specification can be found here: http://www.omg.org/spec/GEMS/
For a list of open issues click here.
We now have example messages available online. These are non-normative and provided only to help implementers better understand the specification and improve interoperability between implementations. In the event there is an error with the examples, the standard takes precedence.
Before we get in to the specification, it is important to understand the problem GEMS is trying to solve – basic device control & status. In reality, 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 derive from the fact that vendors do not all choose the same transport mechanisms, protocols and platforms. On top of that, there is significant variation in API designs and system behaviors from one vendor to another. Once you have integrated the hardware, future upgrades may use an entirely different API resulting in impacts to the controlling software.
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. The choice of API or message protocol might be constrained by the device platform. Beyond the platform, the vendor’s expertise in specific technologies and the product goals must be considered. Sometimes the API design is designed to fit within a customer’s architecture; typically the first customer. As a user, it is convenient if you can influence a vendor’s API. 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 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 that darn 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.
The following figure shows the complete GEMS UML PIM:
The precise mapping of the GEMS PIM to concrete protocols is captured in the Platform Specific Models (PSM). Initially two PSMs are available. As you will see, these are not complex protocols and can be easily implemented in a variety of devices.
GEMS-XML defines a mapping of the PIM to XML messages using XML schema. This message structure is well suited for network communication and offers features inherent in XML such as strict message validation and XML transformation. Manual processing is possible, but typically an existing XML parser is used.
The following is an example of a set configuration message. In this example, we are setting three parameters. The third parameter is an array of values.
<SetConfigMessage xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="2" token="CS12345" target="/SystemA/FrameSync1" gems_version="1"> <Parameter name="frame_length_in_bits"> <long>1024</long> </Parameter> <Parameter name="sync_pattern"> <hex_value bit_length="22">faf320</hex_value> </Parameter> <Parameter name=”telemetry_ports”> <int>10001</int> <int>10002</int> <int>10003</int> </Parameter> </SetConfigMessage>
GEMS-ASCII maps the PIM to terse ASCII messages with minimal overhead and simple parsing. This message structure is well suited for serial communications and board-level control. It requires manual message processing, but this is easily done using common programming language features such as printf and scanf.
The following is an example of a set configuration message using GEMS-ASCII. This example sets the same parameters as the above XML example.
Because of the nature of these products, GEMS is also used by many software applications related to the space industry, in essence any of AMERGINT's or RT Logic's customers.
Please email any issues to email@example.com. Any questions can be passed to firstname.lastname@example.org.
Special thanks goes to the folks who worked on and provided feedback to this specification:
Rob Andzik, Luis Rodriguez
Brad Kizzort, Dave Overeem, Victor Giddings