Transcript VEST: Virginia Embedded Systems Toolkit* Professor Jack Stankovic Department of Computer Science

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
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 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
• Pervasive
• Global Connectivity
Smart School
Smart Classroom
Smart City
Smart Factory
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 componentbased 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
Configuration Tool
Analysis Tools
Reflective Infor.
Dependencies
ASPECTS
Composition
• Infrastructure
• Embedded System
Dependency
Checks
• Factual
• Inter-component
• Aspects
• General
Analysis
• Real- Time
• Reliability
Configuration Tool
Base Libraries
Configuration Tool
Browse
Compose
Check
Analysis Tools
• SW
• OS
• Middleware
• Aspects
• Domain Code
• HW
• Infrastructures
Product Library
Composition
Dependency
Checks
• Factual
• Inter-component
• Aspects
• General
Map to
Process
Map to
HW
Dependency Dependency
Checks
Checks
Analysis
• Real- Time
• Reliability
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
ComponentID
Flag: SW/HW
Code
WCET
Memory/Size
Data
Bandwidth
Importance
Deadline
Security
Jitter
Power
HW
Bus,
memory,
processors,
cache,
D/A,
A/D,
sensor,
actuator,
co-processor,
DSP,
Networks
Power
speed
reliability
size
cost
accuracy
sensitivity
range
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
Workload
Analysis - H()
Composed (Distr) System
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
What it takes to
execute!
PCB Reflective
registers
ptr to stack
priority
deadline
FT requirements
part of group
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
1
2
3
vs
1
2
FT
3 exec.
3
T1 = P1; T2 = P2; T3 = P3;
Lost information
Node 1
Node 2
Node 3
System does not know they are related