Home             Products            Support   




Our Customers



Consulting and Implementation
Services

Supporting
SECS-I      HSMS
 SECS-II    300mm

   GEM    PVECI

Platforms!

     

News and Views

New C++ SECS Equipment Software

Ok, we got with the program.  By using std::string and STL based data structures, our C++ API has been made much simpler to use.  Now, the compilers take care of making sure that allocated data gets freed instead of trusting the developer to code all the needed de-allocation calls.  We also figured out how to overcome issues that exist when exporting STL data from a shared library, or sharing objects across different runtime library versions.  The simple answer is, we don't - the new C++ source files are provided for inclusion in your application project.  Take a fresh look at our C++ SECS tool software for Windows, Linux, and POSIX platforms with 32 bit and 64 bit versions.

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

With the number of packages included in the Datahub SDK toolset, we are constantly updating one thing or another, whether its with new features, bug fixes that we have developed, or source changes pulled in from open-source revisions.  We use the Recent Changes documentation page as a means to alert you to what has been changed recently.  There is a link to this page from the Documentation home page, near the bottom of the left-most frame.   If we think something is not important to you, such as the revision of our logo in a program icon,  we may mention it way down on the page.  The more important changes are near the top, just below the remarks on the major release change.  They are more-or-less in descending order by date.  The exceptions would be when we have made a minor change to an item that was recently mentioned.  In that situation, we may choose to add another sentence and a newer date, and leave the rest of the paragraph in its original place.  If you are using an older version of the Datahub SDK, you may want to look at our online version of the Recent Changes document to see if its time to download a newer version.
 

  About Us                   Contact Us                 News and Views             Integrators                Documentation                Support 

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