Implicit Path Enumeration Technique Research Articles

WCET Analysis Based on Micro-Architecture Modeling for Embedded System Security

To ensure the timely execution of hard real-time applications, scheduling analysis techniques must consider safe upper bounds on the possible execution durations of tasks or runnables, which are referred to as Worst-Case Execution Times (WCET). Bounding WCET requires not only program path analysis but also modeling the impact of micro-architectural features present in modern processors. In this paper, we model the ARMv8 ISA and micro-architecture including instruction cache, branch predictor, instruction prefetching strategies, out-of-order pipeline. We also consider the complex interactions between these features (e.g., cache misses caused by branch predictions and branch misses caused by instruction pipelines) and estimate the WCET of the program using the Implicit Path Enumeration Technique (IPET) static WCET analysis method. We compare the estimated WCET of benchmarks with the observed WCET on two ARMv8 boards. The ratio of estimated to observed WCET values for all benchmarks is greater than 1, demonstrating the security of the analysis.

Improving WCET Evaluation using Linear Relation Analysis

The precision of a worst case execution time (WCET) evaluation tool on a given program is highly dependent on how the tool is able to detect and discard semantically infeasible executions of the program. In this paper, we propose to use the classical abstract interpretation-based method of linear relation analysis to discover and exploit relations between execution paths. For this purpose, we add auxiliary variables (counters) to the program to trace its execution paths. The results are easily incorporated in the classical workflow of a WCET evaluator, when the evaluator is based on the popular implicit path enumeration technique. We use existing tools - a WCET evaluator and a linear relation analyzer - to build and experiment a prototype implementation of this idea.

Calculating WCET estimates from timed traces

Real-time systems engineers face a daunting duty: they must ensure that each task in their system can always meet its deadline. To analyse schedulability they must know the worst-case execution time (WCET) of each task. However, determining exact WCETs is practically infeasible in cost-constrained industrial settings involving real-life code and COTS hardware. Static analysis tools that could yield sufficiently tight WCET bounds are often unavailable. As a result, interest in portable analysis approaches like measurement-based timing analysis is growing. We present an approach based on integer linear programming (ILP) for calculating a WCET estimate from a given database of timed execution traces. Unlike previous work, our method specifically aims at reducing overestimation, by means of an automatic classification of code executions into scenarios with differing worst-case behaviour. To ease the integration into existing analysis tool chains, our method is based on the implicit path enumeration technique. It can thus reuse flow facts from other analysis tools and produces ILP problems that can be solved by off-the-shelf solvers.

Fast, Interactive Worst-Case Execution Time Analysis With Back-Annotation

For hard real-time systems, static code analysis is needed to derive a safe bound on the worst-case execution time (WCET). Virtually all prior work has focused on the accuracy of WCET analysis without regard to the speed of analysis. The resulting algorithms are often too slow to be integrated into the development cycle, requiring WCET analysis to be postponed until a final verification phase. In this paper, we propose interactive WCET analysis as a new method to provide near-instantaneous WCET feedback to the developer during software programming. We show that interactive WCET analysis is feasible using tree-based WCET calculation. The feedback is realized with a plugin for the Java editor jEdit, where the WCET values are back-annotated to the Java source at the statement level. Comparison of this tree-based approach with the implicit path enumeration technique (IPET) shows that tree-based analysis scales better with respect to program size and gives similar WCET values.

Editorial: OOP and discrete math

This issue has three terrific papers. The first, Verification of real-time systems design, by M. Emilia Cambronero, Valentín Valero, and Gregorio Díaz, presents a way to verify aspects of software during design. The second, A systematic representation of path constraints for implicit path enumeration technique, by Tai Hyo Kim, Ho Jung Bang, and Sung Deok Cha, proposes to encode path constraints into ‘flow facts’ to improve the accuracy of implicit path enumeration. The third, Fault localization using a model checker, by Andreas Griesmayer, Stefan Staber, and Roderick Bloem, gives a method for using model checking information to not only identify software failures, but to help find where the corresponding faults may be located. I learned a new word last year. A retronym is a descriptive word that was not needed before a new word came into being. When we started writing object-oriented programs, we needed a new word for what we used to do (procedural programming). Procedural programming had the advantage of following directly from algebra; a C function is essentially an example of applied algebra. We all took algebra in high school, so learning procedural programming in college was straightforward. But OO programming uses concepts that do not appear in algebra! My daughter took Java programming in high school last summer. She was introduced to classes, inheritance and polymorphism as follows: ‘These are new concepts unlike anything you've seen before. Thus they are a bit hard to swallow at first.’ I gave her all kinds of examples from real life (watches and wall clocks inherit from general clocks, rocking chairs and desk chairs inherit from chairs, which inherit from furniture, etc.). But it struck me that we have no mathematical context for this. Yet programming is always very mathematical! I didn't learn OO programming until the end of graduate school in the 1980s. In fact, I didn't see information hiding until graduate school because I had undergraduate majors in math and business programming. As a math student, I took some abstract, way out, ‘useless,’ classes such as logic and set theory, Boolean logic, linear algebra, abstract algebra, and number theory. At the time, I thought it helped me have fun with the Rubiks cube, and little did I know these classes were preparing me to be an OO programmer … When I first learned about data structures and information hiding, they were not ‘new concepts.’ They were simply non-rigorous abstract algebras: sets of values with functions. Stacks and queues are not always complete or consistent, but they are useful! What's the point? The point is that teaching procedural programming is easy and natural because students have a solid grounding in elementary algebra. They are only applying concepts they already know. But teaching them OO is hard, because they have not studied logic and set theory, let alone Boolean and abstract algebras! First year CS students today usually take two semesters of OO programming and two semesters of calculus. In their third semester, they take data structures and multi-variable calculus or differential equations. Finally, in their fourth semester (or later) they squeeze in a discrete math class. But by then it is too late to help them with their elementary OO programming!! It's hard to know how much three semesters of calculus will help a CS student, but I believe an early class or two in discrete math would help them enormously. In fact, they probably need to take discrete math much earlier, before high school programming. They can certainly learn discrete math before the traditional pre-calculus, trigonometry, algebra 2, or even geometry. Perhaps this is why high school students think our field is ‘boring,’ ‘hard,’ ‘useless,’ and ‘only for nerds.’ Perhaps this is why programming seems so hard. Perhaps if we taught discrete math before OO programming, students would start studying computing disciplines again—and we wouldn't need so much testing. 25 January 2010

A systematic representation of path constraints for implicit path enumeration technique

AbstractAccuracy of implicit path enumeration technique (IPET), which statically estimates the worst‐case execution time of a program using integer linear programming, relies on flow information captured as flow facts. Unfortunately, flow facts are inadequate for capturing complex and often subtle path constraints such as causalities. Manual annotation often introduces many disjunctions, and performance of IPET computation suffers significantly. This paper proposes a technique of encoding a subset of path constraints into flow facts. The technique has advantages over conventional approaches: (1) translation process is fully automated and (2) efficient IPET computation is possible because generated flow facts are compact in that they contain at most one disjunction. To demonstrate the effectiveness of our technique, a software tool was implemented to automatically generate flow facts for the subset of path constraints and case study has been conducted using public benchmark suites, GNU openSSH codes, and Korea multi‐purpose satellite (KOMPSAT‐1) software. Copyright © 2009 John Wiley & Sons, Ltd.