Closed seanmcilroy29 closed 7 months ago
NAMRATA-WOKE
commented
1 year ago @ursvill what's the status here? Are you going to create a google doc and edit? Once it's edited, we can share it with the Standards WG for final thoughts/comments before we schedule it for publishing.
ursvill
commented
1 year ago Hi Urs
This is the link to the case study in Github. My understanding is that this got approved for publication as a technical case study and that we will be working on a less technical article together. I will start working on it next week and I hope to have a draft by the end of the week. Does that sound good? Do you use github for articles of other means like google docs? Is there a generic template for the articles we should follow? Thanks in advance.
ursvill
commented
1 year ago Hi Daniel Sounds great about a draft and don’t worry too much about the language. I can fine tune that part. I just need to be able to follow it. Once we have a draft, I will put it on Gdrive and share with you, so we can both work on it. We do not have a template. But you can see with the other case studies, it’s great to have a few subtitles (I can help) and visuals are fantastic. Jenya is our designer; she can help touch up or create graphics. Urs
ursvill
commented
1 year ago NAMRATA-WOKE
commented
1 year ago Daniel (kapokasa) is still missing piece of the outcome - how much energy they were able to save. Once the last paragraph is there, we will build the executive summary. Moved publishing date up to July 17. Might move up if Asim's modelling article (June 5) is not done in time.
Connect with @Jenya-design to get her to create the main article image and graphics in the article that can be in GSF branded colours.
ursvill
commented
1 year ago @Jenya-design - can you have a look at this one from a design perspective; add main graphic and update diagrams? Timeline for publishing June 5
Jenya-design
commented
1 year ago Sure @ursvill I'll send you the update for review next week
NAMRATA-WOKE
commented
1 year ago @ursvill waiting for conclusion. Will send a follow-up today.
Jenya-design
commented
1 year ago Hello @ursvill Please review the images attached and on Drive Let me know if this article belongs to one of the content streams - Use Cases, Expert Perspectives, Reflections, Conversations - and I should add the badge on the cover Thank you
cc @NAMRATA-WOKE
ursvill
commented
1 year ago @Jenya-design - thank you so much; it's a USE CASE We usually have that info in the issue title
ursvill
commented
1 year ago @seanmcilroy29 - Hey Sean, we are doing a last look-through on the article and the graphics, but this can go into approval. Publication date Jun 5.
seanmcilroy29
commented
1 year ago @ursvill - Article is now in draft and ready to publish on June 5th.
ursvill
commented
1 year ago @Jenya-design - Hi Jenya, the 3rd graphic has a typo at the bottom "Ethernet"
Jenya-design
commented
1 year ago Hi @ursvill Thanks for letting me know, I saw Daniel's comment on Drive, working with this and the 'Use Case' badge design I'll send you the update today
Jenya-design
commented
1 year ago @ursvill please check updated images in the attachment and and on Drive Let me know if you need any adjustments Thank you
Article Details
SCI Case Study
Proposer: Daniel Lazaro| Aveva | GitHub U/N: kapokasa) Abstract: This document describes a system that can accurately measure the energy consumption of application software. Why: SCI Use Case Audience: Timeline: End of May
Overview
This document describes a system that can accurately measure the energy consumption of application software. Instead of relying on energy measurement circuits that are integrated into the computer’s motherboard the whole computer is treated as a black-box and the electrical energy provided to the device is accurately measured using a high-precision benchtop power supply. The precision of the energy measurements is 0.01 Watts. The first part of the document describes the hardware and software architecture of the system. It provides all the necessary details to build a complete system. Part 2 covers a typical use case and workflow for measuring the energy consumption of a software product.
Architecture for the system under consideration
Technical details of the components in the architecture
The following table contains the hardware components needed for one system. The PC and power supply ship with all the necessary power and data cables except Ethernet CAT5 cables which need to be provided separately.
Table 1: Bill of hardware components
Procedure
This section describes the setup:
Setting up the hardware
The small form factor PCs will be powered by the bench top power supplies instead of the power bricks that ship with the PCs. To avoid injury and damage to the PCs, research into the power requirements of the PCs is recommended.[CH1] The power bricks in our example deliver a constant voltage of 20.0V and are rated for a maximum power of 135W. This means that they can provide a peak current of 6.575A. The Rigol DP811A power supplies have one channel that can support a peak current of 10A at 20V. Make sure to consult electrician or electronics engineer before proceeding with the hardware setup. The DC power brick has two cables attached to it. One cable is supplying the bricks with 120V AC power. The other end of the PC power supply carries DC power to the Small Form Factor PC. It plugs into the PC using a 6 mm male barrel connector. This end of the Lenovo power supply can be reused. Cut this cord close to the power brink and measure the polarity and voltage using a multi-meter. Mark the polarity of the two wires. Connect the wires to the correct terminals of the 20V Channel of the Rigol power supply. (Caution: confusing the polarity will damage the PC).
Workflow/Methodology
To calculate the power consumption, two measurements are required:
The resulting energy consumption is the difference between both measurements. It is calculated as the average of the Power measurements times their duration. The duration of the measurements is application specific and related to the typical application lifecycle.
Configuration Options
One PC – Sequential measurement
The baseline measurement and the loaded system measurement can be performed on the same PC in sequential order. This has the advantage that only one PC is needed.
Two identical PCs – Parallel measurement
The baseline measurement and the loaded system measurement can be performed in parallel by running the baseline on the first PC and the loaded system on the identical second PC. The advantage of the second configuration is that the Power consumption can be calculated continuously and in real time.
Measurement data archival
A critical part of the system is its ability to archive data in AVEVA Data Hub. The following graphic shows the power measurements of the baseline and loaded system (parallel configuration) over time.
Data flow and system software
The measurements are collected by the Raspberry PI (Voltage, Current, Power and Energy) and stored in AVEVA Data Hub for data archival and further consumption and analysis. The following diagram illustrates the data flow in detail:
Power usage prediction
The power usage by an application can be predicted using supervised machine learning. Performance metrics like CPU, Memory and I/O transactions need to be recorded in addition to the power usage data. A supervised machine learning algorithm, e.g., a neural network or regression, can be trained using this data. Finally, predictions about the power consumption can be made based on given performance metrics using the trained machine learning model.
(What) Software boundary
All software included in the small factor PC including OS, drivers and any other prerequisites required are included. For distributed software systems a hypervisor is used to accommodate such scenarios.
(Scale) Functional unit
In our industry and products we have different functional units that can be used. Examples are:
Due to the complexity and heterogeneity of systems we chose to load them based on a typical user deployment loads per license boundaries (varies per product targeted). Due to the high lever nature and black box approach of this methodology, we will break down the total number to the functional per unit parameter in the future steps.
Emission Estimation Framework Before AVEVA worked with Green Software Foundation guidance on Software Carbon Intensity, we developed a preliminary estimation framework for our Scope 3 use of product sold emission. Based on GHG reporting protocols, the emission for business activities can be simplified as:
Emission = Activity x Emission Factor Per Activity
To AVEVA products, the “activity” refers to the power consumption incurred when our customers use AVEVA products on annual basis. Emission factor is the average global emission factor per power consumption without going to details of power consumption at each customer site. Based on purchased IEA data, global average emission factor for power consumption is 0.49 g CO2e/Wh in 2019. Following formular is developed further to better account for AVEVA product related footprint with effective usage count, additional power required for software execution and effective usage time per year.
(How) Quantification method
(Quantify) SCI Value Calculation
SCI = (O+M) per R
Operational Emission
O= E x I Where E = ( PL - PB ) x t = (16.009 W – 11.335W) x 8322h = 39 kwh O = 39 kwh x 474.8 gCO2e/kwh = 18517.2 gCO2
O = operational emission E = energy consumed by a software system for a functional unit of work PL= Average of measured loaded system power consumption = 16.009 W PB= Average of measured baseline system power consumption = 11.335W t = annual usage hour. Assume the software will be used in operations full day with 95% availability in the year: t = 365 x 24 x 95% = 8322 hr I = location based emission factor. For the case study, we will use 2019 global yearly average emission factor 0.4748 kgCO2e/kWh to represent a global average status I = 474.8 gCO2e/kwh
Embodied Emission
M = TE x TS x RS = 350000 gCO2 x 20% x 100% = 70000 gCO2
TE = Total Embodied Emissions; the sum of Life Cycle Assessment (LCA) emissions for all hardware components. Here we refer to the PC provider’s report on emission for PC from Dell. “Total greenhouse gas emissions for the Latitude E6400 = 350 kg CO2eq” TS = Time-share; the share of the total life span of the hardware reserved for use by the software. Here we assume the hardware total life span = 5 years. Share of one year to the lifespan is 20% RS = Resource-share; the share of the total available resources of the hardware reserved for use by the software. Here we assume the hardware is dedicated for the software. So the resource share = 100%
Sites for Software Sustainability Actions
Energy Efficiency
Hardware Efficiency
N/A Since we do not control the HW on which our customers run our software.
Carbon Awareness
N/A Since we do not control how our customers source their energy.
Important Information
To be filled out later
Author: Daniel Lazaro Other contributors: (Experts, Reviewers) Article Link: (Link to the doc, must be in our official GSF drive) Graphics Link: (Link to the design assets for this article, must be in our official GSF drive) Published Link: (The link the article was published to for memory)
Checklist