Improving system integration by

standardizing and automating the Modbus

protocol

David Ågren

Systems Sciences, bachelor's level

2020

Luleå University of Technology

Department of Computer Science, Electrical and Space Engineering

Author Note

This paper is written as the final thesis leading to a Bachelor's degree in System Sciences at Luleå University of Technology, 2020.

I would like to thank Per Olofsson at BnearIT in Luleå for the opportunity to conduct my work with their support and feedback. I would also like to thank my academic supervisor at Luleå University of Technology, Johan Wenngren for valuable feedback and suggestions regarding all parts of the dissertation. Having completed this bachelor’s degree in parallel with my normal job I must extend my deepest thanks to my current employer, Maxovent AB in Boden for allowing me exceptional flexibility in scheduling and planning my own projects. Most importantly, my wife, Cecilia. For putting up with me during these last three years, working during the day and studying during the night. You’re the best, I love you.

Abstract

Communicating devices are on the rise. Fueled by the introduction of Internet-of-Thing (IoT) and Industry 4.0, more and more devices are capable of information sharing. There is a long history of communicating devices in industrial and building management contexts that previously relied on fieldbuses. One of these legacy fieldbuses is the Modbus protocol, originating in serial communication and now adapted for use with Ethernet. It has significant adoption in the fields of industrial automation systems (IAS) and building management systems (BMS) but carries many limitations. Industrial systems often have a long lifespan and fundamental changes are not introduced quickly. This leads to a need for legacy communication protocols to be able to function alongside the new paradigms for the foreseeable future. In order to facilitate this phase, an attempt to improve system integration in the Modbus context is performed in this thesis. By utilizing standardization and automation principles, additional functionality and definitions are proposed to the Modbus protocol to help improve system integration. By using interviews with system integrators and document reviews of available Modbus description documents three iterative development processes are performed to answer the research questions. A proposed data model is presented, allowing for a standardized way to represent the contents of a Modbus register. Its attributes are clearly defined with descriptions and constraints. A new function code specification (0x47) is defined and presented in the same form as other function codes are described in the current Modbus specification. It allows for Modbus descriptors to be retrieved directly from the slave device. As a proof-of-concept the function code is developed in an existing Modbus implementation (Modbus4J). A client application is created to allow for fully functional demonstrations for a broader audience. The resulting communication is captured in Wireshark and presented as proof-of-concept.

Keywords: Modbus, Fieldbus, Legacy Protocol, Standardization, Automation, Industrial

Automation, Building Management Systems.

1. Introduction 1 1.1 Purpose 2 1.2 Research questions 2 1.3 Delimitations 3 1.4 Previous research 3

2. Theory 4 2.1 Industrial communication and fieldbuses 4 2.1 Modbus 5

2.1.1 Transport 6 2.1.2 Message structure 7 2.1.3 Limitations 8

2.2 System integration and standardization 9 2.3 Automation 9 2.5 Java and Modbus4J 10

3. Method 11 3.1 Research method 11 3.2 Data collection 12

3.2.1 Literature review 13 3.2.2 Interviews 15 3.2.3 Comparison 16 3.2.4 Personal experience 16

3.3 Artifacts 16 3.4 Reflections 18

4. Result and analysis 20 4.1 Data model 21

4.1.1 Requirement generation for the data model 21 4.1.2 Designing the data model 22 4.1.3 Artifact, presenting the data model 27 4.1.4 Evaluating the data model 28

4.2 Modbus master and slave 29 4.2.1 Requirement generation for the Modbus master and slave 29 4.2.2 Designing the Modbus master and slave 31 4.2.3 Artifact, presenting the Modbus master and slave 34 4.2.4 Evaluating the Modbus master and slave 38

4.3 Client application 40 4.3.1 Requirement generation for the client application 40 4.3.2 Designing the client application 42 4.3.3 Artifact, presenting the client application 47 4.3.4 Evaluating the client application 48

5. Discussion 50 5.1 Future research 51

6. References 53

Appendix A - Interview guide 57

Appendix B - Early draft 58

Appendix C - Compiled Modbus description table 59

Appendix D - Table of available formats 60

Appendix E - Evaluation interview guide 62

1

1. Introduction

Industrial Automation Systems (IAS) and Building Management Systems (BMS) provide control and supervision for buildings and industrial systems. In both contexts there is a long history of using communicating devices (Thomesse, 2005). From the most basic sensor to large enterprise-wide supervision and control systems (SCADA), all share the need to transfer data. Depending on the sender, recipient, and its intended use, the method used to transfer the data may differ. To facilitate this data transfer a communication channel is required, a physical interface, and a suitable communication protocol for the information exchange (Delsing, 2017). One of the most widespread and commonly supported in both IAS and BMS is the Modbus protocol (Jakaboczki & Adamko, 2015; Makhija & Subramanyan, 2003a). Modbus is most commonly used to transfer measured values, control signals, commands, indicators and alarms. This data can be transferred between systems to enable some enhanced or extended functionality. Usually this requires a systems integrator to configure and verify that the data is transferred correctly between systems. Often this operation is performed once, and only repeated if the requirements of the systems change. Additionally, the data transferred can be presented in a supervisory system where values are continuously monitored and manipulated, this is usually found in the industrial or manufacturing context. The person controlling and supervising the system is usually called a systems operator.

In order to interconnect various devices from different manufacturers, they need to be integrated with each other. This process differs greatly depending on the type of system and its capabilities. System integration is a broad subject that can be applied in all levels of computerized information systems (IS). In short it can be described as the process of interconnecting a number of subsystems to enable some extended functionality in a larger context. While there are many types of system integration, this thesis will mainly focus on data integration (DI) (Goodhue, Wybo, & Kirsch, 1992).

Following the increasing interest in Internet-of-Things (IoT) and Industry 4.0 (Åkerman, 2018; Weyer, Schmitt, Ohmer, & Gorecky, 2015), more communicating devices are being introduced into the IAS and BMS context. This furthers the need to improve system integration and the need for generally accepted ways to transfer the increasing amounts of data. (Delsing, 2017). Industrial products generally have long life cycles which often leads to a mix of old and new sub-devices within the same domain (Herterich, 2017). One option to ease the transition between new and old may be to adapt and improve legacy protocols, alternatively adopt or develop new types of solutions (Antonio José Calderón Godoy & Isaías González Pérez, 2018).

Many legacy fieldbus protocols specify a limited data packet without any or very limited description of what the data represents. As one of the most widely used data-only messaging

2

systems (Jakaboczki & Adamko, 2015; Makhija & Subramanyan, 2003), a typical Modbus register contains either 1- or 16-bits of data (Modbus Organization, 2012). No other information is available from the Modbus device, giving no hint on how to interpret the received data. It is not known what unit the register represents, how it should be scaled, or if it is part of a composite register. This requires the system integrator to acquire an external description of the Modbus registers elsewhere (Falk, 2019). Usually this is found on the manufacturer website, an email, a printed paper accompanying the device, or through some third-party medium. Often the register description is provided in non-machine-readable formats such as Adobe PDF. Regardless of the medium in which it is delivered, it is often unstructured as manufacturers have their own preferences in both file format and data structure. There is no universally accepted data model or data representation for describing a Modbus register (Makhija & Subramanyan, 2003b). This lack of common data representation makes any forms of automatic processing impossible without taking all possible presentations into account.

1.1 Purpose

The purpose of this study is to explore how system integration using Modbus can be improved by using standardization and automation.

By using standardization an attempt is made to establish which attributes that are required to properly describe a Modbus register in the fields of industrial and building management system context. The intention is to enable automatic conversions into different target systems and thus reducing the need for human input and manual processing.

The next step is to implement automation. A proof-of-concept artifact where the Modbus protocol is extended by developing additional functionality. The purpose of this functionality is to eliminate the need for outside searching for description documents that could be hard to find, have the wrong version, or simply be incorrect. By getting the description directly from the device by using a Modbus function code, it is attempted to reduce integration time, and the need for testing since the information should be considered more reliable.

1.2 Research questions

RQ1. How can system integration regarding Modbus be improved using standardization and automation?

RQ2. Standardization. Which attributes are needed to describe the contents of a Modbus register in order to propose a data model?

3

RQ3. Automation. How can an artifact be constructed to allow for the extraction of Modbus register descriptions directly from the Modbus device?

1.3 Delimitations While many of the research questions and results could be adapted to fit similar protocols or other communication contexts, this thesis focuses solely on the Modbus protocol. No attempt to generalize any specific results will be done. However the intention is that the results may be used as a basis for further research. The final artifact will be based on the TCP implementation of Modbus, as it is identified as the easiest way to demonstrate a proof-of-concept by capturing the produced request and response.

1.4 Previous research There is plenty of research surrounding Modbus as a consequence of its widespread use. Information security is the main branch of inquiry (Fachkha, 2019; Knapp & Langill, 2015; Al-Dalky, Abduljaleel, Salah, Otrok, & Al-Qutayri, 2014). The Modbus organization released a new security protocol extension enabling TLS encryption as recently as October 2018 (Modbus Organization, 2018). Other fields of study include the reliability of transfer, such as adding serial data integrity checks while retaining backward compatibility (Urrea, Morales, & Kern, 2016). Authentication and efficiency are also fields of interest (Pricop, Fattahi, Parashiv, Zamfir, & Ghayoula, 2017). One paper defines a Modbus description language using XML. It attempts to solve the same problem regarding standardization but by using a very different approach (Sanyal, New, Nutaro, Fugate, & Kuruganti, 2015). Very few papers ground their research in the perspective of the integrator. This is not surprising as the integration process is usually only relevant during installation or subsequent upgrades of the system. Nonetheless, the integration process is often a considerable expense during the installation or upgrading phases (Sanyal et al., 2015; Zhou & Nelson, 2011).

4

2. Theory 2.1 Industrial communication and fieldbuses Fieldbus systems have been used as far back as the 1970s first industrial networks with the aim of allowing for greater automation of processes, supervision and new functionality. There are a large variety of different fieldbus systems, both open and proprietary. In their inception, the use was often very specific, leading to many proprietary solutions. Usually they were created to solve a limited problem or use-case which in turn lead to their individual strengths and weaknesses. As the technology matured and its adoption increased, companies attempted to standardize their solutions (Thomesse, 2005). Their common denominator is the common goal of transferring information between systems.

“A network for connecting field devices such as sensors, actuators, field controllers such as PLCs, regulators, drive controllers, etc., and man-machine interfaces.” (Thomesse, 2005, p.1073)

Industrial and building management systems have entered a shift in paradigm. It is moving towards a more decentralized architecture with communicating devices capable of information sharing in ways not previously available. This change is driven by the introduction of Internet of Things (IoT) and Industry 4.0. The still established current state of art standard typically follows the hierarchically ISA-95 automation pyramid architecture which consists of layers 0-4 (Delsing, 2017).

Figure 1. ISA-95, automation pyramid. Based on Åkerman (2018, p.2).

5

Large research projects are being conducted investigating the possibilities to adapt to the changes in connectivity structure following decentralization. Since many systems are large and production critical changes cannot happen overnight and methods to integrate or convert legacy systems must be developed (Antonio José Calderón Godoy & Isaías González Pérez, 2018).

Much has happened in the last 20 years. Historically, various fieldbus protocols, both open and proprietary using serial communication such as RS-232 or RS-485 were used to interconnect and communicate between different devices. Over the years, computational resources have increased substantially, not only for computers which can be found in layer 2, but also for the controllers, PLCs, and embedded devices found in layers 0 and 1. While communication capabilities previously were limited to layer 2 and some devices in layer 1. Today many of the sensors in layer 0 that were previously passively measured by resistance, voltage, or current now have the computational capability to measure and communicate values, status, and other variables directly over an interconnected fieldbus. (Weyer et al., 2015)

Another big change in the use of communication protocols is the introduction of Ethernet and TCP/IP. Many of the previous fieldbuses that were used in serial communication lost their purpose and have no or limited use today, while others were developed and extended to make use of the new capabilities with Ethernet connectivity (Thomesse, 1998). One of these extended protocols is the Modbus protocol having gained the capability of ethernet communication with ModbusTCP while retaining the possibility to communicate with legacy devices over serial lines (Modbus Organization, 2006). 2.1 Modbus Modbus was first developed by Modicon for use with their PLCs in 1979. The rights to the protocol were transferred to the Modbus Organization in 2004 by Schneider-electric. The Modbus Organization (http://modbus.org) is an association of Modbus users and manufacturers that maintain all things related to the Modbus protocol. It is described in detail in the openly published Modbus specification (Modbus Organization, 2012). The Modbus specification begins by describing the general properties of the protocol, such as addressing, memory space, architecture, and structure. Following the more general description of the protocol, it continues to define all officially accepted function codes. In short, a function code is a well-defined template describing the structure of a request- and response message. They are described in enough detail to allow for implementations of both requests and responses in various devices. All function codes correspond to a unique number between 1 and 127. A range of these function codes are reserved as user-defined where functionality not accepted in the official specification can be implemented. Should the functionality later be accepted into the

6

specification, its function code would have to be changed and moved into the reserved function code range. All officially accepted functionality is described in the specification. Manufacturers do not need to support all function codes, only the functionality needed for the particular device may be implemented (Modbus Organization, 2012). The most commonly used data transfer function codes can be seen in Table 1.

Table 1. Modbus function codes. Name Function code Size Read / Write

Discrete input 2 1-bit Read-only

Coil 1 1-bit Read and write

Input register 4 16-bit Read-only

Holding register 3 16-bit Read and write

When integrating a Modbus device, two distinct types of information are needed. First the device-specific information. It is dependent on the type of transport, device settings, and physical conditions. The most common being Ethernet and serial implementations. This calls for information such as IP-address, port, baud rate, stop-bits, parity, timeouts, and more. Sometimes these are variable settings, other times they are hardware limitations. Once a connection is established to the device, the second type of information is needed. This is data specific information. How to access a specific type of data and once obtained, how to interpret that information. This requires function code, address, and how to interpret the raw data received.

2.1.1 Transport The OSI-model is a communication model developed by ISO (https://www.iso.org) for defining abstract layers describing everything from hardware link to application programs. The Modbus protocol resides in the seventh OSI-layer, the application layer, (H. Zimmermann, 1980) meaning that its definition is independent of hardware and underlying layers. The Modbus specification only defines the structure of the message in the form of request and response, making the protocol transport agnostic. This allows for use over both serial communication such as RS-232 and RS-485 and ModbusTCP (Dao-gang Peng, Hao Zhang, Li Yang, & Hui Li, Jul 2008). Some differences exist, serial communication has CRC checks to ensure the validity of the data whereas ModbusTCP relies on the redundancy checks of the TCP-protocol. It is also possible to send encapsulated Modbus over TCP data which does not strip the CRC check, this requires support from both master and slave.

7

Modbus follows a master and slave architecture. Serial implementations only have one master which controls the flow of information on the serial bus, meaning only one device sends requests. However it is common for devices to have several interfaces in order to enable multiple master and slave networks simultaneously, allowing for both vertical and horizontal integration, see Figure 2. ModbusTCP does not have the same limitations, but instead the TCP-stack sets any limitations regarding the number of concurrent connections. ModbusTCP may also refer to the nodes as server and client.

Figure 2. Modbus connection overview.

2.1.2 Message structure A Modbus message is divided into application data unit (ADU) and protocol data unit (PDU). The ADU which may differ depending on the transport. The PDU is the same regardless of transport.

8

Figure 3. Modbus message structure.

Three different PDUs exist, the request, response, and exceptions, all are well defined in the specification (Modbus Organization, 2012). Modbus primarily uses the four function codes as described in Table 1. File transfer and various diagnostics are also defined as a type of data transfer but are outside the scope of this study and not as frequently used. Generally a Modbus request contains a fixed number of data fields whereas the response often has a variable data size depending on the number of continuous registers in the request.

2.1.3 Limitations To ensure functionality regardless of transport, limitations on the size of a Modbus ADU needs to be set to accommodate even the most restrictive settings. The first implementation of serial Modbus sets this limitation to 256 bytes. This translates to a PDU limitation of 253 bytes, one of these bytes is needed for function code which leads to the largest possible data payload being 252 bytes according to the Modbus specification. The most commonly used function codes in the Modbus specification are 1, 2, 3, and 4 as described in Table 1. These are used to retrieve data from a Modbus slave. By requesting a number of continuous registers, the response can reach the maximum Modbus PDU constraints. However it is important to note that a single register in the commonly used function codes contains a maximum of 16-bits, it is only by packing registers together that responses can contain more than 16-bits of data payload. The Modbus specification defines a number of reserved ranges for implemented functionality. It also defines several available codes as user-defined. This allows for extended functionality in the Modbus protocol, as is the purpose of this study. Ranges 65-72 and 100-110 are available for user-defined functionality. Everything above 127 is reserved for exception codes.

9

2.2 System integration and standardization

The field of research regarding system integration is vast. A common technique to mitigate some of the difficulties of integration is often standardization. Limiting the scope to industrial fieldbus systems focused on integration, the results are more relevant to this study. In this context, system integration can be described as a way to connect a number of systems into a larger whole with the purpose of creating additional functionality or capacity (Sauter, 2007).

System integration involves many different techniques, middleware, applications, and adapting existing systems. One of these techniques is Data Integration (DI), where many definitions exist. Goodhue et al., (1992) references a number of possible definitions of data integration based on literature review before coming to his own interpretation. “Data integration generally means the standardization of data definitions and structures through the use of a common conceptual schema across a collection of data sources” (Goodhue et al., 1992), p. 194) “Data integration ensures that data have the same meaning and use across time and across users, making the data in different systems or databases consistent or logically compatible” (Goodhue et al., 1992, p. 194) “We define data integration as the use of common field definitions and codes across different parts of the organization” (Goodhue et al., 1992, p. 194) All of the above definitions fit well in the Modbus context. It is also by looking at data integration we can take the first step to standardization. Defining the common conceptual schema as described in the first quote. 2.3 Automation There are many types of automation depending on the context of where it is applied. It can be used to describe everything from industrial manufacturing tasks to the improvement of work procedures or processes (Abogunde, 2015). This thesis takes a broad approach to automation, defining it as the following:

A method or technique to automate processes or tasks with the purpose of reducing human interaction, manual operations, and sources of error.

More specifically, we attempt to reduce the need for human interaction when performing system integration using Modbus. This is done by adding additional functionality into the Modbus

10

protocol and allowing for new applications to perform the tasks previously performed manually. To enable automation, the process intended to be automated needs to be known and well defined. The rules of the process must be established. This in turn leads to another desirable result, by following the defined rules sources of errors are reduced. 2.5 Java and Modbus4J Java is one of the most common programming languages today. Rated by TIOBE (https://www.tiobe.com/tiobe-index/) as number one in April 2020. Regardless of ranking it is undoubtedly one of the most used languages. It was developed and released in 1995 by Sun Microsystems, which was later acquired by Oracle. Its syntax is similar to C and C++. It compiles into bytecode and runs in a Java virtual machine (JVM) making the code cross-platform able to run on any machine capable of running the JVM. Its widespread use and maturity has led to large quantities of third party applications and libraries. One of these libraries is the Modbus4J Modbus implementation, developed by Infinite Automation Systems and Serotonin Software. It is released under the GNU General Public License v3.0, meaning it is free to use, modify and distribute. It is available through GitHub and Maven. It supports the most commonly used Modbus function codes, one to four as both master and slave.

11

3. Method To fulfill the purpose of this study it is required to explore possibilities, understand processes and interpret opinions regarding system integration. An exploratory qualitative approach was used in order to gain a deeper understanding of the problems system integrators face and the limitations presented by the protocol itself. By ensuring a deep understanding of the underlying issues, better solutions may be proposed. An abductive reasoning is used by utilizing both empirical observation and theory to evaluate and draw conclusions. The workflow is based on iterations. Following an iteration, an evaluation of the result is performed, either internally, by expert users, or by testing of functionality. This cycle of performing iterations and evaluation of the results is coupled by pragmatic solutions with the intention of finding the best solution for any given problem. The research methodology is based on process steps and subsequent iterations as needed, it shares many similarities to Design Science Research Method (DSRM) (Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007). Following the research questions, the study can be divided into three parts. Each with its own purpose and independent functionality, but with the intention of combining the individual parts together to a final product leveraging qualities from all.

3.1 Research method The research method used in this thesis is based on a process cycle containing three steps. The methodology is intended to be flexible and is based on iterations to gradually improve the result depending on the evaluation. The three steps may be altered, iterated, and omitted.

Figure 4. Research methodology process cycle

The output is the artifacts that address the previously established research questions. Three different processes have been performed, all with their own iterations and artifacts. All are aimed at the common purpose of answering the three research questions. The approach, process, requirements, and end result of each of the three processes differ and benefit from having their own iterations. All three final artifacts have value in themselves and can be implemented independently (client application to some extent), however, it is by leveraging these three

12

processes together that significant improvements to the integration process can be achieved. As such they are performed as separate processes cycles with some overlap in the evaluation steps.

1. Requirements As the intended area of research and use of Modbus as a medium for conveying the solution can be considered deep in the system integration context. We begin the first step by providing a background in order to produce a rich and detailed view of the problem. Next is the requirement generation which will set the objectives for the coming design phase. The requirement gathering is based on the analysis of the qualitative interviews conducted with active system integrators, Modbus documents, and the restrictions found in the Modbus specification (Modbus Organization, 2012).

2. Design The artifacts are produced in order to meet the requirements. The result differs depending on which process is currently being designed. In the data model, the result is a template, a number of attributes required in order to properly describe a Modbus register. The Modbus slave and master produces Java code, changes to the open-source project Modbus4J (Infinite Automation, 2020) that implements a new function code allowing for both request and response messages. This is used as a medium for conveying a function code specification following the same structure as the Modbus specification (Modbus Organization, 2012). Finally, the client application is produced. With core-functionality, the application will be able to request a Modbus register description and export received information to common data formats in accordance with the data model.

3. Evaluation The artifacts validity is demonstrated by presenting the design and all the design factors, limitations, and considerations against the previously generated requirements. All the processes are validated against expert users, protocol restrictions, and usability. The expert users are presented with all artifacts as separate results as well as the final demonstration which uses all three artifacts in combination. The feedback provided is used to validate the perceived value and its relation to the research questions. The feedback is then evaluated and in some cases implemented by adding additional iterations.

3.2 Data collection

The data collection is based on triangulation of literature review, examining target and client systems, comparisons to other communication protocols, and interviews with active system

13

integrators. The purpose is to collect different perspectives on the same phenomenon, increasing the validity of the data.

3.2.1 Literature review

The literature review is using previous research in order to analyze problems and solutions to identify the needs of the integrator, as well as the possibilities of the protocol. This signifies RQ1. Searches are made using google scholar and Luleå Tekniska Universitet, University library. They are performed using keywords in combination and using references in reviewed literature to find new studies. All references are imported into ProQuest RefWorks (https://refworks.proquest.com) and sorted into folders depending on context.

Significant keywords: BMS, IAS, Integration, Industrial integration, Modbus, Fieldbus, DSRM, Standardization, Automation, IoT, Industry 4.0

When identifying the most commonly used attributes as in RQ2, a more quantitative data collection is used. Twenty product-specific Modbus description documents are reviewed along with two target systems for integration. In short, a Modbus description document is a definition of what types of information are available in a Modbus device and how to retrieve said information. The results are quantified and compiled to identify the most common attributes used for describing the contents of a Modbus register. In order to achieve a heterogeneous selection of documents relevant for both industrial applications and building management systems a number of steps were taken. Ten different categories were identified and selected with the aim of being representative of a wide range of different products and applications. These categories were identified and selected by using the author's personal experience of different IAS and BMS applications. This study focuses mainly on the first three layers in the ISA-95 automation pyramid, it is attempted to evenly distribute the identified applications between layers 0-2 (Åkerman, 2018). For each application, two documents were reviewed. As manufacturers often tend to adopt their own representation of a Modbus register, no manufacturers are represented more than once, target systems not included. 18 of the documents were found by online searches using google and by combining the application name with Modbus. Two were selected by personal correspondence from previous system integration projects. Inclusion and exclusion factors were selected:

Inclusion: Contains >= 3 attributes for describing the Modbus registers AND a Modbus register map (addresses).

Exclusion: Manufacturer already represented in the selection.

The document structure varies greatly. Some present generic attributes based on groups where the entire document is the descriptor while others present tables with individually defined

14

attributes. In some cases the descriptions are attached to general manuals, leading to documents ranging from 4 to 168 pages.

Two target systems for integration (masters) were examined to represent the other side of the integration spectrum. In short, which attributes are needed for integration into those two systems. They were chosen as they represent the most commonly used systems in the region where the author is active.

Table 2. Device list for Modbus documents.

Application Layer 0 Layer 1 Layer 2 Number of reviewed

documents

Autonomous ventilation unit * * 2

PLC / Remote I/O * * 2

Cooling unit * 2

Frequency controller * 2

Humidifier / Dehumidifier * 2

Pump * * 2

Fan * * 2

Pressure-/ air volume-transmitter * 2

Temperature-/ humidity-transmitter * 2

Energy- / electrical-meter * 2

Target system* * 2

Total: 5 7 3 22

The identification of attributes has quantitative qualities, however, the decision on which attributes to implement in regards to RQ2 is based on qualitative considerations from interviews and target systems as Modbus limitations and actual integration by end-users need to be taken into account.

The need for an additional lookup table was identified during the evaluation phase of the data model. By combining all available data formats defined in the Modbus4J library and the two target systems reviewed, a compiled list can be found in Appendix D.

15

3.2.2 Interviews

Semi-structured interviews have been conducted with three active system integrators from both industrial and building management systems, see Appendix A and Appendix E. One was conducted in person and two by phone as they were located elsewhere and the current corona situation has made personal meetings problematic. The selection was intended to give a rich view of the issues being investigated and ensure a high level of validity. The author has knowledge of other companies working in the field of Modbus integration. By using the snowball method, each interview is ended by asking them to recommend someone they know are using the protocol in a different way than they do themselves. Respondent 1 (R1) suggested respondent 2 (R2) which worked well, as they represent very different roles in the integration process. Respondent 3 (R3) was found by calling and requesting an interview with one of the larger companies active in the region. Respondent 3 was not known by the author before making first contact. The intended purpose of the selection is to find different roles in system integration to allow for triangulation and a rich description of the integration process and Modbus usage in order to address the research questions. All interviews were transcribed, coded and categorized in OneNote using color-coding to identify categories and tying these to requirements and design decisions. Respondents 1 and 2 are also used for feedback regarding RQ1 and RQ2 and as expert users for usability testing and evaluation of the final artifact and its perceived value for the integrator, RQ1.

Respondent 1 (R1) is an operating technician working with system integration including Modbus. Active in the same small company as the author of this paper. Mainly working in the field of heating and ventilation control systems. He has nine years of experience as a system integrator.

Respondent 2 (R2) is a business developer and quality control manager at a medium-sized enterprise. They develop, produce and handle the post-sales market of professional electronics. It provides a unique perspective as their products are used on both sides of the integration, both as slaves and masters. They also produce OEM products for other companies. Has twelve years of experience in the Modbus integration context.

Respondent 3 (R3) is an experienced system integrator and service manager active in the ventilation, HVAC, and industrial context. He is active in a large enterprise with over 800 employees all over Sweden. He works in a wide range of fields and products and has more than twenty years of experience with system integration in general.

The main problem regarding the selection among system integrators is that the intended purpose of this study may elude some of those active in the industry. Some simply have no interest in the

16

development of better integration processes, others may not have reflected on the fact that the process may improve. Given the technical nature of the proposed solution, the right respondents are not easy to find. With more time and resources available the number of respondents would have been increased. However, the three respondents used in this study represent a wide range of roles allowing for different perspectives and a deeper understanding of the problem.

3.2.3 Comparison

By reviewing the technical specifications of the newer and more advanced BACnet (http://www.bacnet.org/) protocol and the well-proven and standardized M-bus protocol. Comparisons to Modbus are carried out where applicable. The intention is to borrow ideas and functionality to address the requirements generated in the development process. Aside from the similar purpose of the protocols, they are fundamentally different and consideration must be taken to the limitations of the Modbus protocol and to ensure backward compatibility.

3.2.4 Personal experience

I am currently working as a systems integrator in the context of building automation systems but with a background in industrial remote heating power plants. I have experience with several fieldbus systems and have worked as an end-user with hundreds of Modbus integrations over the years. I’ve only performed the role of end-user integrator, and have no previous experience modifying the Modbus protocol itself. Regardless, my perspective on the system integration process is likely to be influenced by my previous experiences and must be taken into account.

3.3 Artifacts

The proof-of-concept and artifacts are implemented using agile methods and iterations as needed. It contains three separate phases and together correspond to the previously established research questions.

1. Define a template specifying a number of attributes needed to describe the contents of a Modbus register.

2. Define a new function code specification for allowing retrieval of Modbus descriptions directly from the target device. Implement the new function code as both master and slave in Java code.

3. Design a GUI capable of requesting Modbus descriptions as master from slave device and presenting these in a machine-readable format.

17

The requirements generation is based on three sources of information. First, the interviews, indicating the need for a data model and to support design choices when selecting the final attributes. Referred to as respondents (R1, R2, R3). Secondly a literature review which consists of a number of Modbus description documents and target systems. Lastly the Modbus specification which will be a source of limitations as the protocol itself sets a number of restrictions due to its architecture.

Building upon the previously established data model for Modbus descriptions. This new functionality is implemented into a Modbus server capable of sending Modbus description responses. It is based upon a fully implemented Modbus stack, Modbus4J (Infinite Automation, 2020). Published under the GPT3 license, free to use and modify. Modbus4J was forked in GitHub and its base functionality tested to ensure that it did indeed work as both Modbus master and slave. Testing was successful and adaptations began locally. The fork can be found at:

https://github.com/zept/modbus4j All development was carried out in the Eclipse IDE environment (https://www.eclipse.org/ide/) using Java. Development began with slave functionality for obvious reasons, without a server to respond it is difficult to send a request. After testing existing functionality in the current implementation of Modbus4J, the new function code was added in parallel. Initially requests on the new function code yielded holding registers to allow for testing before adding any new data structures. New Java files were added for both request and response. Once functionality had been ensured the problem of data mapping needed to be addressed. A new data structure was implemented to allow for the new function code to contain as much information as it needed to give a rich description of a register. Two types of testing was available with the slave while developing. First, a simple socket-based manual request made in Java which simply returned the response in raw data to be interpreted manually. Once the basic structure of the message was valid and conformed to Modbus standards. Testing was then carried out using a Modbus polling program called Modscan32 (https://www.win-tech.com/) with the ability to send user-defined requests. It then enabled the responses to be presented in various formats for easier readability. After the completion of the slave functionality, which was verified by testing with the previously described third party testing tools. The master implementation was developed in the same codebase project as the slave implementation, with the intention of some functionality overlap between master and slave. Master functionality was verified by running customized Java test files that retrieved data in live use with a TCP slave server serving the data for the new function code as previously implemented.

18

Once functionality and data transfer between master and slave was completed. A client with basic GUI and support for the new request functionality was constructed in order to extract the Modbus register descriptions from the server. The project can be found here:

https://github.com/zept/modbus-descriptor-client

Few of the respondents and most likely few system integrators have experience in programming and prefer visual frontends as opposed to command-line operations. The purpose of the frontend is mainly to allow for feedback on the functionality but also to visualize the intended new integration process for demonstrations.

Initially development of the core functionality was performed using plain Java files to establish the foundation of the project. Once basic functionality and data models were established and tested, the frontend development began. The application is constructed to use the new master functionality added in the Modbus4J library. This allows the client application to construct and send a request using the new function code. The response from the server is presented as a table in the client with the ability to select which registers are of interest. The selected registers can be exported in a number of different file formats. Both slave and master applications are exported as separate single executable jar files which allows the author to distribute the files without any configuration needed. Runnable jar files can be found in the following repository.

https://github.com/zept/modbus-descriptor-binaries

The TCP slave implementation is deployed and served over the internet from the author’s personal servers in a virtual machine serving only the Modbus slave. The expert users were given the external IP-address along with the jar file and asked to validate the functionality and its perceived value in regards to RQ1. The resulting communication was captured in WireShark (https://www.wireshark.org/) and presented as a proof-of-concept.

Followup evaluation interviews were performed with respondents 1 and 2 following the evaluation interview guide found in Appendix E. The respondents were asked to give feedback on all three results, the data model, the function code specification, and the client application. Their input was evaluated and several changes were performed by adding additional development iterations.

3.4 Reflections

Having performed this study based mostly on a qualitative approach, some issues were identified. First, not all system integrators have the expertise or interest in improving the

19

integration process. Some are comfortable in this process as they have performed them hundreds of times and have simply accepted that it is an error-prone process that needs several manual operations. Without knowing the possibilities and limitations of the Modbus protocol, it is difficult to know what improvement can be made, therefore it is sometimes easier to simply accept the situation. Another issue with interviews is that the respondent is asked to remember a sometimes fairly long process containing many steps. Finding documents, interpreting documents, writing lists, validating lists, testing alarms, and so on. It is difficult to remember exactly how the process is performed and where problems usually arise, especially when it’s a process the user has gotten used to and no longer reflects on. I believe that a quantitative approach using experiments and questionnaires may have given an even better foundation for requirement generation. The questionnaire would solve the problem of forgetting the issues that happened during integration, not forcing them to answer on the spot. It could be made even more accurate by interviewing or observing a number of system integrators beforehand to narrow in on the issues to better define the questions and allowing a long time frame for submission. The evaluation of the client application could be measured using an experiment approach, allowing for purely quantifiable results such as time without, and time with the new function code implementation. This having its own caveats. Regardless, experiments and questionnaires in a relatively narrow field such as system integration in the IAS and BMS context would require a substantial amount of time, travel, and available respondents. More than possible for this thesis. In the end, the respondents that participated in this study provided very good feedback, suggestions, and perspectives on both system integration and Modbus which in my opinion, provided an excellent foundation for the work conducted.

20

4. Result and analysis

This chapter describes the results based on interviews, document review, and target systems. It is divided into three sections, each with its own end result. Data model, Modbus master and slave and client application. All sections follow the same methodology, requirements generation, designing the artifact, presenting the artifact, and evaluating of the artifact. Basing the research around standardization and automation. The respondents have highlighted the problems present in the integration of Modbus devices today, and further indicated which problem areas are the most pressing to solve. By analyzing their responses, a number of common factors stand out. All the respondents R1, R2, and R3 emphasize the problem of finding the correct documentation for the current device. Further elaboration by R2 shows that this is a source of error, making it difficult to ensure the correct version or revision of the documentation. By automating the process, allowing Modbus devices to respond with descriptions of their own values, this separation between device and documentation is eliminated, and sources of error are reduced. R1, R2, and R3 all agree that it may be problematic to read a Modbus register and how to interpret the received response. This is due to a lack of standards regarding how to describe a Modbus register. Several de-facto standards exist, but no generally accepted data model exists on how to represent a Modbus register. Having a generally accepted standardized data schema would allow for automatic processing. Based on the results from the interviews the basic steps for delivering a solution can be outlined as follows:

1. Standardization a. Purpose: Simplify the integration process by defining a standardized data model. b. Process: Collect, quantify and analyze currently published descriptions. c. Product: A defined template for describing a Modbus register.

2. Automation

a. Purpose: Reduce the need for manual processing and sources of error. b. Process: Artifact development. c. Product: A specification for an additional Modbus function code. d. Product: Master and slave implementations to allow for proof-of-concept

communication.

21

4.1 Data model

4.1.1 Requirement generation for the data model The main objective of the data model is to establish a template that can be used to describe the contents of a Modbus register. As pointed out by R2, few manufacturers follow the same standards which makes integration slow and error-prone. A common standard would allow producers of Modbus products to adopt a generic way to represent a Modbus register. It would also allow end-users and integrators to create automatic scripts that can convert generic Modbus device descriptions directly into various target systems, controllers, HMI’s and SCADA’s. The intention is that the data model will be applicable to all Modbus devices, both old and new. Regardless if they are able to implement the proposed automation part as in chapter 4.2 they should always be able to use the proposed standardized data model. To open up for the possibility of automatic script conversions, all attributes need to be well defined as to what they may contain (R2).

Requirement 1: The identified attributes combined are capable of describing the contents of a Modbus register.

Requirement 2: All attributes need to have clear definitions regarding size, datatype and limitations

The data packet in a Modbus PDU is limited to 252 bytes in its most restrictive form. This means that all values need to be lean and have the ability to be represented in a byte conservative fashion (R2). Text should be represented as an ASCII charset to minimize size constraints. Due to this size constraint it’s reasonable to assume that not all attributes present in the data model are represented in the automation functionality. It’s also reasonable to assume that some of the attributes that are identified in the development phase won’t be relevant for all types of devices (R1, R2). This sets the need for mandatory and optional attributes.

Requirement 3: Attributes are defined as mandatory or optional. If the standardized data model were to be a completely standalone result, description and data fields would not need any limitation and could contain hundreds of attributes and unlimited data field sizes. However since this study aims to implement an automation element allowing for direct extraction of Modbus register descriptions from slave devices a number of considerations and trade-offs need to be taken.

22

Requirement 4: Data fields must have the ability to be represented through small byte-sized (<= 4bytes) values or ASCII-code series (unlimited).

Table 3 - Requirement summary for the data model.

Requirements Data model

1

The identified attributes combined are capable of describing the contents of a Modbus register.

2

All attributes need to have clear definitions regarding size, datatype, and limitations

3 Attributes are defined as mandatory or optional.

4

Data fields must have the ability to be represented through small byte-sized (<= 4bytes) values or ASCII-code series (unlimited).

4.1.2 Designing the data model A number of attributes are identified after compiling the list of documents, see Appendix C. Attribute names that share the same purpose have been merged during compilation. Such as tag-name, which sometimes is defined as a BACnet name, or just a name. Other attributes like scaling and format are presented separately as they indicate different ways to modify the Modbus content. Scaling means multiplying or dividing the received value, whereas format can indicate different types of data manipulation to reach the end value. Something identified as common is the fact that many manufacturers embed a lot of information in the description field. In many cases the information is not consistent, some values hold format whereas others contain nothing, this was also pointed out by both R1 and R2. The full table can be seen in Appendix C, this also indicates how some of the values are presented, in the description, or as independent values. Figure 5 shows attributes as X-axis and manufacturers color-coded in the Y-axis.

23

Figure 5. Compiled Modbus description documents.

As illustrated by Figure 5, the address and type of register is present in every descriptor. This can be considered the most basic information needed to use the Modbus protocol. Which function code we need to use in order to request the information and at which register address the value we wish to request is located. R2 pointed out that some addressing conventions define the function code merged with the address, which leads to an overlap between valid addresses and the merged representation. Meaning that it is not known if the function code should be taken off the address or not. This is resolved by defining the address and function code separately. The function code is often presented in the document as a heading or overall description of the implementation and not in table format, regardless it is always present in some form. Description can also be considered always present, one document did not specify a description, however, the device itself inferred what was present.

Added to the data model as mandatory: Type of register (function code) Added to the data model as mandatory: Address Added to the data model as mandatory: Description

Unit is also a common attribute, sometimes omitted but mainly in products where the unit can be deduced by looking at the functionality of the device. It is identified as a commonly used attribute by all respondents (R1, R2, R3) and added to the data model.

24

Added to the data model as mandatory: Unit

Tag-name / descriptor is a relatively wide collection of attributes looking very differently. In this context they are defined as a short name or identifier of the contents of the register. This can be everything between descriptors such as “Temperature outlet” to a very specific variable name following various naming standards such as “HeatingSettings.Cor_HS2Curve_Y7”. While their purpose often is vague or ambiguous in the description documents they are a key attribute when integrating the registers in target systems where a unique variable name is a mandatory identification (R2). Depending on the type of target system, different naming conventions may be forced by the system. This may be solved by using a standardized naming convention to provide tag-names which in turn may be automatically converted into the required naming convention. Some may opt to not provide any tag-name at all which leads to the tag-name definitions to be a manual process by the integrator. Due to the ambiguous nature and wide definition of tag-names coupled with a huge number of available naming conventions, this attribute is identified as important but optional.

Added to the data model as optional: Tag-name Scaling is another one of the most common, and sometimes also the most complicated attribute (R1, R2). This is often defined as an integer value for multiplication or division of the received value to reach a final result. Scaling is sometimes omitted and instead presented as register format, which may be presented as Integer, IEEE754 float, ASCII-code, or many other data types. It is important to note that no data types are defined in the Modbus specification, only the payload. Many de-facto standards exist on how to interpret the transferred data. Format of register is a more versatile type of scaling as it allows for data manipulation by predefined rules of the received value, for example IEEE754 float values as described by R2. It also allows for the definition of composite registers, by stating the format of a register as 32- or 64-bits it enables the integrator to know how many consecutive registers that should be merged for the final value. As the size of composite registers, it can be inferred by the format of the register, this makes the specific attribute size in bytes identified in the document review redundant. Another type of scaling is the combination of raw min-/max value in combination with the user-defined min-/max range. The relation between the two allows for scaling, this is found in one of the target systems documentation. Format of register is selected as the more versatile of the different methods for scaling, enabling data manipulation as well as allowing us to omit byte size attributes. Format allows for manipulation and byte size. Many registers available are of type integer and use division of another integer to allow for decimals, meaning that another attribute named scaling still must exist in cases where the format is some type of integer which should contain decimals. Scaling then becomes optional as it depends on the type of format.

25

Added to the data model as mandatory: Format of register Added to the data model as optional: Scaling

Type R/W, meaning if the register itself allows for reading or writing. Modbus already specifies four types of function codes. Coils (RW) and discrete inputs (R), for reading bit-specific data. Holding- (RW) and Input-registers (R) for 16-bit data. The read or write information may, therefore, be deduced based on the type of function code used to retrieve the data. Many manufacturers ignore the use of all function codes and use only one or two for simplicity. All the information of a Modbus device is often accessible using holding registers. This choice by the manufacturers does give purpose to the type R/W attribute. However if attempting to write a read-only value, one could argue that the manufacturer should implement an exception code response showing that writing is not allowed. As alternatives to this attribute exist, making it redundant, it is not added to the data model.

Not added to the data model: Type R/W Supported commands exist in less than half of the reviewed documents. Its meaning is showing which function codes can be used on that specific address. It is very structure-specific, where a single address may retrieve the same data in parallel over a number of function codes, alternatively allowing for multiple writes or other types of functionality. This is a choice by the manufacturer. It is however difficult to gauge as it is inferred by a combination of other attributes, but only a few define it as an independent attribute. If a clearly defined type of register (function code) is provided this attribute will be redundant.

Not added to the data model: Supported commands

Limits on the Modbus values are provided in some descriptions. Two types of representations are present, range, and fixed minimum and maximum data field. They provide the same information, the only difference being that the range is both minimum and maximum values in the same data field whereas min- and max-values are in separate data fields. Taking the automation limitations into account, it is difficult to present a range of values in a single register. If min- and max values are present, they will need to have the ability to represent a value as large as the retrieved value in order to allow for the limits to range the full span of values. As the retrieved value may be a composite register with the possibility of 64-bits or more while the automation process needs to be very lightweight it may not be possible to reserve that many bytes for the min- and max values. This problem is solved by setting the values as optional, if not present, no limit exists. If a limit is exceeded then it will be the manufacturers’ responsibility to respond with an exception.

26

Target systems use these limitations in order to limit set values before sending and therefore avoiding any unexpected behavior or exception codes.

Added to the data model as optional: Minimum value Added to the data model as optional: Maximum value

Default value attributes add nothing to how a register should be read or interpreted. It can however be an aid to the integrator during the integration process and while troubleshooting. These values can be validated to test that the expected values are found in the specified addresses in new installations. During troubleshooting any unexpected or changed value can be quickly identified. As it is not needed for interpreting how to read a Modbus register, it is set as an optional value.

Added to the data model as optional: Default value The final attributes identified in the document review. System version, user-level write, update status, and error value are uncommon attributes and often manufacturer specific. System version may be useful at times. However, providing a system version as an attribute for every single register is very verbose. A system-wide version should suffice and the manufacturers should keep a structured approach to their Modbus maps, not changing existing addresses but instead building on empty or reserved space and possibly invalidating no longer used addresses. There should be very good reasons to change the content of a register between versions. It is a source of error that is difficult to identify. User level write is also a manufacturer-specific implementation trying to solve information security issues. By adding a password register needing to be validated before allowing read and writes to specific registers. This allows for different user levels but is in essence a password security measure built on top of the Modbus protocol, not defined in the Modbus specification. Other types of information or physical security architecture should be implemented and provide this security. Update status is a way to define how often the value is updated internally in the Modbus device, by that measure we can evaluate its reliability. Error value is a way to identify incorrect values without responding with exception codes. All of the above can be solved by other means or are very situational, they are not added to the data model.

Not added to the data model: System version Not added to the data model: User level write Not added to the data model: Update status (interval) Not added to the data model: Error value

27

4.1.3 Artifact, presenting the data model

Table 3 - Proposed data model Mandatory Datatype Range Description

Function code Yes Unsigned 8-bit

Integer 0-256 The function code used to retrieve a value from a

specific address.

Address Yes Unsigned

16-bit Integer 0-65535

0-based Modbus address. The address should be presented the same as in a

Modbus request.

Unit Yes

ASCII or Integer in

user-defined lookup table unlimited.

If using the proposed new function code to extract description, the length of all attributes combined for a single descriptor is limited to 246 bytes. If numeric,

use a user-defined lookup table.

Format Yes

Unsigned 8-bit Integer or predefined

ASCII. Appendix D

0-256 or unlimited.

It can be represented as both Integer and ASCII. An integer used for lean representation for developing new function code while predefined ASCII code can

be used for human-readable purposes.

Scaling No Signed 16-bit

Integer -32768 - +32767

Negative value = division Positive value = multiplication

Description Yes ASCII Unlimited.

If using the proposed new function code to extract description, the length of all attributes combined for

a single descriptor is limited to 246 bytes.

Tag-name No ASCII Unlimited.

If using the proposed new function code to extract description, the length of all attributes combined for

a single descriptor is limited to 246 bytes.

Minimum value No

IEEE 754 - Single

precision float

±1.18×10^-38 to

±3.4×10^38

Datatype is selected as it is capable of representing a wide range of values, including decimals. If

required limits exceeds datatype capability, exclude attribute and respond with exception on write.

Maximum value No

IEEE 754 - Single

precision float

±1.18×10^-38 to

±3.4×10^38

Datatype is selected as it is capable of representing a wide range of values, including decimals. If

required limits exceeds datatype capability, exclude attribute and respond with exception on write.

Default value No

IEEE 754 - Single

precision float

±1.18×10^-38 to

±3.4×10^38

Datatype is selected as it is capable of representing a wide range of values, including decimals. If

required limits exceeds datatype capability, exclude attribute and respond with exception on write.

28

As stated in Table 3, the format can be defined as both an integer or an ASCII string (type). See Appendix D for a complete list of available formats.

4.1.4 Evaluating the data model Both respondents 1 and 2 stated that they believe the proposed data model to be a feasible solution. R2 emphasizes that it is dependent on the manufacturers or users to adopt this or any other proposed solution in order to allow for a standardized way of representing a Modbus register. R2 highlighted the issue with addressing offset, where some manufacturers begin at address 0 (0-based) and others at address 1. Evaluating the received feedback, an addition was made to the proposed data model, defining the address field as 0-based to avoid any possibility for misunderstandings. Neither of the respondents identified any issues with the attributes or values presented. R1 also pointed out the possibility to convert already existing Modbus descriptions to fit into this model, allowing for integrators to upload converted Modbus documents to central repositories.

29

4.2 Modbus master and slave The proposed data model is mainly aimed at RQ2, the standardization. Building upon this, the next step is to address RQ3, the automation. All respondents (R1, R2, and R3) stated that the retrieval of Modbus register descriptors is a manual process. The source of information was also problematic as the documents could come from many different sources, customers, e-mails, consultants. R2 and R3 considered this to be a major issue directly influencing the reliability of the retrieved data. R1 also highlighted the fact that with low reliability, a high amount of testing is needed to ensure that the correct information has been entered. Requirements generation are basic generalizable steps that need to be taken in order to allow for the new functionality. This may differ depending on the slave platform and transport, requirement generation is done with ModbusTCP in mind. The design part of development is much more specific regarding platform and solutions, it shows one way to solve the requirements generated. The main purpose and intended endpoint of this development is to present a proof-of-concept with a clearly defined message structure that may be implemented in different ways depending on the platform.

4.2.1 Requirement generation for the Modbus master and slave The main purpose of automation is usually to create more efficient processes by reducing manual operations and human interaction. In this context, leading to shorter integration times and fewer sources of error. Modbus most commonly used data registers are limited to 16-bits per register and some devices only allow addressing up to 9999. Taking these two limitations into account means that using any of the already defined function codes (excluding file transfer code due to complexity) would limit the available space to 9999 * 2 bytes without any additional data present. Considering the sometimes lengthy descriptions needed, this would not suffice for a large device. This leads to the first requirement.

Requirement 1: A new function code needs to be defined, allowing for larger payloads (PDU) per address.

In order to achieve backward compatibility and allowing for both serial and TCP devices. The maximum size of a Modbus PDU is set by its most restrictive setting. This means 253 bytes in serial mode. Subtracting the function code gives us a maximum user-defined data transfer of 252 bytes. This also means that the Modbus request message will only be able to request one register at a time since a single register may contain the full message length of 252 bytes.

30

Requirement 2: The new function code should allow for responses of up to 252 bytes per address in the slave device.

Modbus descriptions are a mix of values and text with few limitations. As the intention is to adapt the previously proposed data model into this implementation, messages need to be well defined. The current specification only defines the structure of the message, this is mainly due to registers being restricted to 16-bits and relies on external descriptors. This may not be that case with a substantially longer message, response and request messages need to be clearly defined. Predefined numeric values can easily be specified as to their location and should be defined as static length. However text is usually dynamic and its length is often unknown which leads to text fields being of variable length. All data fields should be encoded or defined as byte constrained as possible without limiting the presentation.

Requirement 3: Request and response messages need to be clearly defined and consist of both static- and variable-length variables. Requirement 4: Data should be encoded as byte conservatively as possible.

In general, the intention is to stay as true to the current Modbus specification as possible while allowing the proposed new functionality. Responses such as exception codes and error handling should be handled in the same way as it is stated in the Modbus specification.

Table 4 - Requirement summary for Modbus master and slave. Requirements Modbus Master and slave

1

A new function code needs to be defined, allowing for larger payloads (PDU) per address.

2

The new function code should allow for responses of up to 252 bytes per address in the slave device.

3

Request and response messages need to be clearly defined and consist of both static- and variable-length variables.

4 Data should be encoded as byte conservatively as possible.

31

4.2.2 Designing the Modbus master and slave Code can be found at:

https://github.com/zept/modbus4j

The Modbus specification specifies the range for user-defined function codes as 65-72 and 100-110. Function code 71 was chosen without any special considerations for use with the development of the new functionality. The decision is also made to not allow writes of the new function code. It is intended that the Modbus descriptors are shipped with the device and not easily changed to avoid corruption by mistakes or ignorance. Updates of these descriptions would need system-, firmware or other tooling to modify. The most commonly used Modbus function codes result in either 1-bit or 16-bits per register. As shown in Requirement 1, the data received from a single address register needs to be larger than 16-bits to allow for adequate description quality sizes. In Modbus4J data is mapped as either Boolean (bit) or Short (16-bit) identified by an Integer (address). This is solved by adding a new type of data storage, serving a byte array. More code was added to allow for the extraction and conversion of the data regarding getters and setters. This solution was the most efficient in this implementation, on other platforms other limitations may apply and multidimensional arrays may be a better choice to get more space while retaining the byte limitations.

Figure 6. New function code data structure.

Much of the generics in Modbus4J is hardcoded around the fact that values are either one or 16-bits. The response message always ends up as a byte array before transport which was used here. Maximum message size is set by specifying the maximum number of registers read, this implying a maximum size of 16-bits. As the solution presented sidesteps this limitation, a validation step is performed while setting the byte array. Meaning that it is a slave side validation that limits the size of the byte array. An additional Java file is created for setting the byte array with humanly readable input. The new class is named SetDescriptionsByteConvertion and allows for integers and strings to be converted into byte arrays, it’s placed in the test package and is used with ListenerTest3.

32

Requirement 1 - Modbus master and slave

A new function code needs to be defined, allowing for larger payloads (PDU) per address.

Solution

Added new data storage and logic allowing for a single address to store more than 16-bits of data.

Requirement 2 - Modbus master and slave

The new function code should allow for responses of up to 252 bytes per address in the slave device.

Solution

Slave side validation is implemented, in combination with the new “unlimited” byte array storage structure.

The proposed data model found in chapter 4.1.2 has already been somewhat adapted to fit into a small byte representation. This is even more pressing when considering the payload limit of the new function code. By default the payload of Modbus4J is set to 250 bytes, to avoid making unnecessary changes this limit is accepted while in theory some additional bytes could be implemented. Taking Figure 5 into account while considering the proposed data model the following decision is made.

Table 5. Attributes for artifact implementation

Attributes to include

Attributes to exclude

Function code Minimum value

Address Maximum value

Unit Default value

Format

Scaling

Description

Tag-name

33

The reasoning behind the excluded attributes is that their size combined adds up to 12-bytes which is relatively large. Also if a value outside the allowed range is set, the receiving slave should simply reject it, allowing for both master or slave side implementations on how to handle the exception. Default value is more of a troubleshooting variable where unusual values may be detected or as a way to revert to factory settings. Its use is considered less common than the other attributes as supported by figure 5 showing low numbers of implementation. Unit was initially intended to be represented by an integer value which corresponded to a unit of measurement according to the IEC 61158 fieldbus standard (International Electrotechnical Commission, 2019), it is an established and well-accepted standard. This approach was revised for two reasons. One, it is not freely available and users without access will need to find ways to obtain the unit associated with the code. Secondly, the client frontend application may run into licensing issues if attempting to convert an integer to unit using that publication. The solution for this is that the data field is transferred as ASCII characters giving the manufacturer full control of the presentation. As ASCII symbols are limited this poses some limitations which some manufacturers may view as a problem. This is solved by defining an additional rule, if all ASCII characters are numeric then use a user-defined lookup table, such as the IEC standard. This functionality will need to be implemented in the client or manually entered. It allows for manufacturer-specific units and signs. Requirement 4 - Modbus master and slave

Data should be encoded as byte conservatively as possible.

Solution

Setting all data fields possible as static length is the most byte efficient structure, with the exception of unit.

A similar situation exists with the format attribute, however, the difference is that there are far fewer types of formats available for a Modbus register. Neither does there exist any licensing issues regarding its representation. It is impossible to cover all possible manufacturer variants that may exist. The list of formats presented in Appendix E is based on all available presentations found in all the reviewed Modbus documents as well as both of the target systems reviewed. Should the proposed data model be implemented, it is recommended that the list of possible formats is attached as an Appendix, and any additions are placed in the hundreds range (1XX). Keeping the beginning of the list to the more accepted standards. This is implemented directly into the client application for seamless use. All other attributes are presented in the same way as in the proposed data model leading to a message structure as follows. All variable-length attributes begin with a leading byte defining the length of the data field. In total static data fields take up 10 bytes, adding the request function

34

code needed to wrap the data payload adds one byte, meaning that the theoretical combined length of all variable-length fields is 252 - 10 - 1 = 241 bytes or ASCII characters.

Figure 7. New function code response message structure.

Requirement 3 - Modbus master and slave

Request and response messages need to be clearly defined and consist of both static- and variable-length variables.

Solution

A request/response template is presented in a similar fashion as other function codes described in the Modbus specification.

4.2.3 Artifact, presenting the Modbus master and slave

The function code specification presented below is intended to conform to the same format as other function codes in the Modbus specification. In addition to the description and tables necessary, a state diagram is constructed to fully conform to the template used for the existing function code specifications.

35

Function code specification: 71 (0x47) Read Register Description The function code is used for retrieving information about available registers present in the slave device. All descriptors should be ordered continuously from address 1 (0x01) to enable reading descriptions until getting an exception. Address 0 (0x00) is reserved for future use with device-specific information. Message structure is defined by leading static length byte fields and trailing variable length text fields. Text fields begin with one byte defining its length. Scaling is to be interpreted as a signed integer, negative values are defined as the division by its absolute value, positive values indicate multiplication. All fields combined are limited by the PDU maximum size limits. The address and function code should be presented in the same way as it is in a request message. Example: addressing starts at 0x00. Request Function code 1 Byte 0x47

Starting address 2 Bytes 0x0000 to 0xFFFF

Sub-function 2 Bytes 0x0001*

*Reserved for future functionality. Defaults to 0x0001 unless implemented.

Response Function code 1 Byte 0x47

Byte count 1 Byte 0x00 to 0xFA

Function code (description) 1 Byte Unsigned int

Address 2 Bytes Unsigned int

Format** 1 Byte Unsigned int

Scaling 2 Bytes Signed int

Unit length 1 Byte 0x00 to 0xFA

Unit Variable-length US_ASCII

Tag-name length 1 Byte 0x00 to 0xFA

Tag-name Variable-length US_ASCII

Description length 1 Byte 0x00 to 0xFA

Description Variable-length US_ASCII

** See Appendix D - Table of available formats

36

Error Function code 1 Byte 0xC7

Exception code 2 Bytes 01 or 02 or 03 or 04

Request and response example Request Response

Field Name (Hex) Field Name (Hex)

Function 47 Function 47

Starting Address Hi 00 Byte Count 1E

Starting Address Lo 01 Function code (descriptive) 04

Quantity / Sub-function Hi 00 Address Hi 00

Quantity / Sub-function Lo 01 Address Lo 0D

Format 14

Scaling Hi FF

Scaling Lo F6

Unit length 01

Unit 43

Tag-name length 0A

Tag-name 5A 31 5F 54 4C 31 5F 50 56 31

Description length 0A

Description 54 4C 31 20 73 65 6E 73 6F 72

37

Figure 8 - Read Register Description state diagram

38

4.2.4 Evaluating the Modbus master and slave Most iterations in the phase of development were initiated by an attempt to conform to Modbus specification standards. The intention was to produce a result as close to the published specification. One such iteration was the length fields, initially all text fields were separated by delimiters. Upon closer inspection of the Modbus specification, it was discovered that byte count or byte length was the preferred solution in other function codes. As many embedded platform limitations are unknown to the author as well as ASCII mode serial mode limitations, it was decided to instead conform to the identified solution. Another iteration was performed and all text fields were given a leading byte length identifier. Exception code 03 is defined in the specification but not implemented in the current master/slave implementation. It is intended as a future indication if a sub-function is supported or not as per the two sub-function bytes in the request, currently not implemented. Evaluation of the Modbus library is performed by capturing live communication transferred by using the developed function code. The resulting communication can then be compared to the previously presented function code specification to ensure that it conforms to the standard.

Figure 9. Captured Modbus function code 71 request message.

39

Figure 10. Captured Modbus function code 71 response message.

As indicated by the captured Wireshark communication. The structure of the Modbus message complies with the proposed specification presented in chapter 4.2.3.

40

4.3 Client application As stated by respondent R1, as much simplicity as possible is desirable, preferable that everything is instantly presented in an excel sheet. Many system integrators lack a deeper understanding of the Modbus protocol, its limitations, and its possibilities. This is not surprising as their role in a system integration process is that of an end-user tying two or more systems together. What’s going on behind the scenes is simply irrelevant as long as they can complete their given task. In order to meet the request of simplicity and also to be able to demonstrate the new functionality and ideas presented in this study. A graphical user interface has been constructed in order to demonstrate possible uses and visualize how the integration process may be simplified. This artifact is presented to the respondents where they will provide feedback as expert users.

4.3.1 Requirement generation for the client application All respondents requested some need for simplicity. R1 stated specifically that simplicity was a major factor. Not all system integrators are capable of configuring computer software and handling third party libraries. It is deemed necessary to minimize the need for configuration and installation to avoid issues not pertaining to the functionality that is intended to be tested.

Requirement 1: The client application should demand as little configuration and installation as possible and keeping the proposed functionality in focus. If possible, distributable as a single runnable executable.

The message structure of the master and slave implementation in Modbus4J is primarily based around byte efficiency. This choice was taken to allow as rich descriptions as possible. Following the previously established request for simplicity, it is desirable to produce humanly readable output from the response message.

Requirement 2: Responses should be presented in a humanly readable format while retaining the ability to be processed automatically.

By reviewing the Modbus document descriptions in combination with performed interviews and the master and slave implementation, four main components that are needed to support the desired functionality are identified.

41

Table 6. Client application components. Functionality Description

Target settings

In order to connect to a device, target settings such as IP-address and port are needed. In serial mode, more parameters need to be set in order to connect to the slave.

Request settings

Once a connection is established, a request message needs to be constructed and sent on that connection. In order to construct this message, a number of parameters need to be set.

Response handling

The application needs to handle any responses following the issued request. As no data model is complete, the user should be allowed to modify retrieved values where needed.

Output to file

This may be considered a part of the response handling. All respondents (R1, R2, and R3) indicated that they use some form of tabulated data in various file formats. Also both target systems reviewed support file import functions. The functionality to export to file is required to support sharing and further handling.

These main components should be implemented to some extent, not necessarily with all features present. However the base functionality of every component should be present to allow expert users to gauge the proposed new integration process and provide relevant feedback.

Requirement 3: The client application should contain the following functionality, target settings, request settings, response handling, and output to file. Requirement 4: The user should be able to modify attributes if needed before selecting an output.

42

Table 7 - Requirement summary for client application. Requirements Client application

1

The client application should demand as little configuration and installation as possible and keeping the proposed functionality in focus. If possible, distributable as a single runnable executable.

2

Responses should be presented in a humanly readable format while retaining the ability to be processed automatically.

3

The client application should contain the following functionality, target settings, request settings, response handling and output to file.

4

The user should be able to modify attributes where needed before selecting an output channel.

4.3.2 Designing the client application

Java was chosen as the preferred platform for development. Mainly due to the simplicity of using the previously modified Modbus4J library as its Modbus master implementation. The Modbus4J project was added as a dependency and added to the build path. Initial development was performed using test files and scripts and once functionality and data models were established, frontend development began. This in turn gave rise to most files being modified to better fit the frontend project and changes found to be necessary during the development phase. Following the previously established four components as defined in requirement 3 the layout in Figure 11 was created.

43

Figure 11. Client application layout.

Target- and request settings may influence each other depending on transport. These two components share a tabbed view. Only the TCP tab is implemented as the main purpose is to provide a proof-of-concept that is easier to do remotely over TCP than serial communication. Host and port are the required variables for use, defaults to localhost for local testing, and 502 which is the standard ModbusTCP port. Request settings contain node, which may also be called device Modbus address. In order to avoid any confusion with the Modbus register address the name node was selected and is commonly used. Initially the variables offset and length were called range from and range to. It was changed to follow the same norm as Modbus uses, this was done to avoid any unnecessary confusion regarding different types of implementation. Offset is the same as starting address, and length the number of registers to traverse before stopping. Length defaults to 9999, if the input length is longer than the number of available descriptions in the slave device an exception code is received and the client application interprets this as there being no more descriptions in the device.

44

When pressing the button to send request, the information defined in target- and request settings are formatted to create and send a Modbus request. Bad configuration leads to error messages stating which component is the most likely cause.

Figure 12. Client application error messages.

Successful response results in a populated Jtable component coupled with four buttons. All rows and cells are editable. It is possible to add new rows, remove rows, select all and clear the table. This allows the system integrator to do any manual operations or adaptations as they see fit. The three attributes defined in the proposed data model but omitted in the new function code implementation, min-, max- and default-value can be manually entered here if needed.

Figure 13. Client application demonstration.

45

Requirement 2 states that the Modbus descriptor response should be humanly readable. This mainly concerns three attributes. The unit is transferred as ASCII after some considerations in the development of the master and slave implementation. ASCII allows for any representation of available symbols which are limited. It is also stated that if the unit is solely numeric, it should be interpreted according to a user-defined lookup table. This is not implemented in this client as the feature was assessed to be of lesser importance and contained possible licensing issues. Following the same logic, the attribute format is transferred as an unsigned integer but presented as a String as defined in Appendix D. The string is enough for most system integrators to know what kind of register they are looking at, alternatively as a foundation for searching for additional information on how to handle the data. The last attribute that is altered before the presentation is scaling. It is transferred as a signed integer indicating division for negative values and multiplication for positive values. Instead of presenting the value as negative or positive, they are presented as they are intended to be used with a leading division or multiplication sign. Requirement 2 - Client application

Responses should be presented in a humanly readable format while retaining the ability to be machine-read.

Solution

Index or integer values transferred are interpreted and presented as humanly readable text.

Requirement 4 - Client application

The user should be able to modify attributes where needed before selecting an output channel.

Solution

The Jtable is editable in every cell and accepts user input, custom rows, and alterations. Output to file is presented as simply as possible, one field for specifying the output file, one drop-down for selecting the preferred file format and a button to start exporting the current table. In the client application, only the .csv file format is implemented. The file is written to the current path and the number of successfully written lines are returned as a notification alert. Upon closer inspection, an example file may look like Figure 14. By allowing exports to commonly used and open file formats further conversions may be performed using various scripts or directly imported into target systems.

46

Figure 14. Client application output.

Requirement 3 - Client application

The client application should contain the following functionality, target settings, request settings, response handling and output to file.

Solution

The application is designed using the four needed components to ensure functionality. All components are described based on functionality.

The application is exported as an executable jar file for use cross-platform. All required libraries are embedded in the file. Any file output from the application is located in the same folder as the executable is running from.

47

Requirement 1 - Client application

The client application should demand as little configuration and installation as possible and keeping the proposed functionality in focus. If possible, distributable as a single runnable executable.

Solution

Packaged as an executable jar file with all dependencies embedded. No configuration or installation is needed. Runs in the JVM, cross-platform.

4.3.3 Artifact, presenting the client application

The developed artifacts can be found at Github. The client application is intended to be run with the Modbus slave implementation. Source code for the client application and Modbus slave implementation:

https://github.com/zept/modbus-descriptor-client

https://github.com/zept/modbus4j

No configuration, runnable jar executables for both repositories can be found at:

https://github.com/zept/modbus-descriptor-binaries

48

Figure 15. Client application

4.3.4 Evaluating the client application

Presented with the client application, both respondents 1 and 2 successfully retrieved Modbus descriptors from a central server. Both responded with initial positive feedback. R1 expressed a wish for more humanly readable results, the initial prototype client application returned the results in table format in the same form as transferred. This meant that scaling was a signed integer forcing the integrator to know that negative values mean division. Also format was presented as an integer, it was not possible to know that that integer meant without a lookup table. This feedback was considered and another iteration performed. A checkbox labeled “Display raw values” was added. The intention is to switch between humanly readable results and raw values, this allowing conversion scripts to use either representation. It was not fully implemented in the client application, but allowed for format and scaling to be presented in a humanly readable form.

49

R2 again emphasized the need for a clearly defined addressing standard, (0- and 1-based addressing) as previously described in the evaluation of the master and slave implementation evaluation. As address 0 in the new function code is reserved, the address field in the client application defaults to 1 and is therefore consistent with 0-based addressing. Following discussions and justification for design choices and decisions during the demonstration, excellent feedback was given by both R1 and R2. R2 suggested that the work performed should be presented to the Modbus organization. Following the question if the respondents had anything else to add, R1 stated that the solution presented met all the needs discussed in the previous interview. “Great, we’re really pleased with this. With this we’ll get everything directly by using one address... “ Feedback is given by (R1), translated from Swedish.

50

5. Discussion

The proposed changes to the Modbus protocol are a collection of best practices and actions taken based on current usage as indicated by the respondents. By analyzing their integration processes, problem areas became apparent and requirements could be generated. Some of these issues were also found in previous research, such as the need for external searches of Modbus descriptions as indicated by Falk (2019). Modbus is a very limited communication protocol. All the proposed changes are done with some tradeoff or consideration taken based on current limitations (Modbus Organization, 2012). There are other protocols and applications available today that do not have the problems found in the Modbus protocol. This is usually achieved by adding complexity to the implementation or usage (Newman, 2013). The fact is that Modbus has tremendous adoption among manufacturers in both IAS and BMS (D. Aguirre, S. Gamboa, & A. Rodas, 2019; Jakaboczki & Adamko, 2015; Makhija & Subramanyan, 2003). This is likely due to the simple structure of the Modbus protocol, where functionality can be implemented with a very small memory footprint. This makes it ideal for small embedded devices (Cena, Cereia, Cibrario Bertolotti, & Scanzio, 2010). Having its origin in very restricted devices is likely a factor in why the proposed functionality has not already been implemented in some form. When the Modbus protocol was developed memory was expensive, every single bit count. With the advancement of technology and the drastically reduced cost of memory, this is no longer an insurmountable obstacle and would only affect a small number of the most basic embedded devices. The proposed solutions allow the Modbus protocol to retain its simple construction that allows programmers to quickly implement the currently needed functionality with the addition of one new data structure. At some point Modbus will be redundant, however, until that time, old and new protocols and applications will live side by side and require both support and methods to efficiently integrate into the systems of the future (Antonio José Calderón Godoy & Isaías González Pérez, 2018). This thesis presents three main artifacts.

1. The proposed data model for describing the contents of a Modbus register 2. The function code specification defining a new function code for retrieving Modbus

descriptions. 3. A proof-of-concept using a Modbus master and slave implementation along with a client

application to demonstrate the process. The proposed data model defines a number of attributes and their individual constraints and limitations in order to describe the contents of a Modbus register. As stated by Goodhue et al (1992), by clearly defining the structure we standardize the representation of a Modbus register. This enables the use of automatic conversion scripts or import methods between target systems.

51

While not all use-cases can be represented in any product the selection takes a broad approach to different contexts. This directly relates to RQ2. The function code specification attempts to stay within the limitations of the current Modbus protocol while staying transport agnostic. The new function code specification is presented in the same manner as other function codes are presented in the Modbus specification (Modbus Organization, 2012). By analyzing the respondents’ interviews it was clear that many manual operations existed in the process of retrieving and interpreting a Modbus register description leading to both high integration times and sources of error. Abogunde (2015) defines automation as the process of reducing sources of error, human interaction, and improving performance. The proposed function code removes the need for manual searches, reducing both human interaction and the possibility of incorrect documentation. By following the previous definition, the developed artifact has automated a part of the system integration process. The message request- and response message structure is defined down to the byte, making it fit well into Goodhue et al (1992) definition of data integration where the data is standardized to conform to a common schema. By automating this process and by providing a clear specification of how the message structure is transferred we direct this result towards answering RQ3. A Modbus master and slave implementation was created when defining the function code specification. By implementing this functionality in a simplified client application, the ability to demonstrate possibilities for improvement regarding Modbus integration is enabled and is directly aimed at RQ1. By using the master- and slave implementation together we are able to capture and present a proof-of-concept. Additionally, by publishing both source-code and executable binaries, we enable a broader audience the ability to run and test the proposed solutions independently on their own systems. By simplifying the integration process for the system integrator we reduce the time needed for integration and sources of error. It is the ambition that the end result will be improved and therefore also have an impact for the system operators.

5.1 Future research As stated by respondents 1 and 2 (R1, R2), the artifact produced here is a good first step. R2 wished for further research to be conducted regarding semantics to be integrated into the protocol, such as identity or baseline functionality of the register or object. The question is if the limitations of the Modbus protocol has been reached, at least while keeping backward compatibility. The use of third party definitions such as Haystack (https://project-haystack.org/) could be used in combination with Modbus and is a possible next step to research (R2).

52

A Modbus integration requires two types of Modbus information. The device-specific information such as Modbus address (node), baud rate, parity, stop-bits, IP-address, transmit delays, and more. This information may be cross-transport as many devices support multiple types of transport at the same time. The other type needed is to register specific information. This is needed to know which address to poll and how the response is intended to be interpreted. This study has deliberately limited the scope to register specific information. Respondent 2 emphasized the issue regarding device-specific information which often demands a trial and error approach before finding the correct information. This has been considered but not investigated further. As a possible future feature, address 0 in the new function code has been reserved for possible use for this purpose. This would require another clearly specified response message capable of describing the most common device-specific information. Both R1 and R2 wished for a more customized description list, proposing everything from role-based to light sized lists. The new function code is prepared for the use of sub-functions, extending the possibility to allow for new functionality in the same function code. An example in a medium-sized configurable controller could be the ability to request all relevant registers for an HVAC system, heating system, or ventilation system. The request would specify which function which is of interest and the response would be limited to those registers. In its simplest form it would be a list referring to the relevant register descriptors. Other uses could be the ability to request a number of registers based on user level. As the request message proposed in this study contains plenty of space for additional parameters, this would be trivial to implement on the request. The slave implementation would be more platform-specific and needs further investigation if deemed interesting.

53

6. References

Abogunde, A. M. (2015). Brief overview of automated industrial plant: A. International Journal

of Computer Trends and Technology (IJCTT), 23(3), 123-131.

Åkerman, M. (2018). Implementing shop floor IT for industry 4.0

Antonio José Calderón Godoy, & Isaías González Pérez. (2018). Integration of sensor and

actuator networks and the SCADA system to promote the migration of the legacy flexible

manufacturing system towards the industry 4.0 concept MDPI AG. doi:10.3390/jsan7020023

C. Fachkha. (2019). Cyber threat investigation of SCADA modbus activities

doi:10.1109/NTMS.2019.8763817

Cena, G., Cereia, M., Cibrario Bertolotti, I., & Scanzio, S. (2010). A MODBUS extension for

inexpensive distributed embedded systems doi:10.1109/WFCS.2010.5548625

D. Aguirre, S. Gamboa, & A. Rodas. (2019). Low-cost supervisory control and data acquisition

systems doi:10.1109/CCAC.2019.8921296

Delsing, J. (2017). IoT automation [elektronisk resurs] arrowhead framework. Boca Raton:

Taylor & Francis. Retrieved from http://marc.crcnetbase.com/isbn/9781315367897

E. Pricop, J. Fattahi, N. Parashiv, F. Zamfir, & E. Ghayoula. (2017). Method for authentication

of sensors connected on modbus TCP doi:10.1109/CoDIT.2017.8102673

Falk, H. (2019). IEC 61850 demystified [IEC 61850 demystiferd]. Norwood, MA: Artech House.

Goodhue, D. L., Wybo, M. D., & Kirsch, L. J. (1992). The impact of data integration on the

costs and benefits of information systems MIS Quarterly. doi:10.2307/249530

Herterich, M. M. (2017). On the design of digitized industrial products as key resources of

service platforms for industrial service innovation. Paper presented at the 364-380. Retrieved

54

from https://www.alexandria.unisg.ch/250712/

Infinite Automation. (2020). Modbus4J – open source modbus library [computer software].

https://infiniteautomation.com/modbus4j-open-source-modbus-library/:

International Electrotechnical Commission. (2019). IEC 61158 - industrial communication

networks - fieldbus specifications. International: IEC.

Jakaboczki, G., & Adamko, E. (2015). Vulnerabilities of modbus rtu protocol - a case study.

ANNALS OF THE ORADEA UNIVERSITY. Fascicle of Management and Technological

Engineering, XXIV (XIV), 2015/1(1) doi:10.15660/AUOFMTE.2015-1.3111

Knapp, E. D., & Langill, J. (2015). Industrial network security : Securing critical infrastructure

networks for smart grid, SCADA, and other industrial control systems (2. ed. ed.). Waltham,

MA: Syngress.

Makhija, J., & Subramanyan, L. R. (2003a). Comparison of protocols used in remote monitoring:

DNP 3.0, IEC 870-5-101 & modbus. Paper presented at the M. Tech. Credit Seminar Report,

Makhija, J., & Subramanyan, L. R. (2003b). Comparison of protocols used in remote monitoring:

DNP 3.0, IEC 870-5-101 & modbus. Electronics Systems Group, IIT Bombay, India, Tech.Rep,

Modbus Organization. (2006). MODBUS MESSAGING ON TCP/IP IMPLEMENTATION

GUIDE V1.0b. Retrieved from

http://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

Modbus Organization. (2012). MODBUS APPLICATION PROTOCOL SPECIFICATION

V1.1b3. Retrieved from http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

Modbus Organization. (2018). MODBUS/TCP security. Retrieved from

http://modbus.org/docs/MB-TCP-Security-v21_2018-07-24.pdf

55

Newman, H. M. (2013). BACnet : The global standard for building automation and control

networks. New York, N.Y.] 222 East 46th Street, New York, NY 10017]: Momentum Press.

Retrieved from

http://proxy.lib.ltu.se/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=e000x

ww&AN=607370&lang=sv&site=eds-live&scope=site

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science

research methodology for information systems research. Journal of Management Information

Systems, 24(3), 45-77. doi:10.2753/MIS0742-1222240302

R. Al-Dalky, O. Abduljaleel, K. Salah, H. Otrok, & M. Al-Qutayri. (2014). A modbus traffic

generator for evaluating the security of SCADA systems doi:10.1109/CSNDSP.2014.6923938

Sanyal, J., New, J., Nutaro, J., Fugate, D., & Kuruganti, T. (2015). The modbus definition

language specification: A first step towards device interoperability International Building

Performance Simulation Association. Retrieved from

http://proxy.lib.ltu.se/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=edselc

&AN=edselc.2-52.0-84976448422&lang=sv&site=eds-live&scope=site

Thomesse, J. -. (1998). A review of the fieldbuses. France, Europe: HAL CCSD; Elsevier.

Retrieved from

http://proxy.lib.ltu.se/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=edsba

s&AN=edsbas.25D4FE3C&lang=sv&site=eds-live&scope=site

Thomesse, J. -. (2005). Fieldbus technology in industrial automation. USA: IEEE.

doi:10.1109/JPROC.2005.849724

Urrea, C., Morales, C., & Kern, J. (2016). Implementation of error detection and correction in the

56

modbus-RTU serial protocol. International Journal of Critical Infrastructure Protection, 15,

27-37. doi:10.1016/j.ijcip.2016.07.001

Weyer, S., Schmitt, M., Ohmer, M., & Gorecky, D. (2015). Towards industry 4.0 -

standardization as the crucial challenge for highly modular, multi-vendor production systems.

IFAC-PapersOnLine, 48(3), 579-584.

Zhou, X., & Nelson, R. M. (2011). A plug-and-play framework for an HVAC air-conditioning

unit and temperature sensor auto recognition technique--part I: Review of critical technologies

ASHRAE. Retrieved from

http://proxy.lib.ltu.se/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=aph&

AN=67217634&lang=sv&site=eds-live&scope=site

57

Appendix A - Interview guide

● Introduction. ○ Outlining what the project is about. ○ Stating the purpose of the interview and it's intended usage. ○ Explaining the respondents right to withdraw at any time ○ Elaborating on the right to anonymity and the inability to ensure complete

anonymity.

● Personal ○ Work title? ○ Size of company? ○ Years of experience in IAS or BMS system integration?

● What problems, if any, have you identified while performing Modbus integration.

○ If possible, please describe a typical generic integration process and point out where and how the problems arise.

● Are there any alterations that you would like to see implemented into the Modbus

protocol? ○ Elaborate

● Is there any functionality in other protocols or applications that you think would benefit

the Modbus protocol if implemented?

● What is your opinion on the following solution? ○ [Showing image of early draft implementation] See Appendix B. Early draft ○ Is there anything you would like to change or add?

● Any additional comments, ideas, or feedback?

● Would you be interested in providing feedback for any final product once completed?

58

Appendix B - Early draft

59

Appendix C - Compiled Modbus description table

60

Appendix D - Table of available formats Index Type Description

1 ONE_BIT_BINARY Binary bit value

2 ONE_BIT_BINARY_BIT_0 Single bit from 16-bit register.

3 ONE_BIT_BINARY_BIT_1 Single bit from 16-bit register.

4 ONE_BIT_BINARY_BIT_2 Single bit from 16-bit register.

5 ONE_BIT_BINARY_BIT_3 Single bit from 16-bit register.

6 ONE_BIT_BINARY_BIT_4 Single bit from 16-bit register.

7 ONE_BIT_BINARY_BIT_5 Single bit from 16-bit register.

8 ONE_BIT_BINARY_BIT_6 Single bit from 16-bit register.

9 ONE_BIT_BINARY_BIT_7 Single bit from 16-bit register.

10 ONE_BIT_BINARY_BIT_8 Single bit from 16-bit register.

11 ONE_BIT_BINARY_BIT_9 Single bit from 16-bit register.

12 ONE_BIT_BINARY_BIT_10 Single bit from 16-bit register.

13 ONE_BIT_BINARY_BIT_11 Single bit from 16-bit register.

14 ONE_BIT_BINARY_BIT_12 Single bit from 16-bit register.

15 ONE_BIT_BINARY_BIT_13 Single bit from 16-bit register.

16 ONE_BIT_BINARY_BIT_14 Single bit from 16-bit register.

17 ONE_BIT_BINARY_BIT_15 Single bit from 16-bit register.

18 16_BIT_UNSIGNED 16-bit unsigned integer

19 16_BIT_UNSIGNED_SWAPPED 16-bit unsigned integer

20 16_BIT_SIGNED 16-bit unsigned integer

61

21 16_BIT_SIGNED_SWAPPED 16-bit unsigned integer

22 16_BIT_BCD 16-bit binary-coded decimal

23 16_BIT_ASCII_CHARSET Double ASCII characters

24 32_BIT_UNSIGNED 32-bit unsigned integer

25 32_BIT_UNSIGNED_SWAPPED 32-bit unsigned integer

26 32_BIT_UNSIGNED_SWAPPED_SWAPPED 32-bit unsigned integer

27 32_BIT_SIGNED 32-bit signed integer

28 32_BIT_SIGNED_SWAPPED 32-bit signed integer

29 32_BIT_SIGNED_SWAPPED_SWAPPED 32-bit signed integer

30 32_BIT_FLOAT 32-bit single-precision float

31 32_BIT_FLOAT_SWAPPED 32-bit single-precision float

32 32_BIT_FLOAT_SWAPPED_INVERTED 32-bit single-precision float

33 32_BIT_UNSIGNED_MOD10K 32-bit unsigned MOD10K

34 32_BIT_UNSIGNED_MOD10K_SWAPPED 32-bit unsigned MOD10K

35 32_BIT_SIGNED_MOD10K 32-bit signed MOD10K

36 32_BIT_BCD 32-bit binary-coded decimal

37 32_BIT_BCD_SWAPPED 32-bit binary-coded decimal

38 48_BIT_UNSIGNED_MOD10K 48-bit unsigned MOD10K

39 48_BIT_UNSIGNED_MOD10K_SWAPPED 48-bit unsigned MOD10K

40 64_BIT_FLOAT 64-bit double-precision float

41 64_BIT_FLOAT_SWAPPED 64-bit double-precision float

42 64_BIT_UNSIGNED_MOD10K 64-bit unsigned MOD10K

43 64_BIT_UNSIGNED_MOD10K_SWAPPED 64-bit unsigned MOD10K

44 64_BIT_UNSIGNED 64-bit unsigned integer

45 64_BIT_UNSIGNED_SWAPPED 64-bit unsigned integer

46 64_BIT_SIGNED 64-bit signed integer

47 64_BIT_SIGNED_SWAPPED 64-bit signed integer

98 USER_DEFINED_FORMAT User-defined format

99 UNKNOWN_FORMAT Unknown format

100 - USER_DEFINED_TYPES User-defined space for adding additional codes.

62

Appendix E - Evaluation interview guide

● Introducing the three artifacts. Data model, function code specification, and client application.

● Data model: ○ Thoughts on this? ○ Anything you would like to change, add, or remove? ○ Do you think this is a viable solution for standardizing the representation of a

Modbus register? ● Function code specification.

○ Thoughts on this? ○ Anything you would like to change, add, or remove? ○ Anything you see that is missing?

● Client application. ○ Thoughts on this? ○ Anything you would like to change, add, or remove? ○ Do you think this is a viable solution to improve system integrator for Modbus

end-users?

● Do you have any additional feedback regarding any of the artifacts or otherwise?

● Demonstration ended. Thank you.