Far from being a done deal, the ISA SP100 "Principles of Operation" document is, itself, in question. The following letter was sent to the ISA SP100 Community, in care of Pat Kinney and Dan Sexton, and signed by a whole bushel load of SP100 members. I especially point out section 3 (Interoperability) below: Dear Pat and Dan,We would like to share common comments, remarks and concerns about the Principle of Operation document (PoO) and other ISA ISA100 dynamics. This letter is being sent in addition to the any individual comments which you may receive as part of the formal comment period associated with the PoO.We hope these comments will further support our mutual goals of a quality wireless industrial standard. We also want to reaffirm our commitment to continued participation and support as part of ISA100 until a user supported, implementable standard can be achieved.

1 Overview of the PoO

1.1 Comment:

The PoO in its entirety does not convey a simple, clear and concise picture on how the ISA100.11a standard is envisioned to operate. Its 67 pages make it too long and too detailed in many areas to digest for users and technologists with minimal or no experience in the wireless communications technology. In spite of its size, it still leaves many operational aspects of the system unclear or totally unaddressed while driving into very deep and detailed technical information in other areas.

In addition, the ISA100.11a summary of goals misses some key topics. For example, it does not seem to address full system lifecycle issues such as device replacement, decommissioning, maintenance, etc. Furthermore, it seems that the document dives directly into diagrams connecting network devices without providing an overall framework for the users to start with.

As another example, the PoO does not adequately address how ISA100.11a will create and support reliable networks which is a crucial user and market requirement. From the user's perspective, it is vitally important that the system be reliable but the PoO does not offer enough detail to provide assurance that this goal can be successfully met. The PoO asserts that channel hopping and path diversity will cure all reliability problems without providing high level details on how this would actually occur. While we agree that channel hopping and path diversity are indeed the underpinnings for reliable networking, a proper detailed description on how this occurs is required to allay user concerns, and this area requires significantly more attention.

From the onset of this standards effort, the ISA100.11a participants agreed to create some early documents intended to capture valuable input long before starting to write the PoO and specification. These documents include the Technical Requirements Document (TRD), User Requirements Document, and very large set of specific Use Cases collected from a broad range of industries and applications. These documents form the foundation and serve as the key background documents needed to create a broadly accepted and useable standard.

In principle, the PoO should be a reflection of these background documents. In its present form, it is difficult to determine how specific requirements are addressed in the PoO. It is unclear how the PoO addresses user requirements, how various proposed low-level and highly detailed technical solutions map to addressing specific user needs and requirements, and in general does not appear to reference or acknowledge other applicable background documents.

It is also unknown how the PoO addresses user-supplied use cases and how the system can address these use cases in a manner that can be validated.

1.2 Proposed improvement:

1) Provide first much clearer and more user-focused overall summary before diving in details.

2) PoO should contain references to these background documents and vice versa where appropriate. Each document should be written in the detail level that is adequate for it, but should be consistent among the entire set of documents.

3) Condense some of the very detailed sections into clearer and more user-oriented summaries - the application, gateway, and security sections would likely benefit the most.

2 Fostering a Quality Standard

2.1 Comment:

There is a concern amongst many SP100 participants that this standardization effort is focused completely on speed to some sort of a standard and that this focus on speed over all else is leaving behind previously prepared materials such as the TRD, User Requirements, and Use Cases as specific examples. This material was diligently prepared, reviewed, and ratified by participants in this process for the purpose of helping to guide and eventually validate the standard. A formal effort to validate and audit the various steps is vital to ensuring that the standard meets the original goals. In addition, it is important to maintain these documents so that they reflect the actual requirements and direction of the standard as the effort evolves and changes; changes as part of the process are normal and do not reflect badly on the participants in this effort. Reasonably accommodating changes as they occur will likely reinforce the particpants collective knowledge, experience, and growth in the areas this standard is trying to address.As this standard effort first got underway, the scope of ISA100 seemed to increase at every meeting to cover more and more functionality without a corresponding update or adjustment to the resources or schedule needed to reach these. As a response to this expansion, earlier this year there was a serious effort to "prune" functionality from the standard in an effort to shorten the time to completion (primarily by deferring some features and capabilities to subsequent releases); however, recently numerous new items have been added (such as the incorporation of provisioning strategies, physical interfaces, and tools) without any sort of assessment as to the impact on the previously announced target dates which seems unrealistic.There is concern among users and vendors that the current focus is entirely on speed without taking to time to audit or otherwise verify that we are building on the previously agreed requirements or addressing important use cases which may compromise the quality or applicability of the resulting standard. As the ISA100.11a standard will likely only have one chance to "come out of the gate" with a relevant and useful standard, it is very important to focus on the quality of the standard and the meeting of user needs as it will be difficult to recover from a release that is perceived to fall short. Quality and completeness would appear to be much more important than speed as a less functional or less complete standard available quickly will likely meet with indifference; a high quality standard coming out when it is ready has the best chance for widespread support, adoption, deployment, and device availability. The relevant user community is certainly aware this effort is underway and keeping them up to date and demonstrating relevance to their needs and requirements will go further towards acceptance than simply releasing something quickly. It does not appear that anyone is advocating dragging the process out for longer than required and certainly some focus on progress must be enforced, but as with any activity, a realistic schedule needs to be created and maintained as the standards effort progresses and changes occur as the standard evolves. Without realistic schedules, the interest level from users and vendors to participate in the process will wane as it will become increasingly difficult to believe relevant progress is being made nor will they be able to accommodate the upcoming standard in their respective plans.

2.2 Proposed improvement:

As a proposed solution, we would like to suggest that a formal schedule containing milestones and tasks be developed and circulated to the ISA100 community. This schedule should include the effort needed to review, maintain, and audit against previously created materials such as the TRD, User Requirements, and similar earlier work products. In addition, this schedule should be maintained and updated to reflect changes in the standard as well as progress towards the end goals as appropriate to support users and vendors in their participation and as an aid to their planning processes.

The signers of this letter are committed to working with and continuing our participation of the ISA100 working group through completion of a meaningful high-quality standard.

3 Interoperability

3.1 Comment:

An important interoperability issue to the users and to the equipment vendor community is interoperation with WirelessHART devices. This is not addressed in the PoO. The goal is to make the ISA100 network a universal network that can support both WirelessHART devices and native ISA100 devices. This preserves the customer's wireless investments and it avoids them having to deploy competing and non-interoperable networks. This interoperability strategy simplifies and speeds up the deployment of wireless sensor networks by removing the risk of having to make a binary choice between adopting the WirelessHART standard and an ISA100.11a standard.

3.2 Proposed improvement:

To do this a section should be inserted into the PoO which describes in principle how ISA100.11a Release 1 will support WirelessHART devices. The PoO should state that interoperability between WirelessHART devices and ISA100.11a will be provided within the ISA100 network. ISA100.11a field routers have the capability to communicate to WirelessHART children and other ISA100.11a devices in a non-interfering fashion. The ISA field router will also tunnel WirelessHART messages between WirelessHART devices and a WirelessHART enabled gateway. This enables users to deploy both WirelessHART and ISA100.11a devices in one integrated network.

4 Use of an RFC4944-based Network Layer

4.1 Comment:

There are several issues regarding the use of RFC4944 (previously referred to as "6loWPAN") within the process industry market. User discussions plus general market feedback shows this to be a very contentious issue with potential deployers of this technology being strongly split for or against a heavily IP-centric network. This sort of contention needs to be resolved in some sort of agreeable manner to enable ISA100.11a to be a viable standard for the broadest possible user base.On the marketing side, there are ample indications that for every plant manager who does not want IT personnel to potentially share ownership of the control systems there is a plant manager who would welcome IP connectivity to his end devices. Similarly, there are IT departments from process industries that do not want to see potentially hundreds or thousands of IP devices appear on their network management console and likely an almost equal number for whom this would not be a problem. With the high degree of polarization this item brings to the standard, it is difficult to see how choosing one option or the other helps to create a viable standard without creating a significant market split.

It is clear that IP technology is being deployed as the communications fabric in a multiplicity of applications. However, the rate of adoption within specific segments (such as the industrial market and its many submarkets) and interest in specific technology-driven approaches such as RFC4944 vary dramatically from customer to customer even within the same marketplace. While it is the opinion of numerous experts in the networking field that some manner of IP convergence is almost certainly coming at some point in time, it may be far enough into the future that attempting to "force" or even "jump start" this type of technology adoption through the mandate of RFC4944 is too divisive for the current target user base. In light of this potential, it is certainly important to keep future options open for ISA100 to evolve and respond to market changes as they occur but it would be difficult for this standard to force these changes when such significant user resistance is already obvious.

4.2 Proposed improvement:

Based on the above observations, there are two recommended improvements:1) The PoO should recognize these different market views and acknowledge them by stating that multiple network layers may be supported by ISA100; at the present time, we would like to express our support for an SP100-specific mode, a WirelessHART compatible mode, and a RFC4944 compatible mode.2) ISA should organize forums where plant managers and IT personnel can discuss the issues associated with the use of IP-enabled sensors in the field to validate the different approaches to better understand the needs of users and deployers of this technology.

5 Summary

We offer our common concerns in the interest of making ISA100 a successful and substantial standard for the industrial marketplace and bring these comments in such a spirit. These comments reflect the areas where we were able to reach a consensus given the time available.It is our hope our concerns can be addressed in a reasonable period of time and certainly significantly prior to the ISA100.11a specification being released for comment.Brent Bailey Flow Products, LLC Sujit R. Das Eaton Corporation Mike Dow Freescale Albert FeinÃ¤ugle Balluff Peter Fuhr Apprion Stefan Gross Siemens Juergen Gutekunst Balluff JosÃ© Gutierrez Emerson Thomas Hartmann HARTING KGaA Christian Herzog STG Hesh Kagan Invensys Bernd KÃ¤rcher Festo Tomas Lennvall ABB Ryan Maley STG Ian McPherson Apprion Mike Medley Emerson Mark Nixon Emerson Axel PÃ¶schmann ifak Jeff Potter Emerson Israel Radomsky Eltav Wireless Monitoring Ltd. Uwe Schaefer Werner Turck GmbH & Co. KG Gerd Scholl Hochschule HH (University of Hamburg) Christian Seiler Endress+Hauser Process Solutions AG Paul Sereiko Aisprite Klaus SÃ¸nderskov Nielsen Danfoss A/S RenÃ© Struik Certicom Romeo Velarde AIN (advanced industrial networks) Christoph Weiler Siemens Ludwig Winkel Siemens