En applikation för kommunikation mellan fastighetsägare och hyresgäst vid åtgärder i fastighetens styrsystem

(1)

Sj ¨alvst ¨andigt arbete i informationsteknologi 16 juni 2019

En applikation f ¨or kommunikation mellan fastighets ¨agare och

hyresg ¨ast vid ˚atg ¨arder i fastighetens styrsystem

Erik G ˚adin

Ester Kylm ¨anen Markus Sj ¨oholm Matilda Tamm

Civilingenj ¨orsprogrammet i informationsteknologi

(2)

Institutionen f ¨or informationsteknologi

Bes ¨oksadress:

ITC, Polacksbacken L ¨agerhyddsv ¨agen 2

Postadress:

Box 337 751 05 Uppsala

Hemsida:

http:/www.it.uu.se

Abstract

En applikation f ¨ or kommunikation mellan fastighets ägare och hyresg äst vid ˚atg ärder i fastighetens styrsystem

Erik G ˚adin Ester Kylm ¨anen Markus Sj ¨oholm Matilda Tamm

The development of larger cities is currently prevented by congested electricity grids. In today’s modern society, it is not sensible to build new real estates without a guarantee of access to energy, both during the construction and the maintenance. Market participants who utilize the power grid simultaneously is an example of what leads to these congested grids. The cities’ total energy consumption does not necessarily need be adjusted. Rather, the times of usage must be. This puts a great deal of responsibility on property owners who have a big impact on the energy consumption, because they have the power to control the consumption in their properties. Therefore, the purpose of the project was to allow the property owners in an easy-to-manage and convenient man- ner to inform their tenants of changes made inside the properties. The result was the implementation of an add on to a mobile application in the form of a cloud-based database, which could be connected to the database of the property’s control system. Furthermore, through the application property owners can give tenants suggestions on how they can contribute to reduce energy use. Our solution will not solve the entire capacity shortage in the grids, but rather it is a partial solution and one step closer to a smarter electricity use and a changed user behaviour. A solution that does not require expansion of the power grid.

Extern handledare: Ulf Näslund, Vasakronan AB Handledare: Mats Daniels och Björn Victor Examinator: Björn Victor

(3)

Sammanfattning

Utvecklingen av större städer förhindras för närvarande av kapacitetsbrist i elnätet. För dagens moderna samhälle är det inte rimligt att bygga nya fastigheter utan en garan- ti av tillg˚ang till energi, b˚ade under byggnationen och det senare underh˚allet. Mark- nadsaktörer som belastar elnätet samtidigt är ett exempel p˚a vad som leder till dessa

överbelastade nät. Städernas totala energiförbrukning behöver inte nödvändigtvis juste- ras. Snarare m˚aste förbrukningen under högbelastade tidpunkter flyttas till tidpunkter d˚a belastningen är mindre, – näten m˚aste allts˚a användas smartare. Detta innebär mycket ansvar för fastighetsägare som har stor inverkan p˚a energiförbrukningen, eftersom dem har möjligheten att styra förbrukningen i sina fastigheter. Därför var syftet med projektet att l˚ata fastighetsägarna p˚a ett lätthanterlig och bekvämt sätt informera sina hyresgäster om förändringar som utförs i fastigheterna. Resultatet var implementation av ett tillägg till en mobilapplikation och i form av en molnbaserad databas, vilken kunde uppkopplas till fastighetens styrsystem. Vidare finns även möjlighet för fastig- hetsägare att ge hyresgäster förslag p˚a vad de själva kan bidra med för att minska ener- gianvändningen. V˚ar lösning kommer inte lösa hela kapacitetsbristen i elnäten, utan det

är snarare en dellösning och ett steg närmre en smartare elanvändning och ett ändrat användarbeteende. En lösning som inte kräver utbyggnad av elnätet.

(4)

Inneh ˚all

1 Inledning 1

2 Bakgrund 2

2.1 Kapacitetsbristen i eln¨aten . . . 2

2.1.1 Kapacitetsbrist beroende p˚a v¨ader . . . 3

2.1.2 Kapacitetsbrist grundad p˚a tid . . . 3

2.1.3 Kapacitetsbrist i Uppsala . . . 4

2.1.4 On-demand-signaler och CoordiNet . . . 5

2.2 Uppdraget . . . 5

2.2.1 Leed-certifiering . . . 6

2.2.2 Vasakronans regleringar och nuvarande mobilapplikation . . . . 7

3 Syfte, m˚al, och motivation 7 3.1 Syfte . . . 7

3.2 M˚al . . . 8

3.3 Motivation . . . 8

3.3.1 H˚allbara st¨ader och samh¨allen . . . 8

3.3.2 H˚allbar industri, innovationer och infrastruktur . . . 9

3.4 Avgr¨ansningar . . . 10

4 Relaterat arbete 11 4.1 Informationsspridning . . . 11

4.2 Reglering av eln¨atet . . . 11

4.3 Mobilapplikation med push-notifikation . . . 12

4.4 Notis baserat p˚a v¨aderprognos . . . 12

(5)

5 Metod 13

5.1 Informationsh¨amtning . . . 13

5.2 Databas . . . 13

5.2.1 IDUN . . . 14

5.2.2 Molnbaserad databas . . . 14

5.3 Programspr˚ak och arbetsg˚ang . . . 15

5.3.1 Mobilapplikation . . . 16

5.3.2 Back-end . . . 17

6 Systemstruktur 17 6.1 Användargränssnitt för hyresgästerna . . . 18

6.2 Gr¨anssnitt mot IDUN . . . 19

6.3 Centrala databasen . . . 19

7 Krav och utv¨arderingsmetoder 21 7.1 Information och kommunikation . . . 21

7.1.1 Information anpassad till ber¨ord fastighet . . . 22

7.1.2 Automatiserad informationsuppdatering . . . 22

7.1.3 Kommunikationen med databasen . . . 23

7.2 Push-notifikationer . . . 23

8 Prototyp för gränssnitt mot hyresgäster 24 9 Implementantion av den centrala databasen 25 9.1 Databasens uppbyggnad . . . 25

9.2 API mellan klient och databas . . . 26

9.3 Molnbaserad databas . . . 27

(6)

9.4 V¨ader-API . . . 27

9.5 API mot molnbaserad databas fr˚an IDUN . . . 28

10 Utv¨arderingsresultat 28 10.1 Information och kommunikation . . . 28

10.1.1 Fastighetsanpassad information . . . 29

10.1.2 Automatiserad informationsuppdatering . . . 29

10.1.3 Kommunikation med databasen . . . 29

10.2 Push-notifikationer . . . 30

11 Resultat 30 11.1 Olika typer av notifikationer . . . 31

12 Diskussion 31 12.1 Resultatet . . . 32

12.2 Arbetsg˚angen . . . 32

12.3 Digitaliseringen . . . 32

12.4 Akt¨orerna p˚a marknaden . . . 33

13 Slutsatser 33

14 Framtida arbete 34

(7)

1 Inledning

Dagens kapacitetsbrist i landets elnät är resultatet av industrialiserade städers kraftiga beroende av energi, tillsammans med en avsaknad av incitament för att vara flexibel i sin elanvändning. Med kapacitetsbrist menas att mängden ström som elnätet kan trans- portera vid en given tidpunkt är mindre än efterfr˚agan [Ema19]. Det här resulterar i ett hinder mot den ekonomiska tillväxten [Lin18b]. När stadens nätägare inte har möjlighet att förse byggföretag med tillräckligt mycket energi för att antingen fullfölja deras projekt, eller underh˚alla byggnadens ändam˚al (till exempel att bist˚a med serverhallar, kon- tor eller industrier), stagnerar stadens tillväxt. Sverige löser ofta effektbrister idag med import fr˚an grannländer [Kra18] men om nätet är tr˚angt hjälper inte det.

En av de främsta möjligheterna för att minska nätens effekttoppar är att fastighetsägare, som en av de tyngre användarna av elnäten i Sverige, är med och aktivt styr sin elanvänd- ning för fastigheterna. Startskottet för att ta fram lokala marknadsplatser p˚a kommun- niv˚a, där företag f˚ar incitament i form av ekonomisk ersättning för att vara flexibla i sin elanvändning, har redan skett [Fas19]. I framtiden kommer dessutom operatörerna i elnäten kunna skicka ut uppmaningar till aktörerna i näten om att de behöver bist˚a med minskningar i sin elförbrukning vid höga effekttoppar. Avst˚ar aktörerna fr˚an att bidra med förändring riskerar de b˚ade högre elräkningar liksom att bli av med eventuella förvärvade miljöcertifieringar.

När fastighetsägarna är med och ställer om i sina styrsystem för att uppn˚a m˚alet om minskade effekttoppar kan ett behov uppst˚a att kommunicera dessa förändringar till sina hyresgäster. Om gästerna ska känna sig inkluderade behöver de bli uppdaterade om ändringarna som uppst˚ar vid styrningar av exempelvis belysning, ventilation, värme eller ˚atkomst till fastigheten. Utöver att gästerna ska känna sig inkluderade är det om inte

ännu viktigare att de har möjlighet att planera sin elanvändning. För att de ska kunna planera sin användning m˚aste de givetvis informeras om när ett smartare beteende är extra viktig.

Det är ocks˚a viktigt att ägarna förmedlar informationen p˚a ett sätt som inte upplevs kon- trollerande eller framst˚ar som bestraffande. Helst ska de vara informerade redan innan de känner eventuella effekter av förändringarna. Som en konsekvens av ett minskande behov för hyresgäster att behöva kontakta sin fastighetsägare, gynnar applikationen hy- resgästen. Tillägget gynnar ocks˚a fastighetsägare eftersom de har ett smidigt sätt att f˚a ut information innan den efterfr˚agas av hyresgäster [Nä19].

Den här rapporten demonstrerar ett tillägg till en mobilapplikation som siktar mot att tillfredsställa behovet av kommunikation mellan fastighetsägare och hyresgäster. Tilläg- get till˚ater b˚ade automatisk och manuell kommunikation med hjälp av meddelanden

(8)

2 Bakgrund

och visualiseringar, vilka kommunicerar p˚ag˚aende förändringar i fastigheten. Tillägget till mobilapplikationen hjälper till att delvis lösa kapacitetsbristen genom att uppmana hyresgäster genom notifikationer och p˚a s˚a sätt förhindra problemet innan det uppst˚ar.

Uppdraget utfört i samband med rapporten skedde specifikt för fastighetsföretaget Va- sakronan. Eftersom vi ser behov av att andra fastighetsföretag kommer behöva anpassa sig till krav rörande reglerad elanvändning, har de möjligheten att använda liknande metoder och lösningar beskrivna i rapporten.

Resultatet av projektet var implementation av ett tillägg till en mobilapplikation och en molnbaserad databas, vilken kunde uppkopplas till databasen tillhörande fastighetens styrsystem. Vidare finns i applikationen möjlighet för fastighetsägare att ge hyresgäster förslag p˚a vad de själva kan bidra med för att minska energianvändningen. V˚ar lösning kommer inte lösa hela kapacitetsbristen i elnäten, utan det är snarare en dellösning och ett steg närmre en smartare elanvändning och ett ändrat användarbeteende. En lösning som inte kräver utbyggnad av elnätet.

2 Bakgrund

Här beskrivs bakgrunden till projektet. I 2.1 presenterar vi problemet med kapacitetsbrist och hur den kan bero p˚a infrastrukturen i elnäten, väderleken, samt tidpunkten p˚a dygnet och varför kapacitetsbristen behöver lösas. Kapacitetsbristen kan förenklat uttryckas som en jämförelse med en vältrafikerad motorväg. Vid en viss tidpunkt har motorvägen bara en viss kapacitet, ett visst antal bilar som kan trafikera vägen. En möjlighet för att förhindra köer och stopp i trafiken är att bygga ytterligare filer, men detta är ett b˚ade dyrt och tidskrävande tillvägag˚angssätt. Kan man istället förm˚a tillräckligt m˚anga bilar att vara mer flexibla och undvika motorvägen under rusningstid, behöver man inte bygga ut vägen.

I 2.2 introducerar vi v˚art uppdrag samt v˚ar externa intressent Vasakronan och motivet till deras uppstart av projektet.

2.1 Kapacitetsbristen i eln ¨aten

I samband med att länder blir mer urbaniserade leder utbyggnad av deras städer till en ökad energikonsumtion. När stora energikrävande byggnadsprojekt p˚abörjas utan att stadens elnät antingen hunnits eller prioriterats att rustas upp för att möta det nya behovet uppst˚ar en kapacitetsbrist. Med kapacitetsbrist menas att det är ”fullt” i kab-

(9)

2 Bakgrund

larna som elnäten best˚ar av [Per18]. Ett exempel p˚a när elnätet överbelastas är när det

är mycket byggnationer runt om i staden. Anläggningsmaskiner som lyftkranar kräver stora mängder energi, vilket kommer att belasta elnätet. Detta leder till att andra delar av staden, exempelvis större fastigheter, kommer att behöva använda mindre energi för att balansera ut detta temporära energibehov. Energiförbrukningen för olika fastigheters miljösystem kan vanligtvis regleras av dess fastighetsägare. Vasakronan är ett exempel p˚a en s˚adan fastighetsägare.

2.1.1 Kapacitetsbrist beroende p ˚a v ¨ader

Risken för att kapacitetsbrist uppst˚ar är högre vid vissa väderförh˚allanden [Sve19], exempelvis när utomhustemperaturen är l˚ag. D˚a blir behovet av el större eftersom det krävs mycket energi för att bibeh˚alla inomhustemperaturen i bostäder och andra fastigheter, vilket belastar elnätet.

I och med omställningen till förnybar och väderberoende elproduktion kommer det ocks˚a krävas större flexibilitet i elanvändningen. Beroende p˚a r˚adande väderförutsättningar kommer det vid vissa tidpunkter kunna produceras mycket el, exempelvis när solen ski- ner och det bl˚aser mycket, men inte lika mycket vid andra väderförutsättningar [Asp18].

2.1.2 Kapacitetsbrist grundad p ˚a tid

För hyresgästerna finns det sätt att bidra till en minskad belastning p˚a elnätet genom att vara mer flexibel i sin elanvändning. I fastigheter där diskmaskin, tvättmaskin och TV, laddning av elbilar med mera används i hög grad, g˚ar betydande mängder elektricitet ˚at.

Om man istället för att sätta p˚a dessa produkter direkt när man kommer hem fr˚an jobbet avvaktar tills belastningen p˚a elnätet har g˚att ner fram˚at kvällen och natten, gör det stor skillnad för samhället. Vanligtvis sker nedg˚angen i belastning senare under kvällen när kontorsbyggnader och affärer har stängt för dagen. D˚a moderna vitvaror vanligtvis är utrustade med möjlighet att fördröja starttiden s˚a underlättar detta för hyresgästen att anpassa sig.

En möjlig lösning för att kunna fortsätta utveckla städerna som beskrivet ovan, är att sänka det totala effektuttaget under effekttopparna. Detta kan ˚astadkommas genom att flytta delar av effektbehovet som ej är knutet till en specifik tid, till tidpunkter d˚a elnätets belastning är lägre. De redan nämnda exemplen p˚a vad hyresgäster kan göra är oftast de enklaste men änd˚a minst använda ˚atgärderna. En stor del i detta är okunskap hos hyresgästerna om situationen och hur stort inflytande de faktiskt har tillsammans. Det- ta är n˚agot som vi vill belysa i v˚ar lösning för att uppmana till ett smartare beteende

(10)

2 Bakgrund

hos individen. Genom att använda dagens elnät smartare har staden en möjlighet att f˚a samma önskvärda resultat idag, som först om m˚anga ˚ar kommer ˚astadkommas av att fortsätta bygga ut det befintliga elnätet. Att bygga ut elnätet tar tid, och i dagens bygg- takt beräknas elnätet inte möta behovet av anslutningar förrän 2030 [Nor18a].

I framtiden kommer fler hjälpmedel för att underlätta för hyresgäster att vara flexibla i sin elanvändning. Exempelvis p˚a dessa är eltariffer [TT18] och nya smarta elmätare [Mas18]. Eltarifferna kommer kunna liknas vid trängselskatter p˚a el, medan de nya elmätarna kommer vara mer användarvänliga och göra det lättare för användarna att p˚averka sin egen elkonsumtion.

2.1.3 Kapacitetsbrist i Uppsala

Redan ˚ar 2016 blev Uppsala Kommun varse om den r˚adande kapacitetsbristen inom kommunen. Detta efter att ett företag som använde förbränning av fossila bränslen som energikälla ville ställa om sig till ett mer miljövänligt alternativ och ansökte om att f˚a ansluta sig till stadens stamnät. Denna förfr˚agan fick avslag fr˚an kommunen [Noh19]

d˚a den ökade energikonsumtionen skulle riskera att försätta bostäder utan elektricitet.

Detta blev startskottet p˚a kommunens nuvarande arbete mot att reducera och effektivisera stadens energikonsumtion för att kunna fortsätta utveckla och expandera staden utan att försätta inv˚anarna strömlösa. Det som har lagt grunden till problemen i Uppsa- la är ett historiskt högt bostadsbyggande, nyindustrialisering samt den ökande energi- användningen hos stadens inv˚anare.

Specifikt för Uppsala har en analys gjorts med slutsatsen att effekttopparna har potential att sänkas med tolv procent [Noh19]. För att uppn˚a detta krävs bland annat aktiv styrning av elanvändningen. Redan ˚ar 2020 är tanken att olika aktörer i Uppsala kommun och tre andra kommuner runt om i Sverige ska verka i en miljö där det finns incitament för flexibilitet hos energikonsumenter i sin elanvändning [Lin18a]. Flexibiliteten handlar främst om att konsumenterna flyttar sin elanvändning till tider p˚a dygnet d˚a elnätet är mindre belastat. Privatkunder och företag kan d˚a komma att f˚a ersättning för att vara mer flexibla i sin elanvändning genom att flytta energikrävande processer till tidpunkter d˚a belastningen i elnätet är lägre. Detta ger d˚a inte bara incitament för större företag utan även för privatpersoner eftersom de kommer märka att deras hyra blir lägre ifall de anpassar sitt energianvändande efter stadens ekosystem.

Det svenska stamnätet ägs av staten och förvaltas av affärsverket Svenska Kraftnät.

När olika industrier och företag vill använda mer el m˚aste regionnätsägaren ansöka hos Svenska Kraftnät för att öka effektuttaget fr˚an stamnätet. Dessa ansökningar avsl˚as ifall elnätets belastning är för hög, vilket är fallet för flera större städer.

(11)

2 Bakgrund

2.1.4 On-demand-signaler och CoordiNet

Som en ˚atgärd för att r˚ada bot p˚a kapacitetsbristen kommer elnätsägare, till exempel Vat- tenfall Eldistribution, inom kort introducera s˚a kallade on-demand-signaler. Signalerna kommer skickas fr˚an elnätsägarna till större aktörer p˚a elmarknaden där de uppmanas att sänka sin energikonsumtion för att motverka r˚adande överbelastning p˚a elnätet. Som en större aktör p˚a elmarknaden är det här projektet en del av Vasakronans förberedelse inför de här signalerna.

Introduktionen av on-demand-signaler är en del av projektet CoordiNet, som bildades i samband med FN:s h˚allbarhetsm˚al 2020. CoordiNet är ett EU-sponsrat projekt med syfte att dels hitta lösningar p˚a den effektbrist som finns i elnäten inom EU, men ocks˚a främja ett samarbete mellan elmarknadens olika aktörer i stamnäten. M˚alet med samarbetet är att aktörer ska hjälpa till att avlasta de mest ansträngda omr˚adena genom att använda lägre belastade elnät och resurser fr˚an andra aktörer när deras egna stamnät är

¨overbelastat [Bj¨o18].

I Sverige samarbetar Vattenfall Eldistribution och E.ON Energidistribution, tv˚a av de tre största energidistributörerna i landet, samt Svenska Kraftnät, som st˚ar för utbyggnaden av det nationella stamnätet. Syftet med samarbetet är ett projekt för att finna lösningar p˚a effektbristen som finns runtom i det svenska elnätet. Just nu är ökningstakten av landets tillväxt snabbare än utbyggnaden av elnätens kapacitet. Det är framför allt lagar och handläggningstider som är problemet till detta. Projektets sätt att angripa problemet är snarare att hitta en lösning under tiden det arbetas mot att minska tiden för handläggningstider och ändra lagar för snabbare utbyggnad av elnätets kapacitet. Det finns städer som passerat sin gräns för att kunna ansluta nya industrier eller bostads- omr˚aden och därmed stannar deras tillväxt av. Att l˚ata de städer som redan n˚att sitt tak för ny anslutningar st˚a stilla i de tio ˚ar det kan ta för en utbyggnad av elnätet, är inget alternativ d˚a detta kan hota Sveriges konkurrenskraft. Projektet berör b˚ade hush˚all och industrier. De betonar att flexibiliteten ska göras möjlig medan bevarad komfort hos kund samt elnätskostnader ska bibeh˚allas. Just nu undersöks i projektet vilka incitament som behövs för att börja bidra med sin flexibilitet [Asp18].

Eftersom on-demand-signalerna ¨ar under utveckling och i dagsl¨aget inte i bruk, finns ingen klar struktur eller offentlig information om hur dessa kommer fungera.

2.2 Uppdraget

För detta projekt har vi arbetat som konsulter ˚at STUNS energi, med Vasakronan som slutkund. Vasakronan är Sveriges största fastighetsbolag som äger, förvaltar och ut-

(12)

2 Bakgrund

vecklar centralt belägna kontors- och butiksfastigheter runt om i Sveriges storstäder [Vas19a]. Vi fick i uppdrag att utveckla ett system för att informera deras hyresgäster om miljöförändringar som sker i fastigheten och varför dessa förändringar genomförs.

Förändringar som Vasakronan utför kan vara sänkt ventilation och temperatur, vilka utförs som följd av en on-demand-signal p˚a grund av kapacitetsbristen. Vidare önskades det möjlighet att ge konkreta tips till hyresgästerna om hur de kan vara med och bidra till ett mer energieffektivt samhälle. Ett exempel p˚a vad hyresgästerna kan uppmanas till är att använda hush˚allsmaskiner vid tidpunkter där belastningen vid elnätet är lägre.

Hyresgäster engageras av mobilapplikationen genom att själva kunna bidra, vilket är en förebyggande lösning till kapacitetsbristen. Genom förebyggande lösningar kan kort- siktiga lösningar som förbrukar jordens resurser undvikas. V˚ar lösning löser inte hela problemet med kapacitetsbristen, men skiljer sig fr˚an andra förebyggande lösningar som använder jordens resurser. Även om tanken är mer förnybar energiproduktion som sol och vind och det d˚a är inte är användningen av jordens resurser som avses, är det istället byggnation av vindkraftverk etc. som kräver material och p˚a s˚a sätt utnyttjar jordens resurser. Likas˚a nätutbyggnad som kräver kopparledningar använder jordens resurser.

Vidare är mentaliteten hos hyresgäster och allmänheten ocks˚a mycket viktig för hur miljön kommer att se ut i framtiden. Därför har v˚ar lösning även l˚angsiktig p˚averkan.

Uppmaningar till hyresgäster leder även till att de till en viss del kan se till att hy- resvärden inte behöver göra oönskade förändringar i fastigheten. En annan fördel hy- resgästen själv f˚ar genom att effektivisera sin energianvändning är att elräkningen blir billigare och hyresgästen sparar d˚a pengar. V˚art arbete har inte fokus p˚a detta, och det

är ingen självklar konsekvens av användande av v˚ar mobilapplikation, men hyresgästen kan förhoppningsvis f˚a inspiration till att effektivisera sin energianvändning genom de notifikationer som mobilapplikationen skickar ut.

2.2.1 Leed-certifiering

Grunden till uppdraget kommer fr˚an att Vasakronan och andra större aktörer inom en snar framtid kommer motta on-demand-signaler fr˚an företagen som hanterar elnäten, t.ex. Vattenfall. Med en on-demand-signal menas att Vattenfall kommer meddela större energikonsumenter om att elnätet för tillfället är p˚a väg att bli överbelastat och uppma- nar därför aktörerna att minska sin strömkonsumtion under en viss tidsperiod för att undvika överbelastningen i elnätet. En av anledningarna till att aktörer som Vasakronan vill hjälpa till att bidra till en minskad belastning, är en certifiering kallad Leed. Ett Leed- certifikat [Swe19] innebär att aktören aktivt bidrar till att minska energiförbrukningen och dessutom anpassar sin elkonsumtion efter belastningen i elnätet för att undvika

¨overbelastningar.

(13)

3 Syfte, m˚al, och motivation

Vasakronan har i dagsläget certifieringen Leed Platina-certifikat, vilket är den högsta certifieringen som kan erh˚allas. Certifieringen g˚ar hand i hand med Vasakronans miljö- policy som bygger p˚a FN:s program Gloabl Compact samt FN:s h˚allbarhetsm˚al [Vas19b].

För att inte riskera att bli av med certifieringen krävs det att Vasakronan p˚a ett effektivt sätt kan vidta ˚atgärder vid dessa on-demand-signaler. Dessa ˚atgärder behöver sedan kunna informeras till fastigheternas hyresgäster för att undvika att n˚agon ska behöva vara ovetande och uppleva obehag av en förändring.

2.2.2 Vasakronans regleringar och nuvarande mobilapplikation

Tillämpningar av AI-teknik för att utveckla h˚allbara och smarta städer förutsp˚as bli allt vanligare [Vin18]. I Vasakronans fall kommer det tillämpas genom reglering av ener- gianvändningen i bostäder. Eftersom regleringen d˚a sker automatiskt, blir det inte lika naturligt för Vasakronans anställda att informera hyresgästerna om de regleringar som genomförs. Detta är vad som har legat till grund för Vasakronans projekt, d˚a informa- tionsflödet till hyresgästerna har blivit lidande av den ökade automatiseringen.

Vasakronan har idag en mobilapplikation som heter Hyresgästinfo [Vas]. I applikationen finns det information om alla deras fastigheter som kan vara relevant för hyresgästerna.

Det finns till exempel information om var hyresgästerna kan källsortera sina avfall och vilken service som finns i närheten av fastigheten. Det finns även kontaktuppgifter till de som är ansvariga för just deras fastighet. I applikationen kan hyresgästerna även f˚a information om nyheter gällande fastigheten. Denna del används i dagsläget inte särskilt frekvent av Vasakronan. Detta är n˚agot v˚art uppdrag är tänkt att lösa genom att skapa ett aktivt flöde med information till hyresgästerna i den delen av applikationen.

3 Syfte, m ˚al, och motivation

Här beskrivs projektets syfte, m˚al och motivation. Projektet motiveras genom att be- skriva problemet, varför det behöver lösas, samt genom att visa att problemet inte är löst.

3.1 Syfte

Syftet med projektet var att ge möjlighet för b˚ade Vasakronan och deras hyresgäster att p˚averka energianvändningen för att motverka kapacitetsbrist i elnätet, samt att un-

(14)

derlätta kommunikationen mellan Vasakronan och deras hyresgäster. Effekterna av projektet blev d˚a informerade hyresgäster och ett mer jämnt belastat elnät.

3.2 M ˚al

För att uppn˚a projektets syfte var m˚alet med projektet att skapa ett tillägg till Vasakro- nans mobilapplikation. Där skulle Vasakronan kunna göra följande:

• Informera sina hyresgäster om de ˚atgärder de utför i fastigheterna.

• Ge hyresgästerna konkreta tips p˚a vad de själva kan bidra med för att minska den totala energianvändningen.

• Engagera hyresg¨asterna till att adoptera ett smartare energit¨ank.

3.3 Motivation

M˚anga städer har i dagsläget elnät som inte klarar av den belastningen som staden, vid vissa tidpunkter, efterfr˚agar. Detta är p˚a grund av att elnätet inte används effektivt och till full grad vid alla tidpunkter p˚a dygnet.

För att främja ett h˚allbart samhälle med h˚allbara industrier och infrastrukturer samtidigt som städer och samhällen kan fortsätta utvecklas, krävs det att lösningar p˚a problemet med överbelastade elnät hittas redan idag, och att vi inte väntar tio ˚ar medan elnätet byggs ut. Att bygga ut elnätet i stor skala kräver mycket jobb som förbrukar mycket av jordens resurser, vilket inte är h˚allbart. Om man istället kan hitta ett sätt som effektivi- serar energianvändningen, krävs mindre av jordens resurser.

Dessa är problem som även identifieras av FN, vilket syns i deras h˚allbarhetsm˚al, främst m˚al 9, som handlar om h˚allbar industri, innovationer och infrastruktur, samt m˚al 11, som handlar om h˚allbara städer och samhällen. Projektets syfte anknyter därmed till FN:s h˚allbarhetsm˚al 2030.

3.3.1 H ˚allbara st ¨ader och samh ¨allen

Att effektivisera energianvändningen krävs för att vi ska kunna fortsätta utveckla v˚ara städer och samhällen utan att behöva öka kapaciteten p˚a det befintliga elnätet. Lösningen p˚a detta är att fastighetsägare utför ˚atgärder i sina fastigheter, samt att hyresgästerna

(15)

kan informeras om vad de själva kan göra för att bist˚a. Det är viktigt att hyresgäster engageras för att förebygga problemen p˚a elnätet, istället för att hela ansvaret ligger p˚a att fastighetsägaren tar tag i problemet när problemet redan är ett faktum.

Projektet var viktigt för att p˚a ett automatiserat sätt tillgodose hyresgäster med information om vilka ˚atgärder fastighetsägaren utför. Det var ocks˚a viktigt att uppmuntra hyresgäster att själva bidra till att minska den totala energianvändningen vid specifika tidpunkter, för att förhindra att elnätet blir överbelastat. För fastighetsägare var det viktigt att hyresgäster ocks˚a blir medvetna och bidrar till att lösa problemet eftersom fastighetsägaren d˚a själv inte kommer att behöva styra över energianvändningen i fastigheterna. Att fastighetsägare ska styra över energianvändningen var n˚agot som kanske inte uppskattas av dess hyresgäster och med resultatet fr˚an detta projekt kommer hy- resgästerna f˚a chans att själva bidra s˚a att fastighetsägare inte behöver styra över deras energianvändning p˚a samma sätt.

Vidare finns en koppling mellan v˚art projekt och FN:s h˚allbarhetsm˚al 11 som handlar om hur städer och samhällen ska kunna utvecklas p˚a ett h˚allbart sätt. En betydande faktor till sv˚arigheterna att utveckla städer och samhällen p˚a ett h˚allbart sätt är urbanise- ringen. Under de senaste decennierna har över hälften av världens befolkning förflyttats till urbana omr˚aden, och denna befolkningsdel väntas stiga. Medan detta är en fantas- tisk möjlighet för b˚ade jobbtillfällen och för människor att ta sig ur fattigdom, bidrar det ocks˚a till p˚afrestningar p˚a ekosystemet. Den här förändringen sker till historien sett mycket snabbt, likt hur tekniken utvecklats exponentiellt, och därför m˚aste ocks˚a krav säkerställa att den här förflyttningen av människor sker p˚a ett h˚allbart sätt [Reg17]. V˚art projekt kan användas som ett verktyg för att se till att detta sker p˚a ett h˚allbart sätt.

Detta genom att effektivisera användningen av elnätet i storstäder, samt att uppmuntra människor till ett smartare energitänk. Genom den effektiviserade användningen kan man bygga ut elnäten i mindre skala. P˚a s˚a sätt behöver förflyttningen av människor inte ha en väsentlig p˚averkan p˚a miljön gällande energianvändningen.

3.3.2 H ˚allbar industri, innovationer och infrastruktur

Eftersom det befintliga elnätet i Uppsala och andra städer är begränsat [Nor18b], gäller det att arbeta för att elnäten ska ha kapacitet att ansluta och leverera el i den utsträckning som efterfr˚agas. Elnätet blir överbelastat när antalet användare är för hög i jämförelse med hur mycket elnätet klarar av, vilket leder till kapacitetsbrist [Per18]. Det här är ett viktigt problem att lösa, eftersom utbyggnaden av elnätet är dyr och tar l˚ang tid[Ryd18].

Den här processen kräver att det sätts upp enorma stolpar, införskaffas material och anställs personal som ska utföra arbetet, processer som kräver tillst˚and, vilket är vad som tar l˚ang tid. Svenska Kraftnät räknar med att det tar cirka tio ˚ar fr˚an det att det

(16)

b¨orjar planeras tills det att el kan levereras [Ell19].

Genom v˚ar lösning förhindras tillfälliga utbyggnader som mot˚atgärder för kapacitetsbristen, vilka förbrukar jorders resurser utan att egentligen lösa problemet. Ett exempel p˚a en tillfällig utbyggnad är dynamisk ledningskapacitet, vilket är att noggrant mäta hur mycket kapacitet i en ledning som är outnyttjad [Sve18]. Detta är en lösning som gick i drift i Stockholm hösten 2018 och ses som en kortsiktig lösning innan 2030, när en utbyggnad av nya stamnätsledningar är planerad. Mätdatan kommer sedan att finnas tillgänglig för Svenska Kraftnäts driftavdelning i realtid, vilket kommer kunna undvika onödiga mot˚atgärder och istället leverera elen som den ska. V˚ar lösning handlar ocks˚a om att undvika onödiga mot˚atgärder. M˚algruppen för v˚ar lösning är specifikt de som förbrukar elen i fastigheter, nämligen hyresgästerna. V˚ar lösning strävar till att undg˚a problemet fr˚an början och motivera hyresgästerna själva till att ändra sitt beteende. Skulle man inte lyckas med att motverka kapacitetsbristen under energitopparna f˚ar hyresgästerna ocks˚a information om detta och vad hyresvärden gjort för ˚atgärder.

M˚al 9 betonar att en stabil infrastruktur är en av de viktiga pelarna för ett framg˚angsrikt och fungerande samhälle. Utöver stabil ska den ocks˚a vara h˚allbar. Samtidigt beskrivs hur betydelsen av ett samhällets innovation och teknologiska framsteg är en nyckel till att lösa samhälleliga ojämlikheter och fortsatt utveckling som frodas genom h˚allbara industrier och miljövänlig teknik [Reg15]. Detta inkluderar h˚allbart byggande och plane- ring av b˚ade bostäder och infrastruktur. V˚art projekt bidrar främst till h˚allbart byggande.

Genom en effektivare användning av elnäten kan elnäten byggas ut i mindre omfattning.

3.4 Avgr ¨ansningar

Tillägget som utvecklats i projektet är en prototyp som inte har integrerats med Vasakro- nans befintliga mobilapplikation, anledningen till detta var att Vasakronan för tillfället utvecklar en ny mobilapplikation som inte förväntades vara klar under projektets spann.

Till¨agget som skulle skapas var ocks˚a beroende av on-demand-signaler som ¨annu inte

är i bruk i Vasakronans databas IDUN, vilket ledde till att det var information som vi inte kunde ta del av. IDUN inneh˚aller även känslig information, exempelvis data som inneh˚aller information om elkonsumtionen hos Vasakronans hyresgäster. Denna information ligger inte öppen för allmänheten p˚a grund av risken för att exempelvis konkur- renter till en hyresgäst ska dra slutsatser fr˚an historiken. De skulle därmed kunna nyttja dessa slutsatser till nackdel för hyresgästen. Slutligen är elkonsumtion i allmänhet inte n˚agot företag tycker om att skylta med. Eftersom informationen som vi vill använda

ännu inte finns implementerad och resterande information kan anses känslig har endast ett bevis för hur man kan koppla in databasen gjorts men signaler till prototypen simuleras istället.

(17)

4 Relaterat arbete

Här presenteras olika sorters relaterade arbeten. 4.1 är ett arbete med samma grund- problem in som v˚art projekt. Direkt relaterade arbeten som skulle kunna användas som ett alternativ till v˚art system, presenteras i 4.2 och 4.3. I 4.4 presenteras ett arbete som använder samma metod som v˚art. Här motiveras även varför de olika arbetena relaterar till v˚art, samt vad som skiljer mellan det relaterade arbetet och v˚art arbete.

4.1 Informationsspridning

Vasakronans önskan om att kunna f˚a ut information om energiförändringar till sina kunder kan lösas p˚a flera olika sätt. Vi valde att göra det med push-notifikationer i deras redan existerande mobilapplikation d˚a den redan inneh˚aller mycket information till hyresgästerna och vi inte ville skapa ytterligare informationskanal. Informationssprid- ningen kan dock lösas p˚a flera olika sätt. Ett problem som är likt det som vi löst är att Uppsalavatten skickar ut information till sina kunder vid driftstörningar. Detta görs med hjälp av SMS-utskick [Hol19], vilket deras kunder kan prenumerera p˚a för att f˚a information om eventuella driftstörningar som rör kunden. Att skicka ut SMS till Vasakro- nans kunder kunde har varit en lösning, men eftersom det existerade en mobilapplikation var det lämpligast att fortsätta utveckla den. P˚a s˚a sätt samlas ocks˚a all information till hyresgästerna p˚a samma ställe.

Ett annat sätt att sprida information p˚a är genom utskick via e-post. Uppsalahem använd- er sig av detta system [Upp19] för att n˚a ut med information till sina kunder om till exempel aktuella projekt som Uppsalahem arbetar med. Informationsutskick via e-post hade ocks˚a kunnat lösa det problem som Vasakronan hade, men det skulle skapa en ytterligare informationskanal, vilket vi ville undvika.

Informationsspridning p˚a olika sätt är arbeten som är relaterat till v˚art syfte och grund- problem, vilket är att kunna sprida information. De skiljer sig ˚at d˚a det finns olika sätt att sprida information p˚a. Vi har valt att använda Vasakronans befintliga mobilapplikation för informationsspridningen eftersom den redan används av Vasakronans hyresgäster.

4.2 Reglering av eln ¨atet

VäxEl [Noh18] är ett projekt där man ocks˚a har identifierat problemet med en ökad belastning p˚a elnätet, och därför börjat arbeta för att minska den. Det har skett genom att börja styra kundernas värmepumpar [Sus18] för att reglera effekten efter behovet

(18)

4 Relaterat arbete

i elnätet. Detta är i princip det som Vasakronan vill göra och sedan meddela sina hy- resgäster om. VäxEl är ett projekt som drivs av flera företag, bland annat Sustainable Innovations och STUNS energi. Projektet innefattar även att kunderna har möjlighet att ha batterilager, solceller och laddboxar för elbilar. Detta för att ge kunderna ytterligare möjligheter till att minska belastningen p˚a elnätet och öka möjligheten att enbart använda förnybar energi.

Projektet VäxEl är relaterat till det problem som vi har löst d˚a Vasakronan ocks˚a kan reglera elnätet. Skillnaden i hur elnäten regleras är att Vasakronan har större möjligheter att sänka effektförbrukningen i sina fastigheter d˚a man kan reglera flera komponenter i fastigheten.

4.3 Mobilapplikation med push-notifikation

En del av det arbete vi utförde var att ge möjligheten för Vasakronan att skicka ut push- notifikationer till sina kunder. Ett exempel p˚a mobilapplikation med push-notifikation

¨ar Upplands Lokaltrafiks mobilapplikation UL [UL-]. Genom att i mobilapplikationen bevaka en trafiklinje f˚as push-notifikationer om st¨orningar eller liknande om vald trafiklinje.

Mobilapplikationer med push-notifikationer liknar v˚art arbete eftersom det ocks˚a har notiser som är baserade p˚a yttre faktorer. Man kan likna trafiklinjen med en fastighet i v˚art arbete, där man väljer vilken fastighet man vill ha fastighetsinformation om. Det som skiljer dem ˚at är den yttre faktorn, d˚a v˚ar är Vasakronans databas IDUN, samt väder.

4.4 Notis baserat p ˚a v ¨aderprognos

En mobilapplikation som använder väderprognoser för att p˚a n˚agot sätt styra sin funktionalitet är mobilapplikationen Riseandshine [Ben13]. Riseandshine är en väckarklocka som använder väderprognoser för att väcka dig vid ett visst väder.

En skillnad som finns mellan Vasakronans mobilapplikation och Riseandshine är att Ri- seandshine i nuläget endast är tillgänglig för iOS medan Vasakronan även har sin mobilapplikation tillgänglig för Android-enheter. Vilket API som skaparna bakom Riseands- hine använder sig av är inte känt, men de baserar sin kommunikation med användaren p˚a en väderprognos, precis det som vi ville göra med Vasakronans mobilapplikation.

En annan skillnad är att Riseandshine endast använder sig av det aktuella vädret medan vi är intresserade av ev prognos av vädret n˚agra dagar framöver, för att kunna meddela Vasakronans hyresgäster om kommande överbelastningar av elnätet.

(19)

5 Metod

I detta avsnitt beskrivs metoderna vi har använt oss av för att utföra projektet. Avsnittet täcker informationshämtningen vi använt för att angripa problemet i ett tidigare stadie i 5.1, men ocks˚a de konkreta verktyg som därefter använts för att bygga mobilapplikationen i 5.3, samt den implementerade respektive den redan existerade databasen i 5.2.

5.1 Informationsh ¨amtning

Projektet krävde mycket informationshämtning i det initiala skedet för att kunna kon- kretisera det önskem˚al som intressenten presenterade i uppdragsbeskrivningen. Genom ett uppstartsmöte med Vasakronans chef för teknikutveckling, Ulf Näslund, fick vi en

översiktlig först˚aelse av vad Vasakronan önskade producera. För att kunna tillgodose dessa behov b˚ade fr˚an Vasakronan och deras hyresgästers gjordes litteraturstudier över olika metoder av informationsspridning för att undersöka hur vi p˚a ett s˚a effektivt sätt som möjligt kunde utvidga Vasakronans befintliga informationskanaler utan att det skulle bli p˚afrestande för slutanvändaren.

Fler tekniska detaljer gällande Vasakronans befintliga databas för fastighetsinformation samt styrsystem IDUN, erhölls genom ett möte med Erik Wallin, Vasakronans CTO.

Tekniskt specifika detaljer gällande Vasakronans nuvarande mobilapplikation för informationsspridning till hyresgäster fick vi genom e-postkontakt och möte med Sören Sandell, Vasakronans IT-chef, som även gav oss kontaktinformation till den konsultfirma som arbetar med att utveckla en ny applikation till Vasakronan som ska ersätta den gamla.

Innan vi började implementera tillägget till mobilapplikationen gjordes en skissad low- fidelity prototyp p˚a papper samt en high-fidelity prototyp digitalt över hur vi ville att den skulle komma att se ut och hur vi ville att den skulle fungera. Detta gjordes för att ha en tydlig bild och först˚aelse för vad vi arbetade mot. Även den skissade prototypen gjordes digitalt.

5.2 Databas

Här beskrivs de tv˚a databaser vi använt. 5.2.1 är Vasakronans egna databas IDUN som inneh˚aller data och trafik fr˚an deras fastigheter. Vi har ocks˚a använt en molnbaserad databas till att lagra notiser, vilken presenteras i 5.2.2.

(20)

5 Metod

5.2.1 IDUN

IDUN är en stor databas som Vasakronan använder för att hämta information fr˚an sensorer i sina fastigheter, samt för att kunna styra miljön för hyresgästerna genom att skicka ut reglerande signaler till VVS-system hos fastigheterna. Som majoriteten av databaser är IDUN SQL-baserad, vilket gör det möjligt att kommunicera med databasen genom att hämta och modifiera data [SQL19]. I detta projekt har vi endast varit intresserade av funktionaliteten för att hämta information fr˚an fastigheternas sensorer, eftersom själva styrningen är utanför v˚art arbetsomr˚ade. Informationshämtningen görs genom uppkoppling mot deras strömmande API. API st˚ar för applikationsprogramme- ringsgränssnitt. Det är allts˚a ett gränssnitt inneh˚allande fördefinierade funktioner för att underlätta standardisering samt anpassning och fungerar som en byggsten mellan olika mjukvaror [CM16]. API:et är v˚art gränssnitt mellan mobilapplikationen och IDUN:s existerande kodbibliotek. IDUN f˚ar en s˚a kallad on-demand-signal fr˚an elnätets aktörer baserat p˚a geografisk position. Statusen för ett elnät kan antingen vara normalt belastat eller överbelastat. För att se när statusen för ett visst elnät förändras har finns en prenumeration p˚a on-demand-signal som kommer fr˚an elnätets aktörer till IDUN. När statusen förändras, t.ex. att elnätet g˚ar fr˚an normalt belastat till överbelastat och aktören vill minska energi˚atg˚angen, skickas en manuell sökning till IDUN:s API för alla bostäder som berörs av det geografiska omr˚adet. Alla fastigheter som i denna sökning har statusen att ˚atgärder för energibesparingar genomförs använder vi sedan i v˚art system för att uppdatera den molnbaserade databasen med notifikationer för dessa fastigheter.

5.2.2 Molnbaserad databas

För att spara de aktuella notifikationerna som ska vara tillgängliga för tillägget till användarnas mobilapplikationer valde vi att använda en molnbaserad databas. En molnbaserad databas är en databas-service som är byggd och finns tillgänglig genom en molnplattform [IBM]. Anledningen till att vi valde att lösa lagringen av notifikationer med en molnbaserad databas framför en stationär server är för att möjligheterna för skalbarhet för molnbaserade tjänster är relativt billigt d˚a man bara betalar för det utrym- me man använder. Vidare baserades v˚art val med hänseende till mindre resurser som krävs när inte underliggande infrastruktur behöver tas hand om, samt i besparad tid att sättas upp. Det ger även större flexibilitet än en server som är l˚ast vid en viss geografisk position. Detta gör att tillgängligheten p˚a databasen öppnas upp vilket leder till att databasen är tillgänglig fr˚an praktiskt taget överallt.

Vi valde att använda MongoDB som ramverk (eng. framework) för v˚ar databas. An- ledningen till detta val var dess enkelhet att använda, dess skalningsmöjligheter samt att den även h˚aller god prestanda för enklare förfr˚agningar. Detta passar v˚art arbete d˚a

(21)

5 Metod

vi endast använder funktioner för sökningar, insättningar och borttagningar av objekt.

MongoDB kan även smidigt kopplas upp mot Microsofts Azure-tjänst för att f˚a gratis plats (eng. hosting) under sm˚askalig utveckling. Azure är även Vasakronans befintliga operatör som upprätth˚aller IDUN, vilket underlättar integrationen mot deras befintliga system.

För att använda MongoDB krävs det att man skapar en databas som man sedan kan koppla upp sig mot. En databas i MongoDB best˚ar av tre lager. Som topplager är själva databasen med ett namn som identifikation, där man kan inkludera flera olika databaser i samma projekt och använda deras information sinsemellan. Detta lager används främst i större projekt och det är inget som vi har utnyttjat. Under topplagret kommer ett lager som inneh˚aller olika kollektioner (eng. collections). Kollektioner är till för att sor- tera olika typer av data för att kunna begränsa söktiden för inkommande förfr˚agningar, men eftersom vi endast har en typ av data, inneh˚aller v˚ar databas endast en stor kollektion. Som bottenlager inneh˚aller sedan kollektionerna dokument, vilket är objekt inneh˚allande informationen som ska lagras. V˚ar databas inneh˚aller ett dokument för varje fastighet för att p˚a s˚a sätt kunna ge specifik information till varje hyresgäst baserat p˚a deras adress. Ett alternativ till detta hade varit att göra en kollektion för varje fastighet som Vasakronan äger, men eftersom sökningar g˚ar snabbare i bottenlagret jämfört med mellanlagret med kollektioner valdes detta alternativ bort. Uppdateringar av databasen görs genom en hanterare (eng. handler) som lägger till och tar bort notiser för olika fastigheter baserat p˚a on-demand-signalen som hämtas ur IDUN vilket beskrevs under 5.2.1.

5.3 Programspr ˚ak och arbetsg ˚ang

Som tidigare nämnt under 1, valde vi att bygga vidare p˚a Vasakronans redan existerande mobilapplikation och skapa ett tillägg som lätt skulle kunna integreras. För att kunna hämta information i tillägget krävdes det även att vi byggde en databas som skulle kunna kopplas till mobilapplikationen.

För att kontrollera kvalitén p˚a arbetet granskade vi aktivt kvalitén p˚a koden under ar- betets g˚ang genom parprogrammering där paret ansvarar för att ha granskat varandras delar under utvecklingen. Vi gjorde utöver detta enhetstestning för samtliga moduler för att tvinga oss att följa den planerade strukturen.

(22)

5 Metod

5.3.1 Mobilapplikation

Eftersom Vasakronan själva redan utvecklat en egen mobilapplikation för annan kommunikation med sina hyresgäster, innebar det att vi antingen behövde sätta oss in i den befintliga miljön för applikationen eller göra ett tillägg med minimal klientsida. Efter vidare kommunikation med Sören Sandell togs beslutet att det var omotiverat att utveckla mot den applikationen som används i dagsläget eftersom den inom kort skulle ersättas av en ny. Därmed vore det bättre att utveckla mot den mobilapplikation som är under utveckling hos deras konsultfirma. Den är allts˚a inte färdigutvecklad och det var sv˚art att f˚a tillg˚ang till en kopia p˚a miljön. Därför tog vi beslutet att utveckla en lösning där minimal funktionalitet l˚ag hos klienten för att p˚a s˚a sett ha en mer universal lösning som enkelt kunde integreras till olika miljöer. Vi s˚ag även fördelen med denna metod d˚a den skulle kunna integreras med Vasakronans mobilapplikation i framtiden. Tillägget skulle samtidigt inte vara för smalt anpassad till endast Vasakronans mobilapplikation, utan p˚a s˚a vis vara enklare att hantera om den skulle integreras med andra företag. Genom detta skapade vi en mer universal lösning.

D˚a vi i huvudsak endast ville ha funktionalitet för att visa upp meddelanden och redan använde MongoDB valde vi att efterlikna en MERN stack för detta. MERN st˚ar för Mongo, Express, React/Redux och Node vilket är de ramverk som används för att skapa stacken. React och Redux är de delar som korresponderar till själva klienten i en s˚adan lösning och kan även best˚a av andra ramverk d˚a kommunikationen mot databasen sker genom en server uppsatt i Express och Node. Denna server agerar som ett API där man kan lägga in önskvärd funktionalitet för ens lösning. Klienten anropar sedan detta API för att f˚a informationen som krävs och ansvarar endast för att visualisera den p˚a skärmen. Eftersom klienten har minimal roll i stacken s˚a valde vi att adaptera denna lösning.

Motivet till att utveckla Vasakronans existerande mobilapplikation var att samla all information till hyresgästen p˚a samma ställe. P˚a s˚a sätt kunde vi undvika att hyresgästen som letar information om fastigheten behöver leta p˚a olika ställen för olika information.

Man kan argumentera för att alla kanske inte har en smartphone och därför inte kan f˚a informationen som finns i mobilapplikationen. I dagens samhälle har dock de flesta p˚a n˚agot sätt tillg˚ang till mobilapplikationer [Kar18]. Ska alla kunna ta del av informationen skulle man behöva väldigt m˚anga olika medier, t.ex. e-post, telefon, fax och s˚a vidare. I v˚art projekt har vi därför valt att göra avgränsningen till det medie som flest använder, nämligen mobilapplikationen.

(23)

6 Systemstruktur

Figur 1 De tre kommunicerande huvudkomponenterna: Fr˚an vänster: Gränssnitt mot IDUN, Centrala databasen, Användargränssnitt för hyresgästerna.

5.3.2 Back-end

För back-end programmeringen som hanterar informationen i den molnbaserade databasen har Javascript används med de officiella ramverken fr˚an MongoDB och Azure Event-Hub för att kunna koppla upp oss mot den molnbaserade databasen, samt mot IDUN. Även Node har använts för att skapa en server som kan ligga och bevaka IDUN:s strömmande API som indata.

Anledningen till att Javascript valdes framför andra spr˚ak var att flera medlemmar hade goda kunskaper, samt att det är ett av de ledande programmeringsspr˚aken i arbetslivet för tillfället. Eftersom vi valde Javascript s˚a kom Node som det naturliga valet för att skapa en händelsedriven (eng. event-driven) server, d˚a det är lätt att implementera utan att behöva göra tidskrävande uppsättning.

6 Systemstruktur

I detta avsnitt redog¨or vi f¨or v˚ar systemstruktur som illustrerats i Figur 1. Systemet best˚ar av tre huvudkomponenter:

• Användargränssnitt för hyresgästerna.

• Gr¨anssnitt mot IDUN, fastigheternas databas.

(24)

6 Systemstruktur

• Centrala databasen, v˚ar molnbaserade databas.

Gränssnittet mot IDUN sänder signaler till den centrala databasen som inneh˚aller information om regleringar i fastigheter. Baserat p˚a den här informationen skickar den centrala databasen aktuella notifikationer till användarens mobilapplikation. De aktuella notifikationerna som hämtas av användarens mobilapplikation visas antingen som en push-notifikation eller enbart som en notifikation i applikationen beroende p˚a infor- mationens prioritetsniv˚a. Har informationen hög prioritetsniv˚a visas den som en push- notifikation, allts˚a en notifikation som visas utanför själva mobilapplikationen, p˚a applikationens startsida eller i notiscenter. Vid information med l˚ag prioritet sparas informationen bara som en notifikation i själva mobilapplikationen. Vid en s˚adan notifikation m˚aste användaren själv g˚a in p˚a mobilapplikationen för att ta del av informationen.

6.1 Anv ändargr änssnitt f ¨ or hyresg ästerna

Denna komponent av systemet innefattar MERN-stacken som beskrevs under 5.3.1.

Gränssnittet best˚ar huvudsakligen av en Express-server som agerar mellanhand för all kommunikation mellan den molnbaserade databasen och klienten. Express är en minimal och flexibel Node.js webbapplikationsram som ger funktionalitet för hämtning av strömmande data till webb- och mobilapplikationer [Exp17]. Vi valde att använda Express tack vare dess användbara grundläggande webbapplikationsfunktioner välan- passade till Node.js.

Huvudsaklig uppgift för användargränssnittet är att hämta aktuell information om regleringar för en fastighet fr˚an den centrala databasen, baserat p˚a användarens geografiska position. Klienten ska sedan p˚a ett grafiskt tilltalande sätt visualisera aktuell notifikation för applikationsanvändarna i fastigheten och i erforderliga fall även sända ut ef- terföljande push-notifikation.

Eftersom vi valde att implementera v˚ar lösning som ett tillägg innefattar den här delen

även v˚ar prototyp skapad i React som vi använt för att f˚a visuell feedback p˚a v˚art system.

M˚alet var att skapa en prototyp som följer samma tema som resten av Vasakronans allmänna färgkodningar. Den befintliga funktionaliteten i applikationen ligger sorterad under olika vyer där varje vy har en knapp under startsidan. V˚ar prototyp kan ses som en av dessa vyer i applikationen men utan stöd för vidare navigering i applikationen.

(25)

6 Systemstruktur

6.2 Gr ¨anssnitt mot IDUN

Gränssnittet mot IDUN best˚ar av tv˚a delar. Den första delen är informationsutvinningen ur IDUN vilket sker genom en prenumeration p˚a deras strömmande API. Det strömman- de API:et är gjort i Azure vilket är Microsofts webblösning för SQL baserade databaser.

V˚art gr¨anssnitt prenumererar p˚a statusen f¨or on-demand-signalen som lagras i IDUN.

On-demand-signalen kommer fr˚an Vattenfall och informerar om överbelastningar i el- nätet och beskrevs i 2.1.4. I de fall där det finns en positiv signal hämtas information för vilken geografisk plats överbelastningen berör och sedan hämtas statusen för alla fastigheter inom den berörda platsen. För de fastigheter där statusen visar att Vasakro- nan har genomfört regleringar baserade p˚a on-demand-signalen skickas en signal vidare till den centrala databasen om att uppdatera notifikationerna i den molnbaserade databasen för att matcha den nya situationen. Den andra delen av gränssnittet mot IDUN är kommunikationen mellan gränssnittet och den centrala databasen. Kommunikationen är enkelriktad fr˚an gränssnittet till databasen och meddelandena sänds som beskrivet ovan när en statusuppdatering ska ske för n˚agon fastighet i databasen.

Meddelandena är i formen av en procentsats som beskriver graden av de genomförda regleringarna. Exempelvis att ventilationen minskat med 20%. Anledningen till att dessa signaler är i procentsats istället för en skala t.ex 1-10, är för att EU har satt ett krav i sin nya agenda om att fastigheter ska kunna styras med procentsatser vilket även aktörer inom elnätet anpassar sig efter [Wal19]. Det ger även oss ett enkelt sätt att bestämma vilken prioritetsniv˚a av notiser som bör hämtas till databasen.

6.3 Centrala databasen

Den centrala databasen, vars komponenter visas i Figur 2, ansvarar för att uppdatera de aktuella notifikationerna för varje enskild fastighet som lagras i molnet. Den centrala databasen ansvarar även för att hämta väderinformation för de kommande dagarna och lägga till notifikationer baserat p˚a vädret om det anses nödvändigt att vidta ˚atgärder.

Den centrala databasen kan brytas ned i flera mindre block, vilka ¨ar f¨oljande:

Molnbaserad databas Den centrala databasen inneh˚aller dels en molnbaserad databas som ansvarar f¨or att att lagra och uppdatera de aktuella notifikationerna till anv¨andaren.

Den molnbaserade databasen är uppdelad baserat p˚a fastigheternas adresser för att kunna plocka fram information som är relevant för en specifik användare. Huvudsakligen best˚ar den molnbaserade databasen av listor med notifikationsobjekt hämtade fr˚an de lokala filerna med meddelanden. Dessa objekt inneh˚aller främst strängar med de text-

(26)

6 Systemstruktur

meddelanden mobilapplikationen ska använda, men även sätt att identifiera dessa meddelanden med hjälp av olika prioritetsniv˚aer och id:n.

Gr änssnitt För att fylla den molnbaserade databasen finns det ett flertal gränssnitt mot filerna där samtliga meddelanden finns lagrade. Dessa gränssnitt har i uppgift att hämta de önskade meddelandena fr˚an filerna som vill visas till användarna baserat p˚a antingen en prioritetsniv˚a eller ett unikt id för ett specifikt meddelande.

API-anrop Den centrala databasen inneh˚aller en komponent med API-anrop mot en väderapplikation som sedan används i en utvärderare för att skapa vädernotifika- tioner baserat p˚a det kommande vädret. Utvärderarens egenskaper som avgör om en vädernotifikation skapas eller inte kan specificeras. Denna process sker för att automatiskt kunna ge hyresgäster r˚ad och information i det fall d˚a vädret är förväntat att orsaka

¨okad belastning p˚a eln¨atet.

Ett medvetet beslut togs att separera filerna som inneh˚aller meddelanden till använd- arna i s˚a stor utsträckning som möjligt. Detta gjordes för att göra det enkelt att snabbt f˚a en överblick i vad som behöver ändras ifall hyresvärden vill byta meddelanden eller notifikationer för ett specifikt fall. Resultatet av detta blev att vi har flera mindre filer med individuella gränssnitt istället för en stor fil med ett avancerat gränssnitt vilken även gjorde utvecklingen lättare.

(27)

7 Krav och utv¨arderingsmetoder

Figur 2 Komponentdiagram ¨over den centrala databasen och dess relaterade milj¨oer:

gränssnittet mot IDUN och API mot applikation. Heldragna pilar är förfr˚agningar och streckade pilar är svar.

7 Krav och utv ¨arderingsmetoder

I detta kapitel beskriver vi de tekniska krav som ställts p˚a det färdiga systemet, samt motiverar vi varför dessa krav är relevanta. Vi redogör även för hur dessa krav har utvärderats för att kunna säkerställa att systemet uppfyller dessa samt hur väl produkten tillgodos˚ag de önskem˚al som uttryckts fr˚an Vasakronan som uppdragsgivare. Därefter beskrivs hur användartester genomfördes för att mäta användarvänligheten hos syste- mets push-notifikationer.

7.1 Information och kommunikation

Huvudkravet som ställdes p˚a den slutgiltiga produkten var att alla hyresgäster som blir p˚averkade av en miljöreglering i en fastighet ska f˚a information om vad det är för reglering som sker och varför den genomförs. En viktigt aspekt för denna informationsspridning är att informationen kommer ut till hyresgästerna medan den är relevant och aktuell. Kravet vi formulerade för att möta denna önskan var att kunderna skulle f˚a informationen innan de börjar märka av förändringarna som sker i fastigheten.

Detta krav utvärderades genom att mäta hur l˚ang tid det tog för notifikationen att n˚a

(28)

användarens mobilapplikation fr˚an att indata skickas till v˚art gränssnitt mot IDUN. För att mäta v˚art resultat mot kravet krävdes en referenspunkt. Det optimala för detta fall hade varit att mäta tiden fr˚an d˚a en on-demand-signal inkommer till IDUN tills dess att miljön i en berörd fastighet har förändrats märkbart. Detta var inte möjligt d˚a v˚ar lösning endast är en prototyp som bygger p˚a on-demand-signalen som i dagsläget ännu ej är i bruk. D˚a vi inte kunde utvärdera detta krav i ett verkligt scenario valde vi därför att sätta kravet högre än nödvändigt för att kunna säkerställa kvaliteten. Kravet blev därför att notifikationen bör n˚a användaren inom n˚agra sekunder d˚a en miljöreglering änd˚a inte har omedelbar effekt utan tar tid att genomföra.

7.1.1 Information anpassad till ber ¨ord fastighet

Informationen till hyresgästerna i Vasakronans befintliga mobilapplikation är specifikt anpassad för enskilda adresser. Eftersom tanken var att v˚art tillägg skulle bli en del av deras applikation ställdes samma krav p˚a v˚ar produkt. Kravet blev s˚aledes att en hyresgäst ska inte f˚a uppdateringar om förändringar i en annan fastighet än den som angivits i applikationen.

För att kontrollera denna funktionalitet simulerade vi en on-demand-signal som vi visste skulle p˚averka en viss fastighet. Genom att därefter manuellt utvärdera förändringarna som skedde i den molnbaserade databasen för den specifika adressen samt för olika adresser i applikationen, kunde vi kontrollera att notifikationerna endast visades för användare tillhörande fastigheten där förändringen skett.

7.1.2 Automatiserad informationsuppdatering

Ett av kraven som formulerades var att uppdateringen skulle vara automatiserad. Anled- ningen till att detta ställdes som krav var att tillägget till applikationen förväntades ligga och prenumerera p˚a signaler fr˚an IDUN som indata. Ifall uppdateringarna istället skulle vara manuella för en s˚adan process krävs det att n˚agon anställd vid varje on-demand- signal g˚ar in och bekräftar att ny information ska skickas ut. Detta tar bort delar av syftet med projektet där vi snabbt vill kunna genomföra anpassningar när det r˚ader kapacitetsbrist för att undvika överbelastningar i elnätet.

Automatiseringen utvärderades genom att skapa en konstgjord on-demand-signal som förändrades med jämna intervall. Notiser matchande dessa signaler läggs d˚a till i den molnbaserade databasen, vilket även kommer informeras om i mobilapplikationen. För att säkerställa att automatiseringen är korrekt utvärderades resultatet av dessa signaler genom att manuellt kontrollera värden för den molnbaserade databasen samt notiserna i

(29)

prototypen av applikationen s˚a att dessa st¨amde ¨overens med den r˚adande signalen.

7.1.3 Kommunikationen med databasen

Ett av kraven som formulerades var att kommunikationen mellan mobilapplikationen och databasen skulle vara s˚a effektiv som möjligt. Detta innebär att databasens ge- nomför s˚a f˚a förändringar som möjligt d˚a applikationen m˚aste hämta ny information vid varje enskild förändring. Anledningen till att detta krav ställdes var för att minska dataanvändningen för användarna vilket resulterar i att applikationen drar mindre ström hos användarens enheten och belastningen p˚a enheten i övrigt minskar.

För att säkerställa en effektiv kommunikation simulerade vi en serier med on-demand- signaler där identiska signaler kom i följd med jämna mellanrum. Anledningen till att identiska signaler behövde skickas var för att kontrollera s˚a att det d˚a inte skedde n˚agon förändring i databasen, eftersom värdena skulle förbli densamma även efter en uppdate- ring. Genom att manuellt logga förändringar som skedde i den molnbaserade databasen under dessa sekvenser och sedan jämföra dessa förändringar mot den skickade sekven- sen med signaler kunde resultatet utvärderas.

7.2 Push-notifikationer

Ett annat krav som ställts p˚a produkten var att applikationens notifikationer inte var av s˚adan karaktär att användarna skulle störa sig p˚a dem. Anledningen till detta krav var att användaren har en tendens att inaktivera push-notifikationer för mobilapplikationen i de fall de finner informationen onödig eller upprepande. Detta skulle hindra det tilltänkta syftet med funktionen d˚a informationen inte skulle uppfattas av användarna direkt i de fall d˚a en akut ˚atgärd är nödvändig. Push-notifikationerna behövde allts˚a vara väl motiverade och inte för frekvent förekommande.

För att utvärdera om push-notifikationerna var för excessiva genomfördes användartester för att f˚a feedback fr˚an slutanvändaren. Under testet simulerades en längre period där det kontinuerligt skedde förändringar i notifikationerna där mer kritiska regleringar och veckoprognosen för väder skickades som en push-notifikation. Testpersonen ombads att säga till om n˚agon notifikation var störande under testet för att se om det var lagom frekvens p˚a push-notifikationerna.

(30)

8 Prototyp för gränssnitt mot hyresgäster

Figur 3 Applikationen d¨ar anv¨andaren har expanderat notifikationen med information om effektminskning.

8 Prototyp f ¨ or gr ¨anssnitt mot hyresg ¨aster

Gränssnittet mot användarna utgörs av prototypen för hur en mobilapplikation hade kunnat använda v˚ar lösning. Gränssnittet illustreras i Figur 3 och Figur 4. Prototypen har byggts med en grund fr˚an Facebook:s Create-React-App [Fac19] som användes för att snabbt kunna sätta upp en utvecklingsmiljö utan att behöva göra alla konfiguratio- ner själva. Anledningen till att detta gjordes var att vi endast behövde grundläggande funktionalitet för att kunna visa det vi ville i v˚ar prototyp. Därav fanns inte behovet att sätta upp en egen utvecklingsmiljö. Koden för applikationen följer den r˚adande praxisen för arbete med React där vi utnyttjar ett globalt tillst˚and (eng. state) för variabelhan- tering mellan de olika komponenterna. Komponenterna är sedan uppdelade efter den funktionalitet som vi vill att applikationen ska uppvisa. I v˚art fall är det de olika ty- perna av notifikationer som utgör komponenterna som f˚ar tillst˚andet som en parameter i form av indata. P˚a s˚a sätt behöver endast de globala tillst˚andet förändras för att f˚a en direkt förändring i den skapade komponenten. Det globala tillst˚andet inneh˚aller den

¨onskade adressen som f˚as fr˚an anv¨andaren, samt listor med de notifikationer som fas-

(31)

9 Implementantion av den centrala databasen

Figur 4 Applikationen d¨ar anv¨andaren har expanderat notifikationen med ˚aterkoppling.

tighetsägaren önskar att visa för fastigheten som korresponderar till adressen. Applika- tionen prenumererar kontinuerligt p˚a ett strömmande API fr˚an v˚ar centrala databas där förändringar för en specifik adress skickas ut till dess prenumeranter. Detta sker genom ett tillägg i applikationen kallat Axios som är en HTTP-klient [Axi19] som etablerar en uppkoppling mot v˚art API. När en förändring sker i den centrala databasen skickas det en signal genom uppkopplingen med ett nytt tillst˚and som blir applikationens globala tillst˚and.

9 Implementantion av den centrala databasen

Här förklaras implementationen av den centrala databasen samt hur den är kopplad till andra delar av systemet.

9.1 Databasens uppbyggnad

Databasen vi skapat kan liknas vid tv˚a listor. En lokal lista inneh˚allande samtliga möjliga notifikationer som Vasakronan kan vilja skicka ut till användarna, och den andra lista som en delmängd av den första inneh˚allandes de aktuella notifikationerna som lagras i molnet och visas för användarna just nu. Detta illustreras i Figur 5.

(32)

9 Implementantion av den centrala databasen

Figur 5 Databasens tv˚a listor, en med samtliga notifikationer och en med akutella notifikationer.

Den aktuella listan uppdateras med hjälp av en hanterare som mottar signaler fr˚an ett API mot Vasakronans styrsystem IDUN. Listan uppdateras automatiskt baserat p˚a de regleringar som Vasakronan gör i sina fastigheter i enlighet med deras eftersträvande att minska belastningen p˚a elnätet.

9.2 API mellan klient och databas

För att kunna hämta information fr˚an den molnbaserade databasen till prototypen för applikationen har ett strömmande API skapats. API:et best˚ar av en Express-server som

är uppkopplad mot den molnbaserade databasen. För att f˚a ˚atkomst till informationen i databasen fr˚an klientsidan g˚ar man genom en av tv˚a vägar (eng. routes) hos servern.