1 / 26

VEST: Virginia Embedded Systems Toolkit*

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

dirk
Download Presentation

VEST: Virginia Embedded Systems Toolkit*

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

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

  3. 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 Embedded Systems

  4. Smart Spaces • Pervasive • Global Connectivity Smart School Smart Classroom Smart City Smart Factory

  5. 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?

  6. 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)

  7. 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

  8. 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

  9. 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

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

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

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

  13. VEST Workspace

  14. 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

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

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

  17. 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

  18. 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

  19. 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)

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

  21. 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

  22. 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

  23. 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

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

  25. 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 1 FT 3 exec. vs 2 2 3 3 Node 1 Node 2 Node 3 T1 = P1; T2 = P2; T3 = P3; System does not know they are related Lost information

More Related