Poster Abstract: Run-time Dynamic WCET Estimation Lia Cagnizi lia.cagnizi@mail.polimi.it Politecnico di Milano, Milano, Italy Federico Reghenzani federico.reghenzani@polimi.it Politecnico di Milano, Milano, Italy European Space Agency, Noordwijk, Netherlands William Fornaciari william.fornaciari@polimi.it Politecnico di Milano, Milano, Italy ABSTRACT To guarantee the timing constraints of real-time IoT devices, en- gineers need to estimate the Worst-Case Execution Time. Such estimation is always very pessimistic and represents a condition that almost never occurs in practice. In this poster, we present a novel compiler-based approach that instruments the tasks to inform, at run-time, the operating system when non-worst-case branches are taken. The generated slack is then used to take better scheduling decisions. CCS CONCEPTS • Computer systems organization →Real-time systems; • Software and its engineering →Real-time systems software; Compilers; • Hardware →Timing analysis. KEYWORDS real-time scheduling, dynamic WCET, compiler transformation ACM Reference Format: Lia Cagnizi, Federico Reghenzani, and William Fornaciari. 2023. Poster Abstract: Run-time Dynamic WCET Estimation. In International Conference on Internet-of-Things Design and Implementation (IoTDI ’23), May 09–12, 2023, San Antonio, TX, USA. ACM, New York, NY, USA, 3 pages. https: //doi.org/10.1145/3576842.3589168 1 INTRODUCTION Many Internet-of-Things (IoT) devices must satisfy given timing constraints, which are usually expressed with the concept of a time deadline. Such IoT systems are then real-time systems. Mixed- Criticality Systems (MCS) are a particular class of real-time systems and have been a subject of research since the Vestal’s article [4]. These systems integrate components with different criticality onto the same platform, where criticality is meant as the level of assur- ance that a software component must guarantee. To guarantee that timing constraints are met for real-time systems, the scheduling analysis must consider the Worst-Case Execution Time (WCET) of each task. This pessimistic assumption leads to a waste of sys- tem resources, for two reasons: tasks rarely execute their longest execution path, and the execution time analyses are usually very pessimistic, substantially over-estimating the real WCET [3]. In Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. IoTDI ’23, May 09–12, 2023, San Antonio, TX, USA © 2023 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 979-8-4007-0037-8/23/05...$15.00 https://doi.org/10.1145/3576842.3589168 10 5 30 60 J2 J1 J3 J4 B1 B2 B3 B4 Figure 1: An example of CFG with four basic blocks (B1–B4) and four jump instructions (J1–J4). The number inside each block represent the worst-case execution time of that block. order to mitigate this problem, slack scheduling techniques have been developed to exploit unused WCET budgets [2]. MCS also targets this problem, with the aim to exploit over-provisioned re- sources and take advantage of the criticality concept. For example, the scheduler admits low criticality tasks during the slack time generated by high criticality tasks that do not run for their entire WCET [1]. However, the limitation of slack-reclaiming approaches is that the actual execution time of a task is known to the scheduler only after its completion. Instead, any info on the actual execution time before completion may help in performing a more ef