Table 1. Example scenarios of event-driven tasks in Internet of Things (loT) environments. We have two input type tasks as event-driven tasks and periodic tasks sub-categorized into fou types as shown in Table 2 below along with their deadline types. Since in smart IoT environments, some of the event-driven tasks are of emergency nature as mentioned in Table 1. These emergency nature tasks are tagged as urgent event-driven tasks with the hard deadline. Next are the non-emergency nature event driven tasks, which can either have soft deadline or hard deadline. Priority periodic tasks are the tasks which arrive at the scheduler at regular interval and hold importance as they might carry some important flow of the system. The priority periodic tasks have hard deadlines. Normal periodic task is a task which has less priority as compared to the priority periodic tasks and has a soft deadline most of the times but can also have a hard deadline in some scenarios. Dividing the tasks into different types, though two sub-types might have same deadline type; helps in understanding the nature and context of incoming task in the smart environments. Also, context-based division of task type brings ease of understanding task dependencies based on contextual scenario learning. Figure 1. Pseudo-code for Fair Emergency First (FEF) algorithm. We have four types of tasks defined in our system as normal event-driven tasks, urgent event-driven tasks, normal periodic tasks and priority periodic tasks. Event-driven tasks are either normal event-driven asks or with urgency tags. The urgent event-driven tasks (ETs) have a default priority, as they are riggered in high emergency cases. Normal event driven tasks are ones which should be executed any ime before deadline, while urgent event driven tasks are the tasks which should be executed as soon as hey arrive. Periodic tasks have a priority with respect to their period. The priority periodic tasks must execute before their deadline as they have hard deadlines. Also, any task with additional urgency or a priority task is considered with a hard deadline, and must execute on time. In ideal scenarios the scheduler must meet all deadlines, while in overloaded scenarios the tasks with soft deadlines might starve or miss. The proposed algorithm, FEF also makes sure to keep the priorities and urgency measures as flexible for the user as possible; as the periodic tasks can also be prioritized over event-driven tasks, if required. Our algorithm focuses on execution of the task by set priorities, obedience of deadlines, lowering the starvation rate for low priority tasks with soft deadlines, and maximizing the CPU utilization (Figure 1). Table 2. Input tasks type and deadline Categorization for loT environments. When the sensing interval is too short and scheduler gets bombarded with periodic sensing data tasks or a series of events occur back to back and the scheduler gets bombarded with loads of event driven tasks. For such cases, in oT systems the soft deadlines are often missed, and with our proposed scheduler, we aim to best allocate the CPU resources to the available tasks while trying to minimize high loss of soft deadlines, or starvation of any low priority task with soft deadline. Figure 2. State diagram for task running states of Fair Emergency First (FEF) algorithm. In the Figure 2 below, the running state of the tasks at the scheduler is shown. During the task scheduling our system will have to choose which task to run depending on many existing factors at the given time. The system can have four types of tasks and run them based on their priority and availability order. The priority order followed is same as explained in FEF algorithm above. Figure 3. Learning of X in Urgency Measure (UM). ET: event-driven task; PT: Preemption Threshold. Figure 4. Prediction for high priority tasks’ safe execution. It calculates each task’s slack, checks each task’s execution time status (execution time completed execution time left), and removes overlapping times to predict safe execution of each task in the future based on the current information and history log. When considering a low priority task to run, t function learns from history log whether running the low priority task in given constraints might his fail some high priority task in the future or not. If the function predicts that it is safe to run the low priority task based on available information at current time t, then the function returns 1 else it returns 0. If the function returns 1 then the value for FM is set to 0 and low priority starving tasks are executed as < result, else the value for FM is set to 1 and high priority periodic task is executed as a result. Hence EM value set as 0 indicates that CPU has enough resources to be allocated to the low priority starving tasks at the given moment (Figure 5). Table 3. Implementation environment for Windows. Table 4. Implementation environment for raspberry PI-embedded system. Table 5. Basic task parameter’s selection criteria. 4.2.1. Periodic Tasks Set Notation Table 6. Tasks set. As shown in actuator tasks and system tasks. In sensing tasks, we have tasks for get sensors which are he Figure 6, the tasks are divided into three main periodic tasks. In sensing tasks, we have two norma categories as sensing tasks, ing the sensing values from periodic tasks as GetTemp, GetHumid and four priority periodic tasks as MotionStatus, PressureStatus, GetECG, and GetPulse. The two control tasks are LED control and fan control, which are generated in result to different sensing thresholds. Fan control is normal event driven task for the given two cases and LED control is urgent event driven task for the given four cases. The only system task is no ification message, which is normal event driven task when generated for normal event driven control tasks and urgent event driven task when generated for urgent event driven control tasks. Figure 6. Tasks flow along with their category and priority tags. Figure 8. Percentage of total tasks’ instances missed. Percentage of Tasks’ Instances Missed in Overload Scenario Figure 9. Average starvation rate comparison between FEF and other algorithms. In Figure 9, the comparisons of tasks’ starvation rates between the proposed FEF scheduler and other scheduling algorithms are depicted. The starvation rate, shown in the figure above for multiple algorithms counts the total weightage of the urgent and non-urgent event-driven tasks missed, priority periodic tasks and normal periodic tasks which never ran even a single instance and priority periodic and normal periodic tasks with many missed instances. Whereas, for our proposed algorithm the starvation rate comprised of only soft deadline tasks as non-urgent event driven tasks and normal periodic tasks. FEF shows the lowest starvation rate with an average of around 10% while the next closest is almost double the proposed FEF scheduling algorithm. The results indicate that proposed algorithm uses CPU time in the most careful manner, putting its best efforts to maximize output. Figure 10. (a) Event-driven loaded scenario without preemption bit (b) event-driven loaded scenario with preemption bit. 5.3. Comparison Analysis with Scheduling Algorithm for Embedded Systems Table 7. Comparison between combined scheduling scheme and FEF. Figure 11. Performance comparison of FEF with and without ANN learning module. Figure 12 shows the result comparisons for worst case execution times intelligent FEF non-intelligent FEF and hybrid priority algorithm. Hybrid priority in the figure above refers to the priority-based (8-256 priority levels) followed by FIFO and RR scheduling algorithm used in the embedded systems. We can observe that the WCET for non-intelligent version is very close to the WCET for hybrid priority, whereas the intelligent FEF scheduling algorithm has very low execution time in such scenarios.
