Add a basic Software Carbon Intensity (SCI) implementation

[fershad]

Is your feature request related to a problem? Please describe.
There is currently no way to use CO2.js itself to generate an SCI score for a given model.
More about SCI here: https://wiki.greensoftware.foundation/3aee3b76b9424189b6cbe93f94152741

Describe the solution you'd like
At the very least, developers should be able to pass in an optional parameter when using CO2.js that would return an SCI score alongside the calculated carbon estimate figure (and Sustainable Web Design Model [SWDM] rating if applicable). What this might look like:

import { co2 } from "@tgwf/co2";
const model = new co2({ model: "swd", version: 4, sci: true });

Alternately, a new SCI API could be created that would allow developers to pass in a model and related parameters. That API would then calculate an SCI score for the inputs and model provided. What this might look like:

import {sci, co2} from "@tgwf/co2";

// Use the SWDM v4 to estimate operational & embodied emissions for 1000 bytes
const model = new co2({ model: "swd", version: 4, results: "segment" });
const estimate = operationalModel.perVisit(1000)

const example = new sci({ 
  operationalEmissions: estimate.totalOperationalCO2e, 
  embodiedEmissions: estimate.totalEmbodiedCO2e, 
  functionalUnit: "page visit" 
});

// This would return a SCI score for each web page visit.

This can be extended to provide a means for developers to "experiment" with different inputs to see the SCI score that would be returned. This could be useful in planning, prototyping, or ideation phases for projects.

For example, let's say a developer wants to see how changing the location of a workload might impact the SCI score for a database backup process that runs once a day for 1 hour. They have knowledge of, or guestimate, the following:

• Grid intensity at both locations being compared
• Operational energy used by the database backup process
• Embodied emissions of the hardware used to run the process

import {sci} from "@tgwf/co2";

const locationAGridIntensity = 300 // grams CO2e per kilowatt-hour
const locationBGridIntensity = 325 // grams CO2e per kilowatt-hour

const totalEmbodiedEmissions = 1500 // grams CO2e
const timeReserved = 1  // The duration of the batch job, in hours per day
const expectedLife = 6 * 365 * 24 // 6 years expected hardware life, converted into hours
const resourcesReserved = 2 // Assuming the backup job runs on a shared cloud instance & uses 2 vCPUs
const totalResources = 8 // The total vCPUs on the cloud instance

const operationalEnergy = 20 // Kilowatts per run

const scoreLocationA = new sci({ 
  operationEnergy: operationalEnergy, 
  intensity: locationAGridIntensity, 
  embodiedEmissions: {
    totalEmbodiedEmissions,
    expectedLife,
    timeReserved,
    resourcesReserved,
    totalResources,
  },
  functionalUnit: "backup job run"
});

// Let's say the data center at locationB refresh their hardware every 4 years instead of 6 years. We can reflect this in our inputs.

const expectedLifeLocationB = 4 * 365 * 24

const scoreLocationB = new sci({ 
  operationEnergy: operationalEnergy, 
  intensity: locationBGridIntensity, 
  embodiedEmissions: {
    totalEmbodiedEmissions,
    expectedLifeLocationB,
    timeReserved,
    resourcesReserved,
    totalResources,
  },
  functionalUnit: "backup job run"
});

This could open up the possibility for developers to use multiple models in calculating an SCI score as well.

Describe alternatives you've considered
This would not be a replacement for other tools like Impact Framework. However, it would complement Impact Framework and allow an easily approachable initial entry to the SCI for developers first touching the topic or those who'd like to use SCI but cannot easily change their codebase to utilise Impact Framework.