LS Retail - Internet of Things Skýrsla

LS Retail - Internet of Things Skýrsla

Vor 2017

Berglind Ómarsdóttir Haukur Ingi Ágústsson Kristinn Guðmundsson

Vilhjálmur Alex Hannesson

Leiðbeinandi: Karl Andrés Gíslason T-404-LOKA Prófdómari: Skúli Arnlaugsson Tölvunarfræði

Vor 2017

Efnisyfirlit:

1. Inngangur 4 1.1 Markmið Verkefnisins 4 1.2 LS Retail 4

2. Verkskipulag 5 2.1 Hlutverk 5 2.2 Viðvera 5 2.3 Þróunarumhverfi 6 2.4 Vinnuaðstaða 6

3. Verkáætlun 6

4. Kröfulýsing 7

5. Áhættugreining 13

6. Hönnun 15 6.1 Kerfið 15 6.2 Viðmótshönnun 19 6.3 Gagnagrunnsskema 21

7. Einingaprófanir 22 7.1 Web client 22 7.2 Web server 22 7.3 Data provider 22

8. Framvinduyfirlit 23 8.1 Sprettur 0 23 8.2 Sprettur 1 24 8.3 Sprettur 2 25 8.4 Sprettur 3 26 8.5 Sprettur 4 27 8.6 Sprettur 5 28 8.7 Sprettur 6 29 8.8 Sprettur 7 30

9. Samantekt 31

10. Rekstrarhandbók 32 10.1. Introduction 32

1 Tölvunarfræði B.Sc.

Vor 2017

10.2. Web Server 32 10.2.1 General Info 32 10.2.2 Prerequisites 32

10.3. Data Provider 32 10.3.1 General Info 32 10.3.2 Prerequisites 33

10.4. Info Server 33 10.4.1 General Info 33 10.4.2 Prerequisites 33

10.5. Modules 33 10.5.1 General Info 33 10.5.2 Prerequisites 34 10.5.3 Module types 34

10.6. Devices 34 10.6.1 General Info 34 10.6.2 Prerequisites 34 10.6.3 Device types 34

10.6.3.1 Coffee Machine 34 10.6.3.2 Vending Machine 35

10.7. Database 35 10.7.1 General Info 35 10.7.2 Prerequisites 35 10.7.2 Schema 35

10.8.Power BI 36 10.8.1 General Info 36 10.8.2 Prerequisites 36 10.8.3 Links 36

10.9 APIs 37 10.9.1 Web Server 37 10.9.2 Data Provider 39 10.9.3 Modules 39 10.9.4 Devices 39

10.10 Adding support for a new device type 40 10.10.1 Add support to database 40 10.10.2 Create a new module 40 10.10.3 Add support to Data Provider 41 10.10.4 The Web Server 41

11. Notendahandbók 42


Vor 2017

11.1. Introduction to the system 42 11.2. Basic Usage 43

11.2.1 Add device 43 11.2.2 Add station 43 11.2.3 Add Module 44 11.2.4 Edit 44

11.2.4.1 Edit Device 44 11.2.4.2 Edit Module 45 11.2.4.3 Edit Station 45

11.2.5 Delete 45 11.3. Admin User 46

11.3.1 See Register 46 11.4. Office User 47

11.4.1 See Analysis 47 11.4.2 See Devices 48

11.4.2.1 See Device Details 48 11.5. Station User 49

11.5.1 See analysis 49 11.5.2 See your devices 50

11.5.2.1 See device details 50 11.5.3 Subscriptions 51


Vor 2017

1. Inngangur

1.1 Markmið Verkefnisins Verkefnið snérist um að hanna og þróa IoT umhverfi fyrir eldsneytissölufyrirtæki með eftirfarandi verkþáttum:

● Hanna umhverfi sem að getur tekið við gögnum frá tækjum í verslunum ● Hanna rauntímaeftirlit og greining á gögnum frá tækjum.

○ Vakta einstök skilaboð frá tækjum um villur ○ Þróa aðferðir til að greina gögnin og meta hvenær hætta er á að búnaður

verði óstarfhæfur ○ Þróa aðferðir til að meta tekjutap byggt á bilanasögu

● Hanna viðvörunarkerfi þar sem notendur geta gerst áskrifendur að eftirliti og fengið aðvaranir sendar í rauntíma á þann hátt sem þeir kjósa

● Hanna viðmót eftirlitskerfis þar sem hægt er að sjá stöðuna á þeim tækjum sem að eru tengd þessu kerfi.

Markmið verkefnisins fólst því í því að búa til lausn fyrir olíufélög sem að leyfir þeim að tengja tæki við verslunarkerfi sín og fylgjast með stöðu þeirra í rauntíma. Áhersla verkefnisins var á kaffivélar og þeirra upplýsingar. Kaffivélar eru hentugar fyrir proof of concept verkefni eins og þetta þar sem þær eru með takmarkað mengi upplýsinga. Afurð verkefnisins var vefsíða þar sem aðgangstýring gefur notendum aðgang að þeim upplýsingum sem tengjast þeirra fyrirtækjum. Upplýsingarnar eru margskonar og fara eftir tegund aðgangs. Flestar upplýsingar eru í formi tölfræði og útreikninga en einnig eru villumeldingar.

1.2 LS Retail LS Retail er leiðandi fyrirtæki í þróun og sölu á hugbúnaðarlausnum fyrir verslunar- , veitinga- og bensínstöðva-rekstur. Lausnir fyrirtækisins eru seldar í yfir 75 löndum af 220 vottuðum endursöluaðilum og er yfir 90% af heildarveltunni tilkomin erlendis frá. LS Retail hefur náð þeim árangri að vera stærsti þróunaraðili Microsoft Dynamics lausna á sviði verslunar í heiminum. Yfir 2800 fyrirtæki víðsvegar um heim nota hugbúnað fyrirtækisins og keyrir hann á u.þ.b. 111.000 afgreiðslukössum í 47.000 verslunum. Hjá fyrirtækinu starfa um 150 manns við þróun á hugbúnaði og sölu. LS Retail hefur höfuðstöðvar á Íslandi og skrifstofur í US, Singapore, Malaysia og Dubai. Hjá félaginu vinnur samstilltur hópur sérfræðinga af mismunandi þjóðernum en net samstarfsaðila sér um endursölu lausna þess.


Vor 2017

2. Verkskipulag Tekin var ákvörðun um að nota Scrum og Agile aðferðafræði í verkskipulagi hópsins. Hver sprettur var skipulagður í tveggja vikna lotum í upphafi þar sem við áætluðum að vinna a.m.k. 2 heila virka daga í viku (fimmtudag og föstudag) og mögulega um helgar ef við sáum þörf á því. Þegar lengra leið á verkefnið voru sprettirnir styttir niður í eina viku. Daily planning fundir voru haldnir alla morgna á föstum viðverudögum kl 9 um morgun. Þessir fundir voru yfirleitt stuttir og hnitmiðaðir þar sem farið var yfir hvað voru verkefni dagsins og hvað var gert daginn áður, ásamt því einfaldlega að samstilla hópinn til þess að vinnan gæti gengið eins snurðulaust og hægt var. Í hverri viku stóð til boða að halda stöðufund með fulltrúum LS Retail, bæði fyrir tæknilega ráðgjöf handa okkur en líka til að sýna LS Retail hver staðan væri á verkefninu. Þessir fundir gátu þó forfallast niður stöku sinnum ef það var lítið af málum á dagskrá. Á hverjum mánudegi var fundur með Karli Andrési, lokaverkefnis leiðbeinandanum okkar, sem gögnuðust hópnum mjög mikið en þar fengum við góð ráð og góð svör við þeim spurningum sem við höfðum ásamt því að eiga oft góða umræðu um verkefnið.

Í lok hvers spretts, annan hvern föstudag, var haldin sprint retrospect fundir þar sem við fórum yfir nýliðin sprett en einnig funduðum við til að skipuleggja næsta sprett og ákváðum hvaða user stories úr product backlognum voru teknir inn í sprint backloginn og brutum þær niður í tösk. Hópurinn notaðist við product backlog sem geymir þær sögur sem voru hannaðar fyrir verkefnið en backloggurinn var síbreytilegur yfir líftíma verkefnisins.

2.1 Hlutverk Product Owner: LS Retail Scrum Master: Kristinn Guðmundsson Þróunarteymi:

● Berglind Ómarsdóttir ● Haukur Ingi Ágústsson ● Vilhjálmur Alex Hannesson ● Kristinn Guðmundsson

2.2 Viðvera Hópurinn hittist 2 sinnum í viku, á fimmtudögum og föstudögum og ef að það sást tækifæri til þess að vinna frekar, hittist hópurinn um helgar. Hver meðlimur hópsins bar ábyrgð á að skrá niður vinnutíma sinn og í hvaða verki hann vann í. Hver meðlimur vann 8 tíma hvorn daginn, samtals 16 klst í viku eða 32 klst í sprett. Þannig að í lok hvers sprett átti hópurinn að geta skilað af sér samtals 128 klst í vinnu. Eftir að formlegum skóla lauk fór hópurinn að mæta á hverjum degi og skilaði hver og einn að meðaltali 8 klst á dag.


Vor 2017

2.3 Þróunarumhverfi LS Retail er náinn samstarfsaðili Microsoft og eru grunnlausnir þeirra þróaðar í Microsoft Dynamics ERP umhverfinu. Einnig eru lausnir félagsins þróaðar í .NET umhverfi og þróunarumhverfinu fyrir farsímalausnir og veflausnir. Hópurinn ákvað því að þróunarumhverfið væri Visual Studio og unnið væri í C# forritunarmálinu. Notast var við GitHub til að deila gögnum með hópmeðlimum og LS Retail veitti aðgang að Microsoft Azure gagnagrunn.

2.4 Vinnuaðstaða LS Retail bauð hópnum upp á vinnurými í opnu rými, þar sem hópurinn vann innan um annað hugbúnaðarfólk fyrirtækisins, með kost á því að leita til þeirra ef upp koma vandamál hvað varðar verkefnið. Hópurinn fékk vinnuaðstöðu hlið við hlið, þannig að við gátum auðveldlega unnið saman og einnig voru fjölmörg fundarherbergi, sem hópurinn gat nýtt sér til hópavinnu og fundarhalds.

3. Verkáætlun Í byrjun verkefnisins var hver sprettur skipulagður frá fimmtudegi fyrstu viku þangað til föstudags vikunnar þar á eftir, þannig að hver sprettur spannaði yfir 2 vikna tímabil. Þegar lengra leið á verkefnið voru sprettirnir styttir niður í viku langa spretti.

Sprint From To Schedule

0 01/26 02/03 Setting up gear and report, researching IoT and setting up environments.

1 02/09 02/17 Start setting up system and coding the test environment, creating a virtual coffee machine. Finishing initial design of the system

2 02/23 03/03 Coding the processing of information from coffee machine, i.e the server

3 03/09 03/17 Coding the website, continued coding on server

4 03/23 03/31 Setting up database and coding connections to that database

5 04/06 04/14 Coding machine learning behaviour and starting testing

6 04/20 04/28 Testing and final additions to code

7 05/04 05/12 Testing and final modifications


Vor 2017

4. Kröfulýsing Hver sögupunktur var byggður upp sem lýsing á notanda kerfisins og hvað hann vill geta gert í kerfinu til að skila ákveðinni niðurstöðu. Til að byrja með var erfitt að gera ráð fyrir hversu margir sögupunktar fóru í hverja sögu, því að enn var óvíst hver vinnuhraði hópsins yrði, en þegar að hópurinn fór að forrita kerfið kom frekar í ljós vinnuhraði hópsins og hversu margir sögupunktar hópurinn réð við í hverjum sprett. Sögupunktarnir eru flokkaðir niður í 4 flokka, þeir eru programming, administrative, documentation og research.

Case Nr.

Key Use case Priority Story Points

Status

0 D I want a time schedule so that i can log my time A 1 Done

1 A I want to Attend a orientation meeting so that i know more about LS

A 1 Done

2 D I want a report to hand in about the project (version 1)

A 13 Done

3 D I want to have a well defined description of the project

A 1 Done

4 D I want to have a work organization report (verkskipulag)

A 3 Done

5 D I want to have a Activity program report (verkáætlun)

A 3 Done

6 A I want to have Trello so that we can be better organized

A 1 Done

7 A I want to have version control to make working together easier and safer for data

A 1 Done

8 R I want to know more about IOT technology A 5 Done

9 A Weekly LS meeting A 1 Done

10 A Weekly Instructor meeting A 1 Done

11 R I want to know more about scrum A 3 Done


Vor 2017

12 D I want to have a requirement analysis report A 5 Done

13 D I want to have a risk analysis report A 3 Done

14 D I want to have a design of the system A 8 Done

15 D I want a product backlog so that i can see stories and what needs to be done

A 13 Done

16 P I want to have a virtual coffee machine for the system to communicate with

A 5 Done

17 A Team meeting A 5 Done

18 D I want to have a Class Diagram so that i can see more easily what is to be implemented

B 8 Removed - Not Implemented

19 D I want to have a list of REST server API commands available so that what needs to be programmed is clearly defined

A 5 Done

20 P As a user I want to be able to monitor multiple machines

A 5 Done

21 P I want to create a relational database in the cloud to store data

A 5 Done

22 P I want to have a structure of front end so we can start testing connections

A 8 Done

23 P As a general user I want to be able to login to a website

A 13 Done

24 P As a general user I want to be able to see which machines are on my wifi and are connected

A 3 Done

25 P As a manager user I want to be able to receive information about machines within my institution

A 5 Done

26 P As a manager user I want to be able to see machine data in form of informational graphs and tables

A 8 Done

27 P As a general user I want to be able to know when water runs out on any of my machines so that I can refill it

A 3 Done

28 P As a general user I want to be able to know when coffee beans run out on any of my machines so that I can refill it

A 3 Done

29 P As a general user I want to be able to receive C 13 Removed -


Vor 2017

information about common rush times so that I can be prepared

Not Implemented

30 P As a general user I want to be able to receive notifications of any warnings or errors in any of my machines

A 3 Done

31 P I want to have a web server to host the website A 21 Removed - Redundant

32 P I want to have a server foundation so that i can work on other features on the server

A 21 Removed - Not Implemented

33 P As a general user I want to receive notifications if the machine is behaving different than normally, for instance pouring coffee slower than normally

C 8 Removed - Not Implemented

34 P As a general user I want to receive error frequency reports to evaluate maintenance needs

C 8 Done

35 P As a new user I want to be able to insert all vital information and preferences so that I can operate the system to my liking

B 21 Removed - Redundant

36 P As a office user I want to be able to see logs on machine error frequencies and maintenance problems on the website

A 5 Done

37 P As a user I want to be able to change my information and preferences so that if something changes or I dont like something, I can change it

A 21 Removed - Redundant

38 D I want to have a presentation ready so that i can impress at the first "Stöðufundur

A 5 Done

39 A I want to present for first "Stöðufundur" A 5 Done

40 D I want a prototype of the websites ui so that i can more easily plan ahead

A 5 Done

41 R I want to know more about server client setup so that i can implement one

A 5 Done

42 R I want to know more about how login authentication works

A 5 Done

43 P I want to initiate the Web server project so that team members can work on it

A 3 Done

44 D I want to design the table scheme for the database A 8 Done


Vor 2017

45 P I want to setup tables in the database A 3 Done

46 P I want to have a notification service so that i can send notifications to subscribers

A 13 Done

47 R I want to set up azure db A 8 Done

48 R I want to learn about Power BI B 3 Done

49 P I want the server to have a hashmap for all authentications to db and powerbi

C 13 Removed - Not Implemented

50 D I want to have a sprint burndown chart so that we can constantly see amount of work left

A 3 Done

51 P I want to have an infoServer so that the server can communicate with a coffee machine

A 13 Done

52 A Setting up a Readme file for the github site, for installations

A 3 Done

53 P I want to have a Data Provider server so the Info server can pass data to the db

A 8 Done

54 P I want to have entity framework set up A 2 Done

55 P i want to have a structure of a web server to connect the database and web client

A 8 Done

56 D I want to have a presentation ready so that i can impress at the second Stöðufundur

A 5 Done

57 A I want to present for second "Stöðufundur" A 2 Done

58 D i want a report to hand in about the project (version 2)

A 8 Done

59 A I want to have a heroku set up for the project B 5 Removed - Not Implemented

60 A I want to have a travis set up for the project B 5 Removed - Not Implemented

61 P I want to have a demo of the project to present to instructors

A 8 Done

62 P i want to have a unit test framework set up for each components

A 8 Done


Vor 2017

63 P I want to implement functions is web server to be able to see which machines are on my wifi

A 5 Done

64 P As a admin user I want to be able to register user to a website

A 13 Done

65 P I want to have all components commented to make functions more clear

A 5 Done

66 P I want to have a module to talk to a coffee machine A 5 Done

67 P I want to have a module to talk to a vending machine

A 8 Done

68 P I want to validate input in the webserver A 3 Done

69 P I want to validate input in the dataprovider A 3 Done

70 P I want to refactor database so that it handles multiple device types

A 5 Done

71 P I want to have a virtual vending machine for the system to communicate with

A 8 Done

72 P i want to have a unit test for the front end A 13 Done

73 P i want to have a unit test for the web server A 13 Done

74 P i want to have a unit test for the data provider A 13 Done

75 P I want to refactor InfoServer to talk to modules and only send and recieve data

A 8 Done

76 P I want to refactor webserver to map to database A 8 Done

77 P I want to refactor dataprovider to map to infoserver and database

A 8 Done

78 P I want to have a vending machine service so that dataprovider can get data

A 8 Done

79 P I want to set up Power BI B 13 Done

80 P I want to be able to register a subscriber from the web client

A 5 Done

81 P I want to be able to remove devices B 8 Done

82 P Modify information about devices B 8 Done

83 D I want to have a finished report to hand in A 8 Done


Vor 2017

84 D I want to have a Operational manual A 5 Done

85 D I want to have a User Manual A 5 Done

86 D i want a report to hand in about the project (version 3)

A 8 Done

87 A I want to present for last "Stöðufundur" A 2 Done

88 A Final Handin A 8 Done


Vor 2017

5. Áhættugreining Hópurinn vann að lausnum við helstu vandamálum sem gátu komið upp við gerð þessa verkefnis, hvert áhættustig var skrifað sem áhætta * líkur og gaf það okkur áhættustigið.

Nr. Risk Risk Level

Action Responsible party

Status

0 Illness in group 2 Group member can still keep on working from home to some extend

Group member

OK

1 Arguments in group

4 Group members will work it out using the 15 min rule, where you get 15 min to be angry after that you have to let it go

Group members

OK

2 Research problems

4 If there is no success after a while you have to drop what you are doing and start focusing on other tasks

Group member

OK

3 Technical problems

1 Company provides an IT department that can help the group with any technical problems that can come up

IT department

OK

4 Built up workload

6 Group members will work extra hours during the weekend to minimize the workload

Group members

OK

5 Snow storm 2 Group member will still work from home and have their usual weekly group meeting using Google hangouts

Group members

OK

6 Problem connecting database

3 Company provides a reliable database server that is managed by the company so there won't be any problems

LS Retail OK


Vor 2017

7 Writer's block 3 If a group member gets writer's block he can either get a second opinion from another group member or ask them to take over

Group member

OK

8 No workspace 1 Group members can work either on company grounds, in a group room in Reykjavik University or at home

Group members

OK

Risk level = Risk * Probability Unlikely and Low risk = 1 * 1 = 1 Unlikely and Medium risk = 1 * 2 = 2 Unlikely and High risk = 1 * 3 = 3 Possible and Low risk = 2 * 1 = 2 Possible and Medium risk = 2 * 2 = 4 Possible and High risk = 2 * 3 = 6 Likely and Low risk = 3 * 1 = 3 Likely and Medium risk = 3 * 2 = 6 Likely and High risk = 3 * 3 = 9


Vor 2017

6. Hönnun

6.1 Kerfið Kerfið er veflausn þar sem þrennskonar aðgangar geta skráð sig inn, það er einn aðgangur á fyrirtæki fyrir aðgangsstýringar, einn aðgangur fyrir hvert útibú og svo aðgangur fyrir skrifstofustarfsmenn.

Sá notandi sem aðgangsstýrir, sér um að búa til nýja aðganga fyrir hvert útibú og sjá til þess að upplýsingar um hvern aðgang séu réttar. Einnig býr hann til nýja aðganga fyrir starfsmenn skrifstofunnar sem þurfa upplýsingar frá öllum útibúum. Þessi notandi sér einnig um að bæta við tækjum fyrir hvert útibú. Hugsa má þennan aðgang sem kerfisstjóra.

Útibúsaðgangar geta fylgst með sínum nettengdu vélum og einnig geta þeir gerst áskrifendur af tilkynningum og fengið þá að vita um leið ef eitthvað bilar eða ef fylla þurfi á vélina. Þeir fá upplýsingar í ýmsum gröfum og með öðrum myndrænum hætti.

Skrifstofuaðgangar hafa aðgang að öllum upplýsingum frá hverju útibúi en hafa ekki heimild til að breyta neinu. Þessir aðgangar fá sömu upplýsingar og útibúin, nema þeir fá upplýsingar frá öllum útibúum.


Vor 2017

Hér á myndinni fyrir neðan má sjá þá notendahópa sem nota kerfið og þeirra hlutverk. Einnig má sjá utanaðkomandi kerfi sem okkar kerfi notar.

Þau utanaðkomandi kerfi sem okkar lausn mun nota eru internet tengdar kaffivélar, PowerBI sem mun greina þau gögn sem sótt eru frá kaffivélunum og svo Azure gagnagrunnur sem mun geyma allar upplýsingar frá kaffivélunum og notendaupplýsingar


Vor 2017

Hér á næstu mynd má svo sjá nánar hvernig kerfið er uppbyggt. Notendur hafa aðgang að vefsíðu þar sem þeir geta séð mismunandi upplýsingar eftir aðgangstegund, vefþjónninn sækir svo viðeigandi upplýsingar í gagnagrunninn.

Svo er eining sem kallast Info Server, sú eining er staðsett innan stöðvar og þjónar þeim tilgangi að smala saman upplýsingum frá öllum tækjum innan þeirrar stöðvar og senda þær áfram á Data Provider. Info Server fær upplýsingar um hvaða Module hann á að tala við og sendir á hvert og eitt module, lista af tækjum sem það module á að tala við. Module eininginn kann svo að tala við sérstök tæki, svo það þarf eitt module til að tala við t.d. kaffivélar og annað module til að tala við aðra tegund af tæki. Data Provider einingin sér svo um að taka á móti þeim upplýsingum sem berast frá Info Server og vista þær á viðeigandi hátt í gagnagrunninn og senda út tilkynningar ef á við.

PowerBI er svo notað til að greina gögnin úr gagnagrunninum og búa til sjónrænar greiningar á gögnunum sem notendur kerfisins fá aðgang að og geta nýtt í sínar rekstrarákvarðanir.


Vor 2017


Vor 2017

6.2 Viðmótshönnun Fyrstu drög að hönnun að viðmóti kerfisins.

Hér má sjá hvernig forsíðunni er háttuð þar sem notandi þarf að skrá sig inn til að öðlast

aðgang að kerfinu sjálfu.

Hér má svo sjá síðuna sjálfa eftir að notandi er búinn að skrá sig inn í kerfið, sem fer eftir

réttindum notandans að kerfinu.

Hér er síðan hægt að sjá lista yfir allar

stöðvar sem tilheyra hverjum notanda, ef valin er sérstök stöð er hún aðeins birt.

Þegar sérstök stöð er síðan valin er þessi síða síðan birt þar sem hvert tæki er listað upp og hægt að sjá upplýsingar um þær.


Vor 2017

Á þessari síðu er síðan hægt að bæta við

stöð eða tæki sem bætist við kerfið

Einnig er hægt að breyta upplýsingum um

hverja stöð eða tæki í kerfinu.


Vor 2017

6.3 Gagnagrunnsskema Verkefnið notast við entity framework til að mappa gögn í gagnagrunninn. Hvert module í töfluskemanu tilheyrir tiltekinni stöð og hvert module hefur tiltekin tæki, þessi tæki geta síðan verið af taginu kaffivél, sjálfssali eða óskilgreint tag þar sem aðeins grunnupplýsingar tækisins eru gefin upp. Skemað styður síðan það að hægt sé að bæta við öðrum tegundum af tækjum, eina sem þarf er að bæta við töflum sem eru sérstaklega ætlaðar fyrir þær tegundir. En eins og staðan er á þessari mynd er hann með stuðning fyrir kaffivélar, sjálfsala og einföld tæki.


Vor 2017

7. Einingaprófanir Öll helsta virkni kerfisins er prófuð með einingaprófunum til að ganga úr skugga um að allt sem kerfið á að geta gert sé að vinna rétt. Prófanir kerfisins samanstanda af 164 prófunum þar sem að heildar prósenta prófana nær í kringum 96% af lógík kóðanum (buisness logic) í kerfinu.

7.1 Web client Framenda prófin voru skrifuð í Jasmine og prófuð með Karma framework. Hver eining er prófuð sér og náðust flestar uppí 100% hlutfall af prófuðum kóða. Samanlagt var 93.88% af framendanum prófaður og skiptist það niður á 94 próf. Hægt er að sjá niðurbrot á hversu mikið af hverri einingu var prófað hér fyrir neðan.


Vor 2017

7.2 Web server Við gerð einingaprófana í Web Server einingunni var notast við Xunit. Heildar fjöldi prófana eru 67 prófanir þar sem að 100% af lógík kóðanum (business logic) er prófaður. Á myndinni hér fyrir neðan má sjá þjónusturnar og föll þeirra ásamt hlutfall þess kóða sem er prófaður.


Vor 2017

7.3 Data provider Við gerð einingaprófana í Data Provider einingunni var notast við Xunit og eru einingaprófin fjögur talsins. Ástæða þessara fáu prófa er sú að þjónusturnar (service) hafa í raun eitt aðalfall sem nota hjálparföll við ákveðnar kringumstæðum. Aðalfallið fær inn einn hlut (object) sem er brotinn niður og greindur og við ákveðin skilyrði eru hjálparföllin keyrð. Það þarf því aðeins einn hlut til að ná yfir allan kóðann, svo lengi sem hann uppfyllir öll þau skilyrði sem þarf til að hjálparföllin séu keyrð. Þrátt fyrir fá próf næst að prófa 96% af lógík kóðanum (business logic). Á myndinni hér fyrir neðan má sjá þjónusturnar og föll þeirra ásamt hlutfall þess kóða sem er prófaður. Aðalföllin eru:

● BasicInfoService - UpdateStatus(UpdateDeviceViewModel) og GetDevicesInStation(int). ● CoffeeInfoService - UpdateDeviceInfo(UpdateCoffeeMachinesViewModel). ● VendingInfoService - UpdateDeviceInfo(UpdateVendingMachineViewModel).


Vor 2017

8. Framvinduyfirlit

8.1 Sprettur 0 Vika 25.Jan - 8.Feb. Hópurinn fór saman á nýliðanámskeið þar sem farið var yfir helstu þætti fyrirtækisins LS Retail. Þar á meðal hvernig fyrirtækinu er háttað og helstu öryggisþætti hússins. Þar á eftir fengu allir lykla að húsinu og gátu farið að koma sér fyrir í rýminu sem að LS útvegaði. Þegar allir meðlimir hópsins voru búnir að koma sér vel fyrir, var skipt verkskipulaginu niður og hófst uppsetning skýrslunnar og einnig kynnt sér nánar hvaða tæki kæmu til boða að tengjast komandi kerfis. Við tók mikil rannsóknarvinna við að skoða kaffivélar sem bjóða uppá utanaðkomandi tengingar. Erfitt er að finna svoleiðis kaffivélar og í lok spretts er enn óljóst hvaða kaffivél verður fyrir valinu. Á meðan sú vinna er ennþá í gangi þá fórum við í að skrifa þarfagreininga skýrslu, áhættugreiningu og fyrstu skrefin tekin í hönnun kerfisins. Vegna eðlis fyrsta sprettsins þá reyndist erfitt að gera burndown rit þar sem mikið af þeirri vinnu sem var gerð var rannsóknarvinna, eins og sést á næstu mynd, og það reyndist erfitt að brjóta hana niður í flokkanlega vinnuhluta. Vinna í klukkustundum í spretti: 97. Sögupunktar kláraðir í spretti: 38


Vor 2017

8.2 Sprettur 1 Vika 09.Feb - 22.Feb. Hópurinn fór í að setja upp þá parta kerfisins sem hægt var að setja upp. Búin var til virtual kaffivél í Python. Kaffivélin getur sent frá sér upplýsingar um sjálfan sig, villumeldingar og sölutölur. Sett var upp project fyrir vefþjón sem hentaði verkefninu. Einnig var hannað viðmót fyrir vefsíðuna sem viðskiptavinir munu nota til að tengjast og fá upplýsingar um sínar vélar. Mestur tími í þessum sprett fór þó í að skrifa skýrsluna og undirbúa stöðufund 1. Vinna í klukkustundum í spretti: 102,5. Sögupunktar kláraðir í spretti: 34


Vor 2017

8.3 Sprettur 2 Vika 23.Feb - 8.Mars. Kerfið er loks komið með rétta mynd og fór hópurinn í það að binda saman allt kerfið í eina heild. Kerfið samanstendur núna af vefsíðu sem er tengd við vefþjón og frá vefþjóninum í gagnagrunn, einnig er um að ræða kaffivélar sem eru tengdar við gagnasafnara sem kemur upplýsingum frá kaffivélunum til gagnamiðlara sem kemur síðan þessum upplýsingum til gagnagruns. Hópurinn fékk aðgang að gagnagrunni frá Azure sem að fyrirtækið skaffaði, og var byrjað á því að tengja hvern part af kerfinu í gegnum grunninn. Hver meðlimur í hópnum gat nú farið að vinna í sínum hlut í kerfinu og í lok spretts var kominn upp heildar mynd af kerfinu og tengingar frá viðmóti viðskiptavinar til kaffivélar Vinna í klukkustundum í spretti: 138,5. Sögupunktar kláraðir í spretti: 34


Vor 2017

8.4 Sprettur 3 Vika 9.Mars - 22.Mars. Fyrstu dagarnir í þessum sprett fóru í það að klára ákveðna áfanga fyrir stöðufund og einnig að undirbúa demo fyrir stöðufund en sá fundur gekk mjög vel. Ágætis tími fór í að uppfæra skýrslur og gera kynningu fyrir stöðufundinn. Hópurinn er kominn á gott skrið og vinnan gengur vel. Eitt af verkefnunum þessa spretts var að setja upp heroku og travis en við komumst fljótt að því að þessi tól hentuðu ekki fyrir kerfið okkar vegna uppsetningarinnar og því var hætt við að nota þau. Einnig byrjuðum við á að setja upp og gera fyrstu einingarprófanir. Vinna í klukkustundum í spretti: 122,25. Sögupunktar kláraðir í spretti: 31


Vor 2017

8.5 Sprettur 4 Vika 23.Mars - 5.Apríl. Hópurinn vann að miklu leyti bara fyrri hluta þessa spretts að sökum lokaprófa sem hópurinn þurfti að byrja að undirbúa sig fyrir. Þrátt fyrir það þá náðist að klára nokkrar mikilvægar sögur sem tengdust að því að tengja vélar inn á kerfið og geta séð upplýsingar eftir mismunandi vélum og mismunandi stöðvum. Héldum einnig áfram að vinna í því að skrifa einingarpróf. Vinna í klukkustundum í spretti: 96,5. Sögupunktar kláraðir í spretti: 42


Vor 2017

8.6 Sprettur 5 Vika 6.Apríl - 19.Apríl. Hópurinn kláraði lokapróf snemma í sprettinum og því fór lokaverkefnið á fullt flug og mæting fór í að vera alla daga vikunnar. Við endurhönnuðum nokkra liði kerfisins til þess að gera kerfið meira einingarskipt. Endurhönnunin var að mestu leyti til að auðvelda það að hægt sé að bæta við nýjum tegundum af tækjum við kerfið. Tengt því þá þurfti að uppfæra töflur í gagnagrunni og búa til nýjar einingar í kerfinu kallaðar modules sem sjá um að tala við hverja tegund af vél. Notification parturinn af kerfinu komst langt á leið í þessum spretti og er í raun tilbúinn. Spretturinn endaði á því að við gerðum virtual vending machine sem að við tengdum inn á kerfið og fengum upplýsingar hjá þannig að við vorum með bæði vending machine og coffee machine tengdar við kerfið á sama tíma. Vinna í klukkustundum í spretti: 158. Sögupunktar kláraðir í spretti: 104


Vor 2017

8.7 Sprettur 6 Vika 20.Apríl - 26.Apríl. Nánast öll virkni kerfisins er kominn og því var farið í það að tengja Power BI við kerfið en það er tól sem hjálpar við sjónræna birtingu á gögnunum sem að eru í gagnagrunninum með því að skila þeim sem gröfum eða ritum. Einnig var unnið að því að klára mikilvæga fítusa í kerfinu sem átti eftir að ganga algjörlega frá. Allar A og B kröfur kláruðust í lok þessa spretts og því var kominn mikil ró yfir hópinn yfir því að verkefnið væri komið á góðan stað og það yrði ekkert stress á lokametrunum. Vinna í klukkustundum í spretti: 192. Sögupunktar kláraðir í spretti: 62


Vor 2017

8.8 Sprettur 7 Vika 27.Apríl - 3.Maí. Tíma var varið í að fínpússa þá virkni sem kominn var í stað þess að dýfa sér ofan í nýjar stórar útfærslur þar sem stutt var í stöðufund þar sem að ákveðið “feature freeze” er sett á. Síðustu dögunum fyrir stöðufund var eytt í að uppfæra skýrsluna og útbúa rekstrarhandbók og notendahandbók ásamt því að undirbúa kynninguna sem verður haldin á stöðufundinum. Reynt var að hafa kynninguna mjög svipaða lokakynningunni til þess að fá góða endurgjöf og æfingu. Mesti munur á milli kynningu á stöðufundi og lokakynningu verður að á stöðufundinum er grafið aðeins dýpra í tæknileg atriði. Vinna í klukkustundum í spretti: 175. Sögupunktar kláraðir í spretti: 42


Vor 2017

8.9 Sprettur 8 Vika 4.Maí - 12.Maí. Byrjun þessa spretts fór í það að vinna í þeirri endurgjöf sem við fengum frá síðasta stöðufundi. Mikið af því sem þurfti að laga var tengt skýrslunni og notendahandbókinni en almennt séð var kynningin og demo-ið á góðum stað. Við ákváðum þó í samráði við leiðbeinandann okkar að gera demo-ið aðeins skýrara með því að breyta handritinu. Hver og einn verður með sitt hlutverk sem ákveðin notandi kerfisins og munum við útskýra betur hvað hver og einn notandi getur gert. Við kláruðum einnig það sem við áttum eftir að gera af einingarprófum, bæði í framendanum en einnig í þjónustum í bakendanum. Vinna í klukkustundum í spretti: 182. Sögupunktar kláraðir í spretti: 36


Vor 2017

9. Samantekt Þrátt fyrir erfiða byrjun þá gekk verkefnið mjög vel. Hópurinn komst á gott skrið og hélt því alveg fram að skilum. Verkefnið var mjög skemmtilegt þannig auðvelt var að eyða miklum tíma í það og endaði hópurinn í 1345 tímum.

+ Í gegnum verkefnið voru margar breytingar gerðar á kerfinu og er upprunalega mynd kerfisins gjörólík lokamyndinni. Hópurinn var mjög opinn fyrir breytingum og utanaðkomandi hugmyndum og var miklum tíma eytt í að betrumbæta kerfið. Hópurinn er mjög ánægður með niðurstöðu verkefnisins og teljum við okkur hafa lært gríðarlega mikið af því. Hér fyrir neðan sést svo heildar burndown tafla fyrir verkefnið


Vor 2017


Vor 2017

10. Rekstrarhandbók Þessi kafli mun vera á ensku þar sem þessi skjölun er einnig fyrir fyrirtækið en LS Retail krefst þess að öll skjöl séu á ensku.

10.1. Introduction This Manual goes into detail about the different components of the system and the prerequisites required to launch them. The system is quite complicated and made from several different components so a chapter will be dedicated to each one. The database schema and information about the database will also be listed in a single chapter, PowerBI will be included in the same way.

10.2. Web Server

10.2.1 General Info The Web Server is a REST API developed in C# .NET Core. It is a middle component that fetches data from the database and forwards it onwards to the web client. The Web Server also makes any changes, requested by the web client, to the database, like removing or modifying a device.

10.2.2 Prerequisites Since the Web Server is developed in .NET Core you will need .NET Core 1.1 and the .NET Core SDK to be able to run the Web Server. .NET Core can be found here: https://www.microsoft.com/net/download/core#/sdk or when installing Visual Studio 2017, you can check ".NET Core cross-platform development" and it will get installed.

10.3. Data Provider

10.3.1 General Info The Data Provider is a REST API developed in C# .NET Core. It’s purpose is to store the information received from the Info Server to the database and send out notifications to notification subscribers. The Data Provider supports three kinds of devices which are coffee machines, vending machines and a basic device which has no information except its status.


https://www.microsoft.com/net/download/core#/sdk

Vor 2017

10.3.2 Prerequisites Since the Data Provider is developed in .NET Core you will need .NET Core 1.1 and the .NET Core SDK to be able to run the Data Provider. .NET Core can be found here: https://www.microsoft.com/net/download/core#/sdk or when installing Visual Studio 2017, you can check ".NET Core cross-platform development" and it will get installed.

10.4. Info Server

10.4.1 General Info The Info Server is a component that is only used to pull information from modules and send them over to the data provider. The idea behind having this component is so that the data provider never has to know about any stations and does not have the ability to pull any information from servers within each station. This is both more convenient and safer. The info server gets a list of module IP addresses, each owning another list of device IP addresses, from the data provider. The server runs through the list of module IPs and sends that module its device list. The response from the module is an object containing all information about the modules devices. The Info server then sends that object to the data provider. The Info server is completely dumb and the only thing it knows is its station number, which has to be pre-determined and configured into the server.

10.4.2 Prerequisites The Server is written in Python 3.5 and has no other dependencies. The server needs to be pre-set to the station it is meant for. Each Info Server has a variable that specifies the station number. The station number is chosen when the administrator creates the station in the database. Python 3.5 can be found here: https://www.python.org/downloads/ , if an earlier version is installed it is highly recommended to upgrade python to version 3.5

10.5. Modules

10.5.1 General Info There is one module for each type of device. The module knows how to communicate with its devices and takes all info available and wraps it into an object. When the module is done talking to all devices in its list, it wraps all objects into one large object and returns it to the info server. If a device is unreachable for some reason, the module sets the status of the device to offline and creates an object with only the status and IP address of the device.


https://www.python.org/downloads/

https://www.microsoft.com/net/download/core#/sdk

Vor 2017

10.5.2 Prerequisites The modules are written in Python 3.5, which needs to be installed. They depend on Flask and Requests, both need to be installed also. If you have PIP package manager installed, all you need to do is “pip install Flask” and “pip install Requests”. Otherwise, Flask can be downloaded from: http://flask.pocoo.org/ and Requests downloaded from: http://docs.python-requests.org Python 3.5 can be found here: https://www.python.org/downloads/ , if an earlier version is installed it is highly recommended to upgrade python to version 3.5

10.5.3 Module types Each module is designed to communicate with a specific type of device, so the modules can vary quite a lot. In this system we have a vending machine module and a coffee machine module. The coffee machine module calls each coffee machine for information on basics, which includes model and manufacturer as well as warning and error information, and it asks for sales numbers for the device. The vending machine module calls each vending machine for information on basics, like the coffee module, sales numbers and stock status.

10.6. Devices

10.6.1 General Info All of the devices used for the system are mocked programs created using python scripts. They are kept as simple as possible while still offering as much data as possible in a reasonable way. These devices communicate with the modules to share their data.

10.6.2 Prerequisites To launch a mock device all you need is Python 3.5. You can run devices independently and you can run as many of them as you want at the same time, they are completely unaware of each other and do not interact. All you need to do is configure them to run on different ports. This is done by changing the last line of code in each device, which is the port number. Python 3.5 can be found here: https://www.python.org/downloads/ , if an earlier version is installed it is highly recommended to upgrade python to version 3.5

10.6.3 Device types In theory the system should handle any type of device but for practical purposes we are using Coffee Machines and vending machines which both implement a basic device interface which will be required for any future created devices.


http://docs.python-requests.org/


http://flask.pocoo.org/


Vor 2017

10.6.3.1 Coffee Machine The coffee machine contains information about warning and error messages and basic info about the machine, such as the manufacturer and model number. It also contains information about the number of sales for each type of coffee. There are API functions that work with an interface for the coffee machine so that you can interact with it, virtual buttons and such. There is also an API to turn the machine off and on.

10.6.3.2 Vending Machine The vending machine has information about sales, stock and warning and error messages. There is also API to buy items in the device and to turn the device off and on. The Device also contains all basic information about itself, such as the manufacturer.

10.7. Database

10.7.1 General Info The database used is an Azure cloud service to both ensure reliable access from anywhere but also because we had easy access to one. The database can easily be substituted by a different one, as is proven by the systems unit tests where an in-memory mock of the database is used.

10.7.2 Prerequisites The database is hosted by Microsoft Azure so there are no special prerequisites assuming web server and data provider are already runnable.

10.7.2 Schema The Schema can be found in chapter 6.3


Vor 2017

10.8.Power BI

10.8.1 General Info Power BI is a Microsoft data analytics tool that is used to visualize the data in our database and provide an effective and stylish way for users, especially office users, to look at the data and analyze it themselves. The system uses Iframes to display the data from the power BI services websites, this way you can still use all of the functionality that the Power BI service provides.

10.8.2 Prerequisites There are no prerequisites required as the service is connected to the database and works directly on the data from there. The only requirement is having the power BI report views that are used by the UI available, they are connected to an account provided with the system.

10.8.3 Links ● A report that shows overall statistics for all the stations:

https://app.powerbi.com/view?r=eyJrIjoiZWI4MjEzZjQtNmM4MC00Yzg1LWJiOTAtZDUxOWQ5ZDdiNzU5IiwidCI6Ijk0ZDkyYjYwLWU2ZmEtNDNjMC04MDA1LWU3M2UwMjgxMmMzNCIsImMiOjh9

● A report that shows statistics for the headquarters station: https://app.powerbi.com/view?r=eyJrIjoiY2MzNGUwYWMtZDdkZC00MWM1LTk4ZWEtMmRjNGZmNWFlNDA0IiwidCI6Ijk0ZDkyYjYwLWU2ZmEtNDNjMC04MDA1LWU3M2UwMjgxMmMzNCIsImMiOjh9

● A report that shows statistics for the LS Retail station: https://app.powerbi.com/view?r=eyJrIjoiOGFlM2RmZWYtNzRmZi00M2M3LTllMTktMzNiNjY2MWNjNTI3IiwidCI6Ijk0ZDkyYjYwLWU2ZmEtNDNjMC04MDA1LWU3M2UwMjgxMmMzNCIsImMiOjh9


https://app.powerbi.com/view?r=eyJrIjoiOGFlM2RmZWYtNzRmZi00M2M3LTllMTktMzNiNjY2MWNjNTI3IiwidCI6Ijk0ZDkyYjYwLWU2ZmEtNDNjMC04MDA1LWU3M2UwMjgxMmMzNCIsImMiOjh9

https://app.powerbi.com/view?r=eyJrIjoiY2MzNGUwYWMtZDdkZC00MWM1LTk4ZWEtMmRjNGZmNWFlNDA0IiwidCI6Ijk0ZDkyYjYwLWU2ZmEtNDNjMC04MDA1LWU3M2UwMjgxMmMzNCIsImMiOjh9








Vor 2017

10.9 APIs

10.9.1 Web Server Authentication:

● [POST] api/login - Used to verify if a given user and password is registered in the database and returns the user object if it is found

● [POST] api/register/user - Creates a new user in the database ● [POST] api/register/station - Creates a new station in the database

Power BI:

● [GET] api/powerbi - Returns a link to a Power BI report for all the stations in the database

● [GET] api/powerbi/stations/{stationID:int} - Returns a link to a Power BI report for a given station id

Basic Service: ● [GET] /api/devices - Returns a list of device objects in the database

Example of output:

[ { "id": 26, "stationID": 1, "stationName": "Headquarters", "ipAddress": "http://localhost:3000", "deviceType": 1, "deviceTypeName": "Coffee", "statusCode": "OK", "name": "Coffee 1" }, { "id": 31, "stationID": 1, "stationName": "Headquarters", "ipAddress": "http://localhost:3500", "deviceType": 2, "deviceTypeName": "Vending", "statusCode": "OK", "name": "Vending 1" } ]


Vor 2017

● [POST] /api/devices - Creates a new device in the database ● [PUT] /api/devices/{deviceID:int} - Modifies information about a device for a given id ● [DELETE] /api/devices/{id:int} - Deletes a device with a given id from the database ● [GET] /api/devices/{deviceID:int}/statuses - Returns statistics on the status of the device ● [GET] /api/stations - Returns a list of station objects in the database ● [GET] /api/stations/{stationID:int} - Returns a station object for the given id ● [PUT] /api/stations/{stationID:int} - Modifies information about a station for a given id ● [DELETE] /api/stations/{stationID:int} - Deletes a station with a given id from the

database ● [GET] /api/modules - Returns a list of module objects in the database ● [POST] /api/modules - Creates a new module in the database ● [GET] /api/modules/{moduleID:int} - Returns a modules object for the given id ● [PUT] /api/modules/{moduleID:int} - Modifies information about a module for a given id ● [DELETE] /api/modules/{moduleID:int} - Deletes a module with a given id from the

database

Coffee Machines Service: ● [GET] api/coffee/machines - Returns a list of all the coffee machine objects in the

database Example of output:

[ { "id": 26, "manufacturer": "Senseo", "modelNr": "12345", "stationID": 1, "name": "Coffee 1" } ]

● [GET ]api/coffee/machines/{machineID:int} - Returns a more detailed information about a

single coffee machine in the database with a given id ● [GET] api/coffee/machines/{machineID:int}/sales - Return a sales object for a single

coffee machine in the database sorted by day, month, year and overall sales


Vor 2017

Vending Machines Service: ● [GET] api/vending/machines - Returns a list of all the vending machine objects in the

database Example of output:

[ { "id": 31, "manufacturer": "Samsung", "stationID": 1, "name": "Vending 1" } ]

● [GET] api/vending/machines/{machineID:int} - Returns a more detailed information about

a single vending machine in the database with a given id ● [GET] api/vending/machines/{machineID:int}/sales - Return a sales object for a single

vending machine in the database sorted by day, month, year and overall sales

10.9.2 Data Provider ● [GET] /api/station/{stationID:int}/devices - Returns a dictionary with a module IP address

and a list of corresponding device type devices IP addresses from a station. ● [POST] /api/devices/type/0 - Stores information about basic devices ● [POST] /api/devices/type/1 - Stores information about coffee machines ● [POST] /api/devices/type/2 - Stores information about vending machines

10.9.3 Modules ● [POST] /info - This is what the info server calls to post IP addresses and the module

returns the object of all device info

10.9.4 Devices ● [GET] /info - Module calls this to get all basic info and status of device, both vending

machine and coffee machine have this ● [GET] /sales - Module calls this to get all sale info from both coffee machine and vending

machine ● [GET] /stock - Vending Machine module calls this to get stock numbers from vending

machine


Vor 2017

10.10 Adding support for a new device type This chapter explains how to add support for a new device type to the system. The first thing to do is to read the previous chapters to get an understanding about how the system works. The best place to start adding support is the database and work from there.

10.10.1 Add support to database The first thing to do is to add a new entry to the table DeviceTypes and from there the device type gets its unique device type id. The next thing to do is to familiarize yourself with the information the new device type has to offer and what information you want stored in the database.

All new devices are registered in the table Devices and get their ID from there. All extra information about the device has to be registered in another device type specific table which has a foreign key that references to the ID column in the table Devices, for example the CoffeMachines table has more detailed information about the device such as the manufacturer and model number and references the ID in the Devices table. The other tables for the coffee machine support such as its sales then references to the ID in the CoffeeMachines table. Other than adding the foreign key constraint to the new device table, the table design for the new device type is completely open.

10.10.2 Create a new module The module is the gateway for the system to communicate with the device type, so to be able to create a module you have to understand how to get information from the device. The module has to know how to communicate with the device and know how the device delivers data.

The module gets a POST request from the info server containing a list of IP addresses of the devices which it is to get data from. For each IP address in the list, the module sends a GET request for information to the device. Depending on the type of module, the number of GET calls and the information they hold, is different. The module wraps all the information it gathers into one object and appends it into an object list of all its devices. When the module has requested information from all its devices, it returns the list of objects with the response to the Info Servers POST request. The module needs to be prepared for devices to be unavailable for any reason. When a module has an unavailable device, the status of the device is set to 3 (offline state) and the module adds information about the devices IP address into the object it creates for it. This then goes into the list of device objects, just like any online device.


Vor 2017

10.10.3 Add support to Data Provider The Data Provider implementation should know how to receive the data delivered from the module and store them in the database.

It is a REST API and has one controller to handle requests and to add support to the controller you have to add a POST function on the URL “devices/type/{devicetypeid}”, where the devicetypeid is the ID of the new device type generated in the table DeviceTypes. It accepts a dynamic model which is cast to a viewmodel which contains the station ID and a list of device informations. Familiarize yourself with the inherits and setup of the viewmodels since they all inherit from the basic device viewmodels to be able to use the standard BasicInfoService functions.

The next step is to create a service for the new device type that can handle the device specific informations and the necessary entities that map to the new tables in the database. The new service has to inherit the BasicInfoService class to get all the necessary basic functions and the db context. The new service has to call the UpdateStatus function from the BasicInfoService with the right parameters for each device in the device list to update its status in the Devices table and send out notifications if needed. Other than that, the services purpose is to update/add all the information wanted to the database.

10.10.4 The Web Server The web server is also a REST API and its purpose is to interact with the system, for example to access the data in the database for the front end to display to the users. The web server has a controller for each type of device so to be able to get data about the new device type you have to create a new controller that handles all the requests for the new device type, such as getting specific information about it. It is set up in a way that all the data delivered to the server is in a viewmodel and all the data sent from the server is in a DTO. Those can be found in the Models folder in the project.

The Web Server also has a device type specific service that contains the logic for the device type and the same goes for the Web Server as the Data Provider where the new service has to inherit the BasicInfoService class for the same reason as the Data Provider. It is also necessary to add the new entities to the Web Server so the EntityFrameworkCore can map it to the database. From there the implementation of the new service is just based on what information is needed in or out to function as wanted.


Vor 2017


Vor 2017

11. Notendahandbók Þessi kafli mun einnig vera á ensku þar sem þessi skjölun er einnig fyrir fyrirtækið sem krefst þess að öll skjöl séu á ensku.

11.1. Introduction to the system Before you can use this system, you need to have an account to log in with. When you have that, you can use the system to get real time feedback on all your connected devices. Whether you are an office user who wants to see sales statistics and error frequencies of devices in all of your stations, or you are a station user that wants to get real time info on the status of your devices, the system will be of much help. An administrator will have to set up accounts, stations and modules before the system can do any real work. In the following guide, each part of the system is well explained for each type of user.


Vor 2017

11.2. Basic Usage

11.2.1 Add device Both Admins and Station users can add a new device, this is the dialog that will pop up when adding a new device. All fields need to be filled out.

11.2.2 Add station This is the module that is shown when adding a new station, only Admins can add new stations. All fields need to be filled out.


Vor 2017

11.2.3 Add Module This is the dialog that is shown when adding a new module, only Admins can add a new module. All fields need to be filled out.

11.2.4 Edit This icon is a button that allows you to edit various components.

11.2.4.1 Edit Device All user types can edit a device and this is the module that is shown when editing. It is possible to change the name, the station, the IP address and the device type.


Vor 2017

11.2.4.2 Edit Module Only the admin user can edit a module and this is the dialog that will pop up when editing. The Device type, the IP Address and station can be edited.

11.2.4.3 Edit Station Only the admin user can edit a station and this is the dialog that will pop up when editing. The name and address can be edited.

11.2.5 Delete This icon allows you to delete a component.

When it’s clicked, a module will pop up to confirm that you want to delete


Vor 2017

11.3. Admin User When you have signed in as a admin user, you get this front page where you can manage all the stations, modules and devices registered in the system as well as see all the subscriptions:

11.3.1 See Register From the front page, select “Register”. There you can create new user to the system, either as a office user or a separate station user:


Vor 2017

11.4. Office User When you have signed in as a office user, you get this front page where you can select from a Power BI data analysis page or navigate to a page where you get a list of all devices in stations:

11.4.1 See Analysis From the front page, select “Power BI analysis”. On the analysis page you get a report from Power BI where you can select to either see reports and data from all the stations or from a single station. In those reports you can see overall sales of coffee cups and vending sales and sort those sales by type and time:


Vor 2017

11.4.2 See Devices From the front page select “Devices”. On the devices page you get a list of all the station registered. There you can select a single station and get a list of all the devices registered to that station. From there you can select a single device to get more details (see next section):

11.4.2.1 See Device Details To see more details about a device, simply click on that device and details window will drop down. There you can see information about the device such as its sales or status statistics. The status pie chart shows you in percentages the status history of that device.


Vor 2017

11.5. Station User When you have signed in as a station user, you get this front page where you can select from a Power BI data analysis page or navigate to a page where you get a list of all devices in stations.

11.5.1 See analysis From the front page, select “Power BI analysis”. You will see information from devices in your station such as the sale numbers over time or in total in visual graphs.


Vor 2017

11.5.2 See your devices From the front page select “Devices”. There you will see a list of all your devices, next to the device icon you can see the status icon of that device. On the right side you can choose to edit that device or delete it and below the list is an option to add a device.

11.5.2.1 See device details To see more details about a device, simply click on that device and details window will drop down. There you can see information about the device such as its sales or status statistics. The status pie chart shows you in percentages the status history of that device.


Vor 2017

11.5.3 Subscriptions From either of the previous pages, you can view the station's profile by clicking on “Profile” in the top right corner. There you can see a list of subscriptions, to add a new subscriptions simply click on the “New Subscription” button and fill out the form.

You have to specify what kind of subscription you are registering, i.e. what device type the new subscriber is going to get notified about and of course the email address which is to receive the notifications.


LS Retail - Internet of Things Skýrsla

Documents

Transcript of LS Retail - Internet of Things Skýrsla