Open Evonet1 opened 4 years ago
I believe we have to allow different physical layers of communication in different parts of the grid, but they can share the same data representation / application layer protocol. This is also related to what I tried to explain in this section of the standard.
(not meaning power-line communication, but only droop control based on local voltage measurement)
This allows to control power flows based on pre-defined voltage setpoints / droop curves. It allows for basic load prioritization and (hopefully) allows to maintain grid stability and ramp-up / black start (even with large inrush currents, as each controller is current-limiting itself).
Allows for improved higher-level energy management and monitoring and may adjust setpoints / curves of 1. It should be as cheap as possible (if it should be mandatory is not clear yet, as described in your document). In-band communication would be cool. But I don't know if it can be passed through a DC/DC converter. And I heard from others about issues with emission (WiFi not working properly anymore) and immission (communication not working depending on used charge controllers) of noise.
I tend towards using Bluetooth 5 mesh for this purpose, as it seems to have a long enough range, is well standardized, doesn't have vendor lock-in.
I think any of the wired comms except for in-band communication are not feasible, as you don't want to put a second pair of wire through the village, adding another potential point of failure and lots of cost. Don't think that normal Ethernet wires for example are suitable to be installed outdoors.
Used to synchronize multiple charge controllers, loads and inverters hooked up to the same bus, hard-wired to a battery. This is where I see the CAN bus being very useful. The communication on this bus is more low-level and not necessary for overall grid-control.
Similarly, a device providing a USB-C port with PD or a PoE device could be considered such a use-case. The communication happening in these interfaces is not directly relevant for the grid. But whether charging is enabled or not could depend on other types of communication from the grid (using method 1 or 2).
I basically agree with most of the points in Chris's paper. It would be great if we could find a reliable and inexpensive in-band communications mechanism that we could put in all devices but I fear this is not possible. I agree with Martin that the standard may need to include multiple communication solutions depending on the context.
I have mixed feelings about Bluetooth 5. It has the benefits Martin mentioned and is relatively inexpensive as components. In some of the Graham Pugh meetings, appliance manufacturers objected to any wireless solution because of the expense of getting certified. This could be mitigated, at a cost premium, if the transceiver was a separate, pluggable component, installed by the reseller.
One approach that I’ve been thinking about builds on Martin’s work with something like the following:
All managed devices are required to include a simple serial interface that we select such as Martin’s CAN bus interface.
All managed devices are also required to include a low-cost expansion connector such as Martin’s UEXT connector and a header that would permit an in-band device attached via UEXT to access the power wires. This expansion connector would permit either a wireless or PLC solution.
We provide reference software for the serial interface and a couple of other communications devices including an in-band device and a wireless device with reference hardware designs
My presumption is that most full-on grids will be installed by a reseller who will select the communications modules and configure the installation. In some small configurations, people may purchase a couple of conforming devices located nearby so they can use the hardwired serial communications.
A couple of specific comments:
Compatibility - whatever schemes we choose need to regulatory compliant and that, by definition, requires compatibility with existing equipment. There may also be country-specific requirements such as specific bands for PLC.
Domain boundaries - this gets to what defines a microgrid which I assert relates to devices operating under a single administration. I don’t think the physical protocol implementation will be problematic. WiFi and PLC have to deal with this problem now. But there needs to be some kind of configuration selection of what is permitted to talk to what, most likely in the form of a certificate or password in a master node. Other communicating nodes can join with a configuration button or smart phone setup as is done on many IOT devices today. The simple out-of-band serial solution avoids this by physical connectivity but boundary configuration reappears whenever there is bridging for remote monitoring and management. It seems clear that any wireless solution and any wired solution that goes beyond one physical containment such as a building or a room in a public space needs encryption.
Bandwidth and latency - Here again I don’t think there is a single solution and we need different solutions depending on the problem we are trying to solve. Responding in real time to load changes will presumably require a faster response than issuing tokens for PAYG. Nordman’s price algorithm uses a 15 minute update interval because he assumes each device will have storage and the problem he is trying to solve is big-picture energy optimization. My current feeling is that we need something that works much faster but this is an area that we will need to experiment with as the project evolves. I don’t think we know enough now to set specific requirements - hence the need for flexibility.
Enforcement - yes loads will be attached where there is power. The question is: what should the grid do about it? One policy could be that if the load doesn’t match the requested demand of enumerated devices then assert a fault. This is the right policy if the grid owner is trying to prevent energy theft. It might be the wrong policy if the owner doesn’t really care and is willing to tolerate unexpected behavior. I think the standard needs to accommodate both policies with some clear definitions about what happens in various circumstances under each supported policy.
Black start etc - this is an area where we need some feedback from appliances makers. There are a variety of potential solutions to the inrush problem such as random delays on startup, soft-start requirements, communicated sequencing etc. Some of these have more cost implications than others. I think the refrigeration people are sensitive to this issue and are interested in creating solutions but we need their input.
Radio interference - we can make some choices in this area but my default would be that DC devices need to conform to the same conducted and radiated limitations that AC devices must meet. The solutions in the AC world are relatively well understood if sometimes painful to meet. There is a duality between radiation and susceptibility. A device with bad radiation is often very susceptible to external signals and hence unreliable. I don’t think we can wave our hands and say it doesn’t matter for DC.
Energy efficiency - I don’t quite understand what Chris is getting at here. PLC has to deal with this problem now in the AC world and does so via receiver amplifiers with high dynamic range that can pull out a signal when the transmission network includes devices where input impedance is only the inherent RF impedance of household devices. That's one reason existing PLC devices are expensive. We might be able to simplify the problem by requiring chokes to create an RF impedance on device inputs but that has cost implications and might preclude attaching unmanaged devices. Out of band signaling only helps if the signal conductors are twisted and potentially also shielded, along with appropriate connectors. All this has cost and ease of wiring implications that make it problematic for a geographically dispersed grid. As I noted earlier, I think out-of-band wiring is a good solution for a compact installation but we need an alternative for a bigger grid.
InBand or OutOfBand.docx A summary of the issues when determining whether signalling for ODG should be in-band or out-of-band. Some critical choices are required!