Worst Case Execution Time Analysis for Modern Hardware Architectures

Knowing the worst case execution times #WCETs# for programs are crucial for the design and veri#cation of real-time systems. Modern hardware architectures utilize pipelinedexecution and cache memory for improved performance. We extend an existing execution time analysis technique, the Implicit Path Enumeration Technique #IPET#, to consider these and other modern hardwarearchitecturefeatures. We extend IPET in two stages. First, we annotate the control #ow graph of the program with variables representing the history of execution, thus allowing the state of architectural entities, such as cache and pipeline, to be determined before each basic block. Secondly, we model the architectural entities with constraints. The result is an equation which contains a complete model of how the program will execute on the modeled architecture. This novel idea provides a straightforward and #exible way of incorporating the behavior of various modern hardwarearchitecturefeatures into WCET analysis

Supporting Early Modeling and End-to-end Timing Analysis of Vehicular Distributed Real-Time Applications

REACTION 2012. 1st International workshop on Real-time and distributed computing in emerging applications. December 4th, 2012, San Juan, Puerto Rico.The current model- and component-based development approaches for automotive distributed real-time systems have non-existing, or limited, support for modeling network traffic originating from outside the vehicle, i.e., vehicle-tovehicle, vehicle-to-infrastructure, and cloud-based applications. We present novel modeling and analysis techniques to allow early end-to-end timing analysis of distributed applications based on their models and simple models of network traffic that originates from outside of the model. As a proof of concept, we implement these techniques in the existing industrial tool suite Rubus- ICE which is used for the development of software for vehicular embedded systems by several international companies. We also conduct an application-case study to validate our techniques.This work is supported by the Swedish Knowledge Foundation (KKS) within the project FEMMVA. We thank the industrial partners Arcticus Systems, BAE Systems Hägglunds and Volvo Construction Equipment (VCE), Sweden

Uml-based modeling of non-functional requirements in telecommunication systems. In:

Abstract-Successful design of real-time embedded systems relies heavily on the successful satisfaction of their non-functional requirements. Model-driven engineering is a promising approach for coping with the design complexity of embedded systems. However, when it comes to modeling non-functional requirements and covering specific aspects of different domains and types of embedded systems, general modeling languages for real-time embedded systems may not be able to cover all of these aspects. One solution is to use a combination of modeling languages for modeling different non-functional requirements as is done in the definition of EAST-ADL modeling language for automotive domain. In this paper, we propose a UML-based solution, consisting of different modeling languages, to model non-functional requirements in telecommunication domain, and discuss different challenges and issues in the design of telecommunication systems that are related to these requirements

Run-Time Monitoring of Timing Constraints: A Survey of Methods and Tools

Abstract-Despite the availability of static analysis methods to achieve a correct-by-construction design for different systems in terms of timing behavior, violations of timing constraints can still occur at run-time due to different reasons. The aim of monitoring of system performance with respect to the timing constraints is to detect the violations of timing specifications, or to predict them based on the current system performance data. Considerable work has been dedicated to suggesting efficient performance monitoring approaches during the past years. This paper presents a survey and classification of those approaches in order to help researchers gain a better view over different methods and developments in monitoring of timing behavior of systems. Classifications of the mentioned approaches are given based on different items that are seen as important in developing a monitoring system, i.e., the use of additional hardware, the data collection approach, etc. Moreover, a description of how these different methods work is presented in this paper along with the advantages and downsides of each of them

Introducing Database-Centric Support in AUTOSAR

Abstract-We propose to integrate a real-time database management system into the basic software of the AUTOSAR component model. This integration can be performed without violating the fundamental principles of the component-based approach of AUTOSAR. Our database-centric approach allows developers to focus on application development instead of reinventing data management techniques or develop solutions using internal data structures. We use state-of-the-art database pointer techniques to achieve predictable timing, and database proxies to maintain component encapsulation and independence of data-management strategies. The paper illustrates the feasibility of our proposal when database proxies are used to manage the data communication between components and to perform run-time monitoring on the virtual function bus. Our implementation results show that the above benefits do not come at the expense of less accurate timing predictions while only introducing a total application CPU overhead, in the order of 4%

Worst Case Delay Analysis of a DRAM Memory Request for COTS Multicore Architectures

ABSTRACT Dynamic RAM (DRAM) is a source of memory contention and interference problems on commercial of the shelf (COTS) multicore architectures. Due to its variable access time, it can greatly influence the task's WCET and can lead to unpredictability. In this paper, we provide a worst case delay analysis for a DRAM memory request to safely bound memory contention on multicore architectures. We derive a worst-case service time for a single memory request and then combine it with the per-request memory interference that can be generated by the tasks executing on same or different cores in order to generate the delay bound