Real-time performance Web Services using EXI Francois Jammes*, Antoine Mensch†, Harm Smit† *Schneider Electric – Strategy & Innovation – Grenoble, France E-mail:
[email protected] †Odonata – Paris, France E-mail: {antoine.mensch, harm.smit}@odonata.fr Abstract – Using Web Services at device level is known to be a low-performance solution, due to the XML verbosity and the required resources to parse XML frames. Implementing EXI (Efficient XML Interchange), a standard binary XML format, is a promising solution to overcome this issue. In this paper, we present a complete EXI implementation in an industrial device and its measured performance, demonstrating that EXI promises are fulfilled.
INTRODUCTION Using Web Services at device level has gained momentum in the last years, thanks for example to the SOCRADES [1] collaborative research project, using the Devices Profile for Web Services (DPWS) protocols [2], standardized by OASIS [3]. Thus, real service-oriented industrial I/O devices have been implemented, using an open source DPWS C stack [4], and have been demonstrated in electronic assembly manufacturing lines. However, Web Services cannot compete from a real-time performance point of view with traditional fieldbus solutions, and this perception is refraining user adoption of the proposed solution, even in relatively low performance demanding applications. Moreover, in process control applications, real-time requirements are very demanding and cannot be met with standard Web Services solutions [5]. The FP7 IMC-AESOP project [6] is addressing these real-time requirements, investigating the use of innovative real-time Web Services, enabled by binary encoding of XML. Amongst several approaches for "Binary XML", it is anticipated that W3C's Efficient XML Interchange (EXI) [7] provides the most efficient solution. Indeed, performance improvements by a factor of 10 are expected to be achievable. This paper presents a full implementation of EXI in an industrial device together with its measured performance characteristics. PERFORMANCE REQUIREMENTS Several projects have explored the use of Service-Oriented Architecture (SOA) for industrial solutions in manufacturing industries, such as the SOCRADES project [1]. However, there exist specific challenging requirements coming with large-scale distributed systems for batch and continuous process applications, which have not been addressed till now, e.g., how deep into the system can we go with SOA-based monitoring and control solutions (including cost, real-time and security issues)? The AESOP project [6] has been set up to address these specific requirements. One of its objectives is “real-time SOA”: determine the real-time issues and the
limits of bringing SOA inside high-performance process control loops. THE EXI STANDARD
Web Services messages, including DPWS messages, are usually encoded using text-based XML and transferred using the SOAP protocol. This implies: - Long frame size, even for a simple message exchange. A frame size in excess of 1 Kbytes may be required to exchange only a few bytes of information (the exact length depending on the context). - Substantial amount of resources (CPU and memory) required to encode / decode SOAP/XML frames. There exist many Binary XML solutions, targeting different types of applications. Several studies comparing various Binary XML technologies have been published, such as [8], concluding that EXI (in schema-informed mode) is the most promising Binary XML solution, both from a frame-size and a performance point of view. In order to confirm the feasibility, footprint and real-time performance of this approach, we implemented EXI in real industrial embedded devices, and measured its characteristics, which we present in this paper. EXI PROCESSOR IMPLEMENTATION A. Issues in embedded XML processing The characteristics of XML raise some issues when used in embedded systems: 1) Verbosity: messages are generally much larger than their useful payload, thus making them unsuitable to constrained communications networks, such as lowpower wireless networks. 2) CPU-intensive character processing: XML processing requires a large amount of string comparisons to process the document structure and of string conversions to process the document content data, especially when the data is typed. 3) Significant code and RAM footprint requirements: fully compliant XML processors are often not very compact, due to the richness and extensibility of the XML format they must support. In addition, while XML processing benefits from good tools and standardized API support on mainstream platforms, such as Java and .NET, this support is not as good on embedded platforms using the C or C++ languages: the available libraries are not standardized, not always userfriendly and often not designed for embeddability.
Overall, an embedded XML processoor implementation faces two main challenges: 1) Reduce the size of XML messages and increase the processor performance, while keeeping down the processor code and RAM footprint requirements. 2) Improve the usability of the XML proccessor. Our implementation consists of a set of XML processors and tools developed in the ANSI C languagge. It addresses the above issues in two ways: 1) By supporting EXI as an alternative reepresentation of the XML Infoset [9], in order to both reduce r the size of messages and speed up their processingg; 2) By providing convenient APIs to access the XML Infoset, including a streaming API and a an XML data binding mechanism. The main features of our implementattion are discussed below. EX representations B. Simultaneous support for XML and EXI Compared to other standard binary serrialization formats, such as ASN.1 [10] or XDR [11], one major m advantage of EXI is its total compatibility with the XM ML Infoset, which means that any XML document can be indifferently represented in the standard text-based forrmat or in the EXI binary format without loss of information. In order to allow applications to fullyy benefit from this compatibility, and easily switch from onee representation to the other without code changes, a single streaming API is provided for parsing and serializing XML documents, independently of their wire representation. This API exposes the XML Infoset as a set of events reprresenting both the structure (elements, attributes) and thee content of the document. Unlike most standard streamiing APIs (e.g. the Java SAX or StAX APIs), which are exclusively text-based, the API also supports direct handling of tyyped data, in order to let applications benefit from more effficient conversions when the underlying representation is already typed. C. XML data binding The streaming API is completed by an XML X data binding mechanism, which supports direct converrsion of the XML Infoset to and from native data structures (C C structs). The two approaches are complementary, as theey have different advantages and drawbacks. The streaming API allows applications to t process XML or EXI documents on the fly, and thereforee may be used to process large documents when available RA AM is limited, as it does not require the complete document too be constructed in memory. However, it can be complexx to use, as the applications are entirely responsible for maaintaining the state and metadata information required to proceess the documents. The XML data binding, in contrast, constructs an inmemory representation of the XML or EX XI documents. It is therefore only applicable to documents thaat are small enough to fit in memory, which is however thhe case for most messages used for XML-based exchanges in embedded systems.
When metadata (i.e. XML Schema [12]) is available at design time, the XML data binding mechanism can use generated code to transform thee XML document to and from custom generated C structs, whhich can be nested to represent the complete document. This approach is both relatively memory-efficient (the total size of the instances of the generated C structs is usuaally smaller than the text representation of the correesponding document), and convenient, as document hanndling is performed through direct, typed data access. When no metadata is availabble, a generic document object model (DOM) is used instead to build the in-memory representation. Compared to thee XML data binding approach, the DOM has two main drawbaccks: 1) It is much less memory effficient: DOM documents can be several times larger thann their text representations, 2) It is less convenient to navvigate: elements and attributes must be accessed through a name lookup, and all content data is represented as charaacter strings. Nevertheless, the DOM approach remains useful to handle metadata for managing XML extensibility: unknown XML elements and attributes matchiing schema wildcards can be mapped to DOM nodes, while known k elements and attributes can use the more efficient XML L data binding. D. Architecture Fig. 1 shows how our impllementation depends on code generation for producing comppiled schema information used by both the EXI processor and the XML data binding mechanism. For a given XML Schema, the code generator takes as input the schema document (X XSD), and produces (i) a C header file containing the gennerated C structs used by the XML data binding and (ii) a C file containing tables representing the compiled scchema information. Multiple schemas are supported througgh the use of the standard schema import mechanisms. In principle, the XML data binding b mechanism should be layered on top of the streaaming API. However, early experiments have shown that thhe overhead of maintaining and synchronizing state informationn related to the traversal of the schema information in both thee EXI and XML data binding modules was detrimental to the overall performance.
Fig. 1: Architecture of embeddded XML and EXI processors
Therefore, an optimized version in which schema state information is shared between both modules has been developed and used for the benchmark. EXI FEATURES IMPACTING PERFORMANCE The EXI specification introduces features that are generally not needed in embedded systems and that impact the performance and footprint of a conformant implementation. This section identifies these features and proposes mechanisms to reduce their impact on the implementation. Since any embedded implementation is likely to encounter the same issues, the proposed restrictions could form the basis for a future standard EXI “embedded profile”. A. Standard EXI datatypes encoding EXI defines a set of standard simple datatypes, used to encode the typed content data of an XML document. The definition of some of these types shows that the EXI design has been strongly oriented to favor the string representation of basic datatypes, which may lead to better performance and compactness when using a text-based API, but is not necessarily a good choice for embedded systems, which rely on native data representation: 1) Float: floating-point decimals are encoded using a decimal mantissa and exponent, rather than the more common binary mantissa and exponent, used for instance by the IEEE 754 standard. This ensures faster conversion to and from the string representation of the float, but requires a more complex conversion to and from its native (usually binary) representation. 2) QName values: XML qualified names (QNames) appearing in content data are encoded using their prefixed representation, which requires the resourceconsuming namespace prefix management option (described below) to be activated to produce meaningful information. 3) Fixed-point decimal: fixed-point decimals are encoded as two integers, representing respectively the integral and fractional part of the decimal. In order to preserve the leading zeroes of the fractional part, it is reversed before being encoded (e.g., the fractional part of “1.0003” is encoded as “3000”). The string representation of the decimal thus becomes a required pivot format in the EXI encoding or decoding process. 4) Time-related types: a similar issue exists for time-related types, as fractional seconds are encoded as integers using the same reversal “trick”. EXI provides an extensibility mechanism that allows new datatypes to be defined. Our implementation currently uses this possibility to introduce two new datatypes: 1) IEEE float and double: the standard IEEE 754 representation can be used in EXI streams for float (32bit) and double (64-bit) values. 2) Expanded QName value: when the prefix management option is turned off, QName values are encoded in expanded form as a pair of strings (URI, local name).
B. Fidelity options In order to ensure loss-less conversions of XML documents to and from the EXI format, EXI introduces several fidelity options: 1) Lexical fidelity: this option forces all content data to be encoded as strings (i.e. as they appear in the XML document), regardless of their type. It requires expensive conversion code for translating between the native data representation and its string representation to be embedded and executed at run-time. 2) Namespace prefix management: namespace prefixes appearing in an XML document are normally not used internally by EXI. However, they need to be preserved in the EXI stream in two cases: (i) when transforming an EXI stream in XML, to avoid the use of generic prefixes (ns1, ns2…); (ii) when using QName values, as their standard EXI representation relies on the prefixed form of the QName. Namespace prefix management impacts processing efficiency, code footprint and RAM usage. 3) Extended XML Infoset: EXI defines additional features, which are seldom needed in embedded systems. These features include support for XML comments, processing instructions, DTD declarations and entity references, as well as for XML fragments and self-contained elements. Our implementation provides compilation options to selectively remove support for the above fidelity options. In addition, it provides its own QName value encoding format, which allows QName values to be meaningfully encoded when the prefix management option is turned off. C. Schema-less documents and deviations EXI introduces built-in grammars that are used to dynamically capture the knowledge of the document structure when it is not provided by a schema. This dynamic process has a significant impact on processing efficiency and RAM usage. Built-in grammars are used: (i) in schema-less mode; (ii) when a deviation from the schema occurs; and (iii) when a schema wildcard is matched by an unknown element. In order to avoid using built-in grammars, an application must ensure that none of the above conditions is met, by: 1) Only using schema-informed mode; 2) Disabling the support for deviations by using the “strict” EXI option; 3) Ensuring that elements matching schema wildcards correspond to known elements only. In such cases, our implementation provides compilation options to completely remove the built-in grammar management code. D. String tables String tables are used in EXI to avoid repeating the same string several times in the EXI stream, by replacing a string already encountered by its index in a table. The use of these tables has an impact on both CPU and RAM usage. EXI provides options to directly or indirectly control the use of the string tables:
1) URI and local element name tables: EXI specifies how these tables are pre-populated when using the schemainformed mode. In this mode, as long as no deviations occur and schema-less elements are not used, these tables can be statically created and will not be modified at runtime. 2) Namespace prefixes: These tables are only used when the namespace prefix management option is turned on. 3) String values: EXI provides options to control both the maximum number of entries in the table and the maximum length of strings stored in the table. By setting either of these options to zero, the use of string tables is turned off. Our implementation provides compilation options to remove string table management code, when EXI options in use ensure that they will not be needed. BENCHMARK OBJECTIVES AND DESCRIPTION The EXI specification has been derived from a set of existing binary XML formats that have been compared through concrete measurements performed on a representative set of documents. Based on the results, the “Efficient XML” format has been selected as the basis of EXI. The measurements report [13] provides precise information regarding the compression gains achieved by the various candidates, as well as their performance gains. However, the latter information is highly dependent on the tested implementation, its implementation language and the reference XML parser implementation used as comparison baseline. In addition, no information is provided in the measurements document regarding code and memory footprint requirements. The goal of this study is thus to assess the following characteristics of our EXI implementation, in order to validate its possible use as an alternative to text XML in embedded devices: 1) EXI compression ratio for a variety of messages. 2) Code footprint. 3) Performance gains: the performance improvements obtained by the EXI implementation, compared to the performance of the gSOAP [14] implementation (version 2.7.14), a C-based XML parser and serializer known for its efficiency. Because gSOAP uses an XML data binding approach, the benchmark tests are focused on this mechanism, rather than on the streaming API. 4) Memory footprint: the amount of RAM required for processing an EXI document. Several test cases have been selected, which are representative of the types of messages that can be exchanged in embedded systems: 1) WS-Discovery [15] messages, standalone or embedded in a SOAP 1.2 envelope: this use case demonstrates the processing of simple metadata information, used in DPWS. The selected message is a ProbeMatches
message, containing two ProbeMatch elements. The message mostly contains atomic and list of string and QName values. 2) Real-time data messages: this use case demonstrates the processing of data-oriented messages. The selected message is an OPC-UA [16] ReadResponse message, containing values of different types (unsigned short, float and double), as well as associated information such as timestamps or status code. 3) XML Schema documents: this use case demonstrates the processing of complex metadata information. It is characterized by the high complexity of the XML Schema used to generate the EXI grammar information and XML data binding structures. Indeed, this schema is so complex that it is not supported by gSOAP. For all test cases, the test was performed by executing several times a loop in which an EXI document is converted into a C object and this object converted back to an EXI document, both conversions being performed using the XML data binding. The test execution times are compared to those of a similar loop based on the gSOAP XML data binding mechanism. One-time initialization and cleanup is performed outside the loops, however the measurements take into account initialization and cleanup that are required for each individual document processing. The input and output documents are stored in memory, to remove the overhead of file system access from the measurements. As the test cases focus on estimating the maximum performance that can be achieved using EXI, all tests have been performed using EXI and compilation options favoring high performance and low memory footprint: (i) “Strict” mode is turned on; (ii) use of built-in EXI grammars is disabled; (iii) use of string tables is disabled; (iv) namespace prefix support is disabled; (v) extended value encoding (IEEE float, QName values) is enabled, in order to avoid expensive string conversion and namespace resolution functions. These tests should be completed in the future to more precisely assess the impact of the various EXI options that have been disabled to produce the reported results. The tests have been executed on two different platforms: 1) A PC running Windows XP, with an Intel Core Duo processor T2500 (2 MBytes Cache, 2.00 GHz, 667 MHz FSB) and 2 GBytes of RAM. The C compiler used for this platform is MinGW GCC 4.5.0. 2) A development board with a Freescale Coldfire MCF5208CVM166 32-bit microprocessor (166 MHz, 16 kBytes internal RAM, 1 MByte external RAM), using the Quadros RTOS. The compiler used for this platform is CodeWarrior 6.4. The code footprint has been measured on object code generated by GCC 4.2.2 for the ARM9 processor. The measured values are similar to those obtained for the Coldfire platform with the CodeWarrior compiler (the ARM9-GCC platform was used because it produces linker maps easier to analyze). All dead code elimination options were used to minimize the resulting object code.
MEASUREMENTS
A. Message compression Table 1 shows the size of the various messages used in the benchmark, for the EXI and the text representation. Compression ratios are highly dependent on the type of the document, and on the EXI options used to encode the documents.
Config.
TABLE 1 Text XML and EXI message sizes (in bytes) Message Text size EXI size Compression ratio
Discovery
ProbeMatches
1091
264
4.1
SOAP1.2 + Discovery
SOAP envelope + 1408 ProbeMatches
445
3.2 18.3
Real-time data ReadResponse
1244
68
XML Schema
Discovery
9489
4319
2.2
XML Schema* Discovery
9489
1159
8.2
* With string tables activated
The first two documents are mildly structured and contain mostly strings and QNames (represented in their expanded form), which are not significantly compressed in the EXI streams. Activating string tables would not significantly change the results, as there is little redundancy in the content data of the documents. The third document is highly structured and contains typed information, which can be encoded more efficiently than character data. EXI yields the best compression ratio for this type of documents, which are the most representative of messages used in real-time exchanges. The fourth document is also highly structured and contains mostly strings and (expanded) QNames. In this particular case, activating the string tables has a big impact on the compression ratio, due to the fact that the target namespace of the XML Schema appears in most expanded QNames and is repeated many times in the EXI stream. B. Code footprint Measured code footprint consists of: 1) The library footprint, which depends on the code compilation options. 2) The generated code footprint, which depends on the XML Schemas used.
Config.
TABLE 2 Code footprint in kBytes (ARM9 – GCC compiler) Generated EXI (full) EXI (small) gSOAP EXI gSOAP
Lib
Total
Lib
Total
Lib
Total
Discovery
4.5 26.2
123.4
127.9
50.7
55.2
81.6
107.8
SOAP1.2 + Discovery
6.5 36.2
123.4
129.9
50.7
57.2
81.6
117.8
R-T data
84.6 429.3
123.4
208.0
50.7
135.3
108.7
538.0
XML Schema 14.6 N/A*
123.4
138.0
50.7
65.3
N/A*
N/A*
* The XML Schema test case is not supported by gSOAP
Table 2 shows the code size in kBytes for the test configurations used in the benchmark. The footprint of our
EXI implementation is provided for two different versions: (i) the full version, compiled with all EXI features; and (ii) a smaller one, compiled with the minimal set of features used to run the benchmark. The library sizes include the object code for both the specific library (EXI or gSOAP) and the functions of the standard C library used by the library. The latter represent a significant fraction of the code for gSOAP and the EXI (full) libraries, ranging from 35 to 60 kBytes. The majority of the standard library code used consists of string formatting functions (sprintf and sscanf) used in conversions. The EXI (small) library has almost no dependencies on the standard library, which explains its much smaller size. In the case of EXI (small), value encoding and decoding functions represent about half the object code. By selectively removing support for some datatypes (e.g. decimal or QNames), or improving the native mapping of others (e.g. date and time-related values, which are currently converted to strings), an additional 8 to 12 kBytes could be saved. The table also shows that our code generation approach, based on generated tables rather than functions, is on average 5-6 times smaller than the gSOAP code generation. Overall, the EXI (small) implementation has a code footprint about half the size of that of gSOAP for small schemas, and an even bigger advantage for increased schema size and complexity. C. Execution times Table 3 shows the measurements on the PC, for 100 000 iterations of the EXI and gSOAP test drivers. Table 4 shows the measurements on the Coldfire development board, for 1 000 iterations of each test driver and a subset of the test cases. The tables show that EXI brings performance improvements when compared to gSOAP, especially in the Real-time data test case, although the gains are not as significant as claimed in the EXI measurements document [12], and are relatively small compared to the compression gains. TABLE 3 Execution times on PC (100 000 iterations) gSOAP EXI
Config.
Milliseconds
Milliseconds
Ratio
Discovery
7 250
2 640
2.75
SOAP1.2 + Discovery
10 578
4 250
2.49
Real-time data
10 218
2 421
4.22
XML Schema
N/A
38 984
N/A
Config. Discovery
TABLE 4 Execution times on the Coldfire board (1 000 iterations) gSOAP EXI Milliseconds
Milliseconds
Ratio
5 217
2 244
2.32
Real-time data N/A* 2 485 N/A* * Some C datatypes used by gSOAP in the Real-time data test case are not supported on the Coldfire board
Reasons for these limited gains include: 1) The use of gSOAP as reference for text XML: gSOAP is widely recognized as one of the fastest XML processors available, especially when data binding is used. The high level of performance in gSOAP is obtained through heavy use of code generation techniques, but also through “shortcuts” affecting its conformance (as exemplified by the fact that gSOAP does not support XML documents with complex schemas). For the WSDiscovery test cases, gSOAP also benefits from the fact that it maps lists of QNames and lists of URIs to plain strings (i.e. no conversion from the XML representation), whilst the EXI binding transforms the data into typed arrays. In the gSOAP implementation, execution would be significantly slowed down by such conversions. 2) The inclusion in the execution times of both XML processing and XML data binding: as the latter is similar in the EXI and gSOAP implementations and induces the same overhead, the relative advantage of EXI for XML processing appears to be smaller than it is in reality. However, the measured execution times are representative of the improvement that can be expected by an application when switching to EXI, as XML data binding is required in both cases. 3) The focus of our implementation so far on the performance of the EXI structural encoding: more work is required to optimize EXI value encoding and decoding, in particular the handling of strings (and QNames), which are heavily used in all test cases, except the Real-time data one. Depending on the test cases, value processing currently represents between 60% and 80% of the total execution time. 4) The inherent complexity of EXI: despite its claims for simplicity, EXI requires a significant amount of state to be maintained, which impacts performance.
improvement is not yet fully obtained. We intend to address this through further optimizations in the value encoding algorithms. - The usefulness of an “embedded profile” for EXI, especially when targeting highly constrained devices, such as wireless sensors. However, for wireless solutions, energy consumption is a very important aspect, which has not been evaluated through the present work, but which is highly correlated to the size of the transmitted frame, thus expecting similar improvements. Future work will include the full delivery of a low footprint and modular DPWS C stack, optionally including an EXI module, embeddable in industrial devices with Ethernet and wireless communication solutions, benchmarking the power consumption in wireless modes, and looking at how to configure and start the system while keeping the full DPWS customer values, such as plug-and-play, possibly using a negotiation phase using full standard XML exchanges prior to switching to the EXI run-time communication phase.
D. RAM usage RAM usage in all test cases has not been precisely evaluated. However, some qualitative assessment of the RAM usage has been made for the Discovery test case. With the EXI implementation, this test case can be executed in less than 4 kBytes of RAM, taking into account the process stack size, the input and output data buffers, the EXI context data used internally by the processor and the user data used to store the converted C structs. With gSOAP, the same test case requires a minimum of about 10 kBytes of RAM.
[6]
CONCLUSION AND FUTURE WORK
[12]
Our work clearly shows that EXI delivers on the promise of taking XML to environments where it could not go before, including for real-time communications and control. More specifically, we demonstrated: - The feasibility of a complete EXI implementation in a real industrial device, within constrained resources. - The higher performance achieved through this implementation, even if the expected performance
ACKNOWLEDGMENT The authors would like to thank the European Commission, which, through its funding of the IMC-AESOP project, provided the means to investigate the subject of this paper. REFERENCES [1] [2]
[3] [4] [5]
[7] [8]
[9] [10] [11]
[13] [14] [15] [16]
IST SOCRADES project website. Available at http://www.socrades.eu/ F. Jammes, A. Mensch, H. Smit, “Service-oriented device communications using the devices profile for web services,” in Proceedings of the 3rd international workshop on Middleware for pervasive and ad-hoc computing. ACM, 2005, p. 8. D. Driscoll, A. Mensch, “Devices Profile for Web Services Version 1.1”, OASIS standard, 1 July 2009. SOA4D open source forge. Available at https://forge.soa4d.org/ Stamatis Karnouskos, Armando Walter Colombo, Francois Jammes, Jerker Delsing, Thomas Bangemann, “Towards an Architecture for Service-Oriented Process Monitoring and Control” in IECON’10 – Annual Conference of the IEEE Industrial Electronics Society, 2010. FP7 IMC-AESOP project. Available at http://cordis.europa.eu/fetch?CALLER=PROJ_ICT&ACTION=D&C AT=PROJ&RCN=62737 J. Schneider, T. Kamiya, “Efficient XML Interchange (EXI) Format 1.0”, W3C Recommendation, 10 March 2011. Guido Moritz, Dirk Timmermann, Regina Stoll, Frank Golatowski “Encoding and Compression for the Devices Profile for Web Services” in AINA’10 – 24th Conference of the IEEE Industrial Electronics Society, 2010. J. Cowan, R. Tobin, “XML Information Set (Second Edition)”, W3C Recommendation, 4 February 2004. “ASN.1: Abstract Syntax Notation One”, ITU X.680, November 2008 M. Eisler, “XDR: External Data Representation Standard”, IETF RFC 4506, May 2006. H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, “XML Schema Part 1: Structures Second Edition”, W3C Recommendation, 28 October 2004. G. White, J. Kangasharju, D. Brutzman, S. Williams, “Efficient XML Interchange Measurements Note”, W3C Working Draft, 25 July 2007. gSOAP: SOAP C++ Web Services. Available at http://www.cs.fsu.edu/~engelen/soap.html V. Modi, D. Kemp, “Web Services Dynamic Discovery (WSDiscovery) Version 1.1”, OASIS Standard, 1 July 2009. “OPC UA Part 1 – Overview and Concepts 1.01”, OPC Foundation, 5 February 2009.
