Basic components and system architecture of the Modbus module.
System Components
Transport Layer: The transport layer takes care of the transportation of the Modbus messages between both of the devices. It makes some additional processing of the data, and sends and receives packages in the appropriate format.
Currently supported transport types are Modbus TCP and Modbus Serial.
Driver Layer: the actual implementation of the Modbus protocol. This layer is included in the API and consists of the following components:
Modbus Driver: manages the Modbus links. The Modbus link provides implementation of the Modbus functions and "raw" access to the corresponding device.
Modbus Manager: manages the Modbus Devices - the basic abstraction of a device. In addition to the Modbus primitives, the Modbus device uses data points to add some semantics and combine various registers and coils into some more meaningful values. Another responsibility of the Modbus manager is to backup and restore the information for the registered devices and to keep consistent state of the system.
Discovery Layer: This should be the part of the Modbus application that is responsible for detecting and initializing devices. This is strongly project specific and there is no suitable abstraction of this. This module is not actually included in the API. This is an extension point and is not mandatory. Although the notion is flexible enough so even simple manual adding can be considered as Device discovery.
Adapter Layer: This module should be used to get the information from the driver layer and wrap it in some project specific form. A form that can be presented to the target group of users and let them do their work without bothering about Modbus requests, registers and so on. It should register listeners for the various Modbus device Lifecycle events (whether device was added, updated, or removed, and so on. This module is not included in the API, because this is strongly project specific and no suitable abstraction can be provided. This module is not mandatory, but without such module the system is not very useful and user-friendly, since the user will have manually extract the data from the registers and coils and then manually convert it, to get some meaningful information.
Module Workflows
Device Detection Workflow
As stated before, the notion "discovery" is used in a very flexible manner. Discovery can be done even manually, by registering a device, using the console commands of the driver layer. After the discovery process is activated, either automatic or manually, the Discovery layer would create a Modbus Link, using the API of the Driver Layer. Using this link some verification can be done, to make sure the device, corresponding to this Modbus Link actually fulfills the requirements and criteria of the product. If this device is suitable for the needs of the system being built, than a Modbus Device must be registered. The discovery layer should provide all of the information required by the Adapter Layer. This can be done using the device properties and the data points of the device. This is the main responsibility of the Discovery Layer. Of course a lot more logic can be done here, like health verification of the system, device configuration changes detection and so on.
After a device is registered, the Driver Layer, takes care to persist the information and forward it to the Adapter Layer. Another responsibility of the driver layer is to keep track of the state of the underlying connection. Any change of the underlying connection is forwarded to the Adapter Layer. If the discovery layer detect any change in the configuration of the device, it must inform the Driver Layer, so the Driver Layer can reflect them and forward this changes to the Adapter Layer. The Driver Layer uses the EventAdmin service to make all of the notifications.
Device Utilization Flow
After a device is registered and the Adapter Layer is notified it is up to the Adapter to make the connection between the end user and the device available. This is done by registering Functional Items or Device Class Object with appropriate properties and operations, properly mapped to the underlying Modbus Device's data points and properties. The Adapter Layer uses the Driver Layer in two ways.
Directly, using the Modbus Link of the Modbus device, to perform Modbus requests to the actual device
Indirectly, by listening for events about the devices state and configuration changes.
