Specification of REST API Services for Modbus Protocol using Formal technique EAI Endorsed Transactions on Cloud Systems Research Article

With the advancements in technologies, there has been a growing trend to move from desktop applications towards web and mobile applications. This move was made possible through introduction of the RESTful Web Services. The benefits of such a move include minimal installation costs, automated upgrading for all users, and increased interactivity and universal access. Modbus is a serial communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Simple and robust, it has since become a de facto standard communication protocol, and it is now a commonly available means of connecting industrial electronic devices. This paper, demonstrates the advantages of providing RESTful interface to modbus protocol. We have used formal SDL (Specification and Description Language) to specify this framework and study their performance evaluation.


Introduction
Representational State Transfer (REST) has gained widespread acceptance across the Web as a simpler alternative to SOAP and Web Services Description Language (WSDL) based Web services.Key evidence of this shift in interface design is the adoption of REST by mainstream Web 2.0 service providers including Yahoo, Google, and Facebook, who have passed on SOAP and WSDL-based interfaces in favor of an easier-to-use, resource-oriented model to expose their services.
Statelessness is the key of REST.Necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body or headers.The URI uniquely identifies the resource and body contains the state of that resource.Then after the server does it's processing, the appropriate state, or the piece of state that matter are communicated back to the client via headers, status and response body.REST is any interface between systems using HTTP to obtain data and generate operations on those data in all possible formats, such as XML and JSON.This is an increasingly popular alternative to other standard data exchange protocols such as SOAP (Simple Object Access Protocol), which have a high capacity but are also very complex.Sometimes it's preferable to use a simpler dataprocessing solution such as REST.

RESTFUL SERVICES
REST defines a set of architectural principles by which one can design Web services that focus on a system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.If measured by the number of Web services that use it, REST has emerged in the last few years alone as a predominant Web service design model.In fact, REST has had such a large impact on the Web that it has mostly displaced SOAP and WSDL based interface design because it's a considerably simpler style to use.A concrete implementation of REST Web service follows four basic design principles: 1. Use HTTP methods explicitly.
4. Transfer XML, JavaScript Object Notation (JSON), or both.In this work, we propose a framework for the formal specification of REST API Services for Modbus Protocol using SDL based system.The purpose of this framework is to provide a formal basis for their performance evaluation and behavioral study.The rest of the paper is organized as follows.Section 4. illustrates specification design of RESTAPI Services for Modbus Protocol using formal SDL language.Section 5 describes of verification and validation of the protocol to rule out design errors.Section 5 illustrates experimental simulations with results and Section 6. provides our conclusion.

Modbus protocol
Modbus protocol is an application layer messaging protocol at Level 7 of the OSI Model that provides client/server communication between devices connected on different types of buses or networks.The Modbus messaging structure was developed by Modicon in 1979.Different versions of Modbus used today include Modbus RTU (based on serial communication like RS485 and RS232), Modbus ASCII and Modbus TCP, which is the Modbus RTU protocol embedded into TCP packets.

Specification of the framework using formal language SDL
Specification using formal SDL (Specification and Description Language) to specify this framework and study their performance evaluation was proposed.Figure 9 and 11 shows modbus request and response channels respectively which acts as channel for sending and receiving modbus request and response.Figure 10 shows Modbus Slave process which waits and listens for modbus request from the Modbus master (RESTServerAndModbusMaster).On receiving a request, it sends back a modbus response.

5.Verification and Validation
The design of the framework must ensure its ability to operate under increasing load, increasing complexity of requests and increasing size of resulting composite services.Hence verification and validation is done to check for correctness of protocol specification and check the protocol for liveness property and safety properties.Protocol validation can be used to increase the quality of protocol design by verifying the system against the requirement.
Validation ensures that the protocol specifications will not get into protocol design errors.(Deadlock, unspecified reception etc).The message sequence chart in figure 13, shows interaction between entities and complete service discovery process.
Safety Property: 1. Ensures non-violation of assertions.2. System ensures that proper data is send from "RestClient" and "RESTServerAndModbusMaster", although it may get lost in the channel Liveness Property: 1. Ensures proper termination of protocol.
2. Even if the data send from RestClient" / "RESTServerAndModbusMaster" gets lost in the channel,it is ensured that the protocol terminates correctly.
Validation 1. From the message chart diagram, it is seen that the proper response is obtained for valid requests.Jayasankar.M and Anandi Giridharan Specification of REST API Services for Modbus Protocol using Formal technique 2. It is also ensured that incase of lossy channel/data loss,the system does not go to a deadlock.3. The timers in the "RestClient" and "RESTServerAndModbusMaster" ensures that if the response is not obtained within a timelimit,an error response is generated and the system again is ready to accept new requests.
Figure 13 : MSC chart generated using SDL The Message Sequence chart generated for the system for normal flow is shown in figure 13. 1.The RestClient sends a http request "restreq" through http request channel once the user initiates it.2. The http request is converted to modbus request "mbreq" by the server and send to the modbus slave through modbus channel.3. On receiving a modbus request, the modbus slave sends back the modbus response "mbresp" to the server.4. The server processes the modbus response and generates the http response "restresp" which is send back to the rest client through http channel

5.Implementation
Following tools were used for implementation of the system

Slave Simulator
A slave simulator is used for simulating a device which has modbus capability.Basically it listens for modbus requests and responds based on the modbus command received."Diagslave", a freely available slave simulator for modbus was used for the project, is shown in figure 14.

RestServer
This is required for performing REST operations, and to obtain the appropriate "REST" response when a query was given by user."EVE", a freely available python library was used to perform necessary REST related operations and to generate appropriate REST response.Figure15 shows documentation of Eve framework.
Figure 15 -Eve python ReST API framework

Rest Client
A Rest Client is required for the user to send "REST" query to rest server."POSTMAN" extension of chrome was used in the project to act as RestClient.Figure16 shows UI interface of POSTMAN tool.
Figure 16: Postman extension for chrome

Modbus Master
A modbus master is required to send modbus command to the slave simulator and obtain the modbus response."Pymodbus" a freely available python library for modbus was used in the project.Figure 17   Using "Eve" Rest framework,the rest services for the Modbus function codes "Read holding registers" and "Write holding registers" were implemented.This can be extended to other function codes as well.2.User can send modbus requests(function codes) by embedding the required data in the request made to the server.On receiving the request,the eve server processes the request and using the "pymodbus" makes a modbus request to the slave simulator and receives back the modbus response.
3.The Modbus response thus obtained can be send back to the user by embedding it in the response data as a response to a rest request.

6.Conclusion
Formal SDL (Specification and Description Language) to specify framework and study their performance evaluation was used.Any web/mobile application which requires interaction with devices can directly call the REST API for modbus and communicate with device.

Figure 1
Figure 1 and 2 shows the package RMB and the system RESTMB.The package RMB contains declarations of all the signals used in the system RESTMB

Figure 3
Figure3shows the possible communication losses that can happen in the system.There are 2 types of losses that can happen viz.http request/response losses and Modbus request/response losses.

Figure
Figure 17:Pymodbus module 1.Using "Eve" Rest framework,the rest services for the Modbus function codes "Read holding registers" and "Write holding registers" were implemented.This can be extended to other function codes as well.2.User can send modbus requests(function codes) by embedding the required data in the request made to the server.On receiving the request,the eve server processes the request and using the "pymodbus" makes a modbus request to the slave simulator and receives back the modbus response.3.The Modbus response thus obtained can be send back to the user by embedding it in the response data as a response to a rest request.