Writing a case study
jeremyh last edited by
I am going to write a case study, for Infinite Automation, on how our organisation has used a MangoES exclusively to monitor over 1,300 data points on an off-grid, hybrid power station.
The power station itself consists of 300+ kW of PV (over 1,200 panels), 320 kVA of diesel generation, and over 700kWh of lithium batteries, and is of utility-grade design. The total project value is in the millions.
I am open to suggestions from the community for the kind of details and information that people would be interested in seeing, most specifically with respect to the use of MangoES product/software.
For commercial reasons I am unfortunately limited in the detail I can disclose, as the project represents significant integration and design work. But if anyone is interested I can always try my best to answer.
Jeremy, that sounds like an interesting case study.
I personally would be most interested in the many "if this happens then do that" your system must have. Your experiences with them. Monitoring data points is a bit old hat. What is done with that data is the most interesting part of any such system.
Also the unique challenges this plant/system faced. How you designed the system to deal with them.
jeremyh last edited by
Thanks for your interest.
Let me provide some more detail.
In our initial design, we opted not to use Mango for any control. We instead use a specific, purpose-built controller from the battery inverter manufacturer. The operation of the station is obviously quite complex (especially when you get down to the power flow stuff) and the controller has to interface with the inverters and batteries via CAN and issue very fast and complex/proprietary commands. It just wouldn't be appropriate to even try to use Mango for this application.
Instead, Mango is used for monitoring only. This way, if the server crashes or locks up for some reason, the autonomy of the station is not compromised. The MangoES box polls and logs data from all the station devices (PLCs, protection breakers, battery inverters, battery controllers, PV inverters, diesel generators, weather instruments, panel instruments) , and then we use the Persistent TCP module to a few hundred of these data points to our main Mango server via VPN (we have two redundant internet links with auto failover).
Technicians in our office are therefore able to log into the MangoES box and view any of the 1,300 monitored values in real time, which has proved to be incredibly valuable. We also use DGLux to display some really nice graphics of what the station is doing, which we display in our office.
Visitors are, without exception, impressed by this! We also provide our end customer with access to these dashboards, and I cant imagine them having a better source of data about the performance of their system.
So the original scope for the MangoES did not include using it for control. However, since Mango is 'plumbed in' to every controller and system on the station, some interesting possibilities have arisen since we commissioned the station.
For example we had a minor issue (a result of a bug in the firmware from the battery manufacturer, basically - which they later fixed for us) that had the effect of overheating our battery inverters to the point of shutdown.
Because Mango had access to all of these devices, we were able to write a script that detected when this condition was about to occur using one set of sensors, and then issued instructions to another bit of hardware in order to slow the overheating.
So we did not have to fly an engineer 1000km+ to site to fix the problem - instead we implemented the workaround over a morning coffee!
As the station continues to operate, we do occasionally find that we have unexpected needs. For example we found that a piece of hardware needed power cycling every so often - a relay hooked into our PLC, controlled by Mango, gives us an easy way to do this manually. At some point in the future, I will set Mango up to watch for a 'no change' condition on a data point from the troublesome device to power cycle it automatically.
We also found, a month or two after commissioning, that we had a need to monitor the voltage of our 24V DC supply (which is backed up by batteries). We were able to implement this by reading the DC input voltage of a piece of networking equipment, using the SNMP module! Again, huge expense saved.
Once I figured out I could do that, I also used Mango to detect - and create alarms - for the dual internet setup, which warns me if one has failed.
Of course, Mango is also a great way to receive alarms when various conditions are detected, such as breakers tripping or equipment showing faults, using the standard event detector and email action. We send emails using a 3rd party transactional email service (sendgrid) so as to ensure prompt and reliable delivery.
Feel free to ask further questions.
Great start of your case study.
Interesting that you write "we opted not to use Mango for any control. We instead use a specific, purpose-built controller from the battery inverter manufacturer".
Please do tell, what controller is that? Why do you write "It just wouldn't be appropriate to even try to use Mango for this application."? I guess you would have to write a large amount of script to replicate that controller.
But still... In my experience Mango is in theory as solid as any of the Siemens, ABB, etc proprietary "Industrial Grade" controllers and a lot more flexible. Problem usually is the "bankability" of using controllers that are not Siemens, ABB, etc.
What might help is to figure out an automatic Mango failover to another Mango System. Looked into that.
One of the systems we manage is a 50kw. 100% Off Grid solar system. Mango has controlled it uninterrupted for over 8 months now. Not a single down second.
Looking into have Mango do the same on two new MW systems.
Interested into your future case writings.
JoelHaggar last edited by