1 / 24

Integrated Design and Analysis Tools for Software-based Control Systems Software Enabled Control

Integrated Design and Analysis Tools for Software-based Control Systems Software Enabled Control. Lead Investigators Shankar Sastry Edward A. Lee Tom Henzinger Alberto Sangiovanni-Vincentelli Other Investigators Luca Berardi Luca de Alfaro Magnus Egerstedt

gitel
Download Presentation

Integrated Design and Analysis Tools for Software-based Control Systems Software Enabled Control

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. Integrated Design and Analysis Tools for Software-based Control SystemsSoftware Enabled Control Lead Investigators Shankar Sastry Edward A. Lee Tom Henzinger Alberto Sangiovanni-Vincentelli Other Investigators Luca Berardi Luca de Alfaro Magnus Egerstedt Laurent El Ghaoui Ben Horowitz Karl Johansson John Koo Jie Liu Xiaojun Liu John Lygeros Rupak Majumdar George Pappas Santosh Philip Claudio Pinello Maria Prandini Shahid Rashid Jean-Francois Raskin Shawn M. Schaffert Hyunchul Shim Bruno Sinopoli Slobodan Simic Rene Vidal OCP Participation Summary UC Berkeley

  2. Objectives • OCP participation • “run-time support methods for hybrid and multi-modal systems.” • Component architectures • maintain efficiency • compose properties • Understand designs • reduce reliance on simulation • correct-by-construction implementations • rely on pre-proven frameworks • Orthogonalize concerns • regimes of operation • federated coordination

  3. Trajectory Plan • Study group (weekly++): • ... • 9/7 CORBA (part I) -- Concepts • 9/9 CORBA (part II) -- Java IDL • 9/14 TAO and Quality of Service in CORBA • 9/17 RT-IDL and Scheduling for Embedded Systems • 9/21 Case Study -- Helicopter Control Systems • 9/28 Real-time Operating Systems -- QNX/PSOS/VxWorks • 10/5 The Time-Triggered Architecture • 10/12 Timed Automata Verification • 10/19 Planning for kickoff meeting • ... • Architecture for Berkeley AERobots (BEAR) project • (RT) Corba experimental platform

  4. BEAR Research Platform NovAtel DGPS Ground Station thanks to: David H. Shim UAV’s Wireless ethernet WaveLan Accesspoint Landing Deck ethernet Wireless ethernet LabWindows GUI ethernet Wireless ethernet Ground Mobile Robots Silicon Graphics PC WaveLAN: T. John Koo Pioneer mobile rotot: Omid Shakernia, Frank Hoffman Pitching deck landing pad: Tulio Ground Monitoring System

  5. Ursa Minor3 thanks to: David H. Shim Boeing DQI-NP on fluid mounting GPS Card GPS Antenna Wireless Modem Length: 1.4m Width: 0.39m Height: 0.47m Weight: 9.4 kg Engine Output: 2.8 bhp Rotor Diameter: 1.5m Flight time: 15 min System operation time: 30 min Navigation computer Radio Receiver

  6. Navigation Hardware (Ursa Magnus) thanks to: David H. Shim 1. Ursa Magnus 2: Boeing DQI-NP based system Li-Ion Batt Li-Ion Batt Power Board Power Board 85MB Flash Disk 64MB RAM Servo System Longitudinal Lateral Main Collective Tail Collective Engine Throttle Servo System Longitudinal Lateral Main Collective Tail Collective Engine Throttle CTC CTC T/O Board T/O Board Ethernet running QNX CPU Penitum 233MMX CPU P-233 WaveLAN Wireless Ethernet PC-104 Stack RS-232 RS-232 PC-104 Stack RS232 RS232 RS232 RS232 RS232 NovAtel GPS RT-2 NovAtel GPS RT-2 W/L Modem 1 -Data Download W/L Modem 1 -Data Download W/L Modem 2- Differential GPS Compass Boeing DQI-NP

  7. OCP = Component-Based Design First principle: We seek software architectures for modular construction of distributed control systems. Backplane approach: OCP software components hardware components RT CORBA interface

  8. Run-Time Models • Key issue: What interface to expose at the OCP level? • OO methods? • Event notification? • Irregular or low rate? • Wrappers for legacy components? Interface definition depends on the model of computation. OCP software components COTS hardware component wrapper component

  9. Model of Computation • Component ontology • processes? objects? procedures? • reactive? active? passive? • Component epistemology • visibility of other components • global information, such as time • reflection and introspection • Interaction protocols • synchronization? push? pull? • delivery guarantees • Interaction lexicon • vocabulary of messages • type system A model of computation is the ontology and epistemology of components together with the protocols and lexicon of their interaction.

  10. CORBA • CORBA provides • distributed objects with location transparency • synchronous (two way) remote method invocation • asynchronous (one way) remote method invocation • deferred synchronous invocation (at higher cost) • COS/CES event channel provides: • asynchronous notification • publish & subscribe • RT event service: • prioritized dispatching • periodic event processing • active consumers and suppliers

  11. Presumed Model of Computation • Component ontology • Objects (CORBA) and processes (TAO) • Component epistemology • publish & subscribe, with event filtering • time is reduced to priorities • Interaction protocols • few constraints … anything is possible. • Interaction lexicon • CORBA method arguments, return values Similar to Linda and JavaSpaces, but with real-time extensions.

  12. Draft Static Structure of a Helicopter

  13. Event Examples • initialize GPS • initialize INS • issue flight command • GPS re-initialize INS (at 1 Hz) • flight control reacts to INS data (at 50 Hz) • sensors notify of landing • height meter publishes distance to ground Excluded • servo loops (control laws) • all fine-grain interaction • all continuous interaction

  14. Hierarchical Component-Based Design Use different interaction mechanisms at the various levels.

  15. Alternative Component Interactions • Hybrid systems • hierarchical nesting of automata and ODEs • is the event channel relevant? How to use it? • Modal models • hierarchical nesting of automata and anything else • are mode changes events in the event channel? • Hard-real-time models • event channel seems more suited to notification of irregular events than to sampled-data signals. How can we extend architectural principles to these alternative models?

  16. Relevant Models of Computation • Publish and subscribe (Linda, JavaSpaces) • Transition systems, state machines... • Synchronous-reactive systems (SR) • ODEs and PDEs (continuous dynamics) • Discrete time (difference equations) • Discrete-event systems (DE, VHDL, Verilog) • Sequential processes with rendezvous (CSP) • Process networks (Kahn) • Dataflow (Dennis) • ...

  17. Proposal • Identify a small suite of MoCs useful for distributed control system design • one will not be enough • architecture at all levels • Study inter-domain semantics • verifiability • comprehensibility • Emphasize what is common across MoCs • abstract syntax for component architecture • semantic commonalities (such as type systems)

  18. Generic Component Architecture(an abstract syntax) For CORBA, relations mediate name service, event channel, and RPC functions. The OCP effort should first agree on an abstract syntax.

  19. Hierarchy & Abstraction Ideally, aggregations of components behave like primitive components. homosemantic composition.

  20. Sequential Composition is Homosemantic • Statements in imperative languages • Procedures • Objects • State machines • Transition systems • Processes and threads are not homosemantic

  21. Abstract Semantics • Data transport • broadcast • publish & subscribe • multicast • push/pull • messages or RPC • synchronization • delivery guarantees • typing • polymorphism The OCP effort should focus on defining its abstract semantics - independent of an implementation, what behavior do we want in component interactions?

  22. Key Points • Heterogeneous hierarchical models can isolate certain sources of complexity, e.g. separating modes from dynamics or events from dynamics. • Consistent use of input/output views of component models facilitates their hierarchical composition (and is consistent with an event-channel transport mechanism). • At all levels, there is a component architecture. Share infrastructure.

  23. Mission Plan • OCP participation (Repeated) • “run-time support methods for hybrid and multi-modal systems.” • Understand application area • software architecture perspective. • Realize event-level architecture • characterize intercomponent interaction semantics. • Realize multi-level architecture • characterize interlevel semantics. • Develop validation methods. • coupled with intercomponent interaction semantics

  24. Conclusions • We are about component based design of real-time, safety-critical control systems. • Dialog should be about models of computation and component architectures. • Agreement should be about abstract syntax, abstract semantics (first).

More Related