by Bill Grey,
Director of Research & Development
Engineers often ask, “What are the differences between Interface A and SECS/GEM for data collection.” This is a high-level comparison of Interface A and SECS/GEM/HSMS-SS data collection features. We are working on some tools to help demonstrate Interface A data collection. More on that later….
Clients
Interface A supports multiple clients where SECS/GEM is usually a single client.
Security
Interface A can be configured for SSL secured communications. Only clients with a valid certificate can use the interface and all data across the wire is encrypted.
HSMS is not secured. In HSMS, any host that has the device ID can connect and data across the wire is binary encoded, but not encrypted.
Additionally, Interface A client features are gated by privileges where GEM features are not privileged.
Equipment Model
Interface A E125 provides methods for its client to upload a description of the logical structure of the equipment which includes parameters, events, and exceptions assigned to modules, subsystems, and IO devices. In this manner, each parameter, event, and exception has the context of the owning component.
In GEM, similar information is found in a manual provided with the equipment. Unfortunately, in most equipment manuals, the relationship of which component on the equipment produces the parameter, event, or exception is not available. Context is missing.
Traces
Interface A traces have features that GEM traces do not. Interface A traces have start and stop triggers. These triggers may include one or more events and/or exceptions. The trace would begin collecting data when any of the start triggers occurs and stop collecting data when one of the stop triggers occurs. This is useful as a trace for a processing module may be defined to start when a processing started event occurs and to stop when a processing completed event occurs for that module. In this manner, the Interface A client defines the trace once and collects the data only when processing is active. Between the triggers, data is collected at the specified rate. The rate is specified with a floating point number designating the number of seconds between samples. The resolution is limited by the equipment.
In GEM, traces begin when defined through a SECS message and end when the specified number of samples is collected. To achieve the same effect as Interface A, a host would have to define event reports for the processing module processing started and processing completed events. When the processing started event is received, the host would have to define the trace by sending a SECS message. When the processing completed event is received, the host would have to terminate the trace with a SECS message. The host would have to do this every time, unlike Interface A. There is a delay between the processing started event and when the trace starts because of the SECS messaging that isn’t there with Interface A. GEM traces are limited to centisecond resolution by the E5 standard even if the equipment could support faster traces. Some older GEM implementations are limited second resolution.
Event Reports
Interface A event reports specify an event and an optional set of parameters to be collected when that event occurs. The Interface A client activates the event report to begin monitoring the event and deactivates the report to stop monitoring the event.
GEM event reports are a little different. A GEM host defines collections of parameters called reports. Then it links one or more reports to one or more events. The same report may be linked to multiple events if needed. Then the host enables the event to begin monitoring the event and disables the event to stop monitoring the event.
Alarm Reporting
Interface A exception reporting is very different than GEM Alarm reporting. Interface A exception reports are defined using a source ID, exception ID, and severity. Any of the fields may be empty or filled in. Source ID identifies which component provides the alarm, for example a processing module or load port. If source ID is the only non-empty field, then all exceptions for that component will be monitored and reported. Exception ID identifies a specific exception name, if this is the only non-empty field, then all exceptions matching this name regardless of source will be monitored and reported. If severity is the only non-empty field, then all exceptions matching this severity will be monitored and reported regardless of source ID or exception ID. If more than one of these fields is non-empty, then reporting will be determined by applying Boolean AND logic to the fields. In addition, exception reports in Interface A may contain parameter data; however, which parameters are supplied with each exception is specified by the equipment manufacturer and not selectable by the Interface A Client.
GEM alarm reporting has two forms. For notification of an alarm being set or cleared, the host may enable alarms and receive a SECS message containing no other data. In GEM, each alarm has one set and one clear event that may be used for event reports. Using these events, the host may be notified of alarm set and clear transitions with reports that contain data chosen by the host.
Reports
Neither Interface A nor GEM provide annotated reports.
Data Collection Impact
Interface A E134 defines a mechanism for the equipment to limit the impact of client defined data collection on material processing. If data collection hinders processing, the equipment may issue a Performance Warning to all clients and deactivate their data collection. The equipment may resume data collection at a later time and issue a Performance Restored.
GEM defines no such throttling or notification mechanism.
You may also be interested in:
