Improving system integration by
standardizing and automating the Modbus
protocol
David Ågren
Systems Sciences, bachelor's level 2020
Luleå University of Technology
Author Note
This paper is written as the finalthesis 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.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
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).
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
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^3 8
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^3 8
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^3 8
Datatype is selected as it is capable of representing a wide range of values, including decimals. If required limits exceeds datatype capability, exclude
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.
