Teknik · Teknisk netværk
Teknisk netværk
De tekniske systemer i en moderne bygning er i stigende grad netværksforbundne. CTS, måleropsamling, lysstyring, adgangskontrol, overvågning og andre systemer kommunikerer via IP og deler ofte den samme fysiske netværksinfrastruktur.
Det giver gode muligheder for integration og dataudveksling, men stiller samtidig krav til, at netværket projekteres som en del af bygningens tekniske infrastruktur.
Et godt teknisk netværk skal være stabilt, overskueligt, dokumenteret og opdelt, så de enkelte systemer kun har adgang til det, de har behov for.
01Et fælles netværk, opdelt efter funktion
Vi anbefaler som udgangspunkt, at bygningens tekniske systemer anvender en fælles administreret netværksinfrastruktur frem for, at hver leverandør etablerer sit eget isolerede netværk.
Det betyder ikke, at alle tekniske systemer skal ligge på samme logiske netværk. Tværtimod giver VLAN mulighed for at anvende den samme fysiske infrastruktur og samtidig holde forskellige systemtyper adskilt.
Som udgangspunkt foreslår vi tre tekniske VLAN:
- CTS, måleropsamling og lysstyring
- adgangskontrol og tyverisikring
- TVO-overvågning
Den konkrete opdeling skal altid tilpasses bygningen. I større eller særligt sikkerhedskritiske installationer kan der være behov for yderligere segmentering.
Pointen er at etablere tydelige grænser mellem systemer med forskellige funktioner og sikkerhedsbehov.
02CTS, målere og lysstyring på samme tekniske VLAN
CTS, energi- og måleropsamling samt central lysstyring har ofte et naturligt behov for at udveksle data.
Et CTS-anlæg kan eksempelvis have behov for energidata, mens et overliggende analyseværktøj kan have behov for både temperaturer, driftstilstande, lysstatus og målinger.
Derfor kan disse systemer med fordel placeres på samme tekniske VLAN, når sikkerheds- og projektspecifikke forhold ikke taler imod det.
At systemerne ligger på samme VLAN betyder dog ikke, at alle enheder nødvendigvis skal kunne kommunikere frit med hinanden. Firewallregler og adgangskontrol kan fortsat anvendes mellem relevante systemer og netværksområder.
03Adgangskontrol og overvågning holdes adskilt
Adgangskontrol, tyverisikring og TVO håndterer en anden type information og har en anden sikkerhedsprofil end almindelig bygningsautomation.
Vi anbefaler derfor, at disse systemer ikke placeres direkte på samme VLAN som CTS og den almindelige tekniske dataopsamling.
TVO bør som udgangspunkt have sit eget VLAN. Videotrafik kan desuden være betydeligt mere datatung end almindelig bygningsautomation, hvilket i sig selv taler for en separat netværkszone.
04Administrerbare switches som rygrad
Hovedkomponenter bør så vidt muligt forbindes til administrerbare switches.
Det giver mulighed for at se, hvor udstyret er tilsluttet, overvåge forbindelser, anvende VLAN og kontrollere kommunikationen mellem forskellige dele af installationen. Centrale switches bør samtidig placeres i aflåste teknik- eller serverrum.
Det er ikke nødvendigvis hensigtsmæssigt at føre et separat netværkskabel fra hver enkelt teknisk komponent tilbage til en central switch. Lokale switches og seriekoblede controllere kan være fornuftige, eksempelvis internt i en CTS-tavle, når det udføres kontrolleret og dokumenteret.
05Nogen skal eje netværksarkitekturen
En af de vigtigste organisatoriske beslutninger er at placere ansvaret for det tekniske netværk.
Hvis hver entreprenør selv vælger IP-adresser, subnet, gateways og internetforbindelser, bliver resultatet hurtigt vanskeligt at administrere.
Der bør derfor være én ansvarlig funktion, som har overblikket over IP-ranges, VLAN, firewallregler og hvilke systemer der må kommunikere med hinanden eller med internettet.
Det kan være bygherrens egen IT-organisation, en driftsorganisation eller en ekstern partner. Det afgørende er, at ansvaret er tydeligt placeret.
06Internetadgang skal være et aktivt valg
Et teknisk system behøver ikke internetadgang, bare fordi det er IP-baseret.
Nogle systemer har et reelt behov for forbindelse til eksterne tjenester. Andre skal kun kommunikere lokalt i bygningen.
Udgangspunktet bør derfor være, at internetadgang åbnes, når der er et konkret behov. Det samme gælder kommunikation mellem de tekniske VLAN.
På den måde bliver forbindelserne et bevidst designvalg frem for et resultat af, at alle systemer som standard kan kommunikere med alt.
Faste adresser eller DHCP?
En enhed på et IP-netværk skal have en adresse. Enten er den sat fast på enheden, eller også får enheden den udleveret af en DHCP-server, når den tændes.
På et teknisk netværk er faste adresser normen, og der er en god grund til det. Integrationer, firewallregler, punktlister og dokumentation peger på adressen. Skifter en controller adresse, fordi den har været slukket en weekend, holder forbindelsen op med at virke, og dokumentationen passer ikke længere. Fejlfinding bliver også enklere, når en adresse altid hører til den samme enhed.
Prisen er, at hver adresse skal vedligeholdes i hånden, og at en tastefejl giver to enheder den samme adresse.
Mellemvejen er at køre DHCP med reservationer. Enheden spørger som normalt, men serveren svarer altid med den samme adresse, fordi den er bundet til enhedens MAC-adresse. Så ligger listen ét sted og kan vedligeholdes, i stedet for at være fordelt på hundrede enheder, der hver især skal besøges.
Uanset hvad der vælges, gælder én regel: der må kun være én DHCP-server på det tekniske netværk. En router, nogen sætter til for at få et ekstra stik, og som begynder at dele adresser ud, er en klassisk måde at lægge et teknisk netværk ned på. Derfor hører det med til de administrerbare switches at lukke de porte, der ikke er i brug, se IT-sikkerhed og data.
07Dokumentation er en del af installationen
Et velfungerende netværk er ikke meget værd, hvis ingen kan gennemskue det fem år senere.
Netværkstopologi, VLAN, IP-ranges, faste adresser, gateways og væsentlige firewallforbindelser bør derfor være en del af bygningens som-udført-dokumentation.
Det samme gælder forbindelsen mellem netværket og de tekniske datapunkter. For eksempel bør punktlister gøre det muligt at identificere et punkt, dets enhed, objekttype og hvilken komponent eller hvilket system det tilhører.
Sådan kan listen se ud
Selve listen behøver ikke være avanceret. Et regneark med én linje pr. enhed rækker langt, så længe den bliver udfyldt undervejs og ikke rekonstrueret bagefter.
Tryk for fuld størrelse
Hovedet udfyldes af den, der ejer netværksarkitekturen: VLAN, adresseområde og gateway. Linjerne udfyldes af de fag, der sætter udstyr på, og hver linje knytter en enhed til en fysisk port og en fast adresse. Så kan et stik findes ud fra en adresse og omvendt, uden at nogen skal gætte.
De enheder, der sidder bag en gateway og ikke selv har en IP-adresse, hører til i punktlisten og ikke her, se Protokoller.
Netværksdokumentationen fortæller, hvordan man kommer frem til data. Den tekniske dokumentation fortæller, hvad data betyder.
08Et godt fundament for bygningsdata
Det tekniske netværk skal først og fremmest understøtte bygningens tekniske systemer sikkert og stabilt.
Men hvis netværket samtidig er veldokumenteret, segmenteret og giver kontrolleret adgang til data, bliver det langt lettere senere at tilslutte analyseværktøjer, dataplatforme og andre systemer.
Målet er ikke et kompliceret netværk. Målet er en teknisk infrastruktur, som kan forstås, kontrolleres og videreudvikles.
Har du et teknisk spørgsmål?
Book et møde på 45 minutter, eller skriv til os.