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.

OutlineOutline

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

Motivation

• 1998– 100 million processors for workstations

– 6.4 billion for embedded systems

– approximately 2%

• 2001– approximately 0%

• Ubiquitous computing (seemless, invisible,pervasive, amorphous, …)

Embedded SystemsEmbedded 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 SpacesSmart Spaces

Smart School

Smart Classroom

Smart City

Smart Factory

• Pervasive• Global Connectivity

Key IssueKey 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?

SolutionSolution

• 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 CompositionProgram 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?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?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 ToolsPerspective/Design Tools

Requirements

Design/Design Analysis

Synthesis/(Components with Analysis)

VEST

VEST Configuration ToolComponentsMicro-componentsInfrastructures

Reflective Infor.DependenciesASPECTS

CompositionDependencyChecks Analysis

Configuration ToolAnalysis Tools

• Infrastructure• Embedded System

• Factual• Inter-component• Aspects• General

• Real- Time• Reliability

Configuration ToolBase Libraries• SW

• OS• Middleware• Aspects• Domain Code

• HW• Infrastructures

Product Library

Composition DependencyChecks

Analysis

Configuration ToolBrowseComposeCheck

Analysis Tools

• Factual• Inter-component• Aspects• General

• Real- Time• Reliability

Map to Process

Map toHW

DependencyChecks

DependencyChecks

VEST WorkspaceVEST Workspace

Reflection MethodologyReflection 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

FactualFactual

Code

ComponentIDFlag: SW/HW

WCETMemory/SizeDataBandwidthImportanceDeadlineSecurityJitterPower

Powerspeed

reliabilitysize cost

accuracy sensitivity

range

Bus, memory, processors, cache, D/A, A/D, sensor, actuator, co-processor, DSP,Networks

HW

Inter-component Dependencies

Inter-component Dependencies

Interfaces (parameters and types)Call graphPrecedence RequirementsWaits forExclusion requirementsVersion compatibilityIncluded in

ASPECTSASPECTS

• 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 AspectsExamples 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 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 AnalysisExample: RT Analysis

Components/Tasks Platform Components

WCETDResourcesPrecedence

SpeedBandwidthNetwork protocols

Mapping Composed (Distr) System

Analysis - H()Workload

Reflective Information

Research QuestionsResearch 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 NOTWhat 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

SummarySummary

• 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 - ExampleReflection - Example

PCB - not reflective

registers

ptr to stack

priority

registers

ptr to stack

priority

PCB Reflective

deadline

FT requirementspart of group

What it takes toexecute!

Reflection in RTOSReflection 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

1

2

3

1

2

3

vs

T1 = P1; T2 = P2; T3 = P3;Lost information

FT3 exec.

Node 1 Node 2 Node 3System does not know they are related