PNPSCADA integrates with the DCv3.

The DCv3 only does something like 450 meters max, but you can have multiple DCs on the same LV segment. However that is problematic, because the meters join either the one of the other randomly on startup, unless you specifically white/black list them in the DC configs, which is a lot of work. The Meter HAS TO always connect to the same DC, otherwise how can it read the meter profile and keep a coherent history on that.

The DC has a mobile connectivity plug in module, and also supports some LAN ports, where you can plug in a local or a network ethernet cable (the Ethernet RJ plugs)

The DC assumes that you can browse its IP over HTTPS (you have to ignore the certificate domain in terms of authentication). So in that sense, if it is directly on a Mobile network, you need an APN or some kind of a static IP accessible from the PNPSCADA server. Some customers report that dyndns works for them on some networks.

However, on PNPSCADA you can actually either configure the DC on a Generic APN (TCP/IP address and PORT), OR you can configure it on an Active Etherpad or GPRS modem connection. The way THAT works, is that you'd have some unit in the field that connects to the DC locally on the appropriate port for an HTTPS (SSL) connection (connected to the DC with a small ethernet cable), and then that connection is BRIDGED with another connection that connects out to the PNPSCADA server on the IP and PORT as configured for the Active GPRS modem or Active etherpad entity on PNPSCADA. A connection like that can happen through e.g. a Raspberry PI or Beagle Bone Black or any other kind of device capable of both an ethernet connection and a connection out over the internet.

So, PNPSCADA submits HTTPS functions like GET and POST on the DC to read the config on the DC and also to wrap DLMS commands in xml that is sent to the DC over HTTPS, and the DLMS reply is also wrapper in the body of the HTTPS transaction, and the binary data changed to ASCII. The protocol is generally the same as though the server talks DLMS directly to the meters on the other side of the DC, except that it uses LN addressing to the DC, whereas the meter directly uses SN addressing. There is also one other small difference in the Cosem Attribute number for switching the breaker on the E460 on and off.

The one exception to this rule is that the Profile of the meters has to be read from the DC, not by the repeating option directly from the meter. Reading the Profile data over the repeating feature works for the first two weeks or so, but after that, it simply fails, and PNPSCADA is forced to read the Profile data of the meters from the DC.

The problems with reading the Profile data from the DC instead of from the meters are:
1. The data in the DC for a meter might not be up to date. If PNPSCADA reads the meter data after midnight, the DC has not read it yet, and the reading attempt from PNPSCADA will fail, because the data up to midnight is not in the DC yet. This can be mitigated by specifying the offset for the Profile schedule under Advanced Meter Settings in PNPSCADA, but it often happens that a meter's data in the DC might be more than a day or two old, because of Load Shedding interfering with the DC's ability to read the meter data up to date in a timely fashion. What makes the situation worse, is that there would typically be hundreds of these meters, that PNPSCADA has to try and read one at a time from the DC, and PNPSCADA basically try to read them all every half hour, with no success. This causes horrendous performance problems.

2. If the configuration of the profile in the DC and of the profile of the Meter is not in track, it can cause untrue or corrupt readings in PNPSCADA. Care is taken to try to assure the interpretation is accurate, but things can go wrong in this regard between the DC and the meter.

3. The DC doesn't keep a long history on the profile. I think you have 3 weeks or something like that, before the old data gets deleted. So this means, that if for some reason you didn't read the meters for 2 months and then get connectivity back, you have to send technicians to read profile from the meters with an Optical Probe, because the DC doesn't have the missing profile available any more.

Another reason the profile data in the DC might be old, is because the G3-PLC meters in South Africa takes a very long time to build their network through auto-sensing after a power failure. This is because when Landis & Gyr did their pilot for Eskom in Alexandra, South Africa did not have a lot of power failures (Load Shedding) yet, and the most reliable setting they came up with, has the meter connecting to its keypad over G3-PLC for the first hour after startup, after which both meter and keypad try to connect through a DC if available. (this is a setting that can be adjusted in the Landis & Gyr meter with the appropriate software, I think (dot),MAP120). So Load Shedding is really the Bane of Landis & Gyr's G3-PLC solution in South Africa.

What makes it worse, is when the DC connects to PNPSCADA, PNPSCADA now tries to read the meter data. If this then causes DLMS transactions to be repeated over the G3-PLC network, after a power failure when the Landis & Gyr DC and meters are still trying to figure out their fancy network topology, with repeater nodes and all, which takes hours, it slows down the network building process, and that in turn slows down everything, the problem being multiplied by the sheer number of meters on the network.
To mitigate that problem, we advise people to read only profile from E460s configured on a DCv3, and switch off all other checkboxes on Advanced Meter Settings. We have optimized the code to not do unnecessary reads from meters, and to cache certain values like the profile columns, the first time it reads the meter (PLEASE make sure the profile columns on the meters are configured correctly BEFORE you add them in PNPSCADA). In this way, we try from PNPSCADA's side not to interfere with the Landis & Gyr Network building taking place after a power failure. However, you have to disable everything except Profile, because everything else still uses the normal DLMS protocol of the E460 meter. Which means, it goes out on the G3-PLC network.