The concept of the OPC server on the IGUANA gateway is similar to a proxy: Requests issued by OPC compliant clients are translated into ESD commands, while ESD responses are translated into OPC SOAP messages. Functionality which is not directly supported by ESD - such as subscriptions - has to be managed by the OPC server itself. This internal functionality will also retrieve data via ESD commands142.
Therefore the last step in the implementation was to translate OPC operations into ESD commands. At first, the line-based protocol itself had to be implemented. The basic architecture for implementing protocols in the Twisted framework is to separate the protocol from the server logic as depicted in figure 67.
When a client connects to the server, the ESD factory object creates an ESD protocol object which then handles the client/server communication. This communication object then calls functions from another object which implements the required functionality. This basic concept applies to an ESD client but also to an ESD server.
The ESD protocol was quite easy to implement. ESD requests are always sent as a single line and responses can either be single-line and in some cases also multi-line, therefore a very simple state machine had to be implemented.
The addressing scheme in OPC XML-DA and ESD has a different format, therefore a simple function was created that interpretes the ESD address syntax and formats it in an OPC XML-DA compliant style, as already shown in chapter 5.1.
For testing purposes, a simple ESD server was programmed which simulates the ESD functionality of an IGUANA gateway. Fieldbus nodes and datapoints can be configured in a simple XML configuration file which is read at startup. This server also simulates delays143 and implements all necessary ESD functionality, such as READ, WRITE, (E)NODEINFO, DPINFO and NODELIST.