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

5-6 Industrial Communication Systems
• Net real energy (TotWh)
The content of these data is defined by common data classes. As an example of the TotWh-data,
the common data class “binary counter reading” is assigned. It specifies that TotWh must include
the following mandatory data attributes:
• Actual value of the net real energy (name: actVal, type: INT128)
• Quality of the actVal (name: q, type: Quality)
• Time stamp for the actVal(name: t, type: TimeStamp)
Therewith the five properties described in the beginning of this chapter are fulfilled in the IEC 61850
as follows:
1. For a client-server communication the Ethernet, Internet Protocol (IP), Transmission Control Protocol
(TCP), and manufacturing message specification (MMS) are specified as layer 1–7 protocols [7,8].
2. In the MMS, several communication services are standardized. With the GetNameList-service a
server can retrieve the names of all interface variables from a client. Afterwards, it can retrieve the
data types for these variables by using the GetVarAccessAttributes service. With the read and the
write services, it can access the values of the interface variables.
3. The data types and the resolution of the interface variables are defined by standardized data
attributes.
4. The semantics of the applications are standardized by the logical nodes.
5. IEC 61850 does not consider the dynamic behavior of communication.
Therefore, we can say that the IEC 61850 standard enables an “interoperability” of devices.
5.3 achieving Interoperability
Looking at the examples in the previous sections, we see that the key to successful interoperability is
a proper standardization of all levels of functionality. By ensuring that components can cooperate on
physical and logical levels, a lot can be achieved. For simple applications like switching lights in an
office, the process of thoroughly describing the application in written form will suffice. For more complex
applications, it will most likely not be possible to describe every single detail. It may happen that
a written standard contains ambiguities that result in incompatibilities of components that have been
built by different manufacturers. The next step has to be to run tests for all components and test the
achieved level of interoperability. Only by examining the components during their operation, it is possible
to ensure that full interoperability is given.
Software interoperability for complex systems such as distributed automation systems is achieved by
following five approaches that depend on each other:
1. Product testing
Given decent clarity of the written standard, products can be produced to meet this standard
or a subprofile of it. System testing and unit testing can reveal incompatibilities, but do not suffice.
Conformance-based product testing ensures only conformance to a standard, but does not
always create interoperability with other products that have also been tested for conformance.
Differences in product implementations can only be detected in a production scenario; such a test
in a realistic environment can ensure interoperability.
2. Product engineering
Product engineering has the task to create implementations that meet a common standard (or a
subprofile of the standard). It has to achieve interoperability with other software implementations
that also follow the same standard (or a subprofile of the standard).
3. Industry/community partnership
Industry/community partnerships are the driving force toward standardization. They can be
organized nationally or internationally and create standardization workgroups. Such a workgroup
© 2011 by Taylor and Francis Group, LLC