Mixed signals
In demand response schemes, generators and consumers are incentivised to adjust their operation for balancing by reacting to a signal from the party responsible for the network, i.e. the transmission system operator (TSO) or distribution system operator (DSO). A common problem with this is that consumers and the grid operator do not speak the same language and send mixed signals to each other, which is a problem. What does reducing 50 kilowatts for 15 minutes mean in a building? Building automation and management systems of today are typically not cut for these tasks. Not to even mention conducting coordinated responses, i.e. using multiple electrical loads in a building in a controlled and secure manner for demand response. On the other hand, TSOs and DSOs know what they need to keep a grid secure, but can not find ways of expressing the need to parties that can provide the service most effectively: consumers.
There is a clear reason for this. For decades, demand response was a playing field left for large, mostly fossil-fuel-powered, power plants or industrial consumers. Operators of these large power plants had the ability and will to access demand response schemes run by TSOs and DSOs because it was an effective way of making money. However, the energy field is disrupting, which leads to a decentralisation of production capacity and hence brings forward the role of active consumers. This is concretely manifested by the solar panels on your neighbour’s roof and the battery she bought with it. Electricity in bulk tends to be cheap, but with controllable resources that determine when you generate or consume electricity can provide a valuable service to the power system, and TSOs pay for it. Buildings have substantial amounts of electrical loads, which fit this description and can be run without major disruption to anyone.
APIfication of building loads
API, application programming interface, is a description of a resource that a programmer can use in a standardised way. By providing the necessary inputs to the interface, the programmer can get a response in pre-specified, standard form as defined by the API. The programmer does not need to exactly know what is happening behind the scenes, she just needs to deal with the interface and use it to achieve the result she wants. An example of an API is a Google search: By providing a set of search words, the search results are provided back by the API.
Kapacity.io aims to recreate the effect in demand response markets that well-functioning APIs have had on software and data science. We believe the best way to do this is by providing building owners and operators an easy way to join Kapacity.io’s platform and start earning from a variety of demand response markets, and for electricity market players a straight-forward way of using these loads in their operations. Hence, we enable them to speak the same language.
We are only in the beginning, but are starting out by being ourselves the main users of our product together with our customers. We let real-time data and customer demands be the cornerstone of our development process. By working together with most relevant stakeholders, building owners and operators, and electricity market players, we are building a demand response service that is only one click away from consumers to take advantage of their assets.
Work with Kapacity.io
If you’re a forward-looking owner or operator of buildings and real-estate or someone who might benefit from demand response in electricity market trading, just send us a message to hello@kapacity.io. Come part of shaping energy services of the future, by testing our service together with us.
-Rami
CTO, Co-founder
Kapacity.io