Design og integrasjonsveileder

Denne veilederen er utarbeidet for å sikre best mulig resultat fra Kiona. Den inneholder informasjon om den dokumentasjonen som kreves for automationsleveransen, inkludert toppsystemet IWMAC. Ta kontakt med din kontaktperson hos Kiona om du ikke finner en mal.

Hurtigveiledning:

• Last ned maler og sjekklister som vedlegg nederst i artikkelen
• Fyll ut malene og sjekklistene med informasjon om anlegget
• Send dokumentasjonen til [e-mail]
• Kiona gjennomgår og tar kontakt ved spørsmål eller behov for utfyllende informasjon

📘 1 – Design og integrasjonsveileder

1.1 – Formål

Denne veilederen er utarbeidet for å sikre best mulig resultat fra leveransen fra Kiona. Veilederen inneholder informasjon om den dokumentasjonen som kreves for automationsleveransen. Leveransen inkluderer IWMAC-toppsystemet og tilhørende tilleggstjenester. Vedleggene beskriver det underlagsbehovet som gjelder for leveransen, med spesifikke detaljer for bestemte anleggstyper og protokoller.

Alle eksempler og maler er også tilgjengelig på nettsidene til våre Kiona-sertifiserte partnere.

Savner du en mal – ta kontakt med din kontaktperson på salg eller leveranse hos Kiona.

1.2 – Nettverk/IT-infrastruktur

Når leveransen er satt i bestilling, vil man få tilsendt en anleggsserver fra Kiona. For at leveransen kan starte er det nødvendig å få kontakt med den utsendte anleggsserveren i god tid før planlagt oppstart. Start derfor med de nødvendige forberedelsene for at nettverket er klart til riktig tid.

Det er viktig at kunden tidlig avklarer med sluttkunde om anleggsserver skal kommunisere med Kiona-skyen over direkte internettforbindelse eller VPN. Når Kiona har mottatt informasjonen fra kunden, vil Kiona bestille korrekt oppsett fra egen nettverksleverandør.

Ved oppstart av leveransen vil man motta et standardskjema for internett-tilkobling og VPN-tilkobling som beskriver hvilken informasjon Kiona har behov for, samt konfigurering sluttkunden må utføre for at anleggsserver skal komme på nett. Kiona vil ikke kunne starte arbeidet før skjemaene er returnert og innstillingene som er beskrevet, er bekreftet utført.

Anleggs-server leveres med to nettverkskort. Kiona må tildeles to nettverkstilkoblinger – dette er viktig informasjon kunden må innhente. Det anbefales at det ene grensesnittet forbeholdes internettforbindelse, og er adskilt teknisk nett. Det andre grensesnittet tilkobles teknisk nett.

Konvertere levert av Kiona vil bli konfigurert som en del av leveransen, når nødvendig informasjon er overlevert. Konvertere ikke levert av Kiona, kan Kiona bistå med å konfigurere og installere på anleggs-pc – men er ikke inkludert i leveransen og vil derfor bli håndtert som et tillegg.

1.3 – Topologi

For å opprette kommunikasjonsforbindelse mot alle automatikkenheter, har Kiona behov for en komplett topologi som lister opp all nødvendig nettverksinformasjon. Kiona er avhengig av å motta all informasjon om seriell til nettverkskonvertere, med tilhørende oversikt over hvilke automatikkenheter som er tilkoblet de ulike portene.

Se følgende eksempler:

• Grafisk: topologi som PNG, laget i Gliffy eller tilsvarende programvare – IWMAC MAL 12 – Topologi.png / IWMAC MAL 13 – Topologi.gliffy
• Excel: Enkel mal for enheter på IP, avansert mal for både enheter på IP og serielle enheter via konvertere – IWMAC MAL 10 – Enkel topologi kun IP / IWMAC MAL 11 – Topologi IP og seriekonvertere.xltx

1.4 – Parameterlister, tagnavn og beskrivelser

IWMAC bruker navn og beskrivelser fra underlaget/dokumentasjonen mottatt fra kunden. I noen tilfeller kan dette leses av skannere direkte fra utstyret. For at Kiona skal kunne gi sluttbrukere lesbare og lokaliserbare tag-navn må datalistene inneholde nødvendig informasjon og en struktur som tillater Kiona å bygge opp tag-databasene på en god måte.

Her er noen generelle retningslinjer:

• Kiona forutsetter at systemnummer og tverrfaglig merkesystem (TFM) komponentkode angis for hver parameter-/taglinje, samt en enkel parameterbeskrivelse, enten av fysisk komponent eller av funksjon.
• For romkontroll må hvert rom, etasje og om nødvendig bygg, fløy kunne adskilles.
• Alle like funksjoner innenfor hvert rom må få lik funksjonskode.
• For overordnede sentrale komponenter og soneavgrensede funksjoner må sone-/gruppetilhørighet komme frem for hver parameterlinje.
• For lister som omhandler en enhet som kun betjener ett systemnummer, kan systemnummer utelates.

IWMAC-komponentkodestandarden brukes i bilder med mindre annet er avtalt, eller hvis komponentkoder ikke finnes i tag-listen eller tilhørende systemskjema. Alt underlag må være samstemt i tegnkoding for at Kiona skal kunne identifisere komponentenes tilhørighet.

Eksempel for temperaturføler (prosessverdi) og parameter for kalkulert settpunkt:

• 360.001 RT401 Tilluftstemperatur  eller  byggnr_360001_RT401_PV Tilluftstemperatur
• 360.001 RT401 Kalkulert settpunkt  eller  byggnr_360001_RT401_ASP arb. settpunkt

Eksempel for rom:

• R201_Erverdi – Romtemperatur
• R201_BasSetp – Grunnsettpunkt
• R201_HVlv – Pådrag varme
• R201_SQ401_lm – Tilluft VAV1 luftmengde
• R201_SQ402_lm – Tilluft VAV2 luftmengde
• R201_SQ501_spjv – Avtrekk VAV1 spjeldvinkel

I Modbus, KNX, OPC, N2 og tilsvarende tag-lister vil typisk både TFM-koding og beskrivelse kunne være del av en og samme tekst. Det er da viktig at strukturen er lik for alle linjer med system-komponent-funksjonskode i fast rekkefølge med faste skilletegn samt beskrivelse til slutt.

For BACnet-objekter kan TFM-koding gjerne ligge i selve objekt-navnet, mens beskrivelsen legges i «description»-attributtet. Annen strukturering er også mulig så lenge tagen inneholder all nødvendig informasjon og struktur, som tidligere beskrevet.

1.5 – Alarmfunksjonalitet og skrivetilgang

Kiona må direkte i tag-databasen angi hvilke punkter som skal være lesbare og/eller skrivbare. Det samme gjelder alarmnivåangivelse på punkter som skal generere alarm.

IWMAC ønsker normalt kun digitale alarmer i databasen. Om kunden ønsker å generere alarm på multistate (integer) eller flyttallsverdier må det avklares med leveranseansvarlig om dette er mulig for hvert tilfelle og hvilken konsekvens dette har for ekstra tidsforbruk, behov for smarte funksjoner med mer.

Se gjeldende vedlegg for spesifikk protokoll for å se hvordan Kiona trenger å få angitt om punkter skal være skrivbare eller definere alarmpunkt, og tilhørende alarmnivå.

📥 Sjekklister og maler er tilgjengelig for nedlasting som vedlagte filer nederst i artikkelen – én ZIP-fil per språk med alle 25 filer i numerisk rekkefølge.

Sjekklister:

✅ 2.1 – IWMAC Sjekkliste – BACnet

BACnet/IP: enheten må svare på Who-is. BBMD kreves ved multi-subnett-nettverk. I større nettverk med flere subnett må kunden sikre korrekt IT-infrastruktur og BACnet-undersentralkonfigurasjon. Kiona trenger topologi med IP-adresse, nettmaske, gateway, nettverksnummer, enhets-ID og BBMD-identitet (inkl. FDT/BDT-tabellposter).

Sjekkliste – integrasjon av BACnet-enhet	Enhet:______________________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Enheten er ferdig idriftsatt og funksjonstestet.		☐
Enheten kan pinges fra IWMAC-pc.		☐
Ekstrakolonner er lagt til på slutten av EDE-fil.	Alarm Pri, Include Attri., Gruppe, Rom. Se eksempelmal: IWMAC MAL 03 – BACNET Ede.csv	☐
Kolonne "settable" justert: skrivbare punkter satt til "Y", alt annet til "N".	Skrivbare punkter er normalt settpunkter, SD-brytere/vendere og lignende.	☐
Alle punkter med intrinsic reporting og alarmtilstand aktivert er satt til "1" i "Include Attri.".		☐
Det er laget egen liste over hvilke attributter som skal legges frem for datapunktene.	For alle objekter hvor "Include Attri." er satt til "1".	☐
Hver parameter/linje i EDE-filen inneholder systemnummer, komponent/merking og forklarende tekst.	Eksempel: «320.001 RT401 Turtemperatur radiatorkurs A-blokk».	☐
Om systemnummer ikke fremkommer over, må følgende to linjer fylles ut av kunden.		☐
Kolonne "Gruppe" er utfylt med systemnummer for alle linjer i EDE-fil.	Samme nummer/navn for alle objekter i samme system.	☐
Kolonne "Rom" er utfylt for alle objekter/linjer som tilhører romkontroll/sonekontroll.	Samme rombetegnelse på alle objekter i samme rom/sone.	☐
Alarmnivå A, B eller C er angitt for alle alarmobjekter. Må også fylles ut på linjer hvor "Include Attri." er satt til "1".	A for A-alarm (sendes normalt på SMS), C for C-alarm (laveste nivå).	☐
Eventuelle NC binære alarmer er listet opp i en egen oversikt.	Aktiv alarm når Present value er binær "0".	☐
Present value på multistate-objekter benyttes ikke til alarmstatus, driftsstatus og lignende.	Om ikke, konferer med Kiona for å se om det er mulig å transformere dataene i IWMAC-systemet.	☐
Binært datapunkt for å kvittere ut/resette alarmer er lagt frem.	Punktet bør automatisk gå tilbake til "hvilestilling" etter aktivering.	☐
IWMAC SD-kalenderer benyttes, linkes til objekt: ___________________________	Objekttype og ID eller navn på datapunkt som skal linkes til i undersentral, en for hver IWMAC SD-kalender. Objektene kan være binære eller multistate. Skal Kiona stille inn tidspunktene må disse også angis i forkant.	☐
EDE- og state-texts er oversendt i CSV-format.	Se eksempelmal: IWMAC MAL 04 – BACNET StateTexts.csv	☐
Stort nettverk med flere subnett/IP-områder: topologi oversendt.		☐

✅ 2.2 – IWMAC Sjekkliste – Modbus

Modbus-enhetsscanning er ikke mulig. Parameterlister i Excel må inneholde: register/adresse, datatype (sint16, float, bool, uint32 osv.), bitnummer, startbit/antall, word-swap/byte-swap, system+komponent+beskrivelse, måleenhet, skalering, alarmprioritet A–B–C, statustekst (f.eks. 0=Av 1=På), lese/skriveindikator.

Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Vurdering av antall enheter og oppdateringsfrekvens på seriesløyfer.	Kiona integrerer hele parameterlisten med mindre annet er angitt.	☐
Unike slaveadresser og samme kommunikasjonsinnstillinger per sløyfe.	Baudrate, data- og stoppbits, paritet.	☐
Enhet(er) idriftsatt og funksjonstestet.		☐
Tellerpoll kjørt for å teste kontakt med minst ett register per enhet.		☐
Bustopologi med alle enheter sendt.	Slaveadresser, IP-adresser, COM-porter, mediekonvertere osv.	☐
Fabrikat, modell og Modbus-parameterliste sendt.		☐
Komplett Modbus-parameterliste utarbeidet.	Hvis utstyret er tilpasset programmerbart.	☐

✅ 2.3 – IWMAC Sjekkliste – N2 / N2 Open

Enhetsscanning er ikke mulig. Tilstrekkelige parametere for grunnfunksjon i toppsystem (Drift/Feil/Frost/Kalender/Temperaturer/Settpunkt osv.). Per parameter: beskrivelse (system+komponent+tekst), måleenhet, statustekst, lese/skriveindikator. Johnson DX: N2-protokolladresser kreves (f.eks. AI1, XT3DI1, PM10K02). Johnson FX: .prn-fil er utilstrekkelig; N2-adresser kreves (adf1, adi1, bd1, bit1).

Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Kontroller antall enheter og oppdateringsfrekvens	En vurdering er gjort av antall enheter på serielle sløyfer for å sikre at oppdateringsfrekvensen ikke blir for lav.	☐
Kontroller adresser og kommunikasjonsoppsett	Alle serie-enheter på en sløyfe har unike slaveadresser og likt kommunikasjonsoppsett. Baudrate, databiter og stop-biter, paritet.	☐
Enhet(er) idriftsatt og funksjonstestet.		☐
Bustopologi med alle enheter sendt.		☐
Komplett tagliste utarbeidet og sendt til Kiona.		☐

✅ 2.4 – IWMAC Sjekkliste – KNX via NETxOPC-server

For at IWMAC skal kunne integrere KNX er det behov for en del informasjon for å få riktig funksjonsnivå. Det er ikke mulig å “scanne” enhetene eller datapunkter fra enhetene, så kunde må eksportere og oversende nødvendige data fra ETS (Programmeringsverktøyet).

Før anlegget programmeres må en gruppeadressestruktur og navngivning fremvises til IWMAC for gjennomgang og godkjennelse, slik at muligheten for effektiv bildelinking kan ivaretas.

Før integrasjon kan påstartes må IWMAC ha fått tilsendt all informasjon angitt i sjekklisten under. Alle parametere bør navngis på en måte som gjør de lett identifiserbare, se dokument “1 – Design og Integrasjonsveileder”

Excel-fil med utfyllende informasjon må inneholde følgende 7 ekstra kolonner utover data som kommer fra *.esf-filen, se punktene og utklippet under:

• Skrivbare parametere (rw)

• Måleenhet (°C, m3/h, %, osv.)

• Skalering (0-255=0-100 osv.)

• Gateway/IP (for å skille på hvilke parametere som hører til hvilke gateway’s)

• Alarmprioritet (A-B-C), A er høyeste prioritet og vil normalt gå ut på SMS til alarmvakt

• Normalt lukket/NC (0=Alarm, 1=OK)

• Les v/oppstart OPC (Read on reconnect)

Dersom du får tilsendt Modbus-dokumentasjon fra leverandør, er det viktig at du kontroller dokumentasjon opp mot spesifikasjon over.

Sjekklisten under gjelder for alle enheter på en seriell-sløyfe/bak en port på en mediekonverter, eventuelt per unike enhet på Modbus TCP (IP).

Sjekklisten under gjelder for hele “integrasjonen”. Altså ETS-databasen som integrasjonen gjelder. KNX-installasjonen må derfor på forhånd være ferdig igangkjørt og testet før IWMAC kan importere parameterlisten.

Sjekkliste – integrasjon av KNX	Enhet:______________________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Gruppeadressestruktur er avklart og godkjent av IWMAC.	Strukturen er også tilpasset for effektiv bildelinking av romkontrollbilder.	☐
Alle parametere er navngitt etter "1 – Design og Integrasjonsveileder", alternativt avklart og godkjent med IWMAC.		☐
Alle komponenter på busen er ferdig igangkjørt og funksjonstestet.		☐
IWMAC er varslet om hvor mange datapunkter som skal integreres.	Lisens på antall datapunkter og antall gateways.	☐
Topologi som viser hver gateway med bakenforliggende buslinjer med adresser.		☐
Excel-ark med nødvendig informasjon utover det som fremkommer i esf-fil er laget og oversendt IWMAC.		☐
*.esf-fil fra ETS rensket for parametere som ikke skal integreres er oversendt IWMAC.	Avstemt med antallet punkter som er oppgitt ved lisensbestilling.	☐
Oversikt over ønskede SD-kalendere og hvilke datapunkter disse skal skrive til er oversendt IWMAC.	Driftstider må være kjent om IWMAC skal legge de inn.	☐

✅ 2.5 – IWMAC Sjekkliste – OPC DA

OPC-enhetsscanning er ikke mulig. Utfordrende når OPC-serveren er på en annen datamaskin. Kiona må vite om OPC-serveren kan installeres på en IWMAC-PC. Tilkoblingsinfo: tilkoblingsstreng, brukernavn/passord, gruppeadresse/tilgangssti, DCOM-parametere (hvis annen PC), antall parallelle tråder. Parameterliste: unikt navn+beskrivelse (TFM+komponent), OPC-adresse+datatype+lengde, bitspesifikasjon, måleenhet, skalering, statusverdier (f.eks. 0=Av 1=På), lese/skriveindikator (r/rw), alarmnivå (A/B/C).

Verdi	Datatype	Beskrivelse
0	VT_EMPTY	Standard/Tom
2	VT_I2	2-byte heltall med fortegn
3	VT_I4	4-byte heltall med fortegn
4	VT_R4	4-byte reelt tall
5	VT_R8	8-byte reelt tall
11	VT_BOOL	Boolean (TRUE=−1, FALSE=0)
17	VT_I1	1-byte heltall med fortegn
18	VT_UI1	1-byte heltall uten fortegn
19	VT_UI2	2-byte heltall uten fortegn
20	VT_UI4	4-byte heltall uten fortegn
+8192	VT_ARRAY	Matrise med verdier

Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Alle parametere navngitt iht. veileder eller godkjent av Kiona.		☐
Alle komponenter idriftsatt og funksjonstestet.		☐
OPC-tilgang testet med OPC-klient på IWMAC-PC.	Bekreftelse på at tilkoblingen fungerer.	☐
Tilkoblingsinformasjon sendt til Kiona.		☐
Komplett tagliste utarbeidet og sendt.		☐
Kalenderoversikt sendt.		☐

✅ 3.1 – IWMAC Sjekkliste – Ventilasjon

For at Kiona skal kunne sikre at IWMAC-visualiseringen er korrekt, trenger vi tilstrekkelig dokumentasjon. Målet er å skape et enkelt, tydelig system for anleggets sluttbrukere.

Innsendt dokumentasjon skal som minimum inneholde: systemnummer og driftsområdebeskrivelse; anlegsspesifikk funksjonsbeskrivelse med temperaturregulering, vifteregulering, aktive funksjoner inkl. nattkjøling, returluft og forlenget drift, sesongkompenseringskurver, kalenderfunksjoner og forriglinger; systemskisse med komponentkoder (som bygget); beslutning om tidsstyring (automationens ur eller toppsystemskalender).

Sjekklisten gjelder per ventilasjonssystem (systemnummer).

Sjekkliste – ventilasjonsenhet	Systemnr.:_______ Enhet:___________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Systemskisse med alle komponentkoder er sendt til IWMAC med «som bygget» komponentplassering.		☐
Koder på systemskissen er også i parameterlisten.		☐
Alternativt benyttes IWMAC-merking i bilder.		☐
IWMAC-tidsstyringsur skal benyttes.		☐
Alternativt benyttes regulatorens interne ur.		☐
Funksjonsbeskrivelse med informasjon som etterspurt ovenfor er sendt til IWMAC.		☐
Punktene på sjekklisten for kommunikasjonsprotokollen er behandlet.		☐
Eventuelle tilleggsfunksjoner er angitt i skriftlig støttedokumentasjon.	Husk å bestille smarte funksjoner ved behov.	☐

✅ 3.2 – IWMAC Sjekkliste – Varme- og kjøleanlegg

For at IWMAC skal kunne gi en korrekt visualisering er man helt avhengig av å få tilstrekkelig og korrekt dokumentasjon. Målet er å få til et enkelt, oversiktlig og forståelig system for sluttbrukeren av anlegget.

• Korrekte tegninger («som bygget») hvor komponentmerkingen stemmer overens med merkingen i parameterlisten. Dvs. automatikk som styrer/regulerer varmeanlegget må ha samme merking som er gjengitt i dokumentasjon.

• Fullstendige parameterlister hvor parameterne har fornuftige og riktige tekster, samt er merket med komponentnummer iht. tegning. Sluttbruker skal kunne forstå tekstene, og dette er spesielt viktig på alarmtekster.

• Se «IWMAC Design og integrasjonsveileder» for inngående beskrivelse vedrørende krav til benevning.

• Funksjonsbeskrivelse av anlegget. Alt av forriglinger, alarmfunksjoner, sesongvekslingsfunksjoner og reguleringsfunksjoner må medkomme.

• Hvilke settpunkter er ønskelig å vise frem direkte i bildet? (Alle parameter er tilgjengelig under innstillinger). I bildet visualiserer vi normalt viktige SP som sluttbruker skal kunne endre på som kurver, temperaturer, settpunkter etc.

IWMAC designer bilder etter egen standard som gjenspeiler oppbyggingen av varmeanlegget iht. rørskjema så godt det lar seg gjøre. IWMAC vil foreta justeringer og oppdelinger sånn at dette passer inn med definerte bildestørrelser og symboler. Alle alarmindikatorer legges ut som alarmbjeller, disse er kun synlig ved aktiv alarm. IWMAC standard merking er TFM med 3 siffer. Hvis annet er ønskelig, må dette frem komme av dokumentasjon. Det er viktig at fysisk merking samsvarer med skjermbildene visualisert i IWMAC.

Sjekklisten under gjelder pr varme- eller kjølesystem (systemnummer).

Eksempel på et bilde:

Eksempel på kurve:

Sjekkliste – Varme- og kjøleanlegg	Systemnr.:_______ Enhet:__________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Systemskisse med alle komponentkoder er sendt til IWMAC, med «som bygget» komponentplassering.		☐
Koder på systemskissen er også i parameterlisten.		☐
Funksjonsbeskrivelse med informasjon som etterspurt ovenfor er sendt til IWMAC.		☐
Punktene på sjekklisten for kommunikasjonsprotokollen er behandlet.		☐
Eventuelle tilleggsfunksjoner, som værvarsling, effektmåling, måleverdidistribusjon, alarmfunksjoner og lignende, er angitt i skriftlig støttedokumentasjon.	Husk å bestille smarte funksjoner ved behov.	☐

✅ 3.3 – IWMAC Sjekkliste – Romkontroll

For at IWMAC skal kunne gi en korrekt visualisering er vi helt avhengig av å få tilstrekkelig og korrekt dokumentasjon. Målet er å få til et enkelt, oversiktlig og forståelig system for sluttbrukeren av anlegget.

• For å lage skjermbildene må IWMAC få oversendt korrekte plantegninger av bygget i dwg-format, hvor det er mulig å slå av lagene og sitte igjen bare med grunnskissen/rominndelingen.

• Det må settes opp en oversikt over alle rom som skal med i romkontroll, hvor det er angitt:

• Romnummer / navn

• Hvilken romtype (dersom forskjellige romtyper)

• Regulatoradresse

• Hvilke parametere som ønskes visualisert på de forskjellige romtypene. Vi har med i standardleveransen visualisering av inntil 15 tags pr rom.|

Se «IWMAC MAL 09 - Romliste.xltx» for ønsket oppsett av oversikt på romtyper og tagger som skal presenteres.

• Vår standard er å legge ut romtemperatur og aktuelt settpunkt i pop-up. Pop-up blir tilpasset de forskjellig romtyper vi har fått tilsendt fra kunde.

• Det er medtatt maler for inntil 10 ulike/individuelle romtyper.

• Dersom anlegget avviker fra standard må dette være avklart ved salg, og spesifiseres deretter.

• Dersom romkontrollen er satt opp i PLS e.l., så må det være tydelig merking av hvilke parameter som tilhører hvilke rom, og en forståelig beskrivelse av parameterne, se dokument “1 – Design og Integrasjonsveileder”

• Inndeling av plan må være hensyntatt ønsket antall parametere i pop-up, byggets fasong og sluttbrukers brukte logiske inndeling av bygningsmassen.

• Det er medtatt 1 tidskatalog per etasje – om annen inndeling ønskes må dette avklares med IWMAC.

• Visualisering av overstyringsfunksjoner og smarte funksjoner som er ønsket må meldes IWMAC før visualiseringen påstartes.

Vi lager bilder etter vår standard iht. tilsendte dwg-filer så godt det lar seg gjøre. Vi foretar justeringer og oppdelinger sånn at dette passer inn med våre bildestørrelser og symboler.

Eksempel på et bilde ved bruk av standard symboler, ønskes andre symboler så må dette avklares i forkant av prosjektet:

Sjekkliste – Romkontroll	Systemnr.:_______ Enhet:__________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
En romliste med romtyper og en liste over alle rom av de ulike romtypene er utarbeidet og oversendt IWMAC.		☐
Avklart med IWMAC hvilke verdier som vises i pop-up-vinduer.		☐
Plantegninger er oversendt i angitt format, med mulighet for enkel fjerning av uønsket informasjon.		☐
Oversendt dokumentasjon inneholder all informasjon etterspurt i dette dokumentet.		☐
Parametere har samme navn som i parameterlister.		☐
Punktene på sjekklisten for kommunikasjonsprotokollen er behandlet.		☐
Eventuelle ønsker om visualisering av overstyringsfunksjoner er oversendt (strek over ruten hvis ikke aktuelt).		☐
Eventuelle tilleggsfunksjoner som værvarsling, effektmåling, måleverdidistribusjon, alarmfunksjoner og lignende er angitt i skriftlig støttedokumentasjon.	Husk å bestille smarte funksjoner ved behov.	☐
Avklart med IWMAC om indelingen for tidskataloger. Normalt er det 1 tidskatalog per etasje.		☐

✅ 3.4 – IWMAC Sjekkliste – Teknisk og elektrisk

For at IWMAC skal kunne gi en korrekt visualisering er man avhengig av å få tilstrekkelig og korrekt dokumentasjon. Målet er å få til et enkelt, oversiktlig og forståelig system for sluttbrukeren av anlegget.

Signalene er ofte spredt over mange undersentraler og med spredning i hele bygningsmassen. Dette setter krav til at kunden på en systematisk måte setter opp hvilke signaler som skal presenteres i de tekniske sidene.

• IWMAC kan gruppere signaler på lokasjon, system, disiplin eller signaltype etter ønske.

• Det må avklares hvordan signaler skal grupperes

• Det må lages en tabell med fullstendig tag-id og beskrivelse av objektene, Se «IWMAC MAL 02 - Tekniske signaler.xltx» for oppsett av dataunderlag.

• Finnes det grenseverdier eller andre attributter som er relevante må disse også medtas i oversikten.

Eksempel på et bilde ved bruk av standard symboler, ønskes andre symboler så må dette avklares i forkant av prosjektet:

Sjekkliste – Teknisk og elektrisk	Systemnr.:_______ Enhet:__________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Kunden har oversendt liste over alle tekniske signaler som skal presenteres i skjermbilder.		☐
Kunden har avklart med IWMAC hvordan signaler skal grupperes for presentasjon.		☐
Oversendt dokumentasjon inneholder all informasjon etterspurt i dette dokumentet.		☐
Parametere har samme navn som i parameterlister.		☐
Punktene på sjekklisten for kommunikasjonsprotokollen er behandlet.		☐
Eventuelle tilleggsfunksjoner er angitt i skriftlig støttedokumentasjon.	Husk å bestille smarte funksjoner ved behov.	☐

✅ 3.5 – IWMAC Sjekkliste – Energirapport

Når man bestiller energimodul hos IWMAC får man alle energimålere lagt inn i en energirapport.

For at IWMAC skal kunne sette opp en oversiktlig rapport er vi avhengig av at vi får komplett og riktig informasjon om alle målerne på anlegget:

• Alle fysiske målere må være implementert og igangkjørt på anlegget.

• Det må foretas en kvalitetssikring på at den fysiske måleren og Iwmac viser samme verdi.

• Iwmac må få en liste over målerne med merking og hvilken gruppe de ønskes presentert i. se dokument “1 – Design og Integrasjonsveileder”

• Det er også viktig å spesifisere hvilken enhet måleverdien skal hentes fra. (PLS, måler, fjernvarmesentral, etc). Se «IWMAC MAL 01 - Energirapport.xltx».

Det tilbys en standard gruppering:

• Energi Elektrisk

• Energi Termisk Varme

• Energi Termisk Kjøling

• Vannmålere - Mengde

I en energirapport blir målerne lagt inn 1 til 1 og det tilbys ikke noen kalkuleringer i dette oppsettet. Dersom dette ønskes, må det oppgraderes til EOS system hvor det tilbys et mer avansert og bygg-tilpasset oppsett.

Sjekkliste – Energirapport	System:_________________
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Målerstruktur oversendt IWMAC.		☐
Målte verdier på alle målere er kontrollert og godkjent.		☐

✅ 3.6 – IWMAC Sjekkliste – EOS (Energimoniteringssystem)

For at IWMAC skal kunne sette opp en oversiktlig og riktig EOS er vi avhengig av å få et godt bilde av hvordan kunden ønsker å visualisere energioppsettet.

• Alle fysiske målere må være implementert og igangkjørt på anlegget.

• Det må foretas en kvalitetssikring på at den fysiske måleren og IWMAC viser samme verdi.

• Det må foretas et valg på hvordan trestrukturen ønskes gruppert og hvilke beregninger som ønskes.

• IWMAC må få en liste over målerne med merking og hvilken gruppe de ønskes presentert i. Se dokument «1 – Design og Integrasjonsveileder»

• Det er også viktig å spesifisere hvilken enhet måleverdien skal hentes fra. (PLS, måler, fjernvarmesentral, etc). Se «IWMAC MAL 06 - EOS.xltx».

Når man velger flere målere / grupper av målere i EOS så kan man si at hovedregelen er at alle parameter som ligger angitt under disse blir summert i systemet (Energi/Mengde/Personer/Areal).

Man må derfor ha en klar strategi om hvordan man grupperer målere og på hvilke nivå i systemet man vil angi personer/areal for å unngå at disse blir summert flere ganger i samme gruppe.

Dette krever at man bestemmer seg for hvordan man ønsker å bruke systemet og hvilke data man ønsker å hente ut på de forskjellige nivåene og planlegger oppbygningen ut fra dette.

For at vi skal klare å presentere en ET kurve (Energi-Temperatur Kurve) må det finnes en utetemperatur vi kan bruke for dette.

Eksempel trestruktur:

Sjekkliste – EOS
Sjekkpunkt	Forklaring	Utført (Ja/Nei)
Alle beregninger som skal gjøres er dokumentert og oversendt IWMAC.		☐
Alle nøkkelindikatorer er oversendt IWMAC.	Antall personer pr areal, areal for hvert bygningsavsnitt osv. Se EOS-mal.	☐
Avklart med IWMAC hvilke rapporter som kan hentes ut.		☐
Målerstruktur oversendt IWMAC.		☐
Målte verdier på alle målere er kontrollert og godkjent.		☐

Maler:

📊 IWMAC Mal 01 – Energirapport

Select tab: NO – Energirapport.

Hovedgruppe	Målernavn	Ligger på enhet	Kommentar
Elektrisk energi
	001.001-OE01-[Name]	001.001-OE01
Termisk energi – Varme
	011.001-OE01-[Name]	PLS01
Termisk energi – Kjøling
	021.001-OE01-[Name]	PLS01
Vannmåler – Volum
	031.001-OE01-[Name]	031.001-OE01

📊 IWMAC Mal 02 – Tekniske signaler

Select tab: NO – Tekniske Signaler.

Hovedgruppe	Komponent som i tagliste	Ligger på enhet	Kommentar
310 Sanitær
	310.001-MO001	434.002-OU001
351 Kjøling
	351.001-QS001	PLS1

📊 IWMAC Mal 03 – BACnet EDE

BACnet EDE-filen (Engineering Data Exchange) er det standardiserte CSV-formatet som brukes for å eksportere BACnet-objektlister fra en undersentral og importere dem i IWMAC. Kiona har lagt til fire ekstra kolonner på slutten av standardformatet.

Kolonne	Type	Beskrivelse
keyname	Standard	Unikt objektnavn (f.eks. OBJECT_ANALOG_INPUT:11164)
device obj.-instance	Standard	Enhetens instansnummer
object-name	Standard	Kortnavn på objektet (f.eks. RT401 TILLUFTTEMP)
object-type	Standard	Objekttype (0=Analog Input, 1=Analog Output, 3=Analog Value, 4=Binary Input osv.)
object-instance	Standard	Objektinstans
description	Standard	Beskrivelse – skal inneholde systemnummer + komponentkode + tekst (f.eks. "360.001 RT401 Tillufttemperatur")
settable	Standard	Y = skrivbar i IWMAC, N = lesbar
state-text-reference	Standard	Referansenummer til MAL 04 StateTexts (for binære/multistate-objekter)
Alarm Pri	Kiona-tillegg	Alarmprioritet: A (høyest/SMS), B eller C
Include Attri.	Kiona-tillegg	1 = inkluder attributter (f.eks. intrinsic reporting). Krever separat attributtliste.
Gruppe	Kiona-tillegg	Systemnummer for gruppering (samme for alle objekter i samme system)
Rom	Kiona-tillegg	Romsbetegnelse for romkontrollobjekter (samme for alle objekter i samme rom/sone)

Tips: Åpne CSV-filen i Excel med semikolon som skilletegn. Lagre alltid som CSV UTF-8 uten BOM når du sender til Kiona.

📊 IWMAC Mal 04 – BACnet StateTexts

StateTexts-filen definerer tekstmerker for BACnet-objekter med heltalls- eller binære verdier. Den refereres fra EDE-filen via kolonnen state-text-reference. Hvert referansenummer (1, 2, 3…) definerer et sett med tekster der tekst 1 = verdi 0, tekst 2 = verdi 1 osv.

#Ref	Tekst 1 (verdi 0)	Tekst 2 (verdi 1)	Tekst 3	Tekst 4
1	OK	Feil
2	SD-ur	FAC-ur
3	Av	På
4	Vinter	Sommer
7	Auto	Av	På
8	Lav	Høy	Auto (utetemp)

Tips: Legg til egne rader for hver unik statuskombinasjon i anlegget. Referansenummeret kobles til kolonnen state-text-reference i EDE-filen. Binære objekter trenger minst 2 tekster (f.eks. Av/På). Multistate-objekter kan ha opptil n tekster.

📊 IWMAC Mal 05 – DX9100

Mal for Johnson DX9100-regulatorer. Rediger Template 1 eller Template 2. Fliken Example viser eksempeldata og Element IDs inneholder alle DX9100 element-ID-referanser.

Kolonne	Beskrivelse
Element_id	N2-protokolladresse, f.eks. PM01K01, AI1
System number	TFM-systemnummer, f.eks. 360.001
Tag text	Komponentkode/tag, f.eks. RT401
Aliastext	Beskrivende navn på parameteren
Alarm	Alarmnivå: A (høyest/SMS), B eller C
Eng unit	Måleenhet, f.eks. °C, %, m³/h
Scale	Skalering, f.eks. x100 eller x10

📊 IWMAC Mal 06 – EOS

Mal for energimoniteringssystem (EOS). Velg fliken NO – EOS. Malen har 8 kolonner:

Hovedgruppe → Undergruppe 1 → Undergruppe 2 → Undergruppe 3 → Undergruppe 4 → Bak måler → Fysisk måler → Virtuell måler (kol. M)

Hovedgruppe	Undergruppe 1	Undergruppe 2	Undergruppe 3	Undergruppe 4	Bak måler	Fysisk måler	Virtuell måler (kol. M)
Utetemperatur
Kvartal A
	Termiske målere
		Varmesystem				300.001-OE01
		Ventilasjon				310.001-OE02

Tips: Undergruppe 3 og 4 brukes for dypere hierarkier. "Bak måler" angir hvilke undernivåer som summeres i en overordnet måler. Kolonne M (Virtuell måler) beskriver beregnede måleverdier uten en fysisk måler.

📊 IWMAC Mal 07 – FX15

Mal for Johnson FX-regulatorer. Rediger fliken Parameterliste (original). Fliken Status NO (Statustekster) inneholder statustekster på norsk, Guide NO forklarer kolonnene.

Referanse	0	1	2
AvPå	Av	På
AutoAvPå	Auto	Av	På
NormalAlarm	Normal	Alarm
NormalFeil	Normal	Feil
InaktivAktiv	Inaktiv	Aktiv
AapenLukket	Lukket	Åpen
AutoNatt	Auto	Natt
NormalUtløst	Normal	Utløst

Key columns:

Kolonne	Beskrivelse
Point type	ADI=heltall, ADF=float, BD=boolean
Point address	N2-adresse, f.eks. adf1, adi1, bd1
Direction	Input=les, Output=skrivbar
Long name	Fullstendig beskrivende navn
Alarmnivå	A (høyest/SMS), B eller C
rw-flagg	r=les, rw=les/skriv

📊 IWMAC Mal 08 – Modbus

Modbus – in English for all languages.

Kolonne	Beskrivelse
Section A – System code	Systemnummer/TFM-kode
Section B – Component code	Komponent- og funksjonskode
Section C – Description	Beskrivende tekst
Data type	BOOL, UINT16, INT16, FLOAT32 osv.
Function code (read)	Modbus lese-FC (01,02,03,04)
Function code (write)	Modbus skrive-FC (05,06,15,16)
Register type	0x coil/1x input/3x input reg/4x holding reg
Register address	Modbus-registeradresse (desimal)
Engineering unit	f.eks. °C, %, m³/h
Scale (reference)	Skalering fra Scale-fanen
State-text (reference)	Statustekst fra State-Texts-fanen
Alarm level	A=høyest/SMS, B, C

State-Texts tab:

Referanse	0	1	2
OnOff	Av	På
AutoOffOn	Auto	Av	På
NormalAlarm	Normal	Alarm
NormalFault	Normal	Feil

📊 IWMAC Mal 09 – Romliste

Select tabs: NO – Romtyper and NO – Bygg x fløy x.

Romtype	Beskrivelse	Temperatur (RTxxx)	CO2 (Ryxxx)	Fukt (RHxxx)	PIR (RBxxx)
Romtype1	[Room]	°C / r	ppm / r	%RH / r	r
Romtype2	[Conference]	°C / r	ppm / r

📊 IWMAC Mal 10 – Enkel topologi (kun IP)

Topologi med kun IP. Velg fanen NO – Topologi kun IP.

Utstyr	Plassering/etasje/rom	Switch/rom/etasje	IP-adresse	Maske	Standard-gateway	DNS1	Port
=360.001	Floors 2–9	Switch-A	10.0.12.3	255.255.255.0	10.0.12.1	8.8.8.8
=432.001	Energy centre	Switch-A	10.0.12.5	255.255.255.0	10.0.12.1

📊 IWMAC Mal 11 – Topologi IP + seriekonvertere

Topologi IP + seriekonvertere. Velg fanen NO – Topologi IP + serie.

Utstyr	IP-adresser	Nettverksmaske	Betjener	IP-driver	Driveradresse
Block A
=360.001	10.0.12.3	255.255.255.0	Floors 2–9	PMGOLDA	1_1
Sauter	10.0.12.5	255.255.255.0	Energy centre	BACnet	0_1
Moxa	10.0.12.6	255.255.255.0	Modbus serial

📊 IWMAC Mal 12 – Topologieksempel

Eksportert PNG-bilde av topologidiagrammet. Viser nettverkstopologien med alle automatiseringsenheter, IP-adresser, switch, brannmur og Kiona-server. Brukes som referansebilde i dokumentasjon og som vedlegg.

📊 IWMAC Mal 13 – Topologikilde (Gliffy)

Redigerbar kildefil for topologidiagrammet i Gliffy-format (.gliffy). Filen kan åpnes og redigeres i Gliffy (gliffy.com) eller draw.io (app.diagrams.net) – begge er gratis å bruke for grunnleggende funksjoner. Oppdater diagrammet med prosjektspesifikk informasjon og eksporter deretter en ny PNG (Mal 12).

📥 Sjekklister og maler er tilgjengelig for nedlasting som vedlagte filer nederst i artikkelen – én ZIP-fil per språk med alle 25 filer i numerisk rekkefølge.

Versjon 1.0 – april 2026