All posts by Christian Scott

Smart Home

14. November 2017

Anders har brukt de siste to ukene på å lære seg SolidWorks slik at vi kunne lage modell av huset og få det kuttet slik som vi ønsker. Vi har valgt å bruke kryssfinèr til huset. Anders og Espen brukte store deler av dagen på å få modellen kuttet til (Det var mange andre grupper som skulle bruke laser kutteren denne dagen), mens Christian og Jan Helge fortsatte arbeidet med databasen og serveren. Når Anders og Espen kom tilbake med modellen, ble den satt sammen og vi kontrollerte at 7-segmentene og led fikk plass i områdene de var laget for. Alt passet perfekt!

 

21. November 2017

Vi har gjort en helomvending i forhold til prosjektet!

“Ønskelisten” over funksjoner til huset er ganske stor, men vi ikke har tilgang på alle disse delene. Derfor vurderer vi å konvertere prosjektet fra Arduino til Unity3d.

Databasen og serveren vil fortsatt bli brukt på samme måte, men vi ønsker heller at vi skal lage prosjektet i en spillmotor, slik at brukeren kan bruke prosjektet som et spill.

Vi er foreløpig usikre på hvordan vi skal få vår database til å kommunisere med Unity og motsatt, men vi ser etter noen kjappe google søk at dette lar seg gjøre. Vi gjør endringer på to-do listen slik at vi får med Unity biten.

Resten av dagen blir brukt til å legge en plan på hvordan vi skal gå fram for å få til alle løsningene vi ønsker.

28. November 2017

Hele denne uken blir brukt til eksamensforberedelser i Datamaskinarkitektur og VHDL.

 

1.Desember 2017

Vi samlet oss etter vi var ferdige med eksamen og satt i gang med SmartHome prosjektet.

Kommunikasjonen mellom Unity og det vi allerede hadde laget viste seg å være en utfordring. Det ble brukt flere timer før vi klarte å få de til å prate sammen. Jan Helge har tatt på seg jobben med å bruke udemy.com til å lære seg Blender, slik at vi kan få en skikkelig modell av huset. Vi vurderte innledningsvis å bruke ferdige assets fra Unity assets store, men ingen av asset pakkene som lå ute falt helt i smak hos oss. Vi valgte derfor at Jan Helge skulle lage vårt helt eget hus fra grunn av.


4. Desember 2017

Helgen er blitt brukt til å få kommunikasjonen mellom Unity og databasen til å fungere slik den skal.

Vi har satt ønsket temperatur i huset, og ut ifra hvor kaldt det er ute og når på døgnet det er (Hvorvidt solen er oppe eller ikke), så kan man se at temperaturen endrer seg underveis i huset. Det er også lagt inn slik at lysstyrken inne i huset endrer seg ettersom solen er oppe eller ikke.

Det oppsto problemer når vi avsluttet tråden som knyttet unity og databasen sammen. På grunn av måten Unity er satt opp, så ville ikke tråden avsluttes og vi fikk derfor opp feilmelding siden vi forsøkte å starte en ny tråd. Det tok lang tid før vi klarte å løse problemet.

Problemstillingen om hvordan vi skal få overstyrt forhåndssatte innstillinger dukker opp og vi velger derfor å endre litt på tabellene i databasen slik at vi kan ta høyde for dette. Vi legger også til noen ekstra tabeller slik at bruker kan overstyre systemet ved spesielle anledninger (filmmodus, festmodus og lignende).

Den oppdaterte listen over tabellene er som vist under:

Schedule table:

  • ID, BeginHours, BeginMinutes, EndHours, EndMinutes, WeekdayMask, Description, CreationTime, InactivationTime

Zone table:

  • ID, Name, Description

ScheduleValue table

  • ID, TargetValueID, ScheduleID

ParameterType table:

  • ID, Name

CurrentValue table:

  • ID, ZoneID, ParameterTypeID, CurrentValue

Warning table:

  • ID, Notified, Confirmed, Text, Severity, Time

Mode table:

  • ID, Name, Active

ModeValue table:

  • ID, TargetValueID, ModeID

TargetValue table:

  • ID, Value, ParameterTypeID, ZoneID

 

Er det mange Schedules som er slettet som har samme sone og verdi?

  • Hvis samme bruker endrer verdier på samme sone og samme utstyr ofte (f.eks endrer lysstyrken i stuen flere ganger iløpet av en uke), vil vi at systemet skal kunne gi bruker et varsel om bruker ønsker å gjøre denne endringen permanent i den aktive schedulen.

Mode er bestemte endringer i verdier som overstyrer schedule (filmmodus, festmodus, etc)

  • Dette vil overstyre forhåndssatt profil og vil ikke endres før bruker skrur av gjeldende modus

Bruker temp Schedule for å overstyre

  • Når bruker endrer noen av verdiene (lys, temperatur osv) så vil det bli opprettet en temporary schedule som vil overstyre den originale. Bruker vil få mulighet til å sette hvilken tid disse endringene skal gjelde til. Når tiden på temporary schedule er gått ut og ingen endringer er gjort på nytt (bruker får mulighet til å forlenge tiden hvis ønskelig) så går systemet tilbake til schedule som er fastsatt for gjeldende tidsrom.

Smarte brytere / smarte klienter som kan overstyre ting (Hvis vi får tid)

smart bryter:

  • Hvis mannen i huset ønsker å lese på sengen, men kun ha på leselys på sin side. Mannen trykker på en bryter på sin side av sengen og stiller inn ønsket tid. Dette vil da overstyre den fastsatte profilen på det spesifikke lyset i perioden han velger. Når tiden er gått ut så går systemet tilbake igjen til profilen som den opprinnelig skulle hatt på det tidspunktet.

 

5. Desember 2017

Jan Helge har gjort ferdig modellen av huset (Skallet) og han vil bruke resten av dagen på å gjøre de siste endringene slik at huset er ferdig.

 

Resten av gruppen fokuserer på det gjenstående i prosjektet.

Vi gjør Unity klar til filmen som skal lages. Dette gjør vi ved at vi programmerer en patrol-tilstand på playeren vår, slik at han går etter bestemte waypoints av seg selv. Vi gjør dette for at videoen skal kunne bli best mulig og at vi skal få vist de forskjellige funksjonene i huset.

Vi støtte på problemer når vi testet huset i Unity. Problemet oppsto når vi skulle bevege spilleren opp og ned trappen i huset. Vi satt spawn punktet til karakteren i toppen av trappen og satt waypointene i første etasje slik at han ble tvunget til å bruke trappen for å komme seg rundt. Dette gikk ikke. Karakteren ble stående på toppen og stange i trappen. Etter noe tid glitchet han seg gjennom en vegg og kom på mirakuløst vis ned i første etasje og beveget seg slik han skulle.

Etter litt research så fant vi ut at høyden på trappetrinnene var årsaken til problemet. Dette resulterte i at gangbart området i trappen var nesten ikke eksisterende, noe som resulterte i at karakterene ikke tolket trappen som et område han kunne bevege seg på. Etter justering av dette, så fungerte det utmerket.

6. Desember 2017

Modellen av huset (endret variant) overfører vi til Unity og bruker Unity til å legge textures på overflater for å få et mer naturlig utseende på huset. Dette kunne blitt gjort i Blender også, men det er veldig tidkrevende og vi har rett og slett ikke mulighet til å bruke så lang tid på det.

Vi fortsetter arbeidet med databasen da dette ble mer utfordrende enn vi trodde. Animasjoner i huset er lagt til. Figuren kan nå gå gjennom hele huset, i begge etasjer og ut og inn dører (De åpner og lukker seg).

7. Desember 2017

Siste innspurt for å gjøre ferdig prosjektet i dag. Vi jobber fortsatt med kommunikasjonen mellom databasen og unity. Vi har fått til at varmen reguleres, men det har bydd på utfordringer når vi skal introdusere moduser som skal kontrollere flere funksjoner i Unity. Vi gjør siste endringer som må til for å få laget filmen, slik at den blir klar til i morgen.

Til filmen må det lages noen elementer som vi ønsker å bruke. Dette er billboards, vei som går opp til huset o.l.

Husmodellen har nå inventar som gjør det mer realistisk.

 

Websiden

Forside

Slik ser forsiden på websiden ut. Her hentes alle moduser som brukeren har laget fra databasen og listes opp ettersom de er aktive nå eller ikke. Brukeren kan trykke på Deactivate/Activate for å deaktivere/aktivere modusen. Hvis brukeren trykker på Activate for mode 2 skjer dette:

Nederst på siden er den schedulen som er aktive nå. Denne har blitt hentet fra databasen. Tanken er at scheduler er tidsinnstilt og kan være standardinnstillingene brukeren vil ha på huset sitt. Moduser aktiveres/deaktiveres etter brukerens behov og overstyrer scheduler.

På toppen av alle sidene er det en navigasjonsbar som bruker kan bruke til å gå til en av de fire hovedsidene: Home, Modes, Schedules og Zones

Brukeren kan sette opp soner, og velge innstillinger per sone.

Zone siden

Zone siden henter alle sonene brukeren har laget fra databasen og lister dem opp. Her kan brukeren lage nye soner, ved å trykke på Create New Zone. Da lastes denne siden inn:

Her kan bruker lage en ny sone ved å fylle inn navn på sonen og en beskrivelse av hva eller hvor sonene er. Sonen vil bli lagt til i databasen når brukeren trykker på Create.

I listen over soner kan bruker trykke på Edit for en sone, da vil denne siden lastes inn:

Denne siden henter sonen brukeren vil endre fra databasen og laster informasjonen om den inn i feltene. Brukeren kan da se hva verdiene er nå, og kan eventuelt endre dem. Når brukeren trykker på Save vil endringene lagres i databasen.

I listen over soner kan brukeren trykke på Delete for en sone, da vil denne siden lastes inn:

Denne siden henter sonen brukeren vil slette fra databasen. Siden spør om brukeren er sikker på at de vil slette denne sonen, og laster inn informasjon om sonen slik at brukeren kan være sikker på at de trykte på riktig sone og får en sjanse til å ombestemme seg. Når brukeren trykker på Delete, slettes sonen fra databasen.

Schedule siden

Schedule siden henter alle schedulene brukeren har laget fra databasen og lister dem opp. Her kan brukeren lage nye scheduler, ved å trykke på Create New Schedule. Da lastes denne siden inn:

Her kan bruker lage en ny schedule ved å fylle inn beskrivelse av schedulen, start- og stopptid, og hvilke dager schedulen skal være aktiv. Bruker fylle også inn hvilke verdier hver utstyrstype skal ha i hver sone. Hvis bruker vil at schedulen skal sette temperaturen i stua på 15 grader om natten, men 20 grader på soverommet, setter bruker start- og stopptid til nattetider og skriver inn 15 under Livingroom sonen og temperatur, og 20 under Bedroom sonen og temperatur. Schedulen vil bli lagt til i databasen når brukeren trykker på Create.

Denne siden henter alle sonene og alle utstyrstypene fra databasen og lister opp alle utstyrstypene per sone.

I listen over scheduler kan bruker trykke på Edit for en schedule, da vil denne siden lastes inn:

Denne siden henter schedulen brukeren vil endre fra databasen og laster informasjonen om den inn i feltene. Brukeren kan da se hva verdiene er nå, og kan eventuelt endre dem. Når brukeren trykker på Save vil endringene lagres i databasen.

I listen over scheduler kan brukeren trykke på Delete for en schedule, da vil denne siden lastes inn:

Denne siden henter schedulen brukeren vil slette. Siden spør om brukeren er sikker på at de vil slette denne schedulen, og laster inn informasjon om schedulen fra databasen slik at brukeren kan være sikker på at de trykte på riktig schedule og får en sjanse til å ombestemme seg. Hvis brukeren trykker på Delete, slettes schedulen fra databasen.

Mode siden

Modus siden henter alle modusene brukeren har laget fra databasen og lister dem opp. Her kan brukeren lage nye moduser, ved å trykke på Create New Mode. Da lastes denne siden inn:

Her kan bruker lage en ny modus ved å fylle inn navn på modusen og om modusen skal begynne som aktiv. Bruker fyller også inn hvilke verdier hver utstyrstype skal ha i hver sone. Hvis bruker vil at modusen skal slå av alle lys i huset når den er aktiv, skriver bruker inn 0 på alle lys utstyrstypene. Modusen vil bli lagt til i databasen når brukeren trykker på Create.

På denne siden hentes alle sonene og alle utstyrstypene fra databasen og lister opp alle utstyrstypene per sone.

I listen over moduser kan bruker trykke på Edit for en modus, da vil denne siden lastes inn:

Denne siden henter modusen brukeren vil endre fra databasen og laster informasjonen om den inn i feltene. Brukeren kan da se hva verdiene er nå, og kan eventuelt endre dem. Når brukeren trykker på Save vil endringene lagres i databasen.

I listen over moduser kan brukeren trykke på Delete for en modus, da vil denne siden lastes inn:

Denne siden henter modusen brukeren vil slette fra databasen. Siden spør om brukeren er sikker på at de vil slette denne modusen, og laster inn informasjon om modusen fra databasen slik at brukeren kan være sikker på at de trykte på riktig modus og får en sjanse til å ombestemme seg. Hvis brukeren trykker på Delete, slettes modusen fra databasen.

Databasen

Databasen inneholder 7 tabeller: Zones, Schedules, ScheduleValues, Modes, ModeValues, TargetValues og ParameterType.

TargetValues lagrer verdiene brukeren vil at hver sone skal ha per parameter type. Disse linkes opp mot scheduler og moduser via ScheduleValues og ModeValues, slik at flere schedules og/eller flere moduser kan ha samme verdier i sammen sone for samme parameter type uten å måtte dobbeltlagre data.

Når bruker legger til en ny/endrer en schedule eller modus, sørger websiden for at TargetValues som ikke er i bruk av noen scheduler eller moduser slettes; sjekker om det finnes en TargetValue som allerede har en av verdiene schedulen eller modusen skal ha og linker den til schedulen eller modusen ved å lage en ScheduleValue eller ModeValue mellom dem; lager nye TargetValues med en assosiert ScheduleValue eller ModeValue; og fjerner ScheduleValues eller ModeValues mellom schedulen/modusen og en TargetValue den ikke skal ha lenger, men hvor TargetValuen hører til andre scheduler eller moduser så den ikke kan slettes.

Brukeren kan ikke legge til parameterTyper. I parameterType tabellen ligger alle typer utstyr som vårt smarthus støtter.

Unity

Vi bruker Unity3D til å simulere et smarthus. Vi simulerer varme og tid med dag/natt syklus. Vi har implementert temperaturstyring og lysstyring.

Vi har laget soner som korrespondere med sonene vi har lagt til i databasen. Smarthuset mottar en verdi for en sone fra databasen, og prøver å oppnå den verdien i den sonen ved å manipulere utstyret i den sonen.

En sone kan inneholde ovner. Når sonen får en temperaturverdi prøver den å oppnå den temperaturen ved å skru på ovnene hvis temperaturen er lavere enn den ønskede temperaturen eller skru ovnene av hvis temperaturen er høyere enn den ønskede. Dette gjør sonen kontinuerlig slik at sonen holder seg på den ønskede temperaturen.

Som en del av temperatur simuleringen vil soner som ligger ved siden av hverandre gi varme til hverandre, og de vil også få varme fra miljøet utenfor huset.

En sone kan inneholde lamper. Når sonen får en lysverdi setter den alle lysene til å ha den styrken (0 til 100%).

Hver sone har sensorer som merker om det er en person i sonen. Når det er en person i sonen setter sonen alle lysene til den ønskede verdien. Når det ikke er en person i sonen, dimmes lyset til halvparten av den ønskede verdien.

Vi simulerer tid, med en klokke som tikker. Sola følger denne klokka, og står opp kl 6, er høyest på himmelen kl 12 og går ned kl 18 hver dag. På morgen tilfører sola lite varme, midt på dagen tilfører den mest varme, på ettermiddagen tilfører den lite varme, og om natten tilfører den ingen varme.

Vi simulerer tid på året i forhold til temperatur. I juni er det varmt ute, og i desember er det kaldt.

 

Smart Home (Gruppe 9)

Vi er gruppe 9 som består av 4 data studenter ved Høgskolen i Sørøst Norge, campus Kongsberg.

Gruppen består av: Espen Rønningen, Christian Scott, Anders Kristiansen og Jan Helge Slettebø.

 

OPPGAVEN

Smart systems-prosjektet går ut på å designe et system som skal operere i sanntid og ikke ved at kun bruker skal sende inputs. Systemet skal ta sine egne avgjørelser.

Oppgaven som var gitt var helt åpen, så studentene sto fritt til å velge selv hva de ønsket å jobbe med innenfor de gitte rammene, beskrevet over.

 

22.August 2017

Dette er første dag med faget, og foreleserne gav en kort introduksjon med krav og forventninger. De gikk raskt gjennom tidligere prosjekter og gav en indikasjon på hva som var fordeler/ulemper ved at tidligere studenter hadde gjort valgene de gjorde med sine prosjekter. Studentene delte seg inn i grupper og samlet seg for å legge en slagplan for resten av semesteret. Vi avtalte at vi skulle bruke tiden fram til neste møte ved å komme med ønsker til hva vi skulle lage.

 

29 august 2017

Vi samlet oss på grupperom for å diskutere mulige løsninger på oppgaven.

Forslagene som gruppemedlemmene hadde var:

  • Selvspillende sjakk
  • Search and rescue drone
  • Smarthus
  • Fjernstyrt rygging av henger

Selvspillende sjakk:

Forslaget var at man kunne spille sjakk mot andre spillere som ikke var i samme bygg, eller brukte samme sjakkbrett.

Tanken var at en person kunne sitte med sitt sjakkbrett hos seg, utføre trekk og at disse trekkene ville bli utført på sjakkbrettet til den andre spilleren.

Search and rescue drone:

Vi ønsket å lage en drone som ved hjelp av IR kunne finne personer som var savnet, tatt av snøskred o.l. Tanken var at vi skulle lage en drone som man kunne sende opp i vanskelig terreng, som søkte med IR signaler (IR mottaker ble sydd inn i jakker o.l). Når dronen kom direkte over signalet, så skulle kraftige lys bli satt på, slik at redningsmannskapet lett kunne finne den/de savnede personen/personene.

Smarthus:

Ideen var at vi skulle lage et hus og bruke en arduino som kontrollerte forskjellige funksjoner i huset (ved hjelp av en database og et webinterface).

Fjernstyrt rygging av henger:

Man har en bil med henger som er koblet til en fjernkontroll. På kontrollen så har man to modus: en modus for bil og en modus for henger. Når man velger bil så styrer man bilen på vanlig måte. Velger man derimot henger, så styrer man hengeren dit den skal, men i realiteten så er det bilen man styrer. Bilen tar høyde for hvilken retning den må dreie hjulene for å få hengeren til å svinge den retningen den skal.

Vi tok en avstemning og valget falt på smarthus.

5. september 2017

Etter forrige ukes avstemning så satt vi igang med å planlegge hva vi ønsket at smarthuset skulle inneholde.

Under brainstormingen var dette forslagene til utstyr som vi kunne kontrollere:

  • Lys
  • Alarm
  • Temperatur
  • Lås
  • Dyr – katteluke, mating, vann
  • Plante pass
  • Doorbell (vid/bilde)
  • Markiser/persienner/temperaturregulering/solskjerming/vind
  • “You’ve got mail” postkasse
  • Værstasjon
  • Garasjeåpner
  • Brannalarm
  • Slå av inaktive ting
  • Alarmklokke
  • Detektere hvor folk/dyr er?
  • Julelys-show
  • Butler/Jarvis

Vi ble også enige om at vi skulle utvikle en App som kunne styre huset, hvis tiden strakk til.

Christian tok kontakt med Joakim, for å få oppgaven godkjent, noe den ble.

12. September 2017

Christian anbefalte resten av gruppen å ta et kurs på Asp.Net, for dette ville hjelpe oss i forbindelse med oppsett av databasen og websiden. Det ble satt av 2 uker til dette da det var et ganske omfattende kurs.

19. September 2017

Vi fortsetter med gjennomgang av ASP.net. Vi har brukt microsoft sine tutorials til dette og Udemy.com.

Vi lagde i tillegg en foreløpig utstyrsliste over hva vi trodde vi kom til å trenge:

  • 5 hvite led
  • 1 LDR
  • 1 RFID leser + chip
  • 1 IR mottaker + kontroll
  • 1 arduino
  • 1 nettverks shield + wifi?/bluetooth?
  • 1  4 x 7-segmenter
  • 4 temperatursensor
  • 1 pir detektor
  • 1 mikrofon / lyd sensor
  • 1 kamera
  • 1 buzzer

Stue:

  • Bord
  • Sofa
  • TV

Kjøkken:

  • Bord
  • Stoler
  • benk?

Bad:

  • Do
  • Vask
  • dusj/badekar?

Soverom:

  • Seng
  • skap?
  1. September 2017

Dagen ble brukt til å lage en To-do liste slik at vi fikk en anelse om tidsbruk og hvilke deler av prosjektet vi måtte prioritere. Listen ble som følger:

To-Do liste:

  • Sjekke størrelse på lekemøbler
  • Kanskje 3D printe
  • Spør admin om laserkutting og 3D printing
  • laserkutte hus/bygge hus av papp
  • Lage server
  • lage nettside
  • sette sammen arduinoen med I/O

Lys

  • 0%-100% (0-255)
  • tid
  • beholde lysstyrke i rommet

Temperatur

  • tidsstyring
  • manuell styring
  • display current temp

Ringeklokke

  • sende varsel
    • maks en i minuttet (kan stilles på)
  • lage lyd

PIR

  • sende varsel
    • alle lys blinker i minst ett minutt
    • lager lyd
  • aktiv eller ikke?

Babycall

  • sende varsel ved lyd

Magnetbryter

  • sende varsel
    • alle lys blinker i minst ett minutt
    • lager lyd
  • aktiv eller ikke?

Vi lagde også et par scenarioer slik at alt ble satt i kontekst.

Scenarioer:

Pål kommer først hjem. Han bruker RFID for å låse opp døra og lyset i stua og kjøkkenet slås på og alarmen slås av. Han går inn og merker at temperaturen går opp til ønsket nivå (vanlig hjem modus) (alternativt: han sendte melding før han kom hjem slik at temperaturen allerede var god).

Pål er sistemann som forlater huset, han skrur på alarmen og døra låser seg selv etter han har gått ut. Lyset og temperaturen demper seg til forhåndsinnstilt nivå (ingen hjemme modus).

3. oktober 2017

Vi planlegger hvordan tabellene skal se ut i databasen og hvordan de er avhengige av hverandre.

Den foreløpig listen over tabellene er som følger:

 

Profile table:

  • ID, Name, ScheduleID, Description,

Schedule table:

  • ID, Starttime, Stoptime, WeekdayMask, Description

Zone table:

  • ID, Name, Description

ZoneValues table:

  • ID, ZoneID, ProfileID, ParamterTypeID, Preset

Equipment table:

  • ID, ZoneID, Description, EquipmentType

EquipmentType table:

  • ID, Name, In/Out, ParameterTypeID

EquipmentValues table:

  • ID, EquipmentID, MinValue

Dependency table:

  • ID, EquipmentID[EquipmentType.In/Out = In], EquipmentID[EquipmentType.In/Out = Out]

ParameterType table:

  • ID, Name

Preset table:

  • ID, ParameterTypeID, Name, MinValue

Resten av dagen ble brukt til å sette opp et forslag til hvordan vi så for oss at de forskjellige ferdig satte profilene kunne se ut:

Profile:

  • p0, s1, Night time at home (weekdays)
  • p1, s2, Night time at home (weekend)

Schedule: (WeekdayMask refers to starttime)

  • s0, 00:00, 23:59, 127, Default time
  • s1, 23:00, 07:00, b1111001, Night time
  • s2, 00:00, 07:00, b0000011, Night time

Zone:

  • z0, Livingroom
  • z1, Entrance
  • z2, Bedroom

ZoneValues:

  • zv0, z0, p0, pt0, pr4
  • zv1, z0, p0, pt1, pr5
  • zv2, z2, p0, pt0, pr1
  • zv3, z1, p0, pt0, pr4
  • zv4, z1, p0, pt1, pr5

ParameterType:

  • pt0, Temperature
  • pt1, Lights
  • pt2, Access

Preset:

  • pr0, pt0, Comfort, 22
  • pr1, pt0, Sleeping, 16
  • pr2, pt1, Comfort, 80
  • pr3, pt1, Reading, 100
  • pr4, pt0, Empty, 18
  • pr5, pt1, Empty, 0
  • pr6, pt2, Open, 1
  • pr7, pt2, Locked, 2
  • pr8, pt2, Secured, 3

10. Oktober 2017

Begynner arbeidet med databasen og serveren. Vi planlegger at dette skal vi bruke god tid på slik at den blir stabil og akkurat slik vi ønsker. Ønsket er at det skal være enkelt å legge til/fjerne funksjoner uten å måtte endre kode strukturen i databasen.