Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: ryanastiefes on November 18, 2015, 02:29:19 AM
-
Any thoughts on implementating the DNP3 protocol?
-
I'm not familiar with it, but just scanned some info. The messaging seems pretty straightforward, and apparently there are subsets of the RTU protocol suitable for embedded systems. We don't have any current plans to support it, but at first read, I'd say Do-more could handle it fine as a custom protocol.
-
I'm not familiar with it, but just scanned some info. The messaging seems pretty straightforward, and apparently there are subsets of the RTU protocol suitable for embedded systems. We don't have any current plans to support it, but at first read, I'd say Do-more could handle it fine as a custom protocol.
It would be excellent to see DNP3 via Ethernet implemented as an officially sanctioned, supported and documented protocol. This feature is becoming absolutely necessary in both Water Treatment and Energy Distribution industries.
-
The next significant bit of development will be to develop expansion modules for BRX, but after that we would like to spend some time doing comm protocols.
-
Can I jump on the band-wagon for DNP3 as well? It's like the Modbus of the Electric Utility/Generation world.
Would also like to see native support of SDI-12. Very common for Geo-science type instruments (typically low power/low rate stuff like water well monitors, etc). This could probably easily be a custom protocol but having it as a supported things would be best.
Thanks!
-
In homage to the POM Port how about Plug In Protocols (PIPs) if the code space would get a little crowded with a bunch of specialty protocols. Each bringing the firmware support, specialized heap structures and instructions. Some might have do be associated with specialty add-on modules if the protocol requires such hardware. Possibly a profit center if needed.
-
In homage to the POM Port how about Plug In Protocols (PIPs) if the code space would get a little crowded with a bunch of specialty protocols. Each bringing the firmware support, specialized heap structures and instructions. Some might have do be associated with specialty add-on modules if the protocol requires such hardware. Possibly a profit center if needed.
I like the idea. Implementation is hard.
In a system with an OS that supports dynamic linking, this is easy. In a PLC built on bare metal, not so easy.
If there is enough business to justify a module-based implementation, that's a fairly easy answer, however we are still very far away from the point in BRX development where we can justify the time to develop narrowly focused specialty modules. To further complicate the decision, unless ADC specifically requests it due to them feeling like there is a large enough market to justify it, Host is just rolling the dice if we develop such modules.
Another less obvious aspect is that if you sell an expansion module there is an expectation of a more complete implementation, which can be deceptively time consuming. A minimalist implementation as a built-in protocol is often good enough, and requires far less work overall.
The POM port does give us nice options for slave side protocols. Turning the ECOMLT hardware into simple slave protocol converters might be a nice middle ground. The hardware cost is low enough that minimalist implementations wouldn't be bad, and I would think most customers would be willing to spend $69 to add a protocol they needed.
That doesn't answer master side protocols though. That's a much bigger problem, and will likely remain the domain of full expansion modules and robust markets...as time permits.
-
For DNP3 specifically...are y'all wanting master or slave side?
-
however we are still very far away from the point in BRX development where we can justify the time to develop narrowly focused specialty modules.
Agree -- analog, high density discrete, and native remote I/O are all more urgent.
The POM port does give us nice options for slave side protocols. Turning the ECOMLT hardware into simple slave protocol converters might be a nice middle ground. The hardware cost is low enough that minimalist implementations wouldn't be bad, and I would think most customers would be willing to spend $69 to add a protocol they needed.
I'd think the protocolified POMs could (and should) sell for more than hardware-only versions. Maybe $169 or so, at least. For $100 (assuming a one-off app) people get to avoid writing a protocol. Prosoft used to sell Modbus modules for the SLC for $1300. I think the current version is $2K.
-
Agree -- analog, high density discrete, and native remote I/O are all more urgent.
Analog is going well. We had some bumps in the road, but I think we cleared them this week.
I know the BRX EBC is coming along nicely, as is 32 point I/O. No specific launch date on those yet, but they aren't hard things to finish. Once the analog launch is past engineering dependencies and BRX production has settled into a nice rhythm, we'll get those launched.
-
Glad to hear analog is moving along. Our product is starting to get lots of attention and I'd love to move us over to the BRX soon. We need 16 4-20 inputs.
-
Can I jump on the band-wagon for DNP3 as well? It's like the Modbus of the Electric Utility/Generation world. Would also like to see native support of SDI-12. Very common for Geo-science type instruments (typically low power/low rate stuff like water well monitors, etc). This could probably easily be a custom protocol but having it as a supported things would be best.
Thanks!
I'm not familiar with it, but just scanned some info. The messaging seems pretty straightforward, and apparently there are subsets of the RTU protocol suitable for embedded systems. We don't have any current plans to support it, but at first read, I'd say Do-more could handle it fine as a custom protocol.
For DNP3 specifically...are y'all wanting master or slave side?
DNP3 uses the term outstation to denote remote computers as are found in the field. from https://www.dnp.org/pages/aboutdefault.aspx (https://www.dnp.org/pages/aboutdefault.aspx)
DNP3 has been adopted widely by power companies and water utilities where radios are relied on. Basically, it provides a buffer or backlog of data that updates the master station (SCADA) once comms are re-established. So the answer to the master or slave side question is really only slave, for which the protocol designers use the term "outstation". It's pretty exciting to think that Do-more could handle it fine ... even if it wasn't on the POM of the BRX initially. It would be great to see on the H2-DM1E and the T1H-EBC100 as well. And I have to agree with hulbert about SDI-12 support for serial as well.
-
DNP3 is definitely going to get a look. Not sure on form factor, but my expectation is standalone in an ECOM variant.
SDI-12 seems like it would take custom hardware. The protocol sounds easy enough. Since it requires custom hardware (with the 12V and single data line) it would make sense to put it into a variant of a SERIO, but since it is a multi-sensor bus, it sounds like overkill to have 3 or 4 ports on the module. Gotta think about that.
-
DNP3 is definitely going to get a look. Not sure on form factor, but my expectation is standalone in an ECOM variant.
SDI-12 seems like it would take custom hardware. The protocol sounds easy enough. Since it requires custom hardware (with the 12V and single data line) it would make sense to put it into a variant of a SERIO, but since it is a multi-sensor bus, it sounds like overkill to have 3 or 4 ports on the module. Gotta think about that.
Great news BobO, very encouraging to hear that there could be an ECOM variant for DNP3. The D2 group of products is mature (in a good way) and therefore a solid candidate. There's a fleet of "SCADAPacks" out there that Schneider seems to want to deprecate while having customers move to M580. The BMXNOR0200H product they have for the M340 line sounds similar to what an ECOM variant would be ... their combined market share seems worthy of a competitor. Would love to know actual stats on market share but I'm sure they are available somewhere.
SERIO-SDI12 with one port sounds like a great potential product as well!
-
Interesting that the group behind the WITS DNP3 variant has decided to try to broaden their appeal by a renaming to “Worldwide Industrial Telemetry Standard”.
http://www.witsprotocol.org/2018/01/ (http://www.witsprotocol.org/2018/01/)
-
A plain language description of the DNP3 Protocol for anyone who is a data comm geek or just curious... https://www.dnp.org/AboutUs/DNP3%20Primer%20Rev%20A.pdf (https://www.dnp.org/AboutUs/DNP3%20Primer%20Rev%20A.pdf)
-
For DNP3, would you just do Ethernet, or should we consider other physical layers like RS485? Just wanting to support what is in common use, not trying to be all things to all people.
-
Interesting that the group behind the WITS DNP3 variant has decided to try to broaden their appeal by a renaming to “Worldwide Industrial Telemetry Standard”.
http://www.witsprotocol.org/2018/01/ (http://www.witsprotocol.org/2018/01/)
I hope it's better than the old WITS, that was kind of a pain in the butt.
-
For DNP3, would you just do Ethernet, or should we consider other physical layers like RS485? Just wanting to support what is in common use, not trying to be all things to all people.
Certainly the Ethernet flavor would be the top choice! I recently watched a visiting engineer set up a connection to an existing SCADAPack(non-E) using VTSCADA and he made it look trivial. It's a bit more complicated using ClearSCADA but here's a nice writeup on that procedure. https://du5tin.com/2017/06/18/setup-clearscada-ethernet-dnp3-communications-to-a-scadapack-non-e-series/ (https://du5tin.com/2017/06/18/setup-clearscada-ethernet-dnp3-communications-to-a-scadapack-non-e-series/)
Many devices nowadays are trending toward direct network connectivity but of course there will be a considerable contingent of legacy serial remaining out there ... change in some parts of industry happens at a glacial pace. There are simple enough ways to address this for example using an Ethernet<->Serial conversion device such as a Digi One SP.
-
I hope we see both Ethernet and serial dnp on the Brx. I run/develop the scada for a power utility and in many remote locations we have serial radios operating in the 450 band . On these radios we have both reclosers with the ability to talk modbus/ dnp and plc’s with only modbus. We are forced to hold all of the devices on the radio loop at modbus because of the lack of dnp support from plc’s.
-
The system that Austin highlights is typical of many power utilities operating at 9600 or even 1200 bps. The ethernet converter I commented about would only talk to the head radio which kinda negates the benefits of ethernet. My "terms of reference" is a municipality with a robust ethernet 900mhz ISM radio network dating from 2005 onward. The beauty of DNP3 via Ethernet is that when links drop on occasion, as soon as they restore the built-in DNP3 buffer is polled and fills in the gap in data. I imagine the same would apply via serial radio. So yeah, seems there's a strong case for serial as well.
-
Bump.
There's no doubt that DNP3 is a very complex protocol to implement and integrate. Toto, I've a feeling we're not in Kansas anymore...
The view of it from a user perspective would be a data grid or lookup table where:
- the deadband for each analog value is defined so that only a distinct change-in-value is logged and eventually polled.
- the debounce time for each boolean value is defined so that only a distinct change-in-value is logged and eventually polled.
- each point is assigned a "event class" of 1, 2, or 3, to allow three different reporting priorities.
https://en.wikipedia.org/wiki/DNP3#Technical_details (https://en.wikipedia.org/wiki/DNP3#Technical_details)
-
Bump.
There's no doubt that DNP3 is a very complex protocol to implement and integrate. Toto, I've a feeling we're not in Kansas anymore...
The view of it from a user perspective would be a data grid or lookup table where:
- the deadband for each analog value is defined so that only a distinct change-in-value is logged and eventually polled.
- the debounce time for each boolean value is defined so that only a distinct change-in-value is logged and eventually polled.
- each point is assigned a "event class" of 1, 2, or 3, to allow three different reporting priorities.
https://en.wikipedia.org/wiki/DNP3#Technical_details (https://en.wikipedia.org/wiki/DNP3#Technical_details)
We love the idea. There's just too much on our plate at the moment.
-
Probably best not to be advertising products of our competitors here.
-
Understood. :-X I'll PM the mod rather than post.