Keeping the Lights on with Python
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 123 | |
| Anzahl der Teile | 169 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/21219 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
EuroPython 2016123 / 169
1
5
6
7
10
11
12
13
18
20
24
26
29
30
31
32
33
36
39
41
44
48
51
52
53
59
60
62
68
69
71
79
82
83
84
85
90
91
98
99
101
102
106
110
113
114
115
118
122
123
124
125
132
133
135
136
137
140
143
144
145
147
148
149
151
153
154
155
156
158
162
163
166
167
169
00:00
Dämon <Informatik>Red HatSystemprogrammWechselsprungDienst <Informatik>RechenwerkFrequenzDesintegration <Mathematik>Netz <Graphische Darstellung>Physikalisches SystemSystemprogrammComputerarchitekturBitQuick-SortAssoziativgesetzDifferenteEnergiedichteSoftwareRechenschieberTypentheorieEigentliche AbbildungWorkstation <Musikinstrument>Faktor <Algebra>SystemprogrammierungDienst <Informatik>Zentrische StreckungSummengleichungProdukt <Mathematik>GeradeGenerator <Informatik>KonstanteARM <Computerarchitektur>Projektive EbeneGeschlecht <Mathematik>WechselsprungComputeranimation
03:24
EinsLastFrequenzFeldtheorieGeschwindigkeitWasserdampftafelDatenfeldDiagramm
04:35
FrequenzVerschiebungsoperatorEinfacher RingSystemprogrammierungDreiHydrostatikGasströmungProdukt <Mathematik>Exogene VariableSchwellwertverfahrenLaufwerk <Datentechnik>Virtual Home EnvironmentSoftwareDiagrammMetropolitan area networkMalwareKonfiguration <Informatik>Formale SpracheReelle ZahlProgrammGamecontrollerSoftwaretestSummierbarkeitMAPErschütterungFrequenzgangExogene VariablePunktspektrumMereologieDatenloggerEreignishorizontProzess <Informatik>FrequenzResponse-ZeitSystemprogrammierungProgrammierungWeb SiteDynamisches SystemResultanteCASE <Informatik>HardwareKonditionszahlPunktArithmetisches MittelNetz <Graphische Darstellung>Quick-SortAggregatzustandKlasse <Mathematik>System-on-ChipPartikelsystemAnalysisProfil <Aerodynamik>GamecontrollerZusammengesetzte VerteilungFront-End <Software>SoftwareRechter WinkelCodeSoftwaretestCoxeter-GruppeVariableEinfache GenauigkeitPlastikkarteMeterSchnittmengeTypentheorieATMVersionsverwaltungDiagrammGüte der AnpassungPhysikalisches SystemComputerarchitekturWeg <Topologie>Produkt <Mathematik>MikroprozessorTermSoftwareentwicklerMathematische LogikFaktor <Algebra>Generator <Informatik>MultiplikationsoperatorTaskCoprozessorNeuroinformatikLastRuhmasseNatürliche ZahlMathematikZweiGruppenoperationProgrammbibliothekMomentenproblemFreewareTrennschärfe <Statistik>GrenzschichtablösungModemDebuggingEinflussgrößeViereckGraphDifferenteInjektivitätFunktion <Mathematik>BitFormation <Mathematik>RichtungFächer <Mathematik>VollständigkeitProtokoll <Datenverarbeitungssystem>DiagrammFlussdiagramm
14:05
TrägheitsmomentCASE <Informatik>Exogene VariableBitComputersicherheitFrequenzWeb SiteProgrammierungDynamisches SystemSoundverarbeitungInstallation <Informatik>ZehnNetz <Graphische Darstellung>Zentrische StreckungLastSystemprogrammierungTermFlächeninhaltFaktor <Algebra>Faltung <Mathematik>ErschütterungPhysikalisches SystemWeb logInstantiierungTopologieTypentheorieFormation <Mathematik>MereologieVorlesung/KonferenzBesprechung/Interview
Transkript: Englisch(automatisch erzeugt)
00:00
Welcome all to using Python to give the last one. Give Scott some clapping. So this talk is really about, well, I guess it's more of a celebration.
00:20
The last talk was excellent about the architecture and such. I guess this is a compliment in that we talk very little about the architecture. But it's more about talking about the problem that we're solving and why we like using Python so much to solve it. So I'm the technical director at LimeJump. We've been going as a company proper for a couple of years.
00:44
Next slide. So LimeJump is a utility in the UK. We're able to trade energy. And the thing that we're interested today in is aggregation services. We're going to talk a bit more about that in a minute. But we work with small companies in association
01:04
with National Grid. So the National Grid in the UK own the High Vault Electricity Network just for England and Wales. And they work to maintain that. And also they try to keep supply and demand of electricity balanced. And that's kind of where we come in.
01:24
So if we go back to 1870 or 1933 in the UK when our first national power network was created, you had big, mostly coal powered power stations that created a large amount of power
01:42
which was then distributed through high voltage lines across the country going into lower voltage lines, eventually down to big factories, smaller factories and consumers. Now that worked well back in 1870 and 1930s. But things are changing now.
02:01
We've got concerns about climate so we don't want to have big coal fired power stations or other big stations for that matter. And there are new types of power generation coming in like wind, solar generation, we've got some wave power and other things like aerobic digestion where you use waste food products and animal manure
02:22
to generate gas which can then power engines which produce electricity. And we've got landfill gas which is methane coming off waste to produce electricity again. And just now things like batteries are coming in. So the power network has to change
02:41
to meet these new challenges. So this is the kind of thing that we're starting to see. So we're getting a much more distributed power system. So you can see some solar panels and some aerobic digestion there and all sorts of different ways of producing power. And they're working on a much smaller scale.
03:01
The amount of electricity they generate is smaller. They don't come down these high voltage lines so much as more local systems. So we need to start controlling them more locally to balance the grid. But really, what do I mean by balancing the grid?
03:26
So if you think back to the original power stations, you had a big coal fire boiling water up, turning it through turbines. That would turn a huge shaft and then you go back to your magnetic field theory.
03:42
If you turn a shaft and magnetic field, you can generate electricity. And the speed of that shaft is proportional to the frequency of the AC current you get out. So what we're trying to do is to keep this shaft moving at a constant velocity so we get 50 hertz out. So what we have to think is if there's too much load
04:03
on this shaft, say you've got too many lights on, or for example, a power station is broken down, then this shaft is gonna start slowing down because there's not enough power to push it. The frequency of electricity will go down and vice versa, if it's the middle of the night and no one's really using electricity
04:22
and suddenly the wind starts growing very strongly in Scotland, as happens sometimes, you get too much wind power. So there's more supply than demand and the frequency starts to go up. So that's kind of summarized here. So when supply is able to demand,
04:40
which is where we want to be, everything is at 50 hertz. And then as supply is outstripped by demand, the frequency goes down. And when supply is higher than demand, then the frequency goes up. And really what we're trying to do is to keep it within 49.5 and 50.5. In reality, we keep it in a much tighter band than that.
05:01
But when we start getting to these points, then we start having problems. Electronic equipment will stop working in some cases. And if things get really bad, you'll get a complete blackout and that's really not what we want. So that's where we come in. So as I said earlier, the National Grid's job is to balance supply and demand.
05:23
So they have products which we work with customers. So we work with lots of small customers who aren't big enough to go to the National Grid directly. So we coordinate their response and then sell them as a group together to deliver different products to the National Grid.
05:42
The one we've been working on for the last year or we've been starting to implement for the last year with customers is a static response. So when things are getting quite bad, so when frequency goes down to 49.7 or up to 50.3, we either get customers who produce electricity
06:01
to turn things on if the frequency's gone low or if they use electricity, we get them to turn things off. And vice versa, when the frequency of the grid goes too high, we get people who produce electricity to turn their production down or customers who use electricity to turn their usage of electricity up.
06:20
I'm going to touch upon this a lot more and how we do that. But then also in the future, we're going to be starting to look at things like dynamic products where we track the grid frequency so we keep it in a much tighter band and you get two seconds to respond to a change in grid frequency and then enhanced frequency response which is responding very quickly
06:43
and that's coming out in the future in the next one to two years. And there you have to respond to a change in grid frequency within one second, so the only thing capable of doing that at the moment is to have a big battery and to turn the power output from the battery up and down. So what exactly do we do and where does Python come in?
07:04
Well, because we're working with lots of small customers, we have to go and install a panel on each of their sites so this sits with generators or with factory equipment. And we have a PLC in there, a Programmable Logic Controller which is an industrial computer effectively
07:21
that you can use for automation tasks. We have data being back for the 3G modem. We have a quad core, it's a Raspberry Pi-type device where all our Python sits at a customer site level. And also we're starting to use things like Arduinos to control and measure customer equipment.
07:42
And also we have power meters which sit on the power lines out of equipment so that we can measure what's going on, how much electricity they're producing. And we do this, we monitor power every second so we can see second by second how much power a customer is producing or using.
08:02
We measure frequency on site so we know what's happening in terms of frequency on site 10 times a second and we also measure what our system is doing 10 times a second so we can keep track of whether everything's performing properly. Now, for those of you in the last talk,
08:20
this is a very similar architecture to the one being discussed in the last talk. I'm not gonna talk about it quite so much. Other than to say that the data logger there is pure Python and everything, to the right of it is also pretty much Python except the front end stuff.
08:41
And everything to the left of the data logger so the sub-meter controllers and PLCs, they're in a mixture of C and PLC code, which I'll show in a second, which is some ladder logic and some programming by diagram, really. And then we've got industrial power meters which we communicate through a protocol
09:02
called Modbus from the 1970s. So we've got those connected to assets and we can also control assets from there. I should also point out the data logger doesn't just log data, it also sets up the PLC so we can have a semi-autonomous response to events.
09:20
So the PLC is the part that responds when frequency goes out of the spec that I was talking about earlier and it's also the PLC that controls the output of an asset if we were to want to do dynamic or enhanced frequency response. So that's kind of how we do things. Why do we use Python?
09:40
Well, it's fast to develop. This has been developed within two years, really. I think we've written virtually everything that's in production now within the last two years, which I come from a C and C++ background. I don't think we could have done this if we'd used C. There's a huge selection of free libraries.
10:00
I'm preaching to the converted, I guess, with this, but it's transformed the way that we can do things, especially with things like Modbus and the testing. I'm a big fan of pytest, so we use pytest in all our testing and I stay lastly, we use Python, so I can come to EuroPython each year.
10:25
So where have we been having problems with Python? That's a good question. We haven't been having massive problems with Python. We've been moving to asyncio recently and we've cut down our load on our embedded processes,
10:41
the processes of the customer sites by five, tenfold by using asyncio, so that's been really great. We think it's not quite as elegant as it could be, but that seems to be changing a lot with each new version of Python, so we're really enjoying using that. But I guess the biggest problem we have is finding good Python developers in London
11:03
which I'm sure lots of people can sympathise with. So that's kind of really our problems or things that we've been using. Where would we like to use Python? Well, as I said before, I like to talk yesterday on the micro bit and starting to use Python in microprocessors.
11:24
The diagram on the right is part of the PLC software that I was talking about earlier. I've spent days and days with our PLC suppliers debugging this software. It's tricky, it's very, very tricky. This is the kind of code you get.
11:42
You can't put test harnesses around it very easily, so you end up having to try and create every single situation by a mixture of forcing variables within the program and creating the conditions with IO and hardware to try and test it. It's going to respond how you want it to respond in each way.
12:01
So if anyone has any ideas for getting us out of using PLCs, then I'd be really, really pleased to hear them, especially if it's using Python. I'd also say we've been using embedded controls with C, but again, that's not quite as nice in my opinion anyway.
12:21
So what are we going to do next? This is a test case from last week. I spoke about dynamic frequency response. So if you look at the second graph down, you'll see this is a test profile we've injected into one of our panels. This is a battery site.
12:40
So this is a big solar panel array with a 800 kilowatt battery attached to it. So the battery is charged up by the solar array during the day, and then we can discharge it when the customer can get the best prices for electricity. So what we've done here is we've got a charged system. I should say SOC stands for state of charge. So 140 actually means 70% charge
13:03
because there's two battery systems attached. So what we've done is inject different frequencies into that, and if you look at the top one, the kilowatt out, so that's the kilowatt output of the battery, mirrors the frequency. So as frequency goes down, the output of the battery goes up and tracks pretty much the frequency
13:23
as it goes up and down, and you can see the battery discharges and then charges again as we use the power in different ways. So once we've done that, our next job is gonna be delivering dynamic response, and which I haven't mentioned now, this is response at a local level. So this is just a battery responding to the grid.
13:43
What we're looking to do next as well is to have a response across several pieces of equipment. So we might have a engine and a battery, maybe solar farms as well. And what we're looking to do is have each one of them produce their own individual response,
14:00
which when summed together, creates this kind of group response. This means that a lot more customers can get involved in this program and we can give a larger lump of responsive power to the national grid, so it kinda helps everyone. And let's do some more Python as well. And that's it.
14:32
Who has any questions?
14:40
Thanks for the talk. At what kind of scale is this running? How many of these devices are running? So we had our first site installs last year. We're now in the tens of installs. Probably by the end of the year, we'll be moving up to hundreds of installs and on from there. In terms of power, sites range from about 100 kilowatt
15:05
for small sites up to a couple of megawatts for big sites. So if you compare that with a power station, a power station might be 1300 megawatts. So we're rising very quickly. So it is getting bigger and bigger.
15:24
I'm not sure if I understood this correctly from what you said earlier, but is it the case that when demand falls so much that the frequency is at risk of rising or demand rises and the frequency is at risk of falling, that you will get large users of electricity
15:42
to use more or less? Yeah, that's right. And is there a possibility of doing this? I guess you can do that very easily with huge users, but with embedded systems in all kinds of devices in people's homes, you could presumably get ordinary things like fridges
16:02
and heating systems and so on to use more or less appropriately. Is that a possibility? Yeah, yeah. So we've started the industrial scale because it's easier to have a viable business at that scale. But as we refine our technology, we can move into smaller and smaller producers. So in the end, hopefully, yes,
16:22
we'll be able to use home supplies. So if you think of a fridge, for instance, a fridge is only on some of the time, but if you had 1000 fridges, you could predict the base load that the aggregated 1000 fridges use. So yeah, yeah, that's definitely what we're aiming towards.
16:41
How much was security a consideration? Because I could imagine if these systems are hacked, you could destabilize the power grid pretty easily. Yes, because security is a big consideration, yeah. So yeah, we can turn on and off these big batteries and engines. So yeah, that is something we think about a lot.
17:01
Yeah, I don't want to talk about that a bit too much. Yeah. So is it the case that when the frequency drops, you respond, but what happens if you respond and somebody else responds and somebody else responds?
17:22
Isn't there a risk? How do you not like yo-yo? That is very true, actually, and has happened. So we're all employed by the national grid, so they know how much the response will be. So they contract out a set response, but you're right, it has been seen on a few occasions
17:41
where everyone responds at once, and you go from having low frequency to having high frequency. So yeah, that's one for the national grid to sort out, luckily. But that's why they're moving to the dynamic responses, because of course, they're much more granular, so they correct things much more quickly, so you don't get that yo-yoing.
18:01
I should probably also mention that when we're moving away from these big rotating shaft-type systems, the power generation, the coal-fired power stations, we're losing a lot of inertia in the system, which is a stabilizing effect. So a big shaft turning acts like a flywheel, whereas with things like wind, they don't have a flywheel as such,
18:20
because they're electronic-inverted. So yeah, as the UK reduces that, we're gonna become more unstable, so we have to be more careful to stop this swinging up and down a frequency. Any more questions? Great. Give. Yeah, I'll answer questions if anyone wants afterwards,
18:41
or, yeah. Cool. Yeah.