OS2/ai-heatcontrol

Fork 0

SDR-001: Grundelementer for OS2 AI Heat Control #36

New issue

Closed

opened 2026-05-05 13:45:07 +00:00 by JakobNoerby · 1 comment

JakobNoerby commented

2026-05-05 13:45:07 +00:00

(Migrated from github.com)

Beslutningslog: Grundelementer

📆 sidst opdateret: {{ site.time | date: '%B %d, %Y' }}

Issue metadata (Github standard)

name: Beslutningslog
about: Struktureret beskrivelse af en væsentlig beslutning i produktet
title: "Grundelementer for OS2 AI Heat Control"
labels: `sdr'
assignees: JN
Issue reference:

SDR Beslutning

Dato: 2026-04-21
Status: Forslag
Beslutningstagere: Projektgruppen for OS2 AI Heat Control
Beslutningstype: Arkitekturbeslutning / Strategisk beslutning

Beskrivelse af Beslutningen

OS2 AI Heat Control baseres på fire grundelementer:

Datafundament
Reguleringsmotor
Connector-lag
Implementerbarhed og drift

Disse fire grundelementer udgør den overordnede struktur for kerneproduktet og skal anvendes som fælles ramme for kravspecifikation, markedsdialog, arkitekturarbejde, udvikling og videre dokumentation.

Kontekst & årsag

OS2 AI Heat Control skal udvikles som en fælles, åben og kommunalt anvendelig løsning til prædiktiv varmestyring.

På tidligere projektmøder er der identificeret behov for, at løsningen ikke blot består af én algoritme, men af en samlet ramme, som kan fungere på tværs af kommuner, bygninger, CTS-anlæg, IoT-systemer og leverandører.

Beslutningen træffes for at skabe et tydeligt grundlag for:

Kravspecifikation
Markedsdialog
Arkitekturarbejde
Dialog med udviklingspartner
Videre dokumentation i GitHub

Beslutning

Det besluttes, at kerneproduktet i OS2 AI Heat Control struktureres omkring følgende fire grundelementer:

1. Datafundament

Datafundamentet udgør den fælles datamodel og de minimumsdata, der er nødvendige for intelligent og prædiktiv varmestyring.

Datafundamentet skal blandt andet kunne beskrive:

Bygninger
Rum
HVAC-zoner
Temperaturmålinger
Vejrdata
Tidsserier
Styringspunkter
Setpunkter
Tidsplaner
Fallback-strategier

Den konkrete datamodel og det ontologiske grundlag behandles særskilt i #37

2. Reguleringsmotor

Reguleringsmotoren er den fælles styringslogik eller referencealgoritme, som kan beregne og sende prædiktive setpunkter til bygningernes varmeanlæg.

Reguleringsmotoren skal som minimum kunne understøtte styring af fremløbstemperatur for relevante varmeanlæg, fx radiator- og gulvvarmekredse.

Reguleringsmotoren skal desuden understøtte fallback-strategier, så løsningen kan håndtere situationer, hvor data mangler, systemer fejler, eller styringen skal overgå til en sikker standardtilstand.

3. Connector-lag

Connector-laget skal sikre standardiserede integrationer mellem OS2 AI Heat Control og relevante datakilder og tekniske systemer.

Connector-laget skal blandt andet kunne omfatte integrationer til:

CTS-anlæg
IoT-platforme
Sensorer
Vejrdata
Tidsseriedatabaser
Kommunale datakilder
Eksterne services

Connector-laget skal beskrive, hvilke data der skal leveres, i hvilket format, med hvilken frekvens og via hvilke grænseflader.

Der skal arbejdes videre med, om 'GPS-conncetor' kan anvendes som inspiration eller byggeklodser i dette arbejde.

4. Implementerbarhed og drift

Kerneproduktet skal kunne implementeres og driftes i kommunal praksis.

Det betyder, at løsningen skal tage højde for:

Cybersikkerhed
NIS2-relevante vurderinger
Kommunal IT-godkendelse
Drift og vedligehold
Leverandøruafhængighed
Portabilitet
Hostingmodeller
Dokumentation
Lave implementeringsomkostninger
Mulighed for at flytte data og drift mellem leverandører

Implementerbarhed og drift betragtes som en del af selve kerneproduktet og ikke som noget, der først tilføjes senere.

Fravalgte eller udskudte alternativer

Følgende alternativer fravælges eller udskydes på nuværende tidspunkt:

Én algoritme som hele kerneproduktet

Det fravælges at definere kerneproduktet alene som en algoritme. Løsningen skal forstås som en samlet ramme bestående af data, regulering, integrationer og implementerbar drift.

Én fast datakilde som “Source of Truth”

Det fravælges på nuværende tidspunkt at låse løsningen til én bestemt “Source of Truth”. Kommunerne kan have forskellige systemlandskaber, og løsningen skal derfor kunne fungere fleksibelt på tværs af forskellige datakilder og driftsmodelle

Fuld produktarkitektur fastlagt før udviklingspartner

Det udskydes at fastlægge den endelige tekniske arkitektur i detaljer, indtil datamodellen er kvalitetstjekket, og der er gennemført yderligere dialog med markedet og en kommende udviklingspartner.

Konsekvenser

Positive konsekvenser

Projektet får et tydeligt fælles grundlag for kerneproduktet.
Kravspecifikation og markedsdialog kan struktureres omkring fire klare grundelementer.
Connector-laget kan beskrives mere præcist.
Arkitektur og udviklingsopgaver kan opdeles mere systematisk.
Beslutningen understøtter OS2-principper om open source, transparens og genbrug.

Negative konsekvenser

Grundelementerne skal løbende afstemmes med den konkrete tekniske arkitektur.
Der kan opstå overlap mellem datafundament, connector-lag og reguleringsmotor, hvis ansvarsfordelingen ikke beskrives klart.
Der er risiko for, at kerneproduktet bliver for bredt defineret, hvis grundelementerne ikke prioriteres.

Neutrale konsekvenser

GitHub-dokumentation skal opdateres, så de fire grundelementer fremgår tydeligt.
Kravspecifikation, beslutningslog og eventuelle Architectural Decision Records skal referere til denne beslutning.
Ændringer i grundelementerne bør dokumenteres som nye beslutninger eller issues.

Effektuering

Beslutningen effektueres ved, at de fire grundelementer indarbejdes i projektets videre dokumentation og anvendes som ramme for kravspecifikation, markedsdialog og dialog med kommende udviklingspartner.

Det betyder konkret, at:

Projektets beskrivelse af kerneproduktet opdateres med de fire grundelementer.
Kravspecifikationen struktureres med afsæt i grundelementerne.
Connector-laget beskrives nærmere, herunder med inspiration fra OS2sandbox/gps-connector.
Eventuelle ændringer eller præciseringer dokumenteres som nye issues eller supplerende beslutninger.

Ansvarlig: JN / projektgruppen

Risici

Der er risiko for, at grundelementerne fortolkes forskelligt af kommuner og leverandører.
Der er risiko for, at løsningen bliver for kompleks, hvis alle grundelementer udvikles for omfattende fra starten.
Der er risiko for, at forskellige kommuner har forskellige datakilder, datakvalitet og systemlandskaber, som gør standardisering vanskelig.
Der er risiko for, at kommende leverandører vægter grundelementerne forskelligt.
Der er risiko for, at implementerbarhed og drift undervurderes i den tekniske udvikling.

Yderligere information

[PM3] - Workshop om kerneprodukt og SKAL/VIGTIGT/EKSTRA-krav
[PM4] - Oplæg til definition af kerneprodukt
[PM5] - Fastlæggelse af grundelementer, GitHub og open source
OS2sandbox/gps-connector
OS2sandbox/ai-heatcontrol

Specifikke metadata

Beslutnings-ID: SDR-001
Beslutningsområde: Kerneprodukt
Påvirker:
- Kravspecifikation
- Datamodel
- Connector-lag
- Markedsdialog
- Udviklingspartner
- Dokumentation
Relaterede issues:
- #34 Anvende relevante elementer fra OS2sandbox/gps-connector
- #35 Dokumentere beslutning om grundelementer og ontologi
Relaterede beslutninger:
- #37

# Beslutningslog: Grundelementer 📆 _sidst opdateret: {{ site.time | date: '%B %d, %Y' }}_ ## Issue metadata (Github standard) - name: Beslutningslog - about: Struktureret beskrivelse af en væsentlig beslutning i produktet - title: "Grundelementer for OS2 AI Heat Control" - labels: `sdr' - assignees: `JN` - Issue reference: _______________________ # SDR Beslutning - Dato: 2026-04-21 - Status: Forslag - Beslutningstagere: Projektgruppen for OS2 AI Heat Control - Beslutningstype: Arkitekturbeslutning / Strategisk beslutning ## Beskrivelse af Beslutningen OS2 AI Heat Control baseres på fire grundelementer: 1. Datafundament 2. Reguleringsmotor 3. Connector-lag 4. Implementerbarhed og drift Disse fire grundelementer udgør den overordnede struktur for kerneproduktet og skal anvendes som fælles ramme for kravspecifikation, markedsdialog, arkitekturarbejde, udvikling og videre dokumentation. ## Kontekst & årsag OS2 AI Heat Control skal udvikles som en fælles, åben og kommunalt anvendelig løsning til prædiktiv varmestyring. På tidligere projektmøder er der identificeret behov for, at løsningen ikke blot består af én algoritme, men af en samlet ramme, som kan fungere på tværs af kommuner, bygninger, CTS-anlæg, IoT-systemer og leverandører. Beslutningen træffes for at skabe et tydeligt grundlag for: - Kravspecifikation - Markedsdialog - Arkitekturarbejde - Dialog med udviklingspartner - Videre dokumentation i GitHub ## Beslutning Det besluttes, at kerneproduktet i OS2 AI Heat Control struktureres omkring følgende fire grundelementer: ### 1. Datafundament Datafundamentet udgør den fælles datamodel og de minimumsdata, der er nødvendige for intelligent og prædiktiv varmestyring. Datafundamentet skal blandt andet kunne beskrive: - Bygninger - Rum - HVAC-zoner - Temperaturmålinger - Vejrdata - Tidsserier - Styringspunkter - Setpunkter - Tidsplaner - Fallback-strategier Den konkrete datamodel og det ontologiske grundlag behandles særskilt i #37 ### 2. Reguleringsmotor Reguleringsmotoren er den fælles styringslogik eller referencealgoritme, som kan beregne og sende prædiktive setpunkter til bygningernes varmeanlæg. Reguleringsmotoren skal som minimum kunne understøtte styring af fremløbstemperatur for relevante varmeanlæg, fx radiator- og gulvvarmekredse. Reguleringsmotoren skal desuden understøtte fallback-strategier, så løsningen kan håndtere situationer, hvor data mangler, systemer fejler, eller styringen skal overgå til en sikker standardtilstand. ### 3. Connector-lag Connector-laget skal sikre standardiserede integrationer mellem OS2 AI Heat Control og relevante datakilder og tekniske systemer. Connector-laget skal blandt andet kunne omfatte integrationer til: - CTS-anlæg - IoT-platforme - Sensorer - Vejrdata - Tidsseriedatabaser - Kommunale datakilder - Eksterne services Connector-laget skal beskrive, hvilke data der skal leveres, i hvilket format, med hvilken frekvens og via hvilke grænseflader. Der skal arbejdes videre med, om 'GPS-conncetor' kan anvendes som inspiration eller byggeklodser i dette arbejde. ### 4. Implementerbarhed og drift Kerneproduktet skal kunne implementeres og driftes i kommunal praksis. Det betyder, at løsningen skal tage højde for: - Cybersikkerhed - NIS2-relevante vurderinger - Kommunal IT-godkendelse - Drift og vedligehold - Leverandøruafhængighed - Portabilitet - Hostingmodeller - Dokumentation - Lave implementeringsomkostninger - Mulighed for at flytte data og drift mellem leverandører Implementerbarhed og drift betragtes som en del af selve kerneproduktet og ikke som noget, der først tilføjes senere. ## Fravalgte eller udskudte alternativer Følgende alternativer fravælges eller udskydes på nuværende tidspunkt: ### Én algoritme som hele kerneproduktet Det fravælges at definere kerneproduktet alene som en algoritme. Løsningen skal forstås som en samlet ramme bestående af data, regulering, integrationer og implementerbar drift. ### Én fast datakilde som “Source of Truth” Det fravælges på nuværende tidspunkt at låse løsningen til én bestemt “Source of Truth”. Kommunerne kan have forskellige systemlandskaber, og løsningen skal derfor kunne fungere fleksibelt på tværs af forskellige datakilder og driftsmodelle ### Fuld produktarkitektur fastlagt før udviklingspartner Det udskydes at fastlægge den endelige tekniske arkitektur i detaljer, indtil datamodellen er kvalitetstjekket, og der er gennemført yderligere dialog med markedet og en kommende udviklingspartner. ## Konsekvenser ### Positive konsekvenser - Projektet får et tydeligt fælles grundlag for kerneproduktet. - Kravspecifikation og markedsdialog kan struktureres omkring fire klare grundelementer. - Connector-laget kan beskrives mere præcist. - Arkitektur og udviklingsopgaver kan opdeles mere systematisk. - Beslutningen understøtter OS2-principper om open source, transparens og genbrug. ### Negative konsekvenser - Grundelementerne skal løbende afstemmes med den konkrete tekniske arkitektur. - Der kan opstå overlap mellem datafundament, connector-lag og reguleringsmotor, hvis ansvarsfordelingen ikke beskrives klart. - Der er risiko for, at kerneproduktet bliver for bredt defineret, hvis grundelementerne ikke prioriteres. ### Neutrale konsekvenser - GitHub-dokumentation skal opdateres, så de fire grundelementer fremgår tydeligt. - Kravspecifikation, beslutningslog og eventuelle Architectural Decision Records skal referere til denne beslutning. - Ændringer i grundelementerne bør dokumenteres som nye beslutninger eller issues. ## Effektuering Beslutningen effektueres ved, at de fire grundelementer indarbejdes i projektets videre dokumentation og anvendes som ramme for kravspecifikation, markedsdialog og dialog med kommende udviklingspartner. Det betyder konkret, at: - Projektets beskrivelse af kerneproduktet opdateres med de fire grundelementer. - Kravspecifikationen struktureres med afsæt i grundelementerne. - Connector-laget beskrives nærmere, herunder med inspiration fra OS2sandbox/gps-connector. - Eventuelle ændringer eller præciseringer dokumenteres som nye issues eller supplerende beslutninger. Ansvarlig: JN / projektgruppen ## Risici - Der er risiko for, at grundelementerne fortolkes forskelligt af kommuner og leverandører. - Der er risiko for, at løsningen bliver for kompleks, hvis alle grundelementer udvikles for omfattende fra starten. - Der er risiko for, at forskellige kommuner har forskellige datakilder, datakvalitet og systemlandskaber, som gør standardisering vanskelig. - Der er risiko for, at kommende leverandører vægter grundelementerne forskelligt. - Der er risiko for, at implementerbarhed og drift undervurderes i den tekniske udvikling. ## Yderligere information - [[PM3]](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm3.md) - Workshop om kerneprodukt og SKAL/VIGTIGT/EKSTRA-krav - [[PM4]](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm4.md) - Oplæg til definition af kerneprodukt - [[PM5]](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm5.md) - Fastlæggelse af grundelementer, GitHub og open source - [OS2sandbox/gps-connector](https://github.com/OS2sandbox/gps-connector) - [OS2sandbox/ai-heatcontrol](https://github.com/OS2sandbox/ai-heatcontrol) ## Specifikke metadata - Beslutnings-ID: SDR-001 - Beslutningsområde: Kerneprodukt - Påvirker: - Kravspecifikation - Datamodel - Connector-lag - Markedsdialog - Udviklingspartner - Dokumentation - Relaterede issues: - #34 Anvende relevante elementer fra OS2sandbox/gps-connector - #35 Dokumentere beslutning om grundelementer og ontologi - Relaterede beslutninger: - #37

JakobNoerby commented

2026-06-19 08:35:27 +00:00

(Migrated from github.com)

SDR godkendt på pm7

SDR godkendt på [pm7](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm7.md)

This discussion has been locked. Commenting is limited to contributors.