Creating a Digital Twin by Using Real World Sensors

(1)

Datateknik C, Examensarbete, 15 högskolepoäng

CREATING A DIGITAL TWIN BY USING

REAL WORLD SENSORS

Nedim Efendic

Dataingenjörsprogrammet, 180 högskolepoäng Örebro höstterminen 2020

Örebro universitet Örebro University

Institutionen för School of Science and Technology naturvetenskap och teknik SE-701 82 Örebro, Sweden

(2)

Abstract

Örebro University and Akademiska Hus have started an initiative towards smart buildings. A very important role to this is Digital Twin for buildings. Digital twin for buildings is a virtual copy of a physical building. And by adding a Data Driven Simulation System, an even more smart building could be achieved. Given a humidity-, temperature-, illuminance- and motion sensor in a specific corridor at the Örebro University, this thesis will ascertain what can be done by creating a Data Driven Simulation System and using these sensors to achieve the desired smart building. In this thesis, a simulation was created with simulated sensors and pedestrians. The simulation is a clone of the real world, by using real life sensors and applying the data to the simulated sensors, this was partially achieved.

(3)

1 Introduction

1.1 Introducing the background of the project

An owner of the buildings of Örebro University and Akademiska Hus in Örebro has started an initiative towards smart buildings. The reason for this is to have smarter climate controls in the buildings, as well as a more efficient energy consumption with the goal of having no unnecessary costs and environmental emissions.

To achieve this, sensors have been placed. The sensors that will be used in this thesis are humidity-, illuminance-, temperature- and motions sensors.

This thesis will ascertain what can be done with the sensors to achieve the desired smart building. This thesis is a basis for further development of the building.

1.2 Introducing the project

The goal of this project was to create a simulation and a Digital Twin of a specific corridor at the Örebro University (ORU). By reading the sensor data in the real world in that specific corridor, this could be achieved.

The simulation was created in the Unity Game Engine and programming language C#, using Unity 3D Development platform1_{and Visual Studio}2_.

This specific corridor was chosen because it is a part of the smart buildings initiative that ORU and Akademiska Hus has started, and because there was available data readings from the sensors in that corridor that could be used in the simulation.

Unity and C# was chosen since Unity is a very user friendly platform where both simple and complex creations could be achieved and Visual Studio and C# has good interplay with Unity. Hence why this project was possible to create. The author of this thesis has also good

knowledge in both Unity and C#.

This digital twin and simulation could later be used to experiment and gather data from the simulation. The given data from the simulation would be humidity, illuminance, temperature and motion. The original idea was to create a live-feed simulation from the given data from the real world sensors. Which means that the data from the sensors would need to be accurate, detailed and frequent. In this case, they were not.

The purpose of this was to visualize the state of the real world by reading the real world sensors. Visualizing this helps to get a better understanding of the data that the sensors in the

2_{Visual Studio}

https://visualstudio.microsoft.com/

1_{Unity, Unity Real-Time Development Platform.}

(6)

real world output. This simulation would also be used to experiment and test new solutions, as in efficiency and funds, that would later be implemented in the real world to improve.

The data gathered from the simulated sensors (temperature-, humidity-, illuminance- and motion sensors) will be logged in the same way that matches the real world sensors. In this log; motion, illuminance, humidity and temperature is stored.

(7)

1.3 Objectives for the project

What should be done by the end of the project:

● Create a specific corridor with the proper dimensions from Örebro University in Unity editor.

By physically measuring the specific corridor using a laser measurement tool, for most accurate readings, this was successfully created.

● In this corridor, create a live-feed simulation of the real world.

○ Simulation includes; simulated sensors (identical to the real world), simulated pedestrians.

For creating simulated sensors, models are needed to be developed for each of the data sources.

○ To be able to create motion sensors, where motion is being read, simulated pedestrians need to be created. This was successfully created.

○ To be able to create illuminance sensors, where the amount of light is being read, light sources need to be created. This was not successfully created. ○ To be able to create temperature sensors, where temperature is being read, heat

sources would need to be created. This was not successfully created.

○ To be able to create humidity sensors, where humidity is being read, humidity sources would need to be created. This was not successfully created.

Creating a live-feed simulation of the real world was not possible, the main reason was due to the insufficient data output from the real world sensors.

● Sensor readings from the simulated sensors should be simulated to sensor logs from the real world sensors.

By examining the real world sensor data logs, this was successfully created.

● Simulation should visualize the real world, according to the real world sensor data. By creating this simulation in a 3D real-time development platform and examining real world sensor data, this was partially successfully created.

(8)

2 Background

In the following, this chapter introduces the current state of “Digital Twins” and “Dynamic Data Driven Simulations Systems”.

2.1 Digital Twin of a building

A Digital twin (DT) is a digital visual representation of something in the physical world. Just as the name states, it is a twin (copy) of something in the physical world, but created

digitally. [1,2] This thesis will mainly focus on Digital twins for buildings. 2.1.1 What is Digital Twin of a building

A DT of a building is, as mentioned, a digital visual representation of something in the physical world. In this case, it is a building that records and stores information and data about the building in question using different types of sensors. Different types of sensors could be temperature sensor, humidity sensor, motion sensor that tracks pedestrians and so on. In some cases, Building Information Model (BIM) is used to create a digital twin. BIM is a virtual 3D model of a physical building. BIM also holds information of the buildings design and construction and the buildings lifecycle. [3] BIM is similar to a Digital twin. While digital twin is more focused on the people in the environment, in a way that actions are taken for user satisfaction. This is where dynamic information is essential. To be able to satisfy the user, real time information must be provided. BIM is more focused on building information and

construction, and in this case, static information is essential.

Since today's society is more digital than ever, it does make sense to have a digital twin of a building that outputs its state through different sensor readings that contain several thousands lines of code.

To create a proper Digital Twin is a lot of work. Since a lot of different complex tasks are required. The most severe part is to combine and interconnect the physical- and virtual world all together. Logical models would need to be implemented (which is similar to “rules and guidelines” in the system), Physical-virtual connections (example, how would you connect your physical sensors to your virtual simulation sensors), and different kinds of data like (realtime data, execution feedback, simulation results and so on). [1]

2.1.2 Sensors and enabling technology

As mentioned previously. Different logical models need to be implemented, as well as

different connections. These logical models and connections are done by using different types of real world sensors. Typical sensors and sensors used in this thesis will be from motion sensors, temperature sensors, humidity sensors and illuminance sensors.

Logical models are schemes that tell how and what a program or software should do in different scenarios. An example could be that if a room has a too high temperature, then the heating system should be lowered for that room. These logical models are programmed in

(9)

various softwares, and are using data from real world sensors by connecting them to the software.

As mentioned before, these connections are needed to be able to create a DT, since the digital building and physical building has a clear correlation. Physical to virtual connections, and vice versa, provide the possibility for an interaction between the two. A lot of simpler systems use bluetooth for the connectivity between sensors and programs. The most popular way today is using IoT, because of the efficiency and availability.

With the help of Internet of Things (IoT) and sensor technology, these connections could be achieved. Internet of Things is a network filled with various devices with various softwares. The “network” refers to the Internet, where these devices are connected. These physical objects called devices are referred to as the “Things”. These things often use some kind of sensors in various mobile devices, safety devices, medical devices and so on. [4]

The Internet of Things plays a huge role for DTs, since most communications applications and softwares for DTs communicate through IoT. This means that IoT is a great bridge between the physical world and the digital world. In the sense that we use physical objects with digital technology, that can read real-world events and display them in a software.

The structure of an IoT system for a DTs can be quite simple. Requirements for an IoT system, in this case, would be devices with sensors, connection and a program. There are two parts for the program, one for the user interface and one for data processing. Both the data processing and the user interface would be done through a software.

To be able to keep this data and information gathered, companies often use cloud services in the IoT. Cloud services are often huge servers that are run by different companies that communicate with specific devices in the IoT by sharing and collecting data. This makes it very accessible and easy to use. The reason for it being called “cloud” is from a user perspective view. The user can read this data from different devices and locations, and not from only a single device. Therefore from a user perspective view, it is just like the data is stored in a cloud, physically speaking. [5]

2.1.3 Application examples

A DT for a building can be created in different stages of the building. In other words, a DT can be created during the design stages, construction stage or when the building is completed and needs maintenance.

A Digital Twin is often vital for the development- and construction stages of a building. The main reason for this is to more efficiently create and develop an efficient smart building. By creating a Digital Twin before the physical construction, one can design and test the building for the most optimal use. This allows a more efficient plan for the building, in the sense of both physical construction and later maintenance. DT is not only important for a single building, but also for further development of the city. To be able to efficiently build and design a building that also efficiently uses available spaces in the city is important for larger

(10)

cities. And since the population and cities increase in size, DT becomes more important. Creating a Digital Twin has its expenses depending on the size and complexity of the building. Although, by having a Digital Twin, less physical tests need to be tested. Most physical environmental tests can be tested using the Digital Twin, and in that way save on real-life environmental emissions. All of this makes it less costly to test, by not needing to have physical testing material that would cost to create each time a test is being done.

There are different varieties of tests that a building needs to go through before it is complete, with the main topic being structural tests. A few examples would be from durability, load, strength to weather resistance, air tightness, water tightness and so on. One way of testing the buildings in a Digital Twin is to play different scenarios by inserting different values in the DT software. These scenarios can either be environmental real-world scenarios that may occur to the building, or different extreme events that would not normally occur, but would show the tolerance of the building.

As mentioned previously, a DT can be created after the construction of the building. By simply having a Digital Twin for a building, one can manage and maintain the building all in one place, using a digital twin software, by looking at and handling the data that the building is outputting. The most common reasons as to why digital twins are used, is for managing energy, security and safety. No unnecessary energy needs to be used and potential safety and security risks can be foreseen. Common ways of testing this is to expose the DT to safety and security breaches, and learn from that.

In “A Framework for an Indoor Safety Management System Based on Digital Twin” by Zhansheng Liu, Anshan Zhang and Wensi Wang, the authors used DT to create an Indoor Safety Management System. Before creating the desired DT, a BIM was developed during the construction process, which was later 3D visualized. Their DT consisted of an integrated ISMS (Information Security Management System), which holds security information in the real world that is implemented in the virtual world (DT). And by using a specific IoT

structure, created for this system, the desired data transfer between the virtual- and real world could be achieved. This DT uses a SVM (Support Vector Machine) algorithm to analyze the recorded data to be able to realise the safety status of the building. Meaning that the algorithm should know when there is a fire by recording smoke density, rising temperature and so on.[3] 2.1.4 Smart buildings

A Smart building is a building where various types of technology is used to acquire a comfortable and efficient building by creating a safe-, secure-, energy efficient- , and many more-, building. [6] Smart buildings are similar to a DT in the sense of sensors and IoT. But a smart building can often run on their own, by having several systems in the building

communicating with each other. There is no bigger need of maintaining the building manually, since a computer system can react faster than a human being in case of negative types of events. The more detailed and more frequently gathered data, the more precise and efficient smart building one could achieve. This also means that huge chunks of data needs to be stored and handled.

(11)

Although the initial setup price of a smart building is more costly, the operating cost is less than a non-smart building. [7]

2.2 Digital Twin in combination with simulation 2.2.1 Dynamic Data Driven Simulation System

By using smart sensors consuming real-time information, high-velocity-data streams and an interconnected environment using communication technologies, a Dynamic Data Driven Simulation System (DDDSS) can be acquired. These systems are often occurring in Smart Cities and Smart Environment. DDDSSs are often created to improve a system in the physical world. A few examples might be environmental pollution, traffic related issues and diverse safety features. [8] A simulation is created to visualize the physical environment and test different solutions.

As mentioned, the reason for DDDSS varies from system to system. It depends on how important the information is as well as how often it changes. For environmental simulations, dynamic data is very vital. As the environment we live in today is very dynamic, it is very hard to achieve a precise simulation without the use of rapid updates of sensor data. The less rapid updates, the more errors will occur in the simulation.

Therefore, a real-time reality simulation is impossible to achieve. [9] Rapid sensor updates means huge amounts of stored data. Data would need to be iteratively deleted to make sure no errors occur with overfilling data storage. At the same time, depending on how long a specific dynamic information is needed for later use, it would need to be stored for history.

In “Smart City Real-Time Data Driven Transportation Simulation” by Abhilasha Saroj, Somdut Roy, Angshuman Guin, Michael Hunter, Richard Fujimoto, the authors created a model using the a software called “Vissim” version 9.00-08, that would read dynamic data from a sequence of traffic intersections. In this model, there is a task that reads and writes the real-time data, executing the simulation accordingly to the data, and generating different performance metrics. These are the main tasks to make the simulation work. The simulation uses a simulation package that primarily uses real-time information of the traffic lights timing plans, vehicle volume that are queued at intersection red light and turning movement at the intersections. The dynamic data of vehicle volume updates every 5 minutes. In this model, energy emissions and motor vehicle (CO2) emissions are considered and measured. [8]

(12)

3 System Architecture

The simulation is built on Unity 3D Development Platform3_{with Unity game engine using} programming software Visual Studio 20194_{and programming language C#.}

This is a standalone system. The system architecture is quite simple for this project. The Unity 3D development platform is a big part of the system architecture. The view, controller and the data is available in the editor. The output that is not seen in the Unity editor, is the information from the simulation sensors that are logged in a text file outside of Unity.

Fig. 1. Simple diagram showing the standalone system.

Since no direct access to the sensors could be obtained, for the simulation, from the

University real world sensors database, a simple extracted data log was being read. This data log did not have sufficient information to be able to create a precise simulation that would simulate the real world, and far from a real time simulation. But a good estimate could be created.

The components of this simulation are: - The virtual corridor

- Simulation sensors

- Model for each of the sensor readings - Simulated pedestrians

- The behaviour model for the simulated pedestrians - The data given from the real world sensors

- The data from the simulated sensors - Instantiate and delete of pedestrians

4_{Visual Studio IDE}

(13)

Fig. 2. Simple diagram showing the components of the system.

The virtual corridor is the static component of the simulation. The virtual corridor is where both the simulated sensors and simulated pedestrians are placed in.

The simulated sensors are placed on the roof of the virtual corridor and read the activity in the corridor, while the simulated pedestrians walk back and forth. The simulated pedestrians are controlled by two realistic behaviour models, one for the movement and one for the addition and deletion, and a navigation mesh.

The simulated sensors are controlled by a behaviour model based on the data given from the real world sensors. Every 10 minutes, in the simulation, and update will be written from the simulated sensors to the sensor log.

(14)

4 Methods and tools

4.1 Methods

The development method used in this project was systematic development. The project was being developed in a cycle of a few days. During these days, new code was written as well as systematically tested for high quality code. Once every week, a meeting was scheduled to go through what has been done, what is coming up and what problems have occurred. Although a general timeplan was planned since a deadline was established.

The tool used to measure the real world University corridor was mainly a physical laser measurement tool. The length of every wall and the exact position of the sensors were measured by using the laser measurement tool. Although the position of the doorways to the offices was measured using a tape measure and a scaled image of the specific corridor in MazeMap.

4.2 Programming language

The programming language used in this project is C#, coded in Visual Studio 2019. 4.3 Tools

This project has been done on a stationary PC, running Windows 10 operating system. The PC hardware components;

CPU: AMD Ryzen 5 3600 3600Mhz GPU: Nvidia GeForce GTX 1060 6GB RAM: 16GB

HDD

Project was done in Unity 3D Development platform and Visual studio 2019. A physical laser measurement tool was used to measure the University corridor.

Unity 3D Development platform, as mentioned before, is the development platform that this project has been developed on. Unity has a user-friendly user interface, which makes it easy to develop and manage the different components, but at the same time, one can achieve very advanced projects. Since Unity is user friendly and efficient, Unity was a clear choice. All of the stages of simulation development was done in Unity, as well as the 3D modelling. To more efficiently create a precise corridor in Unity, two Unity 3D modelling tools were used. Toolkits called ProBuilder5_{and ProGrids}6_{were used and provided by Unity. These}

6_ProGrids

https://docs.unity3d.com/Packages/com.unity.progrids@3.0/manual/index.html

5_ProBuilder

(15)

toolkits give the availability to keep track of the correct measurements by using clipping points as well as always displaying the dimensions.

When creating the motion sensors, a Unity help tool called Sensor Toolkit by Micosmo7_was used. The Sensor Toolkit allows the sensor to constantly track an agent under the sensor field of view. As well as to stop tracking agents when they are behind a wall. This is useful for when an agent is inside an office room. This toolkit is using a or several raycasts, provided by the Unity engine. Raycast is a ray that starts from a given point in the simulation (in this case, each sensor) and casts that ray into a given direction with a specific length. This ray will detect any collision and send a signal that an agent has been detected.

A single option was considered when creating the data output file. The easiest way to output the data is in a structured text file (.txt). This type of text file can hold a large amount of text, without heavily increasing in datasize. This type of text file is also easy to change, if needed, and is supported by a lot of different programs and softwares to easily read it. Therefore this was a superior option.

4.4 Other resources

Other resources that were needed for this project was the information and data from the University sensors. This data was given by the University in a csv file (Comma-separated values, a tabular format).

7_{SensorToolkit - Micosmo}

(16)

5 Implementation

5.1 Setting up the corridor model

The corridor in the simulation was created by using the ProGrids and ProBuilder tools in a Unity scene. Both ProGrids and ProBuilder are helping tools to create 3D objects in Unity by using real- and exact measurements. By real measurements, the metric system was used. Unity scene is the visual interaction and representation in the editor.

To get the exact measurements of the corridor, a physical measure was done using a laser measurement tool. By physically measuring the specific corridor at the University, ProGrid could be set to a desired measurement for a grid, to more easily build and keep track of the correct measurement. The ProBuilder will place 3D objects in the scene by the desired measurements. By doing this, step by step, the whole corridor was created.

The doorways were created by measuring each doorway's exact position in MazeMap. By knowing the real world measurement of the wall in question, the placement of a doorway could be calculated. By measuring the length from a wall and a doorway, in MazeMap, and dividing it by the full length of the same wall, one would get the percentage of the full length of the wall. By then multiplying that value to the real world full length, the result would be the correct real world measurement of the placement of the doorway.

This was done for every doorway inte corridor except for the entrances in, and out of the corridor.

Fig. 3. A picture of the specific corridor in Örebro University in MazeMap, with a notation of the

length of a wall.

E.g.

Full length of wall 1 in the corridor in the real world = 24,03 meters Full length of the wall 1 in MazeMap = 91,4 centimeters

First doorway of wall 1 in MazeMap = 5,4 centimeters

=> => gives 1,42 meters

(17)

The sizes of each and every office was not measured. Since there is no access to the sensors in the offices, nor do the sensors in the corridor read the offices, there is no point of measuring the exact office space.

5.2 Pedestrian Behaviour

Two options were considered when creating the behaviour for the Agents, a Behavioural Tree (BT) or a Finite State Machine (FSM). Behavioural Tree is a very common way of creating behavioural systems, and was therefore used. Since the agents read values, such as distance to destination or contact with another agent, hundreds of times in a second during the runtime in the simulation, a BT was sufficient. The biggest advantage of BT over FSM is that you can run two or more states at the same time while running. Meaning that the agent is able to keep track of two different states and carry it out if told. While the FSM works in sequence, this would not be possible. But with FSM, a more visually pleasant representation could be achieved. In this simulation, a Behavioural Tree was used.

In this simulation, walking pedestrians were created by using a navigation system. Unity has a built-in navigation system called Navigation Mesh (NavMesh). This navigation system is set to a 3D game object, in this case the agent (pedestrian) which is a 3D capsule. This agent has its own local routine to be able to move around another object to get to its desired destination. The NavMesh uses data, set by the user, to map out a mesh in the Unity scene. In this

simulation, the mesh would be on the floor of the corridor. This mesh consists of convex polygons, in which the NavMesh agent will use to find its shortest path, using A* algorithm to its destination, while at the same time avoiding obstacles. [9]

5.3 Agent Implementation

The core parts of the agent script consists of: ● Select an agent and walk to a destination.

● What should the agent do when it reaches its destination?

● During the trip to its destination, what should it do if it collides with another agent?

When an agent instantiates into the simulation, it will be given a set amount of destinations. In this case it will be all of the office rooms (40 destinations). The agent will pick one of the rooms and make its way there by using the given speed (walk speed) and navigation graph. During this travel, if the agent collides with another agent, there will be a 25% chance that the agents will stop and “talk”. They will stop for a period of three- to ten minutes, and then continue their travel.

When an agent reaches its destination, it will stay at its destination from somewhere in

between 45 minutes up to 2 hrs (working). When an agent is done “working”, it will set a new destination with a probability of 90% to leave the corridor. The other 10% is to set a new

(18)

destination to another office. This was done by creating a BT consisting of different random-and probability values. See Fig. 4 random-and 5.

This simple specific behaviour was decided by interviewing a person that is working in this corridor and explaining how a common day to day looks like. And by combining the

information given from the interview and the given data from the University sensors, this simple realistic behaviour could be achieved.

Fig. 4. Simple behaviour tree showing the Agents behaviour in the simulation

(19)

5.4 Sensor and sensor scripts

During this project, the simulation sensors have gone through several stages of update to create the most realistic sensor. The University sensors track 4 different kinds of data. That is motion, illuminance, humidity and temperature. The primary data for this project was motion. Therefore, motion detection was important.

5.4.1 Motion Sensor

Three options were considered and tested when creating the simulated motion sensor. All of the three options include using Raycast to track and update values. Raycast is a ray that starts from a given point in the simulation (in this case, each sensor) and casts that ray into a given direction with a specific length. This ray will detect any collision and send a signal.

First option was to use a single raycast from the sensor straight down. But that was not sufficient enough since it does not cover enough area.

Second option was to use a SphereCast, which casts a Sphere instead of a single ray. This was not sufficient enough either since it will not track the agent under the sensor field of view. It will only send a signal when an agent enters and exits the sensor field of view.

The third option was to use a help tool in Unity called Sensor Toolkit by Micosmo. The Sensor Toolkit allows the sensor to constantly track an agent under the sensor field of view. As well as to stop tracking agents when they are behind a wall. This is useful when an agent is inside an office room

To create the best copy of the University sensor in the simulation, the third option was used. By using this, a realistic copy of the University motion sensor could be created. The created script tracks data for ten minutes and if there is a change from the previous value, update the log, otherwise, the log should not be updated.

5.4.2 Temperature Sensor

Since no actual heat or cold source was implemented in the simulation, real temperature values could not be read. Therefore a simple randomized probability calculation was implemented to create realism and accuracy to the real world data.

Every 10 minutes in the simulation, this randomized probability calculation will run. Different temperature changes have different probability values. See fig. 6.

(20)

Fig. 6. Table showing temperature changes in the simulation.

This calculation was done this way since it simulates the real life data very well. 5.4.3 Humidity Sensor

Since no humidity source was implemented in the simulation, real humidity values could not be read. Therefore, another randomized probability calculation was created to enhance the fact of realism and accuracy of the real world data.

Every 10 minutes in the simulation, the randomized probability calculation will run. Different humidity changes have different probability values. See fig. 7.

(21)

5.4.4 Illuminance Sensor

Since no illuminance source was implemented in the simulation, nor sufficient enough real world data. This part has been left out of the simulated sensor reading. The given data could not be comprehended and the illuminance values were random.

5.5 Data output

The sensors use a script that writes the tracked data in the simulation, into a text file. Every ten minutes in the simulation, the simulated sensors will write the correct data into a text file by using the System.IO namespace. This allows reading and writing data into files.

5.6 Calibration with real data

The given data from the University sensors was a csv file that was specifically structured to show the correct data. Every row in this csv file shows 6 different values;

- device_name (1 to 3, this file in particular holds data from 3 sensor devices)

- sensor_idx (0 to 3)

- quantityKind (Temperature, Humidity, Illuminance, Motion) - measurementUnit (Celsius, RelativeHumidity, Lux)

- observationTime (year-month-day hrs:minutes:seconds)

- value (depending on sensors_idx, different numerical values)

This tabular format has been identically reconstructed in a text file for the simulated sensors. Every sensor in the simulation has its own row that holds the correct information;

“device_name, sensor_idx, quantityKind, measurementUnit, observationTime, value”.

The values in the simulation have been set to simulate the real world as much as possible with the help of the given data from the sensors in the University. Therefore, to speed up the simulation, no values have been divided. Instead, the whole simulation has been sped up, in mind to keep the realism.

(22)

6 Result

6.1 Visualisation

The simulation will display the corridor at the University, without the roof to easier be able to visually see the pedestrians. During the runtime of the simulation, there will be pedestrians walking in and out of the entrance of the corridor with random time intervals, as mentioned earlier. For the user, to more easily see when a pedestrian has been hit by a sensor, the pedestrians will change color when walking into a sensor. The pedestrians will stand still when they “talk” to another pedestrian, and when they reach their destination in the office (working). As seen in Figure 8, there is a blue pedestrian in the bottom office, which means that it has walked under a sensor that changes its color to blue. There is also another

pedestrian walking in the left corridor, and has walked under a sensor that changed its color to orange. The blue spheres in every office, is a marking for the available destinations to every agent. The green markings above the corridor, on the corridor ceiling, shows the placement of the simulation sensor devices.

Fig. 8. The University corridor in Unity. Showing sensors (green icons), pedestrians (orange glow and

light blue glow) and destinations (dark blue icons).

Every ten minutes, the data log (text file) will be updated with information. The information will replicate the real world data log in the University sensors. If there has been a change since the previous ten minutes in the simulation, the data log will be updated. If there has not been a change since the previous ten minutes, the data log will not be changed.

(23)

6.2 Simulated Data

Simulated data was successfully done. The simulation sensors output data every ten minutes, like the real life sensors do. Although, the simulated data does not output the same identical structure. The real life sensor data is very disorganised, as seen in Figure 9.

Fig. 9. Showing the real life sensor data output.

(24)

Fig. 10. Showing the real life sensor data output in a tabular format.

The simulated data outputs a simple but organised text file, as seen in Figure 11, that can easily be accessed from most programs.

Fig. 11. Showing the simulated sensor data output.

The simulated sensor data output behaves the same way as the real life sensor data output, in the sense that information will be updated and output only if the information has changed from the previous iteration. A text file is small in size, which means that a lot of data can be written without taking up much space.

(25)

6.3 Iterative Testing

Multiple realism tests have been done throughout the development, with great results. During the development, several overloading tests have been done.

6.3.1 Realism/Validation

The core of this simulation is to simulate the real world, and by doing that, realism becomes a great role. Therefore, the different values that have been set in the simulation, have been tested in relation to one another to create the most realism. Values like probability of agents talking, how long an agent will stay in its room, fixed update interval (how many times a second a value is being read) and many more.

6.3.2 Performance

Tests like overloading the simulation with pedestrians in the corridor by rapidly instantiating pedestrians were done. Both positive and negative results came back. The positive result was that the simulation itself would not be overloaded and run as it should. But the negative result was that all of the pedestrians would stand still and “talk” to each other indefinitely. A

measure for this was to make a fixed update interval, meaning that simulated pedestrians will check if a collision with another pedestrian has occurred in longer time intervals. Meaning that instead of checking collisions several hundreds of times in a second, it will check ten times a second. This solution would not work flawless, but would improve the overall simulation.

Even though it is very unlikely that 100 pedestrians would rush in the corridor in real life, this does set a standard as to how optimized the simulation is. But this kind of performance test does not only test the simulation itself, but also the system it is running on. Therefore, by running this simulation on a system that is more powerful, a greater performance result would be achieved.

More common tests like Unit Testing, have been occurring several times during all iterations throughout the development of every script.

Smaller Integration Tests between different scripts have been occurring. Synchronising values when pedestrians are instantiated and deleted during the runtime in the simulation to keep a track of how many pedestrians are in the simulation at a given time.

(26)

7 Discussion

7.1 Project requirements

The requirement for this project was to create a digital twin of a specific corridor at Örebro University, which was created. Although there are different levels of detail in a digital twin, meaning that you could have a more or less detailed digital twin by having more or less sensor readings. This project was very dependent on the data and information from the University sensors. Unfortunately, the data given from the University sensors was not sufficient enough to create a precise simulation that would simulate the real world .

The core idea was to use the data from the University sensors to place out pedestrians at the exact position, which would more precisely show how pedestrians move in the corridor. Since the University sensor data updated and logged information every ten minutes, this is more or less impossible to reconstruct. Therefore, by physically reading the University sensor data, realistic simulated sensors were created. And from that, create a realistic simulation.

Another core idea for this project was to create simulated data and compare it to the observed data in the real environment. Which in this case, was created successfully. By creating

simulated data, a more detailed level of data could also be achieved. This lets the user more easily read and understand the information being logged.

7.2 Social and economical implications

By creating this simulation, experiments or solutions could be tested in the simulation beforehand testing it in the real world. This would save up time and finances for the University.

A solution that could be tested in the simulation, is to turn off the lights in the corridor when no motion is detected. As well as if there is enough light (illuminance) in the corridor, to not turn on the lights at all. This could be calculated in the simulation, instead of testing and calculating in the real world. This would save time, finances and the environment. Another solution is that the simulation can be used for generating controlled sensor data, rather than having to do it in the real world. This would take less time and finance and give you a better overview.

Optimization solutions could be tested as well. Simple tests as to changing the placement of every sensor for the most optimal readings and data outcome. Where would the best

placement for the illuminance sensor be, where the illuminance sensor can read the sunlight through the windows as well as the lights on the ceiling. By placing this sensor in the most optimal position, one could minimize the usage of electrical lightning and therefore save on finances

(27)

7.3 The projects development potential

This project can be further developed. By further developing the simulation, more and more detailed data can be produced to improve the University environment. Further development would include more features to the simulation.

A more detailed data would be more frequent readings from the sensors. By having more frequent sensors reading, a more precise simulation could be created. Although, by having more frequent reading, a bigger data storage would be needed as well as a more powerful system that can read and write this data without any failures. With a more precise simulation, one would achieve more accurate testing and solutions that could be implemented later in the real world.

By adding more features to the simulation, a more realistic simulation could be achieved as well. The biggest realism feature would be to add more behaviours to the agents. E.g. specific agents going to specific rooms, or agents specifically going to other agents. Adding more features includes adding more values to keep track of. Doing this would also mean more funds and time.

7.4 Project success

This simulation helps the user more easily and quickly see how the real world would look like. Therefore, before implementing something in the real world, experiments and changes could be done beforehand in the simulation to optimize the real world change as much as possible.

The project was not fully successful, since a more precise simulation was in mind before the University sensor data was given. As mentioned before, a real-time simulation was in mind, but was not able not to achieve since the data was not sufficient enough. Although, with realism in mind from the start, this was achieved. By using the given sensor data from the University, a simulation that replicates the University sensor data was done.

As mentioned earlier, a “perfect system” is a system that outputs detailed real-time data. By having this, a live feed simulation could be created where you could see everything that is going on. And by having this, security and safety measures could be taken care of. A simple measure as identifying an active fire and alerting everyone nearby. Or a more complex one, identify a person being harassed or assaulted and alerting the authorities.

On the other hand, by having this accurate of a simulation, this simulation can be used for evil-doing. By having a live feed simulation, unwanted users may use that information to coordinate evil-doings as robberies.

(28)

7.5 System expansion

The current simulation is restricted. It does not have all of the features that could occur in the real world. The simulation has the most common features that would occur in the real world. The biggest current restrictions would be the sensors. The sensors do not measure physical temperature, illuminance and humidity. Instead there is a random probability process, as explained earlier. This could be extended by implementing heat/cold-, humidity- and illuminance sources, in which the sensors could read. Other current restrictions are further realistic real world features. As of different real world pedestrian activities.

The simulation itself is not restricted. Other features can easily be added by creating several scripts.

7.6 Self reflection

A small self reflection of the whole project 7.6.1 Knowledge and understanding

I feel like I’ve gotten a much better understanding of different Digital Twins and in which areas it is used. Primarily, Digital Twins for buildings but also for other structures, as in spacecraft. Dynamic Data Driven systems have also played a big role in my theories. Since a simulation most of the time uses dynamic data. It has also given me a realization of how much Dynamic Data Driven systems there are in everyday life. Common things as traffic light stops, some of them use dynamic data to decide what traffic lights, in an intersection, should be red and green depending on the amount of cars in each section.

I feel like I have gotten a generally better understanding in Industry 4.0. In which Digital Twins and DDD systems are very common, if you have the right funds.

I haven’t done any new development methods, since I am most comfortable and feel like iterative development works best in this case.

7.6.2 Skills and abilities

I feel like I studied the theory behind the project well. By studying the theory, and looking at different problems that may occur in my area. Most of my information has been from different studies and articles which contain relevant information. Other information is “common

knowledge” in which several sources, in some cases all sources, explain the same information.

I have iteratively developed the project, and have had meetings with my supervisor every week to verify and explain the development process. A small documentation was noted almost everytime after each working session, explaining what had been done during that session.

(29)

7.6.3 Evaluation ability and approach

Different social, economical and environmental perspectives have been discussed as well. How and what different companies can and cannot achieve depending on what I have achieved with my system. Essentially, any company can create the same simulation that I have since I don't have a super built system (PC).

A lot more could be achieved with this simulation if I was working in a team and had more knowledge of Unity. I didn't really have anyone to reach out for help with Unity, since I did not know anyone with good knowledge. And since I was alone, nothing could be equally distributed to others in which more work could have been done. But the system can be expanded if further work wants to be done.

(30)

8 References

[1] Jiang, Haifan; Qin, Shengfeng; Fu, Jianlin; Zhang, Jian; Ding, Guofu, “How to model and implement connections between physical and virtual models for digital twin application”, Journal of Manufacturing Systems, 2020, ss 1-3.

DOI:10.1016/j.jmsy.2020.05.012

[2] Jones, David; Snider, Chris; Kent, Lee; Hicks, Ben, “Early Stage Digital Twins for Early Stage Engineering Design”, Proceedings of the Design Society International

Conference on Engineering Design, vol 1, 2019, ss 2558-2559.

DOI:10.1017/dsi.2019.262

[3] Liu, Zhansheng; Zhang, Anshan; Wang, Wensi, “A Framework for an Indoor Safety Management System Based on Digital Twin”, Sensors, vol 20, 2020, ss 1-4.

DOI:10.3390/s20205771

[4] Cecil, Joel; Albuhamood, Sadiq; Cecil-Xavier, Aaron; Ramanathan, Parmesh, “An Advanced Cyber Physical Framework for Micro Devices Assembly”, IEEE

Transactions on Systems, Man, and Cybernetics: Systems, vol 49, 2019, ss 92-93.

DOI:10.1109/TSMC.2017.2733542

[5] Petrakis, Euripides; Sotiriadis, Stelios; Soultanopoulos, Theodoros; Tsiachri, Pelagia Renta; Buyya, Rajkumar; Bessis, Nik, “Internet of Things as a Service (iTaaS): Challenges and solutions for management of sensor data on the cloud and the fog”,

Internet of Things, vol 3-4, 2018.

DOI:10.1016/j.jmsy.2020.05.012

[6] Eini, Roja; Linkous, Lauren; Zohrabi, Nasibeh; Abdelwahed, Sherif, “Smart Building Management System: Performance Specifications and Design Requirements”, Journal

of Building Engineering, 2021, ss 1-3.

DOI:10.1016/j.jobe.2021.102222

[7] Ali Berawi, Mohammed; Miraj, Perdana; Sari Sayuti, Mustika, Rohim Boy Berawi, Abdur, “Improving Building Performance Using Smart Building Concept: Benefit Cost Ratio Comparison”, AIP Conference Proceedings, vol 1903, 2017, ss 4-6.

DOI:10.1063/1.5011508

[8] Saroj, Abhilasha; Roy, Somdut; Guin, Angshuman; Hunter, Michael; Fujimoto, Richard, “SMART CITY REAL-TIME DATA-DRIVEN TRANSPORTATION SIMULATION”, 2018 Winter Simulation Conference, 2018, ss 857-859.

DOI:10.1109/WSC.2018.8632198

[9] Hu, Xiaolin, “Dynamic Data-Driven Simulation: Connecting Real-Time Data with Simulation”, Concepts and Methodologies for Modeling and Simulation, 2015, ss 68-70.

(31)

[10] Unity Technologies. Inner Workings of the Navigation System [Internet]. Unity. Unity Technologies; [updated 2021 March 16; cited 2021 March 17]. Available from https://docs.unity3d.com/Manual/nav-InnerWorkings.html

Creating a Digital Twin by Using Real World Sensors

Datateknik C, Examensarbete, 15 högskolepoäng