VEST: Virginia Embedded Systems Toolkit* Professor Jack Stankovic Department of Computer Science University of Virginia October 2001 Supported, in part, by the Darpa PCES program.

Outline Motivation/The Problem Overview of the VEST Tool (A Few) Research Questions What this tool is NOT! Summary/Status

Embedded Systems Engine control Wristwatch Modems Mobile phone Internet appliances Process Control Air Traffic Control 60 Processors in Limo Smart Spaces Sensor/Actuator/CPU clouds with movable entities Smart dust

Smart Spaces Smart School Smart Classroom Smart City Smart Factory Pervasive Global Connectivity

Key Issue Enormous numbers of devices and amounts of software needed –flexible and tailored (off-line for some systems; on-line for others) –interaction with physical/distributed environment (of greater heterogeneity - not just cpus) –many constraints power, mobility, real-time, cost, memory size, ft, etc. How do we develop, tailor, optimize software for such systems in a cost effective manner?

Solution domain specific program composition –take embedded systems software from libraries –map to HW (sensors, actuators, CPUs, etc.) –tailor and optimize HW/SW –automate analysis and dependency checks address hidden dependencies (cross-cutting concerns - aspects)

Program Composition Goal: building a tool that enables component- based construction and analysis of embedded systems –flexible –tailored –considers power, mobility, distribution, heterogeneity, wireless, sensors, actuators, scale, performance

What is a Component? High level components (Corba, DCOM, Java Beans) –reusable, reliable, tailor, dynamic, written by domain experts, … –slow, unpredictable, weak on non-functional properties (performance (real-time), dependability, …), hard to modify Need - Embedded System Components

How is it different? Performance concerns such as meeting deadlines; dependability concerns Physical environment linkage is paramount Global analysis needed Not necessarily third party –careful control over library Domain specific –avionics, smart hospital,... Hypothesis: Significant amounts of attached reflective information (dependencies) are needed

Perspective/Design Tools Requirements Design/Design Analysis Synthesis/(Components with Analysis) VEST

VEST Configuration Tool Components Micro-components Infrastructures Reflective Infor. Dependencies ASPECTS Composition Dependency Checks Analysis Configuration Tool Analysis Tools Infrastructure Embedded System Factual Inter-component Aspects General Real- Time Reliability

Configuration Tool Base Libraries SW OS Middleware Aspects Domain Code HW Infrastructures Product Library Composition Dependency Checks Analysis Configuration Tool Browse Compose Check Analysis Tools Factual Inter-component Aspects General Real- Time Reliability Map to Process Map to HW Dependency Checks Dependency Checks

VEST Workspace

Reflection Methodology Identify the reflective information (semantics) Retain the information in tools/on disk Perform dependency checks and analysis based on that information Retain the information at runtime (flexibility) Expose the information to the application code

Factual Code ComponentID Flag: SW/HW WCET Memory/Size Data Bandwidth Importance Deadline Security Jitter Power speed reliability size cost accuracy sensitivity range Bus, memory, processors, cache, D/A, A/D, sensor, actuator, co-processor, DSP, Networks HW

Inter-component Dependencies Interfaces (parameters and types) Call graph Precedence Requirements Waits for Exclusion requirements Version compatibility Included in

ASPECTS If it can not be cleanly encapsulated in a generalized procedure –affect the performance or semantics of components Examples (categories) –end-to-end real-time performance –dependability –security –concurrency and synchronization –optimizations

Examples of Aspects Logging in Apache Web server Pre-fetching in OS Simple embedded system, then add kill primitive Periodic tasks only, then add aperiodics Change system to use spin locks Sizing Message Buffers Many examples with Concurrency and RT performance

Dependency Checks From the simple to the complex –Ex. 1: Is there sufficient memory? (factual) –Ex. 2: Are the input parameters of the correct number and type? (inter-component) –Ex. 3: Are interrupts disabled/enabled properly? (aspect) –Ex 4: Is the end-to-end real-time constraint being met? (analysis)

Example: RT Analysis Components/Tasks Platform Components WCET D Resources Precedence Speed Bandwidth Network protocols Mapping Composed (Distr) System Analysis - H() Workload Reflective Information

Research Questions What are language independent aspects? –Modular constraints (Vanderbilt) –Instructions on how to change or test components What are the hidden dependencies that exist in real-time and embedded systems; how do we make these dependencies visible –produces an effective methodology? How to integrate component composition with design time tools

What this tool is NOT A complete requirements/specification/design tool –rather it concentrates on improving composition of components from embedded systems libraries No proofs of correctness –avoids common errors, avoids insidious cross cutting errors that can crop up when composing library based components

Summary Status: –first version of tool is operational –second version to include: support for objects, events mapping to active processes and HW additional aspect checks –being migrated to GME

Reflection - Example PCB - not reflective registers ptr to stack priority registers ptr to stack priority PCB Reflective deadline FT requirements part of group What it takes to execute!

Reflection in RTOS Enhances visibility of information between levels (off-line to on-line) –FT and RT information –Individual module and system-wide policies Simple Examples vs T1 = P1; T2 = P2; T3 = P3; Lost information FT 3 exec. Node 1 Node 2 Node 3 System does not know they are related