June 22, 2018
One of the easily overlooked features of our nBox-Tool is the ability to display not only smaller PLC packets but the larger aggregate of application protocol PDUs that they comprise together. The feature has its roots in some first hand experience on its usability.
There was this one instance when an engineer at a partner company, working on one of Metering application protocols (DLMS) running over PLC was not happy with debug tools they had at that time. They were using a PLC sniffer that could show them all PLC packets. Versatile as it was to capture all PLC packets, application (DLMS) PDUs were nowhere to be seen. The feature-rich GUI showed bits and bytes and protocol headers and footers and CRC and signal quality etc etc ... but the one thing that was most important to the application engineer ... visibility of DLMS PDUs ... was missing. So our colleague was left with no option but to pick HEX streams of PLC packet payloads and try to construct DLMS PDUs from them
It is universal among all contemporary PLC technologies to segment application PDUs into smaller chunks at the transmission end while the receiving end would put them together before delivering to higher level application. This is done because smaller the chunk size, higher is the reliability of data reaching the other end to receiver.
While the PLC protocol at the two ends do this splicing and re-joining of application data, the transmitter and receiver (DLMS) applications at the two end-points would stay oblivious of all action happening underneath. In technical jargon, this would be called segmentation-and-reassembly or more simply, just SAR
A PLC modem cannot facilitate data communication if it does not implement the SAR. It is a mandatory component of the PLC stack and therefore (DLMS) application engineers do not need to deal with it. The story is however different when someone implements a sniffer because a sniffer is a passive element and may choose to only show captured traffic on the wire ... which is the split and spliced version of application PDU.
When starting to design the nBox-Tool, we took a holistic view of developing a product that can not only show PLC activities but can also be of productive use to application engineers. The device therefore not only shows bits-and-bytes at PLC layers, it also aggregates the various PLC segments of an application PDU to show a composite whole to make it meaningful for application protocol engineers to see the larger picture.
Trying to support all perspectives, we took the analysis information one step further into the application protocol domain where DLMS uses various COSEM objects for identifying various actions. The COSEM objects, with their numbering convention for efficient representaiton need DLMS engineers to keep a cross-reference document handy in order to map the numbers to meaningful physical entities. For some of the common object models, we included the object names within the displayed data.
All in all, we see that providing useful features like these, went a long way in making the nBox-Tool a success story that it is today !