## 7 Execution Results
### Analysis Using Virtual Tasks  
First off, the scheduling policies are assessed using arbitrary task sets. Task sets are generated based on the input attributes of the task. As described earlier, a task can have attributes like period, execution time, priority, arrival time and type of task, i.e., periodic or event-driven as common in various studies [34]. Figure 9 shows the interface showing a web form to allow the users to add input tasks. For each attribute, a form field is created to let the task designers enter the data. The data have been validated, and if the form field is not filled out or contains an invalid value, an exception is thrown, and as a result, the form does not proceed further. The data validation is crucial in any system design since if the parameters are given wrong values this will have a drastic effect on the overall results of the system and there will be endless anomalies in the overall flow of the system. Figure 8: Implementation Environment based on Raspberry PI. Figure 7: Model View Controller Design Pattern Information Flow. If the validation is passed and the form is submitted as shown in Figure 9(a), a success message is displayed indicating the successful generation of tasks file. The resultant CSV file is shown in Figure 9(b). The CSV contains tasks, and each column represents the attributes of that particular task. For event-driven and sporadic tasks, the period attribute is zero while for periodic tasks, this has some non-zero value. It is worth noting that this form allows users to generate random tasks; however, a user can add tasks of their desired input parameters too. Once the input task load is generated and persisted in CSV, then the same task set can be consumed by any scheduling policies and perform feasibility analysis. If the feasibility analysis indicates that the CPU never misses any task's instance and at the same time the CPU is also not under-utilised, then the claim that the tasks are guaranteed to meet the deadline given the communication delay is known to be under certain upper bound. The tasks are scheduled in real-time using any of the fixed-priority or dynamic-priority algorithms. For simplicity, we use RM and EDF approach, but this tool can support the simulation of any real-time tasks scheduling algorithms. Whatever the algorithm may be, the proposed tool has certain tabs on  
Figure 10: Snapshots of Tasks Addition and CSV Generation using the Web Interface. Figure 9: Snapshot of Task Data Validation. the visualisation page of the algorithm. These tabs are named General Summary, Tasks Timeline, Completed tasks, Missed tasks and CPU timeline. Every tab contents are next to the tab on the same page. The feasibility analysis under EDF scheduling policy is shown in Figure 11. In Figure 10(a), the general summary section is exhibited which accounts for summarising the overall process. It includes items like what are the input tasks and their parameters, hyper period of the tasks, total core needed for efficient simulation, CPU utilisation and process utilisation. For instance, it shows total tasks as 10, total execution time as 624, total core required as 3, CPU utilisation and process utilisation as 3 followed by input tasks representation in a tabular format. Figure 10(b) portrays the CPU timeline of the scheduling footprints of EDF. There are two strips stacked on one another. The upper strip shows the clock cycle while the bottom strip shows the tasks instance which gets CPU on that particular clock cycle. For instance, on the 0 1 clock cycle, task 5's instance 676 is scheduled and for next clock cycle task 5's instance 8618 is scheduled, and this goes on till the clock cycles equal the hyper period. Like Figure 11, Figure 12 illustrates the snapshots of some of the screens of the RM algorithms using the same task set. Figure 11(a) shows the general summary interface as in the case of EDF. The general summary interfaces list the overview of the input load and hyperparameters which are necessary for RM scheduling policy.