H2-DM1E Protocol?

[sspry]

Hello, we make heavy use of Do-more PLCs. The tooling is quite good but we need to investigate custom data collection solutions. Investigating the Do-more software's communication with the H2-DM1E lead me to discover the HAP protocol, which is what the device appears to use.

Is this explicitly supported? It seems like HAP is undocumented, per https://forum.hosteng.com/index.php?topic=961.0. It is not clear to me if the provided SDKs support it.

[BobO]

HAP is just our low-level protocol that sits directly on UDP. Pretty much every Host module uses some part of it. In the case of Do-more, all of the programming communications is done through one of HAPs many function codes.

Do-more controllers allow for directly sending and receiving UDP packets (and also reading and writing TCP streams). Rather than trying to build on HAP, which really doesn't gain you anything useful, you might consider doing a custom protocol.

[sspry]

Do-more controllers allow for directly sending and receiving UDP packets (and also reading and writing TCP streams). Rather than trying to build on HAP, which really doesn't gain you anything useful, you might consider doing a custom protocol.

Our desire to interoperate with these controllers using HAP stems from how it allows almost fully transparent access to the controller's registers. Anything else would be a lot of work on the PLC side to marshal data into and out of a UDP or TCP stream.

We've had some luck putting data from its normal location into MHR/MC registers which are linked to the unit's builtin Modbus server, but that is still quite a bit of work and nowadays many of our programs are dominated not by actual application logic but by data shuffling.

Some usecases further out were automated collection of error state, etc. This data is already reported via HAP so we'd like to access it that way.

[BobO]

Our desire to interoperate with these controllers using HAP stems from how it allows almost fully transparent access to the controller's registers. Anything else would be a lot of work on the PLC side to marshal data into and out of a UDP or TCP stream.

We've had some luck putting data from its normal location into MHR/MC registers which are linked to the unit's builtin Modbus server, but that is still quite a bit of work and nowadays many of our programs are dominated not by actual application logic but by data shuffling.

Some usecases further out were automated collection of error state, etc. This data is already reported via HAP so we'd like to access it that way.

HAP isn't the issue, it's the Do-more programming interface. With other function codes (like for doing DirectNet or K-Sequence) it's simple read and write functions, but the programming interface is about 1000% more complex and none of it is publicly documented. There is a somewhat lighter symbolic interface, but it still requires a session and access to stuff that isn't publicly available. It isn't trivial.

We're about to release a very nice feature using an HTTP-based API that gives you full access to all tags, but that is BRX only.

[sspry]

HAP isn't the issue, it's the Do-more programming interface. With other function codes (like for doing DirectNet or K-Sequence) it's simple read and write functions, but the programming interface is about 1000% more complex and none of it is publicly documented. There is a somewhat lighter symbolic interface, but it still requires a session and access to stuff that isn't publicly available. It isn't trivial.

We're about to release a very nice feature using an HTTP-based API that gives you full access to all tags, but that is BRX only.

We don't really need/want to reproduce the programming interface, there's little point. The IDE is provided for free and is the simplest way to configure and program the devices.

The two functions we do want are PLC host discovery and register read/write. The former is easy to spot, a broadcast is sent out and the PLCs reply. The latter I've made decent progress in understanding but would prefer to save some time if possible. A description of the protocol would be invaluable just to make sure I cover edge cases.

Can you explain the difference between the protocols you referenced and their significance? In the network captures I've generated I only ever see HAP packets which is why I referenced that protocol specifically.


We are quite sure this is the right path forward: we can either understand the protocol once and write a data ingest program for it that will work with all of our PLC programs, or we can create additional programming work for every PLC program that we wish to do data ingest from in addition to creating the data ingest tool.

If you've got more information on the BRX, etc, I'm interested, I was actually under the impression they had been deprecated.

[BobO]

We don't really need/want to reproduce the programming interface, there's little point. The IDE is provided for free and is the simplest way to configure and program the devices.

The comm protocol you are trying to reverse engineer is the protocol used by DmD for programming. I'm not talking about you using it for programming.

The two functions we do want are PLC host discovery and register read/write. The former is easy to spot, a broadcast is sent out and the PLCs reply. The latter I've made decent progress in understanding but would prefer to save some time if possible. A description of the protocol would be invaluable just to make sure I cover edge cases.

Can you explain the difference between the protocols you referenced and their significance? In the network captures I've generated I only ever see HAP packets which is why I referenced that protocol specifically.

HAP is the top level protocol that all Host products speak. Within HAP there are north of 50 function codes. A few of those codes are dedicated to discovery. One of the function codes contains within it then entire Do-more programming protocol, which itself consists of nearly 70 commands. The register read and write commands you are referring to are only a couple of those, but there are other commands for logging in that are also required for what you are trying to do.

We are quite sure this is the right path forward: we can either understand the protocol once and write a data ingest program for it that will work with all of our PLC programs, or we can create additional programming work for every PLC program that we wish to do data ingest from in addition to creating the data ingest tool.

ADC has provided the information you are wanting to a few HMI vendors on an NDA basis. Host has not provided it directly to anyone.

If you've got more information on the BRX, etc, I'm interested, I was actually under the impression they had been deprecated.

BRX is most certainly not deprecated. It is our flagship product and the primary focus of all of our development. The new API I'm referring to will be released early next month and provides read access (write coming in a future release) to all PLC system memory through simple HTTP queries. Results are provided in JSON format.

[sspry]

The two functions we do want are PLC host discovery and register read/write. The former is easy to spot, a broadcast is sent out and the PLCs reply. The latter I've made decent progress in understanding but would prefer to save some time if possible. A description of the protocol would be invaluable just to make sure I cover edge cases.

Can you explain the difference between the protocols you referenced and their significance? In the network captures I've generated I only ever see HAP packets which is why I referenced that protocol specifically.

HAP is the top level protocol that all Host products speak. Within HAP there are north of 50 function codes. A few of those codes are dedicated to discovery. One of the function codes contains within it then entire Do-more programming protocol, which itself consists of nearly 70 commands. The register read and write commands you are referring to are only a couple of those, but there are other commands for logging in that are also required for what you are trying to do.

We are quite sure this is the right path forward: we can either understand the protocol once and write a data ingest program for it that will work with all of our PLC programs, or we can create additional programming work for every PLC program that we wish to do data ingest from in addition to creating the data ingest tool.

ADC has provided the information you are wanting to a few HMI vendors on an NDA basis. Host has not provided it directly to anyone.

Is there any reason why? (I've contacted ADC, we'll see what they say.)

• Releasing protocol documentation actually strengthens any copyright or patent claims you make.
• Making it easier for people to use your hardware in a way they see fit will only mean you sell more units.
• You're not making money on software licensing anyway, so people using the hardware as they see fit can't hurt you.

If we're not able to stream data from these devices easily we're just going to have to go with another vendor. I'm sure other people are making the same or similar decisions. We originally went with PLCs because our engineers had previously used them, but as we are now needing more robust data collection and device management and orchestration capabilities it is looking like we will need to move away from PLCs because of the proliferation of completely opaque proprietary interfaces.

Something we had seriously considered (and that you can find research papers on) is picking a vendor, reverse engineering the backplane, and using their IO modules. Fortunately there are some PLC-like IO boards now.

If you've got more information on the BRX, etc, I'm interested, I was actually under the impression they had been deprecated.

BRX is most certainly not deprecated. It is our flagship product and the primary focus of all of our development. The new API I'm referring to will be released early next month and provides read access (write coming in a future release) to all PLC system memory through simple HTTP queries. Results are provided in JSON format.

That may satisfy our immediate needs, I'll ask why we passed over the BRX earlier in our selection.
What is still open is how to interface a peripheral with a C-more screen.


I hope I don't sound combative, I'm just genuinely surprised -- if you're not making license fees off of software to make up for taking a loss on the hardware, then why bother keeping users from messing with the guts?

[BobO]

I hope I don't sound combative, I'm just genuinely surprised -- if you're not making license fees off of software to make up for taking a loss on the hardware, then why bother keeping users from messing with the guts?

Our PLCs control things that can easily kill people. The protocol you want is the one that we use to program the PLC. Publishing it opens the PLC up to be changed in ways that can be very destructive or dangerous. The security of my users is a far bigger concern than anything you stated, including my profitability. We know of specific instances where control systems (not ours, thankfully) have been hacked and resulted in loss of life. I simply don't need your money or anyone else's badly enough to have that on my conscience.

Any Do-more PLC is capable or sourcing whatever you need through its program and custom protocol features and the new REST API feature on BRX makes it very easy to get information via Java Script or any other web-centric scripting language that can issue an HTTP request and process a JSON response.

[franji1]

Hello, we make heavy use of Do-more PLCs. The tooling is quite good but we need to investigate custom data collection solutions. Investigating the Do-more software's communication with the H2-DM1E lead me to discover the HAP protocol, which is what the device appears to use.

Is this explicitly supported? It seems like HAP is undocumented, per https://forum.hosteng.com/index.php?topic=961.0. It is not clear to me if the provided SDKs support it.

Is OPC/UA support a solution?

[sspry]

Our PLCs control things that can easily kill people. The protocol you want is the one that we use to program the PLC. Publishing it opens the PLC up to be changed in ways that can be very destructive or dangerous. The security of my users is a far bigger concern than anything you stated, including my profitability. We know of specific instances where control systems (not ours, thankfully) have been hacked and resulted in loss of life. I simply don't need your money or anyone else's badly enough to have that on my conscience.

Any Do-more PLC is capable or sourcing whatever you need through its program and custom protocol features and the new REST API feature on BRX makes it very easy to get information via Java Script or any other web-centric scripting language that can issue an HTTP request and process a JSON response.

It is clear to me you have not studied the security of your products or security research in general in any detail. If you had you would know that security through obscurity is not an accepted method of protection. You may refer to https://en.wikipedia.org/wiki/Security_through_obscurity for an overview.

Your decisions do not and can not protect your clients. We (or rather I) evaluated the security of our PLC systems and found all of them, including the Do-more units, to be functionally unprotected. Our solution is to put them on a private LAN and use a VPN for remote connection. This is a typical solution in indusutry. Whatever efforts you have undertaken to secure your PLCs serve no real purpose if they accept unencrypted connections by default.

Again, I'm not trying to be combative. It is important you understand you are wasting your time and have done nothing of note for your users if security is your goal.

[sspry]

Hello, we make heavy use of Do-more PLCs. The tooling is quite good but we need to investigate custom data collection solutions. Investigating the Do-more software's communication with the H2-DM1E lead me to discover the HAP protocol, which is what the device appears to use.

Is this explicitly supported? It seems like HAP is undocumented, per https://forum.hosteng.com/index.php?topic=961.0. It is not clear to me if the provided SDKs support it.

Is OPC/UA support a solution?

It should be, yes. Our strongest requirement is that accessing data from the PLC does not require additional code on the PLC, which is what all current solutions on products we have reviewed entail.

Our other set of requirements is related to device management -- we'd like to get device health statistics, monitor device operation, and power cycle or soft reboot the device remotely. We have no interest in reproducing these functionalities that are commonly found in most PLCs but are unfortunately vendor locked for some reason.

[BobO]

It is clear to me you have not studied the security of your products or security research in general in any detail. If you had you would know that security through obscurity is not an accepted method of protection. You may refer to https://en.wikipedia.org/wiki/Security_through_obscurity for an overview.

Your decisions do not and can not protect your clients. We (or rather I) evaluated the security of our PLC systems and found all of them, including the Do-more units, to be functionally unprotected. Our solution is to put them on a private LAN and use a VPN for remote connection. This is a typical solution in indusutry. Whatever efforts you have undertaken to secure your PLCs serve no real purpose if they accept unencrypted connections by default.

Again, I'm not trying to be combative. It is important you understand you are wasting your time and have done nothing of note for your users if security is your goal.

We aren't publishing the protocol.

The HTTP based REST API should give you what you need. If not, I'm sure there are other products that will serve you better than we can.