News and Views

New Python SECS Equipment and Host Software

We started working with Python on our Nvidia Jetson nx Single Board Computer to explore computer vision applications.  Next thing you know we have had a published article in Volume #83 of Make magazine, and have had customer inquires on using Python for SECS/GEM.  Well, why not?  So we have added libraries and example applications for both equipment and host developers.  See the reference documentation for details.

SEMI Draft Standard #4557 - the Photovoltaic Industry Gets It Right

We applaud the SEMI European PV Standards Technical Committee for their endorsement of using SECS/GEM for communication interfaces with photovoltaic equipment (PVECI). Their draft Guide presents a well-informed and excellent set of decisions for the subset of the SECS/GEM standards to be deployed as well. The guide endorses the best parts of SECS/GEM such as robust HSMS communication, and leaves behind the obsolete features such as Inquire/Grant messages which no longer make sense even for SECS-I communication. The Guide also steers a path away from the complexities of formatted recipes, large dataset transfers (Stream 13), Object Services (Stream 14), E42 recipes (Stream 15), and E139 recipes (Stream 19). These are correct choices - these features pose undue complexity for PV equipment, and stating clearly up front that they should not be used provides needed focus to implementers and avoids wasted effort. What remains is an efficient, understandable core set of messages and protocols that will serve the PV industry well.

The Background Statement of the Draft briefly discusses the context for the selection of SECS/GEM. What is the competition? One of the possible choices is OPC, which originally was an acronym for OLE for Process Control. OPC got started at about the same timeframe as HSMS. Unlike HSMS, the original OPC was based on proprietary Microsoft protocols and was only available for Windows. In recent years the OPC gang has figured out that relying on a proprietary core protocol that they do not own is not a good choice so they have been reinventing themselves. Timing is everything though - their new standards are not widely deployed or supported. That contrasts to SECS/GEM where the core protocol is platform independent and mature, and the toolset vendors have had more than a decade of improving and polishing their products in a competitive market.

What about XML, SOAP, web-services or EDA? To date XML based approaches have failed to achieve widespread use for automation purposes. There is no example deployment that I am aware of which the PV industry can rally behind and emulate. If you are a proponent of these you may chalk this up to their newness, but there are real issues hindering acceptance which potential users are not ignoring. These approaches are all more complex than SECS despite the superficial simplicity of XML tags, so to balance the increased complexity, where is the payback? The argument that common tools can be applied for XML and HTTP doesn't have a lot of weight with anyone who understands socket programming and doesn't need a complex parsing tool for unpacking relatively simple data structures. I recently tried using xmllint for validating message data using the schema files of EDA and found that it crashes validating an equipment self-description message. In the past, I have had similar failures trying to use the metadata files of EDA with other programs. This has been surprising - XML has been around for plenty of time to shake out the version 1.0 bugs so is there something wrong with the EDA files? I can't tell. The EDA standards do not cover the basic scope needed for supervisory control provided by SECS/GEM so they are not a candidate for PV adoption in lieu of SECS/GEM. This is actually good news for SEMI. If EDA were advocated for PV industry use, rejection of EDA and consequently rejection of a meaningful role for SEMI in the PV industry would be the likely result. The EDA standards have severe usability issues that hamper their acceptance. I think the most glaring issue is that you can't use the standards for a guide in constructing or validating message data. This has time-consuming and expensive ramifications for supporting EDA. The industry needs standards that a developer can read and understand what to implement, and that CIM personnel can use to quickly diagnose any data problems. If the actual EDA message content were plainly understood, the authors and their reviewers could improve the hidden issues such as the overly verbose use of classnames and inconsistent naming patterns. Another sore point is the inclusion of long, release specific namespace strings in the body of every message. While I am on my soapbox, does EDA really need security that is more elaborate than used for online banking? Requiring the use of key certificates that have expiration dates and are tied to specific hostnames and IP addresses is a predictable support nightmare. In truth the predictable consequence of this requirement is that SSL will not be enabled for use with EDA in a factory setting and users should be saved the time and expense of providing for it.

The basic usability problems of the newer XML based SEMI standards need to be fixed, or they need to be discarded for a fresh start.  The elaborate class hierarchies specified for message structures and being exchanged in every message are a serious deterioration of progress from SECS/GEM. Let the data modeling be a guide for the cardinality and associations of real data elements that need to be in real transactions, but don't map the data modeling into each message. Simplify the message structures to only the data elements that need to be present, in their simplest structure. Don't focus the standards on the data modeling, focus the standards on real message structures that result from a proper analysis.  

The Recent Changes Datahub SDK Documentation Page

  About Us                   Contact Us                 News and Views             Integrators                Documentation                Support 

Serving the semiconductor manufacturing industry since 1992                          Copyright Hume Integration Software 2022