Achieving Predictable Execution in COTS-based Embedded Systems

Building safety-critical real-time systems out of inexpensive, non-real-time, Commercial Off-the-Shelf (COTS) components is challenging. Although COTS components generally offer high performance, they can occasionally incur significant timing spikes. To prevent this, we propose controlling the operating point of shared resources, for example main memory, to maintain it below its saturation limit. This is necessary because the low-level arbiters of these shared resources are not typically designed to provide real-time guarantees. Here, we discuss a novel system execution model, the PRedictable Execution Model (PREM), which, in contrast to the standard COTS execution model, coschedules, at a high level, components in the system which may access main memory, such as CPUs and I/O peripherals. To enforce predictable, system-wide execution, we argue that realtime embedded applications should be compiled according to a new set of rules dictated by PREM. To experimentally validate the proposed theory, we developed a COTS-based PREM testbed and modified the LLVM Compiler Infrastructure to produce PREM-compatible executables. I. PREDICTABLE EXECUTION MODEL (PREM) Building computer systems out of commercial off-the-shelf (COTS) components, as opposed to custom-designed parts, typically improves time-to-market, reduces system cost, while providing generally better performance. For real-time systems, however, one hurdle in the way of using COTS is transient timing spikes which may occur when there is contention for shared resources. The low-level arbiter of shared resources in a COTS system typically does not have a mechanism to deal with the timeliness aspects of incoming requests, which may end up delaying more critical tasks, causing an unintended and undesirable priority inversion. The PRedictable Execution Model (PREM) [1], in contrast to the standard COTS execution model, coschedules at a high level all active components in the system, such as CPU cores and I/O peripherals. Briefly, the key idea is to control when active components access shared resources so that contention for accessing shared resources is implicitly resolved by the high-level coscheduler without relying on low-level, non-realtime arbiters. Here, we specifically focus our attention on contention at the level of the interconnect and main memory. !"#$%&'()*"#+*,&-#.*/#0123&456&7&-#8/&,9'3:;9-931# 8/&,9'3:;-&#&%&'()*"#9"3&/7:-2#