Design och integrationsvägledning

Den här guiden har tagits fram för att säkerställa bästa möjliga resultat i leveransen från Kiona. Den innehåller information om det underlag och den dokumentation som krävs för automationsleveransen, inklusive toppsystemet IWMAC och tillhörande tilläggstjänster.

Alla exempel och mallar finns också tillgängliga på webbplatserna för våra Kiona-certifierade partners. Om du inte hittar en mall, kontakta din kontaktperson på sälj eller leverans hos Kiona.

Snabbguide:

• Ladda ned mallar och checklistor som bifogade filer längst ner i artikeln
• Fyll i mallarna och checklistorna med information om anläggningen
• Skicka underlag och dokumentation till [e-mail]
• Kiona granskar och återkopplar om frågor eller behov av komplettering

📘 1 – Design och integrationsguide

1.1 – Syfte

Den här guiden har tagits fram för att säkerställa bästa möjliga resultat i leveransen från Kiona. Guiden innehåller information om det underlag och den dokumentation som krävs för automationsleveransen. Leveransen inkluderar toppsystemet IWMAC och tillhörande tilläggstjänster. Bilagorna beskriver det underlag som behövs för leveransen, med specifika detaljer för vissa anläggningstyper och protokoll.

Alla exempel och mallar finns också tillgängliga på webbplatserna för våra Kiona-certifierade partners.

Om du inte hittar en mall, kontakta din kontaktperson på sälj eller leverans hos Kiona.

1.2 – Nätverk/IT-infrastruktur

När leveransen har beställts skickas en installationsserver från Kiona. För att leveransen ska kunna starta måste kontakt etableras med den utsända installationsservern i god tid före planerad driftsättning. Börja därför med de förberedelser som krävs för att nätverket ska vara redo i tid.

Det är viktigt att kunden tidigt klargör med slutkunden om installationsservern ska kommunicera med Kiona-molnet via direkt internetanslutning eller VPN. När Kiona har fått informationen från kunden beställer Kiona rätt konfiguration från sin nätverksleverantör.

När leveransen påbörjas får du ett standardformulär för internetanslutning och VPN-anslutning som beskriver den information Kiona behöver, samt den konfiguration slutkunden måste genomföra för att installationsservern ska komma online. Kiona kan inte starta arbetet förrän formulären har returnerats och de beskrivna inställningarna har verifierats.

En installationsserver levereras med två nätverkskort. Kiona måste tilldelas två nätverksanslutningar – detta är viktig information som kunden måste ta reda på. Det rekommenderas att ett gränssnitt reserveras för internetanslutning och hålls separerat från det tekniska nätverket. Det andra gränssnittet ansluts till det tekniska nätverket.

Konvertrar som tillhandahålls av Kiona konfigureras som en del av leveransen när nödvändig information har lämnats över. För konvertrar som inte tillhandahålls av Kiona kan Kiona assistera med konfiguration och installation på installations-PC:n. Denna tjänst ingår dock inte i leveransen och hanteras som ett tilläggsalternativ.

1.3 – Topologi

För att kunna etablera kommunikationsanslutning med alla automationsenheter behöver Kiona en komplett topologi som listar all nödvändig nätverksinformation. Kiona är beroende av att få all information om seriell-till-nätverks-konvertrar, med tillhörande översikt över vilka automationsenheter som är anslutna till de olika portarna.

Se följande exempel:

• Grafik: topologi i PNG-format, framtagen i Gliffy eller liknande programvara – IWMAC MALL 12 – Topologi.png / IWMAC MALL 13 – Topologi.gliffy
• Excel: Enkel mall för enheter på IP, avancerad mall för enheter på IP och serieenheter via konvertrar – IWMAC MALL 10 – Enkel topologi, endast IP / IWMAC MALL 11 – Topologi IP och seriekonvertrar.xltx

1.4 – Parameterlistor, taggnamn och beskrivningar

IWMAC:s system använder namn och beskrivningar som tas emot i underlaget/dokumentationen från kunden. I vissa fall kan detta läsas av skannrar direkt från utrustningen. För att Kiona ska kunna ge slutanvändare läsbara och lokaliseringsbara taggnamn måste datalistorna innehålla nödvändig information samt en struktur som gör att Kiona kan bygga upp taggdatabaserna korrekt.

Här är några allmänna riktlinjer:

• Kiona förutsätter att ett systemnummer och tvärdisciplinärt märkningssystem (TFM) komponentkod anges för varje parameter/tagg-rad, samt en enkel parameterbeskrivning, antingen per fysisk komponent eller per funktion.
• För rumsstyrning måste det gå att separera varje rum, våning och vid behov byggnad eller flygel.
• Alla liknande funktioner inom varje rum måste ges samma funktionskod.
• För överordnade centrala komponenter och zonbegränsade funktioner måste zon/grupptilldelning anges för varje parameterrad.
• För listor som hanterar en enhet som endast betjänar ett systemnummer kan systemnumret utelämnas.

IWMAC:s komponentkodstandard används i bilder om inte annat har avtalats, eller om komponentkoder saknas i tagglistan eller tillhörande systemschema. Allt underlag måste vara konsekvent i teckenkodning för att Kiona ska kunna identifiera komponenternas tillhörighet.

Exempel för temperaturgivare (processvärde) och parameter för beräknat börvärde:

• 360.001 RT401 Tilluftstemperatur  eller  byggnr_360001_RT401_PV Tilluftstemperatur
• 360.001 RT401 Beräknat börvärde  eller  byggnr_360001_RT401_ASP arb. börvärde

Exempel för rum:

• R201_Erverdi – Rumstemperatur
• R201_BasSetp – Grundbörvärde
• R201_HVlv – Värmepådrag
• R201_SQ401_lm – Tilluft VAV1 luftflöde
• R201_SQ402_lm – Tilluft VAV2 luftflöde
• R201_SQ501_spjv – Frånluft VAV1 spjällvinkel

I Modbus-, KNX-, OPC-, N2- och motsvarande taglistor kan typiskt sett både TFM-kodning och beskrivning ingå i en och samma text. Det är då viktigt att strukturen är densamma för alla rader, med systemkomponentfunktionskoden i fast ordning – med fasta avgränsare först och beskrivning sist.

För BACnet-objekt kan TFM-kodningen ofta ingå i själva objektnamnet, medan beskrivningen läggs i “description”-attributet. Annan strukturering är också möjlig så länge taggen innehåller all nödvändig information och struktur, som tidigare beskrivits.

1.5 – Parameterlistor, alarmfunktionalitet och skrivbehörighet

Kiona måste direkt i taggdatabasen specificera vilka punkter som är läsbara och/eller skrivbara. Detsamma gäller för alarmnivåindikation för punkter som är avsedda att generera alarm.

IWMAC kräver normalt sett bara digitala alarm i databasen. Om kunden vill generera alarm på multistate (heltal) eller flyttalsvärden krävs klargörande med Kiona:s leveransansvarig om detta är möjligt i varje enskilt fall och vilka konsekvenser det kan ha avseende extra tid, behov av smarta funktioner m.m.

Se det specifika protokollbilagan för en beskrivning av den information Kiona behöver avseende om punkter ska vara skrivbara eller definiera alarmpunkter, samt tillhörande alarmnivå.

N2 – Johnson DX specifikt (SYS91/Metasys)

• Interna punkter i regulatorer måste specificeras i parameterlistorna om de ska integreras. Om IWMAC t.ex. ska styra anläggningen med sin kalender på DCO1 måste detta specificeras.
• Det räcker inte att ange endast analoga/digitala ingångar och utgångar. Interna punkter måste också anges för att få med setpunkter, kurvor, brytare, alarm på givare etc.
• Parameterlistor för Johnson DX måste innehålla N2-protokolladresser (t.ex.: AI1, XT3DI1, PM10K02, OUT1, HIA1, AIH1 etc.).

N2 Open – Johnson FX specifikt

• Det räcker inte att skicka .prn-filen för konfiguration av en FX-regulator, eftersom denna innehåller för få tecken och för lite information.
• Om ADI-punkter med bitar används måste dessa specificeras särskilt i parameterlistan.
• Parameterlistor för Johnson FX i Excel måste innehålla N2-protokolladresser (adf1, adi1, bd1, adi1, bit1).

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Kontrollera antalet enheter och uppdateringsfrekvens	En bedömning har gjorts av antalet enheter på serieslingor för att säkerställa att uppdateringsfrekvensen inte är för låg.	☐
Kontrollera adresser och kommunikationsinställningar	Alla serieenheter på en slinga har unika slavadresser och liknande kommunikationsinställningar. Baudrate, databitar och stoppbitar, paritet.	☐
Enheten/enheterna har färdigdriftsatts och funktionstestats.		☐
Busstopologi med alla enheter har skickats.	Slavadresser, kommunikationsinställningar, IP-adresser, COM-portar, mediekonvertrar etc. beskrivs.	☐
Tagglista	Komplett tagglista har tagits fram som beskrivs i den här guiden och skickats till Kiona.	☐

📥 Checklistor och mallar finns tillgängliga för nedladdning som bilagor längst ner i artikeln – en ZIP-fil per språk med alla 25 filer i nummerordning.

Checklistor:

✅ 2.1 – IWMAC Checklista – BACnet

Denna checklista gäller integration av BACnet-enheter med IWMAC-systemet. Alla punkter måste vara uppfyllda innan integration kan påbörjas.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Kontrollpunkt	Förklaring	☐
Enheten är färdigdriftsatt och funktionstestats.		☐
Enheten kan pingas från en IWMAC-PC.		☐
Extra kolumner har lagts till i slutet av EDE-filen.	Alarm Pri, Include Attri., Grupp, Rum – se exempelmall för EDE-fil: IWMAC MALL 03 – BACnet EDE.csv	☐
Kolumnen "settable" justeras så att alla punkter som ska vara skrivbara i IWMAC är "Y"; allt annat sätts till "N".	Skrivbara punkter är normalt sett setpunkter, väljarbrytare och liknande.	☐
Alla punkter med intrinsic reporting och alarmtillstånd aktiverat sätts till "1" i tilläggskolumnen "Include Attri.".		☐
En separat lista har skapats över de attribut som ska presenteras för datapunkterna.	För alla objekt där "Include Attri." är satt till "1".	☐
Varje parameter och rad i EDE-filen måste innehålla ett systemnummer, komponent/märkning och förklarande text.	Exempel: "320.001 RT401 Framledningstemperatur radiatorloop A block".	☐
Om systemnummer inte framgår ovan måste följande två rader fyllas i av kunden.		☐
Kolumnen "Grupp" har fyllts i med systemnummer för alla rader i EDE-filen.	Samma nummer/namn för alla objekt i samma system.	☐
Kolumnen "Rum" har fyllts i för alla objekt/rader som tillhör rumsstyrning/zonkontroll.	Samma rumsbeteckning för alla objekt i samma rum/zon.	☐
För alla objekt som indikerar alarm har alarmnivån angetts som "A", "B" eller "C". Måste också fyllas i på rader där "Include Attri." är satt till "1".	A för A-alarm, B för B-alarm och C för C-alarm. A-alarm är högsta nivå och skickas normalt som SMS. C-alarm är lägsta nivå.	☐
Om det finns binära alarm som är NC (normalt slutna) måste dessa listas i en separat översikt.	Aktivt alarm när Present value är binärt "0".	☐
Present value på multistate-objekt används inte för alarmstatus, driftstatus eller liknande.	Om så är fallet, rådgör med Kiona för att se om det är möjligt att transformera data i IWMAC-systemet.	☐
Binär datapunkt har tagits fram för att kvittera/återställa alarm för respektive system.	Punkten bör automatiskt återgå till "viloläge" efter aktivering.	☐
IWMAC-kalendrar används, länkade till följande objekt: ___________________________	Objekttyp och ID eller datapunktnamn för länkning i undercentral, ett per IWMAC-kalender. Objekten kan vara binära eller multistate. Om Kiona ska ange tiderna måste dessa specificeras i förväg.	☐
EDE och state texts har skickats i CSV-format.	Se exempelmall för state texts: IWMAC MALL 04 – BACnet StateTexts.csv	☐
Stort nätverk med flera subnät/IP-områden: Topologi har skickats.		☐

✅ 2.2 – IWMAC Checklista – Modbus

Denna checklista gäller integration av Modbus-enheter med IWMAC-systemet.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Kontrollpunkt	Förklaring	☐
En bedömning har gjorts av antalet enheter på serieslingor för att säkerställa att uppdateringsfrekvensen på parametrar inte är för låg (bör inte ta flera minuter).	Kom ihåg att Kiona som regel integrerar hela parameterlistan som skickas, om det inte specifikt anges vilka parametrar som ska integreras.	☐
Alla serieenheter på en slinga har unika slavadresser och samma kommunikationsinställningar i övrigt.	Baudrate, data- och stoppbitar, paritet	☐
Enheten/enheterna är färdigdriftsatt och funktionstestats.		☐
En räknarpollning eller liknande har körts för att testa kontakten med minst ett register på var och en av enheterna.		☐
Busstopologi med alla enheter har skickats.	Slavadresser, kommunikationsinställningar, IP-adresser, COM-portar, mediekonvertrar m.m. beskrivs.	☐
Information såsom utrustningens tillverkare och modellbeteckning, inklusive Modbus-parameterlista, har skickats.		☐
En komplett Modbus-parameterlista har tagits fram med information som beskrivs i inledningen till detta dokument.	Om utrustningen är anpassningsbart programmerbar	☐

✅ 2.3 – IWMAC Checklista – N2 / N2 Open

Denna checklista gäller integration av N2/N2 Open-enheter med IWMAC-systemet.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Kontrollpunkt	Förklaring	☐
Kontrollera antalet enheter och uppdateringsfrekvens	En bedömning har gjorts av antalet enheter på serieslingor för att säkerställa att uppdateringsfrekvensen inte är för låg.	☐
Kontrollera adresser och kommunikationsinställningar	Alla serieenheter på en slinga har unika slavadresser och liknande kommunikationsinställningar. Baudrate, databitar och stoppbitar, paritet.	☐
Enheten/enheterna har färdigdriftsatts och funktionstestats.		☐
Busstopologi med alla enheter har skickats.	Slavadresser, kommunikationsinställningar, IP-adresser, COM-portar, mediekonvertrar etc. beskrivs.	☐
Tagglista	Komplett tagglista har tagits fram som beskrivs i den här guiden och skickats till Kiona.	☐

✅ 2.4 – IWMAC Checklista – KNX via NETxOPC-server

För att Kiona ska kunna integrera KNX i IWMAC behövs viss information för att säkerställa att allt fungerar som det ska. Det är inte möjligt att "skanna" enheter eller datapunkter från enheterna, varför kunden måste exportera och skicka nödvändig data från ETS (programmeringsverktyget).

Innan anläggningen programmeras måste en gruppadressstruktur och namngivning skickas till Kiona för granskning och godkännande, för att säkerställa att bilder kan länkas effektivt.

Innan integrationen kan påbörjas måste Kiona ha mottagit all information som anges i checklistan nedan. Alla parametrar bör namnges på ett sätt som gör dem lätt identifierbara; se dokument "1 – Design och integrationsguide".

En Excel-fil med kompletterande information måste innehålla följande 7 extra kolumner utöver data från *.esf-filen:

• Skrivbara parametrar (rw)
• Mätenhet (°C, m³/h, % etc.)
• Skalering (0–255=0–100 etc.)
• Gateway/IP (för att skilja på vilka parametrar som tillhör vilka gateways)
• Alarmprioritering (A–B–C). A är högst prioritet och skickas normalt som SMS till alarmvakten
• Normalt stängd/NC (0=Alarm, 1=OK)
• Läs vid OPC-start (Read on reconnect)

KNX-installationen måste ha driftsatts och testats i förväg innan Kiona kan importera parameterlistan.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Gruppadressstrukturen har klargjorts och godkänts av Kiona.	Strukturen är också anpassad för effektiv länkning av rumsstyrningsbilder.	☐
Alla parametrar är namngivna i enlighet med "1 – Design och integrationsguide", eller alternativt diskuterats med och godkänts av Kiona.		☐
Alla komponenter på bussen har färdigdriftsatts och funktionstestats.		☐
Kiona har underrättats om hur många datapunkter som ska integreras.	Licens för antalet datapunkter och antal gateways.	☐
Topologi som visar varje gateway med underliggande buslinjer och adresser.		☐
Excel-ark med nödvändig information utöver innehållet i ESF-filen har skapats och skickats till Kiona.		☐
*.esf-fil från ETS, rensad från parametrar som inte ska integreras, har skickats till Kiona.	Avstämd mot antal punkter som angavs vid licensbeställning.	☐
En översikt över önskade toppsystemskalendrar och vilka datapunkter dessa ska skriva till har skickats till Kiona.	Driftstider måste vara kända om Kiona ska lägga in dem.	☐

✅ 2.5 – IWMAC Checklista – OPC DA

För att Kiona ska kunna integrera en enhet på OPC i IWMAC behövs viss information för att säkerställa att allt fungerar som det ska. Det är inte möjligt att "skanna" enheter eller datapunkter från enheterna, varför kunden måste ta fram detaljerade tagglistor.

Det är ofta utmanande att få kommunikation att fungera när en OPC-server placeras på en annan dator i nätverket, särskilt om den dessutom hamnar på ett annat tekniskt nätverk och nätverket är domänkontrollerat etc. Kiona behöver därför som regel veta om OPC-servern kan installeras på en IWMAC-PC.

OPC-anslutningsinformation

• Anslutningssträngen för OPC-servern (OPC-servernamnet som ska användas för vår OPC-klient).
• Eventuellt användarnamn och lösenord som klienten måste använda för att ansluta till OPC-servern.
• Gruppadressnamn och åtkomstsökväg om OPC-servern kräver detta.
• Om servern är installerad på en annan PC än en IWMAC-PC måste kunden tillhandahålla en översikt över alla relevanta parametrar för DCOM-konfigurationen, samt maskinnamn, nätverksparametrar, användarnamn och lösenord för kontot som kör och administrerar OPC-servern.
• Antalet kommunikationstrådar som stöds parallellt av OPC-servern och varje enhet bakom den måste anges.

Parameterlista

• Unikt namn och beskrivning av punkt. Denna text ska tydligt identifiera en punkt i förhållande till andra motsvarande punkter, t.ex. ett tvärdisciplinärt märkningssystem (TFM) och komponentkod.
• OPC-registeradress och datatyp och datalängd; se tabell.
• Eventuell bitspecifikation om ett enskilt bit i ett register ska exporteras som en binär datapunkt.
• "Teknisk enhet" såsom grC, bar, Pa, % och motsvarande för analoga värden.
• Skalering måste anges om relevant. Ska decimalpunkten vara rörlig på ett heltalsvärde: x10, x0.1, x0.001 etc.?
• Alla statusar som representeras av booleska eller heltalsvärden, t.ex. 0=Av, 1=På.
• Tydlig beskrivning av om punkten är läsbar eller skrivbar: r för läsbar, rw för skrivbar.
• Alarmnivåklassificering för digitala alarm: A är högst och skickas som alarmmeddelande, B och C är lägre nivåer.

Alla enheter bakom OPC-installationen måste ha driftsatts och testats i förväg innan Kiona kan importera parameterlistan.

Värde (decimal)	Datatyp	Beskrivning
0	VT_EMPTY	Standard/Tom (Ingenting)
2	VT_I2	2-bytes heltal med tecken
3	VT_I4	4-bytes heltal med tecken
4	VT_R4	4-bytes reellt tal
5	VT_R8	8-bytes reellt tal
6	VT_CY	Valuta
7	VT_DATE	Datum
8	VT_BSTR	Text
10	VT_ERROR	Felkod
11	VT_BOOL	Boolean (TRUE = -1, FALSE = 0)
17	VT_I1	1-byte heltal med tecken
18	VT_UI1	1-byte heltal utan tecken
19	VT_UI2	2-bytes heltal utan tecken
20	VT_UI4	4-bytes heltal utan tecken
+8192	VT_ARRAY	Matris med värden (t.ex. 8200 = matris med textvärden)

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Alla parametrar är namngivna i enlighet med "1 – Design och integrationsguide", eller alternativt diskuterats med och godkänts av Kiona.		☐
Alla komponenter på bussen har färdigdriftsatts och funktionstestats.		☐
Kunden har testat åtkomst till OPC-servern med en OPC-klient installerad på en IWMAC-PC.	Bekräftelse på att OPC-anslutningen fungerar och att kommunikation med alla enheter bakom fungerar.	☐
Anslutningsinformation har skickats till Kiona.		☐
Den kompletta tagglistan har tagits fram som beskrivs i guiden och skickats till Kiona.		☐
En översikt över önskade toppsystemskalendrar och vilka datapunkter dessa ska skriva till har skickats till Kiona.	Driftstider måste vara kända om Kiona ska lägga in dem.	☐

✅ 3.1 – IWMAC Checklista – Ventilation

För att Kiona ska kunna säkerställa att den visualisering som IWMAC tillhandahåller är korrekt behöver vi ta emot adekvat och korrekt dokumentation. Målet är att skapa ett enkelt, tydligt och begripligt system för anläggningens slutanvändare.

Följande måste som minimum framgå av insänd dokumentation:

• Systemnummer t.ex. 36.01, 360.01, 360.001 och beskrivning av driftsområde t.ex. lager, kontor, verkstad.
• Anläggningsspecifik funktionsbeskrivning som minst beskriver:
• Typ av temperaturreglering, t.ex. konstant tilluftstemperatur, utekompenserad tilluftsreglering.
• Typ av fläktreglering, t.ex. konstant luftflöde, konstant tryck.
• Eventuella aktiva funktioner och tillhörande setpunkter, t.ex. återluft, nattkylning, förlängd drift.
• Anslutna extramoduler och deras inställningar/aktiva funktion.
• Kurvor för säsongskompensering av luft eller temperatur etc.
• Utetemperatur. Aktivering/deaktivering av funktioner och deras setpunkter.
• Kalenderfunktioner för aktivering/deaktivering av funktioner.
• Förreglingar, ändringar av regleringsformer vid utetemperatur, datum etc.
• Systemskiss – flödesschema med komponentkoder påskrivna; underlaget måste vara "som byggt".
• Ett beslut måste tas om huruvida tidsstyrning från automationen önskas eller om IWMAC ska sätta upp en toppsystemskalender.
• Vid användning av toppsystemskalender måste Kiona informeras om vilka parametrar som ska användas för start/stopp samt tidpunkter.
• Om det inte finns någon dedikerad punkt för ett ur, och IWMAC ska använda anläggningens systemomkopplare, skapar IWMAC en virtuell programvaruomkopplare för bildvisningen.
• Vid användning av uret i automationen försöker IWMAC avspegla detta så bra som möjligt. I vissa speciella fall kan detta innebära utmaningar.

Vid val av toppsystemskalender bör man tänka på att uret i automationen måste deaktiveras. Kiona behöver också veta om alla funktioner (nattkylning, återluft etc.) tas om hand när den parameter används som toppsystemskalendern ska använda.

Checklistan nedan gäller per ventilationssystem (systemnummer).

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Systemskiss med alla komponentkoder har skickats till Kiona, med "som byggt" komponentplacering.		☐
Koder i systemskissen återfinns i parameterlistan.		☐
Alternativt, IWMAC-märkning används i bilder.		☐
IWMAC tidsstyrning ska användas.		☐
Alternativt, regulatorns interna ur används.		☐
Funktionsbeskrivning med information som efterfrågats ovan har skickats till Kiona.		☐
Punkter i checklistan för kommunikationsprotokoll har hanterats.		☐
Eventuella extrafunktioner såsom väderprognoser, effektvakt, mätvärdesfördelning, alarmfunktioner och liknande framgår av skriftligt underlag.	Kom ihåg att beställa smarta funktioner vid behov.	☐

✅ 3.2 – IWMAC Checklista – Värme- och kylsystem

För att Kiona ska kunna säkerställa att den visualisering som IWMAC tillhandahåller är korrekt behöver vi ta emot adekvat och korrekt dokumentation. Målet är att skapa ett enkelt, tydligt och begripligt system för anläggningens slutanvändare.

• Korrekta ritningar ("som byggt") där komponentmärkningen stämmer överens med märkningen i parameterlistan. Dvs. automation som styr/reglerar värmesystemet måste ha samma märkning som visas i dokumentationen.
• Kompletta parameterlistor där parametrarna har vettiga och korrekta texter och är märkta med komponentnummer enligt ritning. Slutanvändaren måste kunna förstå texterna – detta är särskilt viktigt för alarmtexter.
• Se "IWMAC Design och integrationsguide" för en detaljerad beskrivning av namngivningskraven.
• Funktionsbeskrivning av anläggningen. Allt som rör förreglingar, alarmfunktioner, säsongsskiftningsfunktioner och regleringsfunktioner måste inkluderas.
• Vilka setpunkter vill kunden visa direkt i bilden? (Alla parametrar är tillgängliga under Inställningar). I bilden visualiseras normalt viktiga SP som slutanvändare måste kunna ändra, såsom kurvor, temperaturer, setpunkter etc.

Kiona designar bilder enligt egen standard som speglar värmesystemets uppbyggnad enligt PID-ritningen så långt det är möjligt. Kiona gör justeringar och uppdelningar så att resultatet passar in med definierade bildstorlekar och symboler i IWMAC. Alla alarmindikationer läggs in som alarmklockor – dessa syns bara vid aktiva alarm. IWMAC:s standardmärkning är TFM med 3 siffror. Om ett alternativ önskas måste detta framgå av dokumentationen. Det är viktigt att den fysiska märkningen stämmer överens med bilderna som visualiseras i IWMAC.

Checklistan nedan gäller per värme- eller kylsystem (systemnummer).

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Systemskiss med alla komponentkoder har skickats till Kiona, med "som byggt" komponentplacering.		☐
Koder i systemskissen återfinns i parameterlistan.		☐
Funktionsbeskrivning med information som efterfrågats ovan har skickats till Kiona.		☐
Punkter i checklistan för kommunikationsprotokoll har hanterats.		☐
Eventuella extrafunktioner såsom väderprognoser, effektvakt, mätvärdesfördelning, alarmfunktioner och liknande framgår av skriftligt underlag.	Kom ihåg att beställa smarta funktioner vid behov.	☐

✅ 3.3 – IWMAC Checklista – Rumsstyrning

För att Kiona ska kunna säkerställa att den visualisering som IWMAC tillhandahåller är korrekt behöver vi ta emot adekvat och korrekt dokumentation. Målet är att skapa ett enkelt, tydligt och begripligt system för anläggningens slutanvändare.

• För att skapa bilderna måste Kiona ta emot korrekta planritningar av byggnaden i dwg-format, med möjlighet att stänga av lager så att vi sitter kvar med bara grundskissen/rumsindelningen.
• En översikt måste skapas över alla rum som ska ingå i rumsstyrningen, med följande angivet:
• Rumsnummer/namn
• Rumstyp (om olika rumstyper finns)
• Regulatoradress
• De parametrar som ska visualiseras på de olika rumstyperna. Standardleveransen inkluderar visualisering av upp till 15 taggar per rum.
• Se "IWMAC MALL 09 – Rumlista.xltx" för önskat upplägg av översikt över rumstyper och taggar.
• Vår standard är att visa rumstemperatur och aktuell setpunkt i popup-fönster. Popups anpassas till de olika rumstyperna som mottagits från kunden.
• Mallar har inkluderats för upp till 10 olika/individuella rumstyper.
• Om anläggningen avviker från standardproceduren måste detta klargöras vid försäljningstillfället och specificeras därefter.
• Om rumsstyrningen har konfigurerats i en PLC etc. måste rum/parametertilldelningen vara tydligt märkt, med en lättförståelig beskrivning av parametrarna, se dokument "1 – Design och integrationsguide".
• Planuppdelningen måste ta hänsyn till önskat antal parametrar i popupen, byggnadens form och slutanvändarens logiska indelning av byggnadsbeståndet.
• 1 tidskatalog per våning ingår – om en annan indelning önskas måste detta klargöras med Kiona.
• Om visualisering av överstyrningsfunktioner och smarta funktioner önskas måste Kiona meddelas innan visualiseringsarbetet påbörjas.

Så långt det är möjligt skapar Kiona bilder enligt sin standard utifrån de dwg-filer som mottas. Kiona gör justeringar och uppdelningar så att resultatet passar in med bildstorlekar och symboler i IWMAC.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
En rumlista med rumstyper och en lista över alla rum av de olika rumstyperna har tagits fram och skickats till Kiona.		☐
Klargörande har skett med Kiona om vilka värden som ska visas i popup-fönster.		☐
Planritningar har skickats, i beskrivet format och med möjlighet till enkel borttagning av oönskad information.		☐
Insänd dokumentation innehåller all information som efterfrågas i detta dokument.		☐
Parametrar har samma namn som i parameterlistorna.		☐
Punkter i checklistan för kommunikationsprotokoll har hanterats.		☐
Eventuella önskemål om visualisering av överstyrningsfunktioner har skickats in (stryk om ej tillämpligt).		☐
Eventuella extrafunktioner såsom väderprognoser, effektvakt, mätvärdesfördelning, alarmfunktioner och liknande framgår av skriftligt underlag.	Kom ihåg att beställa smarta funktioner vid behov.	☐
Klargörande har skett med Kiona om indelningen för tidskataloger. Normalt sett finns en tidskatalog per våning.		☐

✅ 3.4 – IWMAC Checklista – Teknisk och elektrisk

För att Kiona ska kunna säkerställa att den visualisering som IWMAC tillhandahåller är korrekt behöver vi ta emot adekvat och korrekt dokumentation. Målet är att skapa ett enkelt, tydligt och begripligt system för anläggningens slutanvändare.

Signalerna är ofta spridda över många undercentraler, fördelade i hela byggnadsbeståndet. Detta kräver att kunden på ett systematiskt sätt specificerar vilka signaler som ska presenteras på de tekniska sidorna.

• IWMAC kan gruppera signaler efter plats, system, disciplin eller signaltyp enligt önskemål.
• Det krävs klargörande om hur signaler ska grupperas.
• En tabell med komplett tagg-ID och beskrivning av objekten måste skapas; se "IWMAC MALL 02 – Tekniska signaler.xltx" för presentationen av underlagsdata.
• Om det finns gränsvärden eller andra attribut som är relevanta måste dessa också inkluderas i översikten.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Kunden har skickat en lista över alla tekniska signaler som ska presenteras i IWMAC-bilderna.		☐
Kunden har klargjort med Kiona hur signaler ska grupperas för presentation.		☐
Insänd dokumentation innehåller all information som efterfrågas i detta dokument.		☐
Parametrar har samma namn som i parameterlistorna.		☐
Punkter i checklistan för kommunikationsprotokoll har hanterats.		☐
Eventuella extrafunktioner såsom väderprognoser, effektvakt, mätvärdesfördelning, alarmfunktioner och liknande framgår av skriftligt underlag.	Kom ihåg att beställa smarta funktioner vid behov.	☐

✅ 3.5 – IWMAC Checklista – Energirapport

När du beställer en energimodul från Kiona läggs alla energimätare in i en energirapport i IWMAC.

För att Kiona ska kunna skapa en tydlig rapport behöver vi att kunden skickar oss komplett och korrekt information om alla mätare på anläggningen:

• Alla fysiska mätare måste ha implementerats och driftsatts på anläggningen.
• En kvalitetssäkring måste genomföras för att bekräfta att den fysiska mätaren och IWMAC visar samma värde.
• Kiona måste ta emot en lista över mätarna med märkning samt en angivelse av i vilken grupp kunden vill att de ska presenteras; se dokument "1 – Design och integrationsguide".
• Det är också viktigt att specificera den enhet från vilken mätvärdet ska hämtas (PLC, mätare, fjärrvärmecentral etc.). Se "IWMAC MALL 01 – Energirapport.xltx".

En standardgruppering erbjuds:

• Energi – Elektrisk
• Energi – Termisk värme
• Energi – Termisk kylning
• Vattenmätare – Volym

I en energirapport läggs mätarna in 1 till 1 och inga beräkningar erbjuds i denna konfiguration. Om beräkningar krävs måste konfigurationen uppgraderas till ett energiuppföljningssystem (EOS), där Kiona erbjuder en mer avancerad och byggnadsspecifik konfiguration.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Mätarstruktur har skickats till Kiona.		☐
Mätvärden på alla mätare har kontrollerats och godkänts.		☐

✅ 3.6 – IWMAC Checklista – EOS (Energiuppföljningssystem)

För att Kiona ska kunna sätta upp ett tydligt och korrekt EOS i IWMAC behöver vi ha en god bild av hur kunden vill visualisera energikonfigurationen.

• Alla fysiska mätare måste ha implementerats och driftsatts på anläggningen.
• En kvalitetssäkring måste genomföras för att bekräfta att den fysiska mätaren och IWMAC visar samma värde.
• Ett beslut måste tas om hur trädstrukturen ska grupperas och vilka beräkningar som krävs.
• Kiona måste ta emot en lista över mätarna med märkning samt en angivelse av i vilken grupp kunden vill att de ska presenteras. Se dokument "1 – Design och integrationsguide".
• Det är också viktigt att specificera den enhet från vilken mätvärdet ska hämtas (PLC, mätare, fjärrvärmecentral etc.). Se "IWMAC MALL 06 – EOS.xltx".

När man väljer flera mätare/grupper av mätare i EOS bör man notera att alla parametrar som anges under dessa summeras i systemet (Energi/Volym/Personer/Area).

En tydlig strategi behövs därför för hur mätare ska grupperas och på vilken nivå i systemet som personer/area ska anges för att undvika att dessa summeras flera gånger i samma grupp.

Detta kräver att kunden bestämmer hur de vill använda systemet och vilka data de vill extrahera på de olika nivåerna. Strukturen bör sedan planeras utifrån detta.

För att Kiona ska kunna presentera ett energi/temperaturdiagram måste det finnas en utetemperatur som kan användas för detta.

Kontrollpunkt	Förklaring	Utfört (Ja/Nej)
Alla beräkningar som ska göras har dokumenterats och skickats till Kiona.		☐
Alla nyckeltal har skickats till Kiona.	Personer per area, area för varje byggnadsdel etc. Se EOS-mall.	☐
Klargörande har skett med Kiona om vilka rapporter som ska kunna extraheras.		☐
Mätarstruktur har skickats till Kiona.		☐
Mätvärden på alla mätare har kontrollerats och godkänts.		☐

Mallar:

📊 IWMAC Mall 01 – Energirapport

Fyll i en rad per energimätare. Välj fliken SV – Energirapport.

Huvudgrupp	Mätarnamn	Placerad på enhet	Kommentar
Elektrisk Energi
	001.001-OE01-[Mätarnamn]	001.001-OE01
	002.001-OE02-[Mätarnamn]	002.001-OE02
Termisk Energi – Värme
	011.001-OE01-[Mätarnamn]	011.001-OE01
Termisk Energi – Kyla
	021.001-OE01-[Mätarnamn]	021.001-OE01
Vattenmätare – Volym
	031.001-OE01-[Mätarnamn]	031.001-OE01

📊 IWMAC Mall 02 – Tekniska signaler

Lista alla tekniska signaler som ska presenteras i IWMAC. Välj fliken SV – Tekniska Signaler.

Huvudgrupp	Komponent som i tagglista	Placerad på enhet	Kommentar
310 Sanitär
	310.001-MO001 [Beskrivning]	434.002-OU001
	310.001-QN001 [Beskrivning]	434.002-OU001
351 Kylning
	351.001-QS001 [Beskrivning]	PLS1

📊 IWMAC Mall 03 – BACnet EDE

BACnet EDE-filen (Engineering Data Exchange) är det standardiserade CSV-format som används för att exportera BACnet-objektlistor från en undercentral och importera dem i IWMAC. Kiona har lagt till fyra extra kolumner i slutet av standardformatet.

Kolumn	Typ	Beskrivning
keyname	Standard	Unikt objektnamn (t.ex. OBJECT_ANALOG_INPUT:11164)
device obj.-instance	Standard	Enhetens instansnummer
object-name	Standard	Kortnamn på objektet (t.ex. RT401 TILLUFTTEMP)
object-type	Standard	Objekttyp (0=Analog Input, 1=Analog Output, 3=Analog Value, 4=Binary Input osv.)
object-instance	Standard	Objektinstans
description	Standard	Beskrivning – ska innehålla systemnummer + komponentkod + text (t.ex. "360.001 RT401 Tillufttemperatur")
settable	Standard	Y = skrivbar i IWMAC, N = läsbar
state-text-reference	Standard	Referensnummer till Mall 04 StateTexts (för binära/multistate-objekt)
Alarm Pri	Kiona-tillägg	Alarmprioritering: A (högst/SMS), B eller C
Include Attri.	Kiona-tillägg	1 = inkludera attribut (t.ex. intrinsic reporting). Kräver separat attributlista.
Gruppe	Kiona-tillägg	Systemnummer för gruppering (samma för alla objekt i samma system)
Rom	Kiona-tillägg	Rumsbeteckning för rumsstyrningsobjekt (samma för alla objekt i samma rum/zon)

Tips: Öppna CSV-filen i Excel med semikolon som avgränsare. Spara alltid som CSV UTF-8 utan BOM när du skickar till Kiona.

📊 IWMAC Mall 04 – BACnet StateTexts

StateTexts-filen definierar textmärkningar för BACnet-objekt med heltals- eller binärvärden. Filen refereras från EDE-filen via kolumnen state-text-reference. Varje referensnummer (1, 2, 3…) definierar en uppsättning texter, där text 1 = värde 0, text 2 = värde 1 osv.

#Ref	Text 1 (värde 0)	Text 2 (värde 1)	Text 3	Text 4
1	OK	Fel
2	SD-ur	FAC-ur
3	Av	På
4	Vinter	Sommar
7	Auto	Av	På
8	Låg	Hög	Auto (utetemp)

Tips: Lägg till egna rader för varje unik statuskombination i er anläggning. Referensnumret i StateTexts-filen kopplas till kolumnen state-text-reference i EDE-filen. Binära objekt behöver minst 2 texter (t.ex. Av/På). Multistate-objekt kan ha upp till n texter.

📊 IWMAC Mall 05 – DX9100

Mall för Johnson DX9100-regulatorer. Fyll i fliken Template 1 eller Template 2 med era parametrar. Fliken Example visar ifyllt exempeldata och fliken Element IDs innehåller referens för alla DX9100-element-IDn.

Kolumn	Beskrivning
Grupp	Kategori för parametern, t.ex. Inställningar, Analoga värden, Analoga utgångar, Digitala ingångar, Digitala utgångar
Element_id	N2-protokolladress, t.ex. PM01K01, AI1, XT3DI1
System number	TFM-systemnummer, t.ex. 360.001
Tag text	Komponentkod/tagg, t.ex. RT401
Aliastext	Beskrivande namn på parametern, t.ex. Tillufttemperatur
Alarm	Alarmnivå: A (högst/SMS), B eller C
Eng unit	Mätenhet, t.ex. °C, %, m³/h
Scale	Skalering, t.ex. x100 eller x10

📊 IWMAC Mall 06 – EOS

Mall för energiuppföljningssystem (EOS). Välj fliken SV – EOS.

Mallen har 8 kolumner: Huvudgrupp → Undergrupp 1 → Undergrupp 2 → Undergrupp 3 → Undergrupp 4 → Ligger bakom mätare → Fysisk mätare → Virtuell mätare (beskriv i kol. M).

Huvudgrupp	Undergrupp 1	Undergrupp 2	Undergrupp 3	Undergrupp 4	Ligger bakom mätare	Fysisk mätare	Virtuell mätare (kol. M)
Utomhustemperatur
Kvarter A
	Termiska mätare
		Värmesystem				300.001-OE01
		Ventilation				310.001-OE02

Tips: Undergrupp 3 och 4 används för djupare hierarkier. "Ligger bakom mätare" anger vilka undernivåer som summeras i en överliggande mätare. Kolumn M (Virtuell mätare) beskriver beräknade mätvärden utan en fysisk mätare.

📊 IWMAC Mall 07 – FX15

Mall för Johnson FX-regulatorer. Redigera fliken Parameterliste (original). Fliken Status SV (Statustexter) innehåller statustexter på svenska, Guide SV förklarar kolumnerna.

Statustexter (SV):

Referens	0	1	2
AvPå	Av	På
AutoAvPå	Auto	Av	På
NormalAlarm	Normal	Larm
NormalFeil	Normal	Fel
InaktivAktiv	Inaktiv	Aktiv
AapenLukket	Stängd	Öppen
AutoNatt	Auto	Natt
NormalUtløst	Normal	Utlöst

Viktiga kolumner i Parameterliste:

Kolumn	Beskrivning
Point type	ADI=heltal, ADF=float, BD=boolean
Point address	N2-adress, t.ex. adf1, adi1, bd1
Direction	Input=läs, Output=skrivbar
Long name	Fullständigt beskrivande namn
Alarmnivå	A (högst/SMS), B eller C
rw-flagg	r=läs, rw=läs/skriv

📊 IWMAC Mall 08 – Modbus

Mall för Modbus-integration – redan på engelska, används direkt för alla språk.

Fliken Parameterlist – kolumner:

Kolumn	Beskrivning
Section A – System code	Systemnummer/TFM-kod
Section B – Component code	Komponent och funktionskod
Section C – Description	Beskrivande text
Data type	BOOL, UINT16, INT16, FLOAT32 etc.
Function code (read)	Modbus-funktionskod för läsning (01, 02, 03, 04)
Function code (write)	Modbus-funktionskod för skrivning (05, 06, 15, 16)
Register type	0x coil / 1x input / 3x input reg / 4x holding reg
Register address	Modbus-registeradress (decimalt)
Engineering unit	Mätenhet, t.ex. °C, %, m³/h
Scale (reference)	Skalering från fliken Scale
State-text (reference)	Statustext från fliken State-Texts
Alarm level	A=högst/SMS, B, C

Fliken State-Texts (urval):

Referens	0	1	2
OnOff	Off	On
AutoOffOn	Auto	Off	On
NormalAlarm	Normal	Alarm
NormalFault	Normal	Fault

📊 IWMAC Mall 09 – Rumlista

Mall för rumlista. Välj fliken SV – Rumstyper (rumstypdefinitioner) och SV – Byggnad x flygel x (faktisk rumlista).

Flik 1 – Rumstyper: Definiera sensorer/detektorer och parametrar per rumstyp (temperatur, co2/voc, fukt, pir etc.).

Rumstyp	Beskrivning	Temperatur (RTxxx)	CO2/VOC (Ryxxx)	Fukt (RHxxx)	PIR (RBxxx)
Rumstyp1	[Kontorsrum]	°C / r	ppm / r	%RH / r	r
Rumstyp2	[Konferensrum]	°C / r	ppm / r

Flik 2 – Byggnad x flygel x: Lista alla rum med rumsnummer och rumstyp.

Rumsnr	Rumstyp
Plan 1
Rum102	Rumstyp1
Rum103	Rumstyp1
Rum117	Rumstyp2

📊 IWMAC Mall 10 – Enkel topologi (IP)

Enkel topologimall för anläggningar med enbart IP-enheter. Välj fliken SV.

Utrustning	Placering/våning/rum	Switch/rum/våning	IP-adress	Mask	Standard-gateway	DNS1	Port
=360.001 [Ventilationsagg.]	2–9 vån.	Switch-A	10.0.12.3	255.255.255.0	10.0.12.1	8.8.8.8
=432.001 [Värmesystem]	Energicentral	Switch-A	10.0.12.5	255.255.255.0	10.0.12.1

📊 IWMAC Mall 11 – Topologi IP + seriekonvertrar

Topologimall för anläggningar med IP-enheter och seriekonvertrar (Moxa etc.). Välj fliken SV.

Utrustning	IP-adresser	Nätmask	Betjänar	IP-drivrutin	Drivrutinsadress
Kvarter A
(+)A(=)360.001	10.0.12.3	255.255.255.0	2–9 Ventilation	PMGOLDA	1_1
(+)A(=)360.002	10.0.12.4	255.255.255.0	1 Ventilation	PMGOLDA	2_1
Sauter	10.0.12.5	255.255.255.0	Energicentral	BACnet	0_1
Moxa	10.0.12.6	255.255.255.0	Modbus serieslingor

📊 IWMAC Mall 12 – Topologiexempel

Exporterad PNG-bild av topologidiagrammet. Visar nätverkstopologin med alla automationsenheter, IP-adresser, switch, brandvägg och Kiona-server. Används som referensbild i dokumentation och som bilaga.

📊 IWMAC Mall 13 – Topologikälla (Gliffy)

Redigerbar källfil för topologidiagrammet i Gliffy-format (.gliffy). Filen kan öppnas och redigeras i Gliffy (gliffy.com) eller draw.io (app.diagrams.net) – båda är kostnadsfria att använda för grundläggande funktioner. Uppdatera diagrammet med projektspecifik information och exportera sedan en ny PNG (Mall 12).

📥 Checklistor och mallar finns tillgängliga för nedladdning som bilagor längst ner i artikeln – en ZIP-fil per språk med alla 25 filer i nummerordning.

Version 1.0 – April 2026