wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Profiles and Interoperability 5-7
defines a standard (i.e., creates a written description) based upon the discussions and negotiations
in the workgroup. This standard is then used to build software systems, which meet the standard
and are thus able to communicate with other software systems following the same standard.
Standardization organizations cooperate by adopting existing standards from other organizations;
this reduces the workload, makes national standards internationally available, and reduces
the number of available options when selecting a standard. This again reduces costs for achieving
interoperability.
4. Common technology and Intellectual Property
Sometimes, it is better to use existing technology instead of creating a new system from scratch.
Additionally, the number of options can be reduced by using common technology or intellectual
property. Therefore, it is sometimes feasible to use third party technology instead of own
developments.
5. Standard implementation
A common agreement to implement a standard, may it be national or international, which opens
freely or is only accessible by paying a fee.
Each of these has an important role in reducing variability in intercommunication software and
enhancing a common understanding of the end goal to be achieved.
We shall finally take a look at the important factors characterizing interoperability testing. Two
components set the boundaries and are the core components for testing: the Equipment Under Test
(EUT) and the Qualified Equipment (QE). Ideally, both the EUT and QE are manufactured by different
suppliers; if this is not possible they shall be manufactured in different product lines. If this
is not the case, there is a chance that devices from the same supplier interoperate with each other,
but not with devices from other suppliers. The tests for interoperability have to be done from a user
perspective: they are done only at interfaces that are used for normal user control and observation;
furthermore, the interoperability tests can only be based on functionality that is accessible by a user
and only as experienced by a user (i.e., they are not specified at the protocol level). Note that in this
context a user need not be human, it can also be a software application. This is because the interoperability
tests are performed and evaluated at functional interfaces such as Man-Machine Interfaces,
Application Programming Interfaces and protocol service interfaces. The fact that interoperability
tests are performed at the end points and at functional interfaces means that interoperability test
cases can only specify functional behavior. They cannot explicitly create protocol error behavior or
test this error behavior.
References
1. D. Dietrich, D. Loy, and H.J. Schweinzer, editors. Open Control Networks LonWorks/EIA-709
Technology. Kluwer Academic Publishers, Norwell, MA, 2001.
2. LON Nutzer Organisation e.V. LonWorks Installation Handbook. VDE-Verlag, Berlin, Germany, 2005.
3. LonMark International. LonMark application-layer interoperability guidelines Version 3.4, 2005.
Available at http://www.lonmark.org/technical_resources/guidelines/developer
4. IEC 61850. Communication networks and systems in substations, IEC Standard, 14 parts,
Beuth-Verlag, Berlin, Wien, Zurich, 2002–2004.
5. IEC 61850. Part 7-420 DER logical nodes. Beuth-Verlag, Berlin, Wien, Zurich, 2008.
6. K.H. Schwarz. An introduction to IEC 61850. Basics and User-Oriented Project-Examples for the IEC
61850 Series for Substation Automation. Vogel Verlag, Würzburg, Germany, 2005.
7. ISO 9506. Industrial automation systems—Manufacturing message specification, 2 Parts,
Beuth-Verlag, Berlin, Wien, Zurich, 2003.
8. J.T. Sorenson and M.G. Jaatun. An Analysis of the Manufacturing Message Specification Protocol.
Springer, Berlin, Germany, 2008.
© 2011 by Taylor and Francis Group, LLC