Sharedsolar is a great example of how software can transform otherwise static infrastructure into one that can deliver a flexible, dynamic and easy-to-manage service, for both the provider and the consumer. Deploying micro-grids combining generation, storage and metering technologies – as we do in SharedSolar – is one approach towards bringing immediate service to the populace. Because of the distributed nature of the sites and the subscriber base, it is important that:

• from the operator standpoint, the assets deployed and service provided are managed efficiently with minimal downtime. An emphasis should be placed here on the design of modular systems to allow for later expansion and possible grid connection.
• from the consumer standpoint, they are provided with a high-quality service and the flexibility to pay for it when they are able to.

At the Modi Research Group, we’ve been continually improving our software platforms to address these concerns. Our software solutions consist of two major components:

• the Gateway – a web portal providing operator dashboards for the remote management of the sites. Aside from providing valuable insights into the operations, it also serves as the conduit between customers and the service over the mobile networks. Another key feature is the token management system crucial for tracking revenue collection, that could conceptually be tied-in with 3rd party services like mobile banking.
• the local intelligence – a software application residing at each Sharedsolar site and responsible for near real-time metering of each circuit, consumer credit accounting, aggregated log transmissions to the Gateway, alert mechanisms (system health, consumer credit and consumption), load/energy management and so on. It also provides the messaging interfaces for the Gateway to access the sites, web UI’s for local technicians to troubleshoot over and web service API’s for our local vendor solution using Android devices.

Distributed generation warrants distributed intelligence. Especially when the sources are intermittent renewables like solar (or hydro, or wind), it is important to manage the demand based on how much was generated. This requires data to be passed regularly between the metering devices and the management software, and an interesting question arises about where the service responsibilities should lie. In settings with high-bandwidth, reliable (perhaps, IP-based) communication links, it might make more sense to have the intelligence situated at a central location, away from the sites. This is especially so from the software release/maintenance/control perspectives. In the absence of this communications infrastructure, it becomes imperative to shift a lot of the service responsibilities towards the sites themselves, as we’ve had to do in SharedSolar. Even the model of prepayment is affected by this decision; we’re able to provide pay-as-you-go simply because the accounting happens at the site and does not depend on data transmissions over an expensive and lossy channel (if we can call it that) such as SMS. A positive side-effect of having a high-level, software management system at the sites is the possibility it introduces of deploying standalone [smart] micro-grids.

It is also interesting to note how high-level software languages and frameworks (we use Twisted for local/distributed management and the Gateway is built using Pyramid) – same as those used to develop online services – can be leveraged to build these management systems. The ability to perform system integration with new hardware and add new service features like the Webmin and the web API’s for the local vendor devcies have been absolutely invaluable as we learn and adapt to situations on the ground. And I’m convinced that this would have been impossible within budget/time constraints if it were done at a level closer to the hardware (microcontrollers, low-level code etc.) More on this in a following blog post.