Model-based Design and Network Centric Systems

Size: px

Start display at page:

Download "Model-based Design and Network Centric Systems"

Winifred Lynch
5 years ago
Views:

1 Model-based Design and Network Centric Systems Janos Sztipanovits ISIS, Vanderbilt University DATE 2006 Munich, Germany March 6, 2006

2 Content Model Based Design and MIC Modeling Model Data Management Model Transformation Tool Integration Modeling in dynamic architectures Modeling in sensor network applications

3 Goal and Approaches Building increasingly complex networked embedded systems from components Naïve plug-and-play approach does not work in embedded systems (neither in larger nonembedded systems) Model-based software design focuses on the formal representation, composition, analysis and manipulation of models during the design process. Approaches with differences in focus and details MDA: Model Driven Architecture MDD: Model-Driven Design MDE: Model-Driven Engineering MIC: Model-Integrated Computing

Model-Integrated Computing Approach (ISIS-VU) Domain-Specific Environments Modeling Domain Specific Design Flows: Examples in MIC: ECSL - Automotive ESML - Avionics SPML - Signal Processing

Metaprogrammable Tools, Environments Metamodeling and Metaprogrammable Tools: (mature or in maturation program) GME (Generic Model Editor) GReAT (Model Transformation) OTIF (Tool Integration

4 Model-Integrated Computing Approach (ISIS-VU) Domain-Specific Environments Modeling Domain Specific Design Flows: Examples in MIC: ECSL - Automotive ESML - Avionics SPML - Signal Processing CAPE/eLMS Learning Technology AADL. Metaprogrammable Tools, Environments Metamodeling and Metaprogrammable Tools: (mature or in maturation program) GME (Generic Model Editor) GReAT (Model Transformation) OTIF (Tool Integration Framework) UDM (Universal Data Model) DESERT (Design Space Exploration) dotransition (fsm as FSM, s as State, t as Transition) = require s.active step exitstate (s) step if t.outputevent <> null then emitevent (fsm, t.outputevent) step activatestate (fsm, t.dst) Semantic Foundation Libraries Modeling Semantics (work in progress): Semantic Units Semantic Anchoring

5 Metamodeling Layer Objectives Structural Semantics interface Event structure ModelEvent implements Event case ModelEvent1 Domain models Interchange Formats M C Abstract Syntax Meta-models M S Semantic Domain: Set-Valued Metamodeling Model Data Management Model Transformation Tool Integration

6 Metamodeling and Domain Specific Modeling Languages Domain Specific Modeling Language (DSML) Abstract Syntax A Concepts Relations Well formed-ness rules L = < C, A, S, M S, M C > M C Semantic Mapping M S Parsing Semantic Domain S Mathematical abstraction for specifying the meaning of models Concrete Syntax C Notation for representing models Model: precise representation of artifacts in a modeling language L Modeling language: defined by the notation (C), concepts/relations and integrity constraints (A), the semantic domain (S) and mapping among these. Metamodel: formal (i.e. precise) representation of the modeling language L using a metamodeling language L M.

7 Modeling Example: Metamodel and Models Metamodel: - Defines the set of admissible models - Metaprogramms tool Model: - Describes states and transitions - Modeling tool enforces constraints

OCL Paradigm Definition Storage Options Configuration through UML and OCL-based metamodels Extensible

8 Metaprogrammable Modeling Tool: GME Decorator Browser COM GME Editor Decorator COM Constraint Manager GME Architecture Add-On(s) GModel COM CORE XML GMeta ODBC DB #1 XML DB #n Translator(s) XML Metamodel XML UML / OCL Paradigm Definition Storage Options Configuration through UML and OCL-based metamodels Extensible architecture through COM Multiple standard backend support (ODBC, XML) Multiple language support: C++, VB, Python, Java, C#

9 Model Data Management: The UDM Goals To have a conceptual view of data/metadata that is independent of the storage format. Such a conceptual view should be based on standards such as UML. Have uniform access to data/metadata such that storage formats can be changed seamlessly at either design time or run time. Generate a metadata/paradigm specific API to access a particular class of data.

10 Model Data Management: The UDM Tool Suite GME UML XML data file Binary file Network GME GME/UML Interpreter UdmCopy Backends XML MEM CORBA MGA XML (Meta) <Uml.xsd> UDM.exe Validates Generic API UDM Generated code OCL Eval.cpp.h.xsd API Metaobjects User Program

Model Transformation: The Workhorse of MIC S DSML-1 M S1 A DSML1 DM M C1 C Transformation T M DSML1,DSML2 DSML2 DM C M C2 DSML-2 A M S2 S Meta-level: Translator design Metamodel of Input Metamodel of

11 Model Transformation: The Workhorse of MIC S DSML-1 M S1 A DSML1 DM M C1 C Transformation T M DSML1,DSML2 DSML2 DM C M C2 DSML-2 A M S2 S Meta-level: Translator design Metamodel of Input Metamodel of Transformatio n Metamodel of Output MOF A DSML1 MTL T DSML1,DSM2 MOF A DSML2 MOF UMT MOF M 12 : MOF A DSML1 MOF A DSML2 Implementation: Execution Input Models Physical interface Input Interface Input abstract syntax A P I Rewrite Engine GReAT UDM A P I Output abstract syntax Physical interface Output Interface Target Models Relevant Use of Model Transformations: Building integrated models by extracting information from separate model databases Generating models for simulation and analysis tools Defining semantics for DSML-s MIC Model transformation technology is: Based on graph transformation semantics Model transformations are specified using metamodels and the code is automatically generated from the models.

12 Model Transformation: The GReAT Tool Suite Meta-models MetaModel of Source uses MetaModel of Domain-to-Target Mapping uses MetaModel of Target Metaprogrammable tools configures Meta-Programmable Modeling Tool configures Code Generator generates C/G GRE GME describes creates Meta-Programmable Transformation Tool Debugger describes DEBUG Generated tool (Generated) Transformation Tool Models and applications Source Models Target/Executable Models Target Platform Tools: Tools: UMT UMT Language, Language, GRE GRE (engine), (engine), C/G, C/G, GR-DEBUG GR-DEBUG

13 Open Tool Integration Framework: OTIF TOOL TOOL TOOL TOOL ADAPTOR TOOL ADAPTOR TOOL ADAPTOR MANAGER METADATA BACKPLANE REGISTRATION/NOTIFICATION/TRANSFER SERVICES SEMANTIC TRANSLATOR SEMANTIC TRANSLATOR Standard interface/ Protocol Karsai, ISIS-Vanderbilt RFP is Discussed at MIC PSIG OMG Share Share models models using using Publish/Subscribe Publish/Subscribe Metaphor Metaphor Status: Status: Completed, Completed, tested tested in in several several tool tool chains chains Protocols Protocols in in OMG/CORBA OMG/CORBA CORBA CORBA as as a a transport transport layer layer Integration with ECLIPSE is in progress Integration with ECLIPSE is in progress

Integrated MIC Tool Suite Modeling GME Design Space Exploration Model Data Management UDM DESERT Component

Encoding (T E ) Design Space Pruning Meta Models OTIF TOOL TOOL ADAPTOR TOOL TOOL ADAPTOR TOOL TOOL ADAPTOR

REGISTRATION/NOTIFICATION/TRANSFER SERVICES SEMANTIC TRANSLATOR SEMANTIC TRANSLATOR Standard interface/

14 Integrated MIC Tool Suite Modeling GME Design Space Exploration Model Data Management UDM DESERT Component Abstraction (T A ) Component Reconstruction Design Space Modeling (M D ) Design Decoding Design Space Encoding (T E ) Design Space Pruning Meta Models OTIF TOOL TOOL ADAPTOR TOOL TOOL ADAPTOR TOOL TOOL ADAPTOR MANAGER Best of Breed Modeling Tools Simulators Verifiers Model Checkers METADATA BACKPLANE REGISTRATION/NOTIFICATION/TRANSFER SERVICES SEMANTIC TRANSLATOR SEMANTIC TRANSLATOR Standard interface/ Protocol GReAT Open Tool Integration Framework Model Transformation ESCHER Quality Controlled Repository:

Static Architectures Common Semantic Domain

AIF Schedulability Analysis Rational Rose

BoldStroke/ Models capture invariants in

System Integration Mission Control Platform

and Tool Interchange Formats Invariants are

Metamodels) Models are AIRES the basis for

integration/generation ESML AIF ESML AIF

ESML ECSL-DP Meta-Model ESML GME ESML- CFGL

15 Static Architectures Common Semantic Domain Abstract Syntax: Meta-Models Domain Models and Tool Interchange Formats AIRES Component Model Component Structure ESML AIF Schedulability Analysis Rational Rose PRISM ESML Thread Models ESML GME ESML CFG BoldStroke/ Models capture invariants in the system Component Interaction PRISM CFG System Integration Mission Control Platform Tool Chain Common Semantic Domain Abstract Syntax: Meta-Models Abstract Syntax and Transformations: Meta-Models Domain Models and Tool Interchange Formats Invariants are defined on different levels (Models, Metamodels) Models are AIRES the basis for analysis and Meta-Model AIRES system integration/generation ESML AIF ESML AIF Rational Rose PRISM Meta-Model RISM PRISM ESML ECSL-DP Meta-Model ESML GME ESML- CFGL CFG Meta-Model BoldStroke/ PRISM CFG Mission Control Platform Tool Chain

16 Dynamic Architectures I: Service Models Task Models Heterogeneous MoC-s Describe mode dependent service use Dynamic, data-driven instantiation of instances Migration across platform nodes How to characterize this system? How to bind its behavior? Service Models Heterogeneous MoC-s Dynamic binding to Task Model instances Platform-dependent instantiation and replication of services Platform Models Distributed Dynamic, changing interconnections Error-prone communication Changing configurations

17 Service-Oriented Architecture for Sensor Networks Target is an entity (e.g. human) being sensed and serviced Target Object: Representation of the target that drives the application A finite state machine with different modes A task graph for each mode capturing the desired processing The state of the target (distinct from modes) including location, motion, etc. A Target Object can Migrate from one sensor node to another Switch modes based on sensor information Local Scheduler Target Object state Scheduler/Allocator Local Scheduler Local Scheduler Target Local Scheduler In collaboration with Xenofon Koutsoukos, Vanderbilt and Wayne Wolf, Princeton

18 Application and Middleware Services Scheduler/Allocator A run-time system dynamically binds tasks to application services Using an application service requires only its name and interfaces The scheduler/allocator employs middleware services Distributed discovery service Binding service Data distribution service Local Scheduler Target Object state Scheduler/Allocator Local Scheduler Local Scheduler Target Local Scheduler

19 Scheduler/Allocator Distributed discovery service Query neighboring nodes service registry Create a local model of available services Binding service Local operation space exploration using constraint satisfaction Local scheduling of services at each node Target object Service Registry 1. Filter 2. Angle Correction 3. Speed Tracking 4.

20 Use of MIC Tools and Methods Modeling languages for Modes Task flows Service composition System architecture Data

21 DDS: Emerging Standard for Real-Time Data Distribution Data-centric interaction and coordination of activities Distributed data space; interaction through topics Dynamic interaction patterns (Publish/Subscribe) The system continuously changing Mixed (soft, hard, or quasi) real-time interaction requirements Primary concern: efficient data distribution with minimal overhead Requires ability to control QoS properties: predictability, overhead, and resources used Scaling is a critical issue Reliability and fault tolerance is required data_distribution.htm

22 Dynamic Architectures II: Sensor Networks Local Information Processing Heterogeneous MoC-s Describe real-time sensor processing Power aware algorithms Produces compressed data for migrating across platforms (possibly to base station) Services How to characterize this system? How to bind its behavior? Localization Time synchronization Routing Coordination. Complex state automata Tight dependence onbthephysical properties of the platform Emerging global behavior Platforms Fine-grain distributed Dynamic, highly uncertain interconnections Error-prone computation nodes Continuously changing configurations

Example: Vanderbilt Shooter Localization System Urban environment

simultaneous shot resolution Idea: Sensor network with cheap

resource constrained nodes Very limited communication bandwidth

developed by an ISIS team between 2003-2005 (Maroti M., Simon G.

23 Example: Vanderbilt Shooter Localization System Urban environment with echo and no line-of-site Rapid deployment and low cost Multiple simultaneous shot resolution Idea: Sensor network with cheap acoustic sensors, exploiting redundancy Challenges: Severely resource constrained nodes Very limited communication bandwidth Significant multipath effects in urban environment Solution developed by an ISIS team between (Maroti M., Simon G., Ledeczi A., Sztipanovits J.: Shooter Localization in Urban Terrain, Computer, 37(8), 60-61, 2004.)

24 Technical Approach Detect Time of Arrival (TOA) of acoustic shockwave and muzzle blast Application specific acoustic sensor board: 3 acoustic channels (only a single channel is used in final system) High-speed AD converters FPGA for signal processing: shockwave and muzzle blast detection on board Timestamp of shockwave and/or muzzle blast sent to Mica2 mote Mica2 motes route TOA data to base station Base station fuses data, estimates shooter position and displays result Middleware services: Localization Time synchronization Message routing Remote control Tiny OS operating system ad-hoc networking (Ledeczi et.al. Countersniper System for Urban Warfare, ACM TOSN, 2(1), , 2005.)

System Architecture I 2 C UART Sensorboard Time Sync User Interface Muzzle Blast & Shockwave Detector Sensorboard Interface Acoustic Event Encoder Time Sync Sensor Fusion Sensor Location

25 System Architecture I 2 C UART Sensorboard Time Sync User Interface Muzzle Blast & Shockwave Detector Sensorboard Interface Acoustic Event Encoder Time Sync Sensor Fusion Sensor Location Sensorboard Config/ Monitor Data Recorder Message Routing Message Center Remote Controller Stack Monitor Remote Control Download Manager Plotter Logger SENSORBOARD MICA2 MOTE BASE STATION

26 Unique Challenges: Latency Latency < 2 sec ADC Zero Crossing Coder Shock Wave Detector Zero Crossing Filter Muzzle Blast Detector User Interface Sensorboard Interface Acoustic Event Encoder Time Sync Sensor Fusion Network Sensorboard Config/ Monitor Data Recorder Message Routing Message Center Sensor Boards Base Station

27 Unique Challenges: Latency ADC Zero Crossing Coder Latency < 2 sec? Shock Wave Detector fat spanning-tree flooding Zero Crossing Filter Muzzle Blast Detector User Interface Sensorboard Interface Acoustic Event Encoder Time Sync Sensor Fusion Network Sensorboard Config/ Monitor Data Recorder Message Routing Message Center Sensor Boards Base Station

28 Unique Challenges: Time Synch Flooding Time Synchronization Protocol (FTSP) % ADC Zero Crossing Coder Shock Wave Detector average error (µs) maximum error (µs) 90.00% 80.00% 35 syncronized motes (%) 70.00% Zero Crossing Filter Muzzle Blast Detector microseconds % 50.00% 40.00% percentage User Interface 30.00% 20.00% % Sensorboard Interface Sensorboard Config/ Monitor Sensor Boards Acoustic Event Encoder Data Recorder Time Time Sync Sync Message Routing 0 0:00 0:10 0:20 0:30 0:40 0:50 1:00 1:10 1:20 1:30 1:40 1:50 2:00 2:10 START Leader off Time (hh:mm) Network Sensor Fusion Random motes off Half off All on Message Center Base Station 0.00%

Real-life Experiments Sep 2003: Baseline system Apr 2004: Multishot resolution NORTH B1 Church 60 motes covered a 100x40m area Network diameter: ~7 hops Used

mode in 2003 Up to four shooters and up to 10 shots per second in 2004 Variety of shooter locations (bell tower, inside buildings/windows, behind mailbox,

29 Real-life Experiments Sep 2003: Baseline system Apr 2004: Multishot resolution NORTH B1 Church 60 motes covered a 100x40m area Network diameter: ~7 hops Used blanks and Short Range Training Ammunition (SRTA) Hundreds of shots fired from ~40 different locations Single shooter, operating in semiautomatic and burst mode in 2003 Up to four shooters and up to 10 shots per second in 2004 Variety of shooter locations (bell tower, inside buildings/windows, behind mailbox, behind car, ) chosen to absorb acoustic energy, have limited line of sight on sensor networks Hand placed motes on surveyed points (sensor localization accuracy: ~ 0.3m)

30 Conclusions Network Centric Systems offer completely new solutions for old, very hard problems Model-based design and tools are indispensable in their design. Application design frequently spans DSP/HW/SW/Networking with complex interdependences Modeling paradigms are more complex, heterogeneous and model integration is becoming a major challenge

Model-Integrated Computing

Model-Integrated Computing Janos Sztipanovits ISIS, Vanderbilt University janos.sztipanovits@vanderbilt.edu ISIS Parameters Established by the School of Engineering at Vanderbilt University in 1998 Academic/professional