{"id":45863984,"url":"https://github.com/excoriate/engineering-log","last_synced_at":"2026-03-09T08:03:16.420Z","repository":{"id":324051131,"uuid":"1095761175","full_name":"Excoriate/engineering-log","owner":"Excoriate","description":"A collection of engineering logs, documentation, and styleguides.","archived":false,"fork":false,"pushed_at":"2026-01-20T06:17:14.000Z","size":11148,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-02-27T12:25:12.257Z","etag":null,"topics":["devlog","documentation","engineering-log","markdown","mermaid","styleguide"],"latest_commit_sha":null,"homepage":"https://github.com/Excoriate/engineering-log","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Excoriate.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":".github/CONTRIBUTING.md","funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-11-13T13:39:13.000Z","updated_at":"2026-01-20T06:17:07.000Z","dependencies_parsed_at":null,"dependency_job_id":"15d7a4d9-c8c7-4769-9efc-9ab4c61438da","html_url":"https://github.com/Excoriate/engineering-log","commit_stats":null,"previous_names":["excoriate/engineering-log"],"tags_count":9,"template":false,"template_full_name":null,"purl":"pkg:github/Excoriate/engineering-log","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Excoriate%2Fengineering-log","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Excoriate%2Fengineering-log/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Excoriate%2Fengineering-log/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Excoriate%2Fengineering-log/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Excoriate","download_url":"https://codeload.github.com/Excoriate/engineering-log/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Excoriate%2Fengineering-log/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30287452,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-09T02:57:19.223Z","status":"ssl_error","status_checked_at":"2026-03-09T02:56:26.373Z","response_time":61,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["devlog","documentation","engineering-log","markdown","mermaid","styleguide"],"created_at":"2026-02-27T07:43:01.139Z","updated_at":"2026-03-09T08:03:16.413Z","avatar_url":"https://github.com/Excoriate.png","language":null,"readme":"\n# Steering aggregated pools is be based on telemetry\n\n* Deciders:  [Hein Leslie](mailto://hein.leslie@eneco.com), [Wesley Coetzee](mailto://wesley.coetzee@eneco.com), [Johnson Lobo](mailto://johnson.lobo@eneco.com), [Sebastian Du Rand](mailto://Sebastian.duRand@eneco.com), [Ricardo Duncan](mailto://Ricardo.Duncan@eneco.com)\n* Date: 13-07-2023\n\n## Context and Problem Statement\n\nWhen the agro pool is steered by the VPP aggregation layer, the aggregation layer needs to receive mFRR setpoints from the VPP core. The question here is: how does the VPP core know what the flex capacity is of the aggregated pool? \n\n\n## Decision Drivers \u003c!-- optional --\u003e\n\n* Consistency between pools in aggregation layer and large assets\n* Steering a pool must be based on reliable values, e.g. updated frequently if pool-composition changes\n\n\n## Considered Options\n\n* The current size of the pool and its flex capacity is updated realtime via telemetry to the core\n* The current size of the pool and its flex capacity is updated via timeseries, e.g. forecasted values\n* The current size of the pool and its flex capacity is updated through changing the configuration of an asset\n\n\n## Decision Outcome\n\nChosen option: \"* The current size of the pool and its flex capacity is updated realtime via telemetry to the core\", because it's the most versatile way of sharing the current state (flex capacity) of the pool to the core\n\n## Pros and Cons of the Options \n\n### The current size of the pool and its flex capacity is updated realtime via telemetry to the core\n\nThe current state of the pool (flex capacity, total production) is sent near-realtime via telemetry. If the theoretical size of the pool increases - example: Agro has a new customer, independent whether the customer will have flex available at that time - this will be updated via asset configuration in the asset service.\n\nAs of phase 1 in mFRR VPP core, the pool flex capacity is not shared between the aggregation layer and vpp core. The aggregation layer does share the pool's strike price to the core via the existing strike price topic.\n\n* Good, ingestion of the pool's flex capacity doesn't require any changes in the core\n* Good, because it's the most versatile. \n* Bad, the forecasted flex of the pool is not known in the core.\n\n### The current size of the pool and its flex capacity is updated via timeseries, e.g. forecasted values\n\nThe aggregation layer shares the schedule and the flex capacity of the pool to the aggregation layer. The core will then disaggregate mFRR requests over the pool based on forecasted values.\n\n* Good, because the core knows how much flex capacity a pool has forecasted\n* Good, because it's in line with conventional asset steering.\n* Bad, because if the pool's size decreases, you might have to update the the currentdatetime's period of the timeseries. This might lead to undesirable latency.\n\n\n### The current size of the pool and its flex capacity is updated through changing the configuration of an asset\n\n* Good, because it requires little changes in the core\n* Bad, because conceptually it's strange to update a pool's size via configuration which is usually static data. \n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fexcoriate%2Fengineering-log","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fexcoriate%2Fengineering-log","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fexcoriate%2Fengineering-log/lists"}