Punching Out: How to Stay Focused in Business and M&A
It’s Only Common Sense: Just Imagine…
Marcy’s Musings: Old School vs. New School—When Does It Matter?
In 1987, IEEE introduced Standard Codes, Formats, Protocols, and Common Commands, IEEE-488.2[3]. It was revised in 1992. IEEE-488.2 provided for basic protocols and format exchange, as well as device-independent commands, data structures, and error protocols. IEEE-488.2 was built on IEEE-488.1 but without replacing it. Equipment can conform to the simpler IEEE-488.1 without following IEEE-488.2.
As explained in the Wikipedia definition of IEEE-488[4]: “While IEEE-488.1 defined the hardware and IEEE-488.2 defined the protocol, there was still no standard for instrument-specific commands. Commands to control the same class of instrument (e.g., multimeters), would vary between manufacturers and even models…The United States Air Force, and later Hewlett-Packard, recognized this problem. In 1989, HP developed their TML language which was the forerunner to Standard Commands for Programmable Instrumentation (SCPI). SCPI was introduced as an industry standard in 1990. SCPI added standard generic commands, and a series of instrument classes with corresponding class-specific commands. SCPI mandated the IEEE-488.2 syntax, but allowed other (non-IEEE-488.1) physical transports.”
As explained in the IEEE Standards website[3]: “In 2004, the IEEE and IEC combined their respective standards into a "Dual Logo" IEEE/IEC standard IEC-60488-1, Standard for Higher Performance Protocol for the Standard Digital Interface for Programmable Instrumentation - Part 1: General, replaces IEEE-488.1/IEC-60625-1, and IEC-60488-2,Part 2: Codes, Formats, Protocols and Common Commands, replaces IEEE-488.2/IEC-60625-2.”
MAPS™ protocol—Message Automation & Protocol Simulation (MAPS™)[5]
As explained in GL Communications Inc. overview tutorial:
MAPS specifies a set of standard communication services for factory automation, and has been accepted as an international standard by the ISO. It is a protocol simulation and conformance test tool that supports a variety of protocols for such factory floor controllers as PLC, robots, group controllers and cluster controllers. MAPS is one of the oldest and most used of the factory floor automation protocols, being pioneered by General Motors and adopted by General Electric for its factories. MAPS is based on the Reference Model for Open Systems Interconnection (OSI) of the International Organization for Standardization (ISO). It has three main components: the File Transfer, Access, and Management services, the Manufacturing Message Specification services, and the X.500 services. The protocol such as SIP, MEGACO, MGCP, SS7, ISDN, GSM, MAP, CAS, LTE, UMTS, SS7 SIGTRAN, ISDN SIGTRAN, SIP I, GSM AoIP, Diameter and others. This message automation tool covers solutions for both protocol simulation and protocol analysis. The application includes various test plans and test cases to support the testing of real-time entities. Along with automation capability, the application gives users the unlimited ability to edit messages and control scenarios (message sequences). "Message sequences" are generated through scripts.
MAPS™ is designed to work on TDM interfaces as well as on the IP/Ethernet interfaces. MAPS™ also supports 3G & 4G mobile protocol standards for testing the rapidly evolving mobile technologies. MAPS™ can simulate radio signaling protocols such as LTE (S1, eGTP, X2) interfaces and UMTS (IuCS, IuPS, IuH), GPRG Gb, and GSM A over IP transport layer.
MAPS™ test suite is enhanced to simulate multiple UEs and IMS core elements such as P-CSCF, I-CSCF, S-CSCF, PCRF, MGCF in IMS core network. With the help of mobile phones, and other simulated wireless networks, the VoLTE Lab setup can be operated in real-time for making VoLTE calls and also for interworking with PSTN and VoIP networks. MAPS™ is enhanced to a high density version and a special purpose 1U network appliance that is capable of high call intensity (hundreds of calls/sec) and high volume of sustained calls (tens of thousands of simultaneous calls/1U platform).
A very good description of MAPS and how it works is available in the HP Journal articles of August, 1990.
SECS I & SECII/GEM Protocols[6]
This is the Semiconductor Equipment & Materials International (SEMI) Open Standard. The semiconductor process equipment manufacturers have identified the need for their equipment to communicate with a larger host computer system and developed SEMI Equipment Communications Standard (SECS), which defines parts of all seven ISO open system interconnect (OSI) communications layers.
SECS/GEM standardizes two-way communication within a network or serial cable that connect equipment and is independent of any particular programming or computer operating system.
As explained in the HP Journal article[6]:
SECS I incorporates the use of RS-232-C cabling and pin definitions and a relatively simple line protocol. SECS II defines messages to request and send status information, transfer recipe data, report alarm conditions, send remote equipment control commands, and handle material transfer. SECS I uses a simple ENQ-ACK handshake across an RS-232-C line with checksums at the end of each message. SECS I also defines time-out intervals between handshake responses, individual message characters, and message responses. Message headers are defined in SECS I to include equipment identifiers, message identifiers, message block numbers, and other system information.
SECS II defines message types, format, content, and directions. SECS streams are groups of messages assigned to a general set of equipment functionality. Within each stream, the individual messages are assigned function numbers. For example, SECS stream 1 function 5 (abbreviated S1 F5) is a formatted equipment status request, and stream 1 function 6 is the reply with the status information. Similarly, stream 7 function 5 is used to request the transfer of a process recipe and stream 7 function 6 is used to transfer the recipe. SECS II also defines whether a reply is required or not, the message content and format (including data item definition headers), and whether a message may be used from equipment-to-host and/or host-to-equipment.
A major limitation of the SECS standard is that it defines messages and their content only; it does not define how the messages are used together to perform a function. Equipment manufacturers are left to decide what messages to use to perform functions that were performed manually before. This, of course, makes it difficult to develop translators for external systems to communicate with such equipment.
Figure 6: SEMI’s SECSII/GEM communication standard documents machine connectivity and control / recipes. (Source: HP Journal, July 1985)
Figure 6 show more details of the SECS II/GEM standard built on the OSI 7-level communication model (Figure 7). There is a good free SECS/GEM document available from SEMETECH[7].
Page 3 of 5
