 We will discuss how to make self-to-applications more carbon aware. So thank you, Simon, feel free to talk. Thank you. Thanks for the introduction and thanks to all the folks that are still here around. I know it's the last day of a very eventful week, so I appreciate you being here. I hope you enjoyed the conference so far and are ready for the second to last, I think, talk of the conference. For me it definitely was very fun. So I'll be presenting on the concepts of the green software. Some folks here might already be aware of them, of those who aren't. I'll be going through the basics as well. And this normally, because the tooling I'll be explaining later on, the carbon-aware SDK, normally sits higher up in the stack. This is not directly on embedded. This is going for workloads in the cloud. But the green software obviously targets everything from hardware, from the silicon, all the way to big applications. So I'm really hoping to get some input from you as well. And while I'm explaining these concepts, just give it a thought. And I'll give you some time throughout the talk to answer any questions or jump in with your thoughts and ideas. So I'll sort of maybe with who I am. Some of you may know me, some of you may not. My name is Srimon. I'm an open technology engineer at Avanad. And I'm also co-chairing the carbon-aware SDK project, which I will be mentioning later on in the talk. It's a project that is developed and maintained by the green software foundation. So make sure to check it out after the talk. Recently, for those of you who've seen my Tuesday talk with Jakub, I've talked about I've been getting more into the embedded space more. It's been a thing I really enjoyed doing in my spare time and at, well, earlier stages in my academic history. So it's good to be going back to it from the open source side of it. I'm currently a final year student at the master's program from computer science at University College London, but I'm not putting the logo because I didn't ask for permission in time. But imagine it's there. And yeah, as mentioned on the slide, I double in the areas of game development and embedded systems, IoT, cloud engineering, and I'm pretty crazy about wind surfing. So if there are any surfing folks in here, I can chat to you about that afterwards. So the talk I already kind of gave a brief introduction, but we'll start off with an intro to the green software foundation, what it is. What are the core principles of green software, which we should be thinking about, with a slightly deeper dive in the carbon awareness and also in the hardware efficiency part of it. And finally, if you have the time for it, we'll do an intro and a demo of the carbon awareness decay. So the project I've been co-chairing and a lot of folks developing. So if I can just do a hands check, so raise your hands, who has heard about the greens of the foundation in general. So we have three folks on the audience. Okay, so we need to increase our external visibility, but that's good that we have some knowledge and I'll introduce that in a second. But first of all, just a quick stat, because people love stats. And software-related CO2 emissions in general are actually, they account for roughly 4% of the current world emissions, right? So this is more than the air rail and shipping industry combined, right? So it's only 4%, so it doesn't sound like a lot, but like, you know, it's bigger than this. So we make an impact and there's surely a lot of work for us to be done in that area. So what is the green software foundation? It's a foundation under the umbrella of Linux Foundation and it's a non-profit and it aims to build a trusted ecosystem of people, standards and tooling and best practices for green software. So for building more energy-efficient software and, well, hopefully, for building more energy-efficient hardware that software will be running on. If you want to learn more, please visit greensoftware.foundation and you can learn about the manifesto, the mission and the vision of the entire foundation. So what we do at the GSF, as we abbreviated it to, is we have discussions that cover basically the full stack of software going from cloud applications all the way to hardware. But we are missing the expertise of embedded folks and a lot of the people involved in it are not experts in the field, they're not embedded systems designers and engineers. So although we try to encapsulate that as well, because this is a very important part of where the emissions come from, where the energy consumption comes from, we need your input in it. And if you are members of Linux Foundation and a lot of people here I think are, you very much welcome you to join this and share your expertise with us on the topic. We are already collaborating with CNCF, so the Cloud Native Computing Foundation, on implementing some of the tooling and on extending the standardization around green software. But again, we would love more input from people working closer to the hardware. Here's just an example issue that Chris linked to me of some of the collaboration that's been happening in this space between GSF and CNCF. So either feel free to jump on those threads or just join the GSF GitHub and see what's happening there. And why should we care about it? Why should embedded engineers also care about it? Well, basically some of you might be aware of the greenhouse gas protocol, which defines the scopes of emissions of software, and it's split into three scopes. There are the direct emissions, so things like company software, company facilities and management. So if you actually have some, for example, forklifts running around in your company, right? Or the scope too, which are indirect emissions from electricity purchased, steam, heating and cooling. So this is stuff you import from other providers, mainly electricity, to sustain your business, sustain your whatever you might be doing, even at your house, right? And then finally there are the scope-free indirect emissions from downstream and upstream activities. These are generally the hardest for everyone to calculate, because these come from things we do not, well, directly buy, but are somewhere upstream or downstream in our actions. So obviously if we produce open source software, it's very hard to know who is using the open source software, right? And where it's actually running, so it's hard to find the footprint of it. And green software actually touches on... Oh, it goes through every single scope in here, right? So from the direct emissions from some of the chips, the software might be running on all the way to downstream stuff. So green software principles is a set of core ideas. By the way, maybe before I go further, are there any questions about this part of the presentation? If not, I'll just jump on. If you have anything, just feel free to shoot your hands up. We don't have a lot of people, so we have plenty of time to answer questions. Green software principles are some of the core ideas behind building greener and more sustainable software. And the GSF tried to encapsulate them in a few, and the next few slides will cover them in some detail. I'll also link out to a training portal where you can learn more about it and even get a LF cert if you want to increase your knowledge in the space. So there are three main ways how we can improve and reduce the carbon footprint of our software. The first one, and most obvious one, is energy efficiency. So consuming the least amount of electricity is possible. This might be by improving the efficiency of our software running on our PCs or chips or through other means. And the second way of how we can do that, which is a bit harder to target, but still just as important, is through hardware efficiency. So one of them is using least amount of embodied carbon. I'll introduce that topic in the next slides. And well, for just building more efficient hardware. So yeah, when I get to it, I'll give some more examples. And then carbon awareness. So the last one, which is the least obvious normally, people don't really think about it as much, is in principle doing more when electricity is clean and doing less when it's dirty. Well, we wouldn't want to do it the other way. Or unless you want the whole planet to burn down, I guess. But we don't want that. So starting off with carbon and energy efficiency. So those are the first two principles. And they are very closely interlinked. That's why I put them in a single slide. So the first one, so carbon efficiency is simply the idea of emitting the least amount of carbon possible. And energy efficiency is using the least amount of energy possible. Why it's important is because when we produce electricity, obviously we burn coal, we burn gas. Some of it comes from nuclear, some of it comes from solar, but in the end all of these actions emit some gases into the atmosphere. Not always carbon, but different kinds of gases. So by limiting the energy usage, we limit the carbon emissions and hence we'll save our pliers a little bit. And to not think about all of these different gases, different emissions, different pollutants, and to kind of bring it down to make it easier for us also software engineers to think about them, to kind of group it together, we normally look at greenhouse gases in the carbon dioxide equivalent, right? So we bring all of the different gases, methane and so on, and we recalculate how much methane in the atmosphere, for example, is equal to some amount of carbon dioxide. And this gives us a leverage point to build more standardized tooling, sorry, and to look at less of those gases, so we don't have to spread ourselves so thin and narrow the gap a little bit. An example, how you can recalculate is that, well, methane, as I already mentioned, is a gas that's actually 40 times more warming than CO2, so obviously we cannot just do a one-to-one mapping. We say that one ton of methane would be 40 tons of carbon dioxide equivalent. Energy efficiency, so the second thing I mentioned here, I should have actually jumped to these slides when I was talking about it, so you have some visualization, again, just to resurfacing this, energy comes from different sources of gas. These emit CO2 equivalent, and this gets powered when we run software, so that's why when we do more software, we use up more of those guys on the right emit more CO2 equivalent. Also, another thing here worth mentioning is minimizing energy usage by maximizing utilization. I think this is a rather a strong idea in the embedded space is to use as much of the silicon as we can by compressing our software as much as possible and doing as many things on the limited silicon as we can. Basically, instead of, in cloud terms, instead of doing five servers at 20% utilization, we try to do one server at 100% or maybe to break it down to, so it's not fully throttled, but try to downscale the amount of hardware that's running, but upscale the usage of it, the percentage of what we use. Here comes, I guess, the most interesting part for you guys, the most impactful from the embedded space is the hardware efficiency. And it starts with embodied carbon. Embodied carbon is the idea that every piece of silicon we produce requires some carbon to be emitted, carbon equivalent, I'll be just saying carbon, because carbon equivalent is a bit too long, to be emitted in the atmosphere. So it's important to think about it in the long term and to try and use the hardware as much as we can with the embedded carbon making a small of an impact on the environment. And the one thing, one way how we can look at this is called amortization. It's basically the idea of, well, amortizing, embodied carbon is the idea of spreading the embodied carbon over the expected lifespan of a device. So if we look at the graph here, and we have our embodied carbon stacked up as 400 kilograms, and if we look at, for example, four years of usage, so if you use the device for four years, this equates to roughly 1,000 kilograms of CO2 emissions per year. And one very basic way and I'd say almost obvious way of limiting this, of decreasing this emission is by increasing the lifespan of our hardware. So trying to promote more of renewable markets, of reusing components that are already there, some things that some companies are starting to do is, well, for example, I'm going to bring up Apple, although they have some, well, yeah. Apple, for example, does recycling of iPhones. You can bring in an iPhone. Obviously you don't get a lot of money for it, but at least there's a chance they'll reuse some of the components. And some other companies do that too, it just doesn't count my mind at the moment. And that way, just by increasing the lifespan, for example, of a device by a year, we are already reducing carbon emissions per year by 200 kilograms. So quite substantial. These are obviously examples on big server stacks, like these values would never be the same for a single microchip and iPhone or a microcontroller. But when you think embedded, we need to think about IoT in this space and wearables. And phones. So this directly translates here as well to scale. So rather than each device having a big impact by itself, it's the number of devices that each have a small impact, right? But if we reuse MCUs or increase the lifespan of a lot of IoT devices, MCUs, this brings down the overall embodied carbon for the whole system quite substantially. So it's not just a single device, it's a lot of devices. Any questions or thoughts on that space, on the hardware efficiency, or are we all good to continue? Okay, so you are talking about extending the lifespan of the hardware, and that sounds noble, but I thought about one case, because for example, if I buy a laptop right now and use it for, let's say, five years, and then changes to another one, then of course the old laptop will go to waste and there are a lot of problems with that. But if I force myself to use it for ten years, then of course I don't have the problem of wasting the hardware for just a small amount of time. But it will be very inefficient in five years, and I'll be wasting a lot of power, a lot of time, and a lot of battery life and stuff. I might even waste money on replacement batteries and things like that, which will contribute to the overall effect. And have you done maybe some calculations, maybe do you have some ideas about what are the best strategies to offset those conflicting goals? Right, yeah, it's a very great question. I think the best thing to jump to when you're thinking about this is where is the actual trade-off point? At which time does the embodied carbon, increasing the life expectancy no longer matter for me to grab a new device that is more efficient, uses less energy? And because, well, this is a very fresh space, GSF was founded two years ago, I'm not aware of a project that is up and running and doing these calculations, but there is a project called CarbonQL which is looking at calculating the efficiency full stack of a device, but it's not doing the exact calculation you mentioned, right? So this is something that there is still an open space to look at. But going back to your question of when it's worth it, well, yeah, it boils down to doing the calculation. If you know that your device is, if new device's efficiency, you can calculate how much, for example, something I'll introduce in a second, it's software carbon intensity rating for running some application. A laptop is a hard thing because it's an OS and it runs all kinds of applications, but if it's an MCU, for example, that's running a single application, this is easier to calculate. If you change to a new MCU, we could possibly calculate its exact software carbon intensity, so how much carbon it's producing on that hardware. And then you could also compare it directly to your current MCU, and if then you compare, well, the embodied carbon difference versus that, this will give you exactly what you want to know, like when is the cut of point where do I switch one to the other. It's just that this calculation is difficult. We are standardizing this, if I jump to the next slide. We have defined and released a standard called software carbon intensity, which talks about three things, embodied carbon, so what we just mentioned, software efficiency and carbon intensity. And this gives an idea of some kind of score which allows you for measurement in time between devices for specific applications. This will not give you a comparison that can be compared across all devices, across all applications, but for those applications, it can. So yeah, and just finishing off, again, yes, we are working on it, but your input would be greatly appreciated in this space. Yes, so just a couple of thoughts. I don't want to take too long. So first of all, why there isn't a, I mean, it's a loose idea, like someone should come up with a solution like the calculator that I got, this and this equipment, for example, I'm a end-game gamer and I need to, I don't want to update my RTX to the newest one or I have this and that fleet of MCUs and should I keep on running them or would it be better in terms of power consumption and total cost to replace them with newer ones or more, let's say, more green, right? So that's like, I know it's a very difficult problem to solve, but having such a platform would be definitely beneficial to both big players in the field and people who produce tons of, and just implement tons of them, of the devices in the field that we're speaking embedded here and like regular end-user like me who's considering just changing my laptop because it's, well, yeah. What do you explain just a moment ago? Yeah, exactly. And exactly this is a perfect formula that would go under the umbrella of Green Slaughter Foundation. This is one of the things that we want to target, because getting there is first finding the standardization of how you calculate it. This is something we have already, well, defined, right? There's total government intensity. If you Google that, you'll be able to find the spec of what you should be looking at. The issue is where do you get the data and how can you then compare it against other things? So on a gaming example, you could, for example, define exactly, hey, I'm running on an RTX something. I'm running on an Intel Core on this specific hardware. This is the game I am running, and then you can define the software carbon intensity rating for that game on that hardware. And then, yep. So say you swap out your graphics card or use your laptop for longer. How does that actually affect the static power of the device? Does it use more energy over time? If you swap it out. Well, it depends on the device. Or using the laptop for longer as well. Yeah, I mean, heavily depends on your device. Obviously, if you have a battery, it will decrease in capacity and there's more decrease in efficiency. So I do not exactly remember how it goes, but I believe the efficiency will be worsening, right? Again, it's a trade-off. What is the cut-off point where you should switch, where you should upgrade, when you should replace the part? Yeah, I mean, all of these things are really nice, but again, the issue, as you can see in the graph as well, is that the manufacturing is actually the most polluting part of it. So as much as efficiency is great, we're talking about the difference on, I know, 150 watts to 130 watts, while the actual manufacturing, which includes purifying the silicon, PCBs, bunch of components, all of these together with the shipping, is really just making all of these looks really, really, really insignificant. So, yeah. So, go for it. That's kind of what I wanted here. I wanted the open discussion. I agree with you, but... Yeah, but just to respond to what you said before, if Apple making a device or HP making it, you don't have any control over that, even if that's 80% of the emissions. Whereas if you treat all of it as out of our control, then we'll never make any improvements. As software engineers, we can still reduce this. Just a small question. Did you heard of cold carbon? Cold carbon. Oh, carbon code. I read about it a few days ago. It's not really an embedded area, but it's more like running on the AVS things. As far as I know, it's a Python script or something like that, that measures the impact of your instance and knows about which server cluster uses which combination of solar energy, cold, whatever, and tells you if you migrate your whatever container from this to this, you save that amount of carbon. It's just like, I don't know if someone heard about it. Like a month or a few weeks ago. I haven't heard about it either, so if you can, link to that afterwards would be very cool. But yeah, it's definitely one of the important things. I have actually a few slides on carbon awareness which talk about the shifting of stuff around in the world as well. But yeah, I'm mindful you still have some conversation going on and I'm more keen to have that as well. But if everyone's happy at the moment, like yeah, we can have some work here afterwards. I know we only have like six minutes left or three. How many minutes? 13. Okay, so my clock is very much off. Yeah, and so measurement, again, please do check out software carbon intensity. It will give you an idea of what are the ways to start looking at it. We just need the software also to calculate that. And that is what we can do as software engineers, right? So we've had it. And the last principle mentioned here, the climate commitments is what are actually the methods for reducing the emissions like outside of software, inside of software, but generally how do we reduce emissions. And I know it's a very small graph, so you can find it on learn.greensoftware.foundation in the course material. But basically the two main ways to do that are either via offsets. So offsetting your carbon footprint or by abatement or elimination, so not emitting the carbon in the first place. And obviously the second option is preferable, because you just never emit that at all. But still offsetting is very important and it's a very important idea. It's just much, much complex and in the energy space it's a very complex discussion about how you should do it properly, how you should do matching of your energy, do 24-7 matching, whether it should be hourly, daily, weekly. So just worth noting. And then the last one, last principle that I am more no more of, I guess, and I work closely with is carbon awareness. And I really like this sentence which is doing more when electricity is cleaner and doing less when it's dirty. It's as simple as that, but there are a few ways how you can smartly improve it. It relies on the idea of carbon intensity. Carbon intensity in electricity terms is the amount of CO2 equivalent released per each kilowatt hour spent of energy. And this, for example, is a map from carbon intensity data provider called WattTime. And we can see here from the green leaf to the dark co-icon this is how much carbon intensity, what's the carbon intensity level in a different region. And for example, graph here on the top of it shows us that this directly is related to what sources are, what energy sources are being used in the space at the time. So let's say we have 120 grams of CO2 per kilowatt hour and that means there's a lot of wind there's a lot of solar and let's say later in the day sun stops shining as intensely, wind stops blowing as fiercely and we have to rank up more on burning fuel, burning gas, burning coal and this increases our CO2, right? So we will be emitting more carbon for the same amount of electricity we're using. I hope that everyone gets that, right? Cool. This is I guess not directly carbon awareness but also how the mechanism works when we have a energy consumption on the grid and we the demand is, so this is going for work of how energy consumption might happen on the market. So let's say we had demand going down and there is still some wind, some solar in the system, so we decide to burn less of the fuels non-renewable fuels and later on let's say the wind starts blowing, the sun starts shining and then there is this curtailed energy that appears above our graph. What this means is energy that we're not actually using but we could be using because it's available, right? So it gets thrown away, no one's using it we cannot use that energy. So with carbon awareness the idea is you identify those times when there is more energy there is more energy in the system and you increase the demand. So you shift your workloads, you shift your operations to operate at the times when this curtailed energy is being wasted and instead we can shrink down the usage of carbon, of other carbon producing sources. Just be mindful that this can never go to zero as long as we have non-renewable, well not non-renewable, but carbon producing power plants in the world because they always need to be running at some level you cannot shut them down, it takes too much energy and it's time to restart them. No worries. When coal power plants are run they need to be run at 70% capacity because otherwise they aren't cost effective and cost efficient. So when they go down below that's why they are closing down coal power plants and they cannot be run as power plants. When you run them as peaker plants they have to be started well in advance when you use virtual power plants from batteries and such you can go in with moment's notice but when you are running coal and oil they have to be run in advance and run at least the capacity of 70%. So that is a little bit cool. Thanks for adding that. Yeah, that's actually a number I didn't know so it's cool to learn new stuff from the audience and yeah, a really important point, that's one of the points we cannot shut them off or get them too low. Jumping on to the first idea in carbon awareness of how you can apply it as time shifting so if you look at this graph the blue line is the carbon intensity that varies throughout the day. We have it between 400 and down to 0 is a bit optimistic but let's say that's actually like 200 or something like that, that's more realistic. That's the carbon intensity on the grid and then the green bar is our job. It's a one hour long job that is originally running at 1am to 2am and let's say we are looking at the actual carbon intensity with tools like the carbon hour SDK and we realize that actually we can move the job one hour forward in time, so plan ahead and this will then run at a time that has lower carbon intensity predicted and we can possibly save some carbon being emitted by doing it later. So this is time shifting. Location shifting, it's a bit more radical and it's not always as easy to apply, it really depends on your specific use case but this means totally moving your workload to a different location. This is in the cloud it's more easy to apply than the systems, we cannot just ship our systems to run in a different country and that probably would kill the entire idea but actually maybe this is actually a cool analogy because an important thing when moving your workload is also the shipping cost of it. You have to ship data to a different location and communicate with it. So you have a trade-off of you're moving it to a location that's much better, let's say Spain there is a lot of sun of your data, of your embedded systems or data, yes to a different location and that shipping also requires some energy spent. So it's another thing you have to keep in mind. Yeah, that's a cool analogy. I like it. And the last thing is the combination of two a little bit I guess or brightly more advanced version of time shifting. It's demand shaping. So the blue line is again intensity, the green bar is the intensity of your job how much you're doing on your hardware, so how much let's say how many processes you're running and it's the idea that if you have something, let's say a system that is processing some data and this can be shrunk down. So let's say you don't have to process all of the data at a specific point in time but you can accumulate and then do it later then you can wait for a time where the current density actually goes lower and expand let's say the number of either turn on more devices that will be processing the data or just spawn more jobs that will be processing it. So increasing electricity usage by increasing the efficiency or using more computers to do it and really utilizing that green time. And I know I only have three minutes left so this is a very, very brief introduction to the carbon narrow SDK so the tooling we actually already developed in the green software foundation had a first release and are soon to get a 1.1 release or 1.2 it's getting pretty big but in principle it's a tooling that answers some of these issues please feel free to review the slides afterwards for more info on them the biggest issues are the open source issues so there's a lot of disparate approaches in different companies trying to address it, trying to build carbon narrow tooling and this gives you an open source tool to solve that there's the issue of integrity of approaches so how do we actually know we're not greenwashing, how do we know you use real data for it and another interesting point is the need for a unified approach so we want everyone to be able to collaborate to know the standard for doing this where it sits is it will sit between your application and somewhere and the data sources so if it's a cloud application it will be as a deployed API or a CLI and it consumes the intensity data and gives you a unified interface for all of them because believe me there are so many data sources for carbon intensity data already so having a single interface for all of them is pretty useful just saying hey give me the forecast for carbon intensity data in a unified unit I know I'm jumping through a little bit I normally have a demo of using this and the demo is a Jupiter notebook which you can find on the GitHub it basically just shows I know I'm clicking through it but it basically just shows how you can affect your carbon intensity by doing time time shifting on a 55 day example so let's say we're moving from a certain time to a different time the red line, the blue line are carbon intensity values in different locations visually you can see there is a difference so it normally shows you some examples of how you do it I also have open source not yet upstream the demo of the SDK in a Kubernetes environment which for the cloud folks here is you should be aware of what it is at least roughly and the wrap up carbon aware software is central to the carbonization it's one of the key points of decreasing it so please look at it at least we already have a lot of folks being involved in it last time we took the screen shot we had 200 stars, now we have 325 or 15 so it would be cool to have you there if not there is a plenty of projects in the green sort of foundation which we'd be happy to have embedded engineers involved in and we don't have time for Q&A I wish you all a safe journey back from the conference finally I'll just leave the QR code and then we can look at it and sorry for going over time all right thanks it's very interesting so we had a couple of questions I think we can have some the next session is in 10 minutes so thanks again Siobhan have you got any questions I know it's quite a complicated topic so go ahead one question you showed a graph of the carbon levels do you have time data or can you get some kind of a forecast so you can plan ahead that's a great question that's a great question I normally answer during the presentation you can get both historical data and forecasted data so what time as a one provider it gives you roughly a day advanced data electricity maps gives you much more they have prediction models looking at it there is a very cool study in Microsoft of them doing it to build their software more carbon so if you just google UBS Microsoft carbon awareness you can probably find it where they actually show the differences they noted between forecasted and actual data when they got to the future point what thanks another question all right so I think we have a last presentation 8 minutes