## 7 Execution Results
### Analysis Using Physical Tasks  
The second major part of this research work is to allow users to schedule jobs and monitor them remotely without the need to go on premises. For instance, a user can schedule a real-time job in an IoT space like smart home and made them run using any of the real-time tasks scheduling algorithms. The system will provide the interface for the user to schedule these jobs and track them even if the user is not on his premises. Moreover, the CPU timeline will let the user know which task is executing at which instance and which task is missed at a particular instance. This way the IoT smart space will behave autonomously without the interaction of users and more importantly without the need to be on the location. That being said, to analyse and verify the correct working of the algorithm using actual physical resources, we use Raspberry PI 3 as a central server to which the physical resources are connected. Figure 13 shows the conceptual architecture of the proposed system. Application users logged into the proposed tool which is a web-based application hosted on AWS EC2 as described in Table 5. The user can generate tasks and apply an algorithm to evaluate and visualise the performance and output results of the algorithm. In the same way, if the tasks are physical tasks in a smart world, the tasks can be generated and associated with the respective IoT resources as presented in the smart space studies [55]. The communication between the cloud-based web application and Raspberry PI based IoT node is performed using the HTTP protocol. The Raspberry PI based IoT server parses the request and perform the task on associated physical devices. This way the end goal, which is the monitoring and the evaluation of any algorithm on actual IoT jobs, are fulfilled and can be remotely accessed from anywhere. Figure 12: Snapshot of Rate Monotonic Algorithm’s Simulation using Virtual Tasks. Table 7 describes the tasks which are associated with physical IoT resources. There are mainly two types of tasks; critical tasks which have priority as 1 and non-critical tasks which have priority as 0. For non-critical tasks, temperature sensor, Led Actuator and Fan actuator have been taken whereas for critical tasks e-Health sensor platform's two sensors are taken for getting the ECG and pulse of any elderly under observation. It is to note that we periodically simulate the tasks for repeatedly assessing the response time and the execution within the deadline. The tasks are created using the web interface against every resource, and the input parameters are provided in the form field in accordance with the Table 2.  
In order to see the various tasks in action, the tasks associated with physical resources are made to communicate with the Raspberry PI on a predefined time specified by the main algorithm. The physical resources communicate using general purpose I/O (GPIO), and the status of the algorithms are displayed in runtime on bash terminal as well as on the connected device in case of the actuating devices like a fan. Figure 14 shows the interfaces when the tasks associated with physical resources are scheduled using RM algorithm. As described earlier, we consider two categories of tasks; critical and non-critical tasks which are identified by unique colour codes in the system. If at a specific time, two tasks of critical and not-critical nature are waiting in the system, it will give priority to the critical system. \begin{table}
\begin{tabular}{l l l l l l l l} \hline \hline  
Figure 13: Experimental Setup Design using Raspberry PI and AWS Cloud. In Figure 14a, the task timeline is shown for every task. The rows show the CPU share of the individual task while the columns list all the tasks. In Figure 14b, the CPU timeline is illustrated in clock cycles of 1 epoch. For instance, in the clock interval 0-1 task 1 instance, which is getting temperature value from the sensor, gets executed and the reading is displayed on bash terminal of Raspberry PI.