Indoor Positioning System (IPS) are becoming more common in many areas such as retail, warehouses, smart facilities, and manufacturing.In recent years, Bluetooth Low Energy (BLE)-based IPS has become increasingly popular due to its low cost and low energy consumption. One of the more recent updates, Bluetooth 5.1, provides the ability to compute the location using Angle of Arrival (AoA) or Angle of Departure (AoD). These new features have allowed for better positioning accuracies, where AoA-based positioning has shown sub-meter accuracy. An application area for BLE-based IPS is retail stores where the technology can benefit both the store and its customers. This thesis investigates how to populate a database to be used with an IPS in a real-life store. The assumption is that customers will have BLE equipped devices and run an application that will send the properly formatted BLE advertisements, such that an BLE IPS can locate the user in the store. Additionally, we assume that the application can use the device's e-compass or other means to determine in which direction the user's device is oriented. Based on the position and orientation of the user, the software is assumed to access a database to know what item(s) are near the customer. However, the question remains of how did this data get into the database? This degree project explores this in detail and assesses the amount of time and effort needed to populate this database and the amount of time and effort needed to keep this database up to date. This project followed an iterative Design Science Research (DSR) methodology where the artifact is the database. A relational database was used as they are widely used and joins can easily be performed and it is easy to modify existing tables. The application was developed in Spring Boot and React. Amazon Web Services (AWS) was used to host and provide the necessary services for the database and application. The result showed that the estimated time needed to populate the database in a supermarket with a sales area of 5300 m2, 36623 products, and 220 containers is 106.64 hours and 107.13 hours in the worst case assuming a walking speed of 1.4 m s-1. Updating a product would take 10.34 s and 10.37 s if the time it takes for a staff member to walk to the place where the product is located is excluded. / Inomhuspositioneringssystem (IPS) har blivit allt vanligare inom många områden. De senaste åren har Bluetooth Low Energy (BLE)-baserad inomhuspositionering blivit mer populärt på grund av egenskaper som låg kostnad och låg energikonsumption. En av de senaste versionerna; Bluetooth 5.1 kan beräkna positionen med hjälp av ankomstvinkeln (eng. Angle of Arrival (AoA)) och utgångsvinkeln (eng. Angle of Departure (AoD)). Angle of Arrival (AoA)-baserad positionering kan uppnå en noggrannhet under 1 m. Ett Bluetooth Low Energy (BLE)-baserat IPS kan tillämpas i butiker där det kan gynna både butikens medarbetare och dess kunder. Detta examensarbete kommer att undersöka hur en databas som ska användas med ett IPS i en butik kan populeras. Antagandet i detta projekt är att kunderna kommer ha BLE utrustade enheter som kör ett program som tillåter att användaren kan lokalisera sig i butiken. Dessutom antar vi att applikationen kan använda enhetens e-kompass eller annan hårdvara för att kunna avgöra i vilken riktning användarens enhet är orienterad. Baserat på användarens position och riktning, antas det att mjukvaran kan komma åt databasen och veta vilka produkter som ligger i närheten av kunden. Dock kvarstår frågan: Hur sparades denna data i databasen? Det här examensarbetet kommer alltså att undersöka hur en databas i en butik kan vara uppbyggd om vi utgår från antagandet att BLE är tillämpat i butiken. Vi kommer även bedöma hur mycket tid som krävs för att populera en databas och hålla denna databas uppdaterad. Ett iterativ arbetsätt tillämpades i examensarbetet. I projektet användes en relationsdatabas eftersom det är enkelt att utföra join-operationer och uppdatera tabbeller i databasen. Applikationen som skapades tillhandahåller funktioner för att spara, uppdatera, radera och söka produkter i databasen. Frontend var kodad i React och backend var kodad i Spring Boot. Amazon Web Services (AWS) molntjänser och deras verktyg användes för att köra applikationen och databasen. Resultatet visade att populera en databas med produkter i en mataffär med en säljyta på 5300 m2, 36623 produkter, och 220 behållare (hyllor, kylskåp, etc.) tog 106.64 timmar i bästa fall och 107.13 timmar i värsta fall om vi antar en gångfart i 1.4 m s-1.

Internet of Things (IoT) är en växande teknologi som spelar en allt större roll i samhället. Den innefattar ett nätverk av internetanslutna enheter som samlar in och utbyter data. Samtidigt som IoT växer uppstår utmaningar kring hantering av stora datamängder och säkerhetsaspekter. Företaget Softhouse står inför utmaningen att välja en effektiv tidsseriedatabas för hantering av temperatur- och geopositionsdata från värmesystem i privata bostäder, där både prestanda och dataintegritet via kryptering är av stor vikt. Detta examensarbete har därför utfört en prestandajämförelse mellan AWSTimestream och InfluxDB, där olika tester har använts för att mäta exekveringstiden för inskrivning av sensordata och databasfrågor. Jämförelsen inkluderar AWS Timestream i krypterad form mot InfluxDB i dess AWS-molnversion i krypterad form, samt InfluxDB AWS i krypterad form mot InfluxDB i okrypterad form. Syftet med studien var att ge riktlinjer för valet av tidsseriedatabaser med fokus på prestanda och säkerhetsaspekter, inklusivekryptering. Studien undersökte även hur valet av rätt databas påverkar företag som Softhouse, både i termer av kvantitativa och kvalitativa fördelar, samt att ge en bedömning av kostnaderna. Resultatet visade att InfluxDB i dess AWS-molnversion generellt presterade bättre än AWS Timestream och InfluxDB i dess standardversion. Det fanns tydliga skillnader i prestanda mellan AWS Timestream och InfluxDB i dess AWS-molnversion, men inte lika tydliga skillnader i prestanda mellan InfluxDB i dess AWS-molnversion och standardversionen. Med hänsyn till både prestanda och säkerhet framstår InfluxDB i dess AWS-molnversion som det mest lämpliga alternativet. Det är emellertid av stor vikt att ta kostnadaspekten i beaktande, då AWS Timestream visar sig vara avsevärt mer kostnadseffektivt än InfluxDB. / The Internet of Things (IoT) is a growing technology that plays an increasingly significant role in society. It encompasses a network of internet-connected devices that collect and exchange data. As IoT continues to expand, challenges arise regarding the management of large volumes of data and security aspects. The company Softhouse faces the challenge of choosing an efficient time-series database for handling temperature and geoposition data from heating systems in homes, where both performance and data integrity through encryption are of great importance. Therefore, this thesis has conducted a performance comparison between AWS Timestream and InfluxDB, using various tests to measure the execution times for data ingestion of sensor data and database queries. The comparison includes AWS Timestream in encrypted form versus InfluxDB in its AWS cloud version in encrypted form, as well as InfluxDB AWS in encrypted form versus InfluxDB in unencrypted form. The aim of the study was to provide guidelines for the selection of time-series databases with a focus on performance and security aspects, including encryption. The study also explored how the choice of the right database affects companies like Softhouse, both in terms of quantitative and qualitative benefits, and provided an assessment of costs. The results showed that InfluxDB in its AWS cloud version generally outperformed AWS Timestream and InfluxDB in its standard version. There were clear performance differences between AWS Timestream and InfluxDB in its AWS cloud version, but not as pronounced differences in performance between InfluxDB in itsAWS cloud version and the standard version. Considering both performance and security, InfluxDB in its AWS cloud version appears to be the most suitable option. However, it is crucial to consider the cost aspect, as AWS Timestream proves to be significantly more cost-effective than InfluxDB.

This thesis deals with the design of a technological demonstrator for data collection in IoT environment. A study of available IoT technologies was made, consisting of a description of available sensors / actuators, data transmission and processing. At the same time, the key components of the demonstrator, the AWS IoT cloud service and the MQTT communication protocol, were described. Based on the IoT technology study, a representative set of technological demonstrator elements was designed. Its functionality has been experimentally verified using the ESP8266 and ESP32 WiFi modules using Mongoose-os firmware. The result is a demonstrator of IoT data collection designed for usage in an Smart House.

In this thesis, a scalable, highly available and reactive RabbitMQ cluster is implemented on Amazon Web Services (AWS) and Microsoft Azure. An alternative solution was created on AWS using the CloudFormation service. These solutions are performance tested using the RabbitMQ PerfTest tool by simulating high loads with varied parameters. The test results are used to analyze the throughput and price-performance ratio for a chosen set of instances on the respective cloud platforms. How performance changes between instance family types and cloud platforms is tested and discussed. Additional conclusions are presented regarding the general performance differences in infrastructure between AWS and Microsoft Azure.

DH Anticounterfeit, a company working against counterfeit products, has a mobile application that lacks a proper back-end system to handle and store DH Anticounterfeits data. There are plenty of ways to go about to x this problem, but this thesis is focused on the development of a REST API that will be replacing the non-existent system. The main goal is to create the API and run it within a containerized environment using Docker. The whole system should run on Amazon Web Services, that will be working as a server to keep the system going at all times. Nowadays, security is important due to plenty of ways to attack a system, which is why security and authorization will be a high priority. The result will be a well-functioning, high security system that uses MongoDB database to store and process data in a secure way.

No description available.

This thesis explores the creation of a scaling, containerized, advertisement server that will be used by Gold Town Games AB to better integrate ads into their application(s). The server is built as a Docker image that will be used to create server instances on AWS Elastic Container Service for automatic scaling and server resource configuration. The server was created with the intention that GTG will have full control over what advertisements are shown in their application(s) and to seamlessly integrate sponsored logos onto jerseys or sports fields. This will not only serve as a source of income with advertisers paying for ad space, but it will also make the game elements more realistic as we have come to expect teams and stadiums to be sponsored and plastered with company logos. Another important part when displaying advertisement is to track statistics for the ads, since without a way to show advertisers that their ads are shown and that they are generating engagement it is very hard to sell the ad space. / Detta examensarbete utforskar skapandet av en skalbar, containerbaserad, reklamserver som kommer användas av Gold Town Games AB för att integrera reklam i deras applikation(er). Servern är byggd som en Docker-bild som används för att skapa instanser på AWS Elastic Container Service för automatisk skalning och serverresurshantering. Servern är utvecklad med tanken att GTG ska ha full kontroll över vilken reklam som visas i deras applikation(er) och för att kunna lägga till sponsrade loggor på matchtröjor och i arenor. Detta är inte bara en extra form av inkomst, då annonsörer betalar för reklamplatser, utan hjälper även till att få delar av spelen att kännas mer realistiska då vi är vana att lag och arenor är sponsrade och fulla av företagsloggor. En annan viktig del när man visar reklam är att kunna spara statistik för den, eftersom det skulle vara väldigt svårt att sälja reklamplatser utan att kunna visa att folk faktiskt ser reklamen.

Rapporten behandlar utvecklingen av ett system som möjliggör för rapportering och granskning av avfallsdata. Systemet består av en mobilapplikation och en webbapplikation som utvecklats med React Native respektive React, en databas som utvecklats med MySQL och en back-end bestående av tjänster som erbjuds av Amazon Web Services. I AWS används tjänster som tillåter hantering av mobilapplikation, webbapplikation, databas och användare. Systemet utvecklades av åtta studenter vid Tekniska högskolan vid Linköpings universitet på uppdrag av det australiensiska företaget EcCell. Projektet resulterade i framtagningen av produkten Trace the Waste med nästan alla önskade funktionaliteter. I rapporten diskuteras även vad som hade kunnat göras annorlunda i utvecklingen med hjälp av andra verktyg. Rapporten drar slutsatser om bland annat varför produkten ger värde för kunden och hur den agila arbetsmetoden Scrum påverkat studenternas arbete under distansläge. Varje student har också skrivit ett individuellt bidrag där olika områden relaterade till projektet utreds. Bidragen finns i slutet av rapporten.

Purpose – The purpose of this study is partly to illustrate how the AES encryption methods ECB and CTR affect the computational speed when using the GPGPU framework Cuda, but also to clarify the advantages and disadvantages between the different AES encryption modes. Method – A preliminary study was conducted to obtain empirical data on the AES encryption modes ECB and CTR. Data from the study has been analyzed and compared to determine the various aspects of the AES encryption modes and to create a basis for determining the advantages and disadvantages between them. The preliminary study has been carried out systematically by finding scientific works by searching databases within the subject. An experiment has been used as a method to be able to extract execution time data for the GPGPU framework Cuda when processing the AES encryption modes. Experiment were chosen as a method to gain control over the variables included in the study and to see how these variables change when they are consciously influenced. Findings – The findings of the preliminary study show that CTR is more secure than the ECB, but also considerably more complex, which can lead to integrity risks when implementation is done incorrectly. In the experiment, computational speeds are produced when the CPU memory sends to the GPU memory, the encryption on the GPU and how long it takes for the GPU memory to send to the CPU memory. This is done for both CTR and ECB in encryption and decryption. The result of the analysis shows that the ECB is faster than CTR in encryption and decryption. The calculation speed is higher with the ECB compared to the CTR. Implications – The experiment shows that CTR is slower than the ECB. But the most amount of time spent in encryption for both modes are the transfers between the CPU memory and the GPU memory. Limitations – The file sizes of the files tested only goes up to about 1 gigabyte which gave small computation times.

Microservice architectures are the base of modern cloud applications. With the adoption of microservices, application teams manage to reduce codebase complexity and write more modular services that can run inter-dependently. Despite all the advantages offered by microservices over monolithic architectures, they introduce additional complexities, such as handling inter-service communication, ensuring security, introducing traceability, and achieving acceptable performance. To manage all these microservices, the orchestrator tool Kubernetes has shown promising results, but it is not sufficient to tackle all the cross-cutting concerns of the applications. With more complex architectures, it becomes difficult to troubleshoot and trace inter-service application programming interface calls. For this purpose, the service mesh technology emerged and is being introduced in many companies. There are different implementations available for service mesh, with some being more compatible with specific cloud providers than others. The selection of an adequate service mesh shapes the entire application deployment process. If chosen wrongly, it might introduce further complexities or performance losses. This thesis investigates ways to make this decision more efficiently. It takes into account the company’s needs of service mesh and compares implementations to meet performance expectations with minimal deployment efforts. Specially, we perform different testing scenarios to compare AWS cloud specific, AWS App Mesh with most widely used, Istio service mesh. The outcome suggests that AWS App Mesh performs consistently for all cases with acceptable latency ranges, but, Istio outperforms AWS App Mesh under standard conditions, such as high but manageable request load on the application. In addition, Istio can achieve the same deployment with less lines of code as compared to that of AWS App Mesh. On the other hand, resource utilization by these service meshes is found to be a non-conclusive factor for selecting the service mesh implementation. With these outcomes, application teams can make more well-informed decisions to run the production-grade workloads with an efficient service mesh implementation. / Mikroservicearkitekturer är basen för moderna containerapplikationer. Med antagandet av mikrotjänster lyckas applikationsteam minska kodbaskomplexiteten och skriva fler modulära tjänster som kan köras beroende av varandra. Trots alla fördelar som mikrotjänster erbjuder framför monolitiska arkitekturer, introducerar de ytterligare komplexitet, såsom kommunikation mellan tjänster, säkerhet, spårbarhet och prestanda. För att hantera alla dessa mikrotjänster har orkestreringsverktyget Kubernetes visat lovande resultat, men det är inte tillräckligt för att ta itu med alla övergripande problem med applikationerna. Med mer komplexa arkitekturer blir det svårt att felsöka och få synlighet i mikrotjänster. För detta ändamål växte servicemesh-tekniken fram och introduceras i många företag. Det finns olika implementeringar tillgängliga för servicemesh, där vissa är mer kompatibla med specifika molnleverantörer än andra. Valet av ett adekvat servicenät formar hela applikationsdistributionsprocessen. Om det väljs fel kan det leda till ytterligare komplexitet eller prestandaförluster. Denna avhandling undersöker sätt att göra detta beslut mer effektivt. Den tar hänsyn till företagets behov av servicenät och jämför implementeringar för att möta prestandaförväntningar med minimala implementeringsinsatser. Speciellt genomför vi olika scenarier för prestandatestning för att jämföra AWS App Mesh med Istio servicemesh. Resultatet tyder på att AWS App Mesh presterar konsekvent för alla fall med acceptabla latensintervall, men Istio överträffar AWS App Mesh under standardförhållanden, såsom hög men hanterbar förfrågningsbelastning på applikationen. Istio kan uppnå samma distribution med färre rader kod jämfört med AWS App Mesh. Resursutnyttjande av dessa tjänstenät har visat sig vara en icke avgörande faktor för val av tjänstenätimplementering. Med dessa utfall kan företaget där detta examensarbete genomförs, Infor (Sweden) AB, fatta mer välinformerade beslut för att driva de produktionsmässiga arbetsbelastningarna med en effektiv implementering av servicenät.