ICyPhy Webex Feb 4 2012: Difference between revisions
From Murray Wiki
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 2: | Line 2: | ||
== Presentations: == | == Presentations: == | ||
* [https://www.cds.caltech.edu/~murray/wiki/images/5/50/NOzay-3Feb13-ICyPhy.pdf Overview of the MuSyC challenge problem (Necmiye)] | * [https://www.cds.caltech.edu/~murray/wiki/images/5/50/NOzay-3Feb13-ICyPhy.pdf Overview of the MuSyC challenge problem (Necmiye)] | ||
* [http://www.icyphy.org/ Review of Berkeley modeling and design space exploration work (Pierluigi)] - limited access on iCyPhy wiki | * [http://www.icyphy.org/icyphy/wiki/uploads/Main/PNuzzo-Feb4 Review of Berkeley modeling and design space exploration work (Pierluigi)] - limited access on iCyPhy wiki | ||
* [https://www.cds.caltech.edu/~murray/wiki/images/2/20/MXu_ControlSynthesis_WebEx_4Feb13_iCyPhy.pdf Review of Caltech correct-by-construction synthesis work (Mumu)] | * [https://www.cds.caltech.edu/~murray/wiki/images/2/20/MXu_ControlSynthesis_WebEx_4Feb13_iCyPhy.pdf Review of Caltech correct-by-construction synthesis work (Mumu)] | ||
| Line 10: | Line 10: | ||
# Identify parts of the design process where logic has to be designed by hand (so that we can try out synthesis). | # Identify parts of the design process where logic has to be designed by hand (so that we can try out synthesis). | ||
# Sensor placement/sensor logic | # Sensor placement/sensor logic | ||
# A unified language to capture multiple views (contract like specs in this language) | # A unified language to capture multiple views (design concerns) and/or abstraction levels (contract-like specs in this language) | ||
# Possible ways to integrate EPS domain specific language and LTL spec generator to other design tools (what that language can/should capture to be useful?) | # Possible ways to integrate EPS domain specific language and LTL spec generator to other design tools (what that language can/should capture to be useful?) | ||
# More interesting distributed control architectures: | # More interesting distributed and/or hierarchical control architectures: | ||
## allowing controllers to share contactors | ## allowing controllers to share contactors | ||
## allowing decisions to be made by voting | ## allowing decisions to be made by voting | ||
## mapping sensing and control points to controllers | ## mapping sensing and control points to controllers | ||
## automatically finding local contracts for controllers | ## automatically finding local contracts for controllers | ||
## automatically explore distributed control architectures using contracts and possibly different specialized analysis and synthesis frameworks | |||
[http://www.icyphy.org/icyphy/wiki/Main/2013February5DesignDriverMeeting Corresponding iCyPhy wiki page (limited access)] | [http://www.icyphy.org/icyphy/wiki/Main/2013February5DesignDriverMeeting Corresponding iCyPhy wiki page (limited access)] | ||
Latest revision as of 21:40, 5 February 2013
Presentations:
- Overview of the MuSyC challenge problem (Necmiye)
- Review of Berkeley modeling and design space exploration work (Pierluigi) - limited access on iCyPhy wiki
- Review of Caltech correct-by-construction synthesis work (Mumu)
Possible directions for future work:
- Continuous-time synthesis
- Modelica like component models
- Identify parts of the design process where logic has to be designed by hand (so that we can try out synthesis).
- Sensor placement/sensor logic
- A unified language to capture multiple views (design concerns) and/or abstraction levels (contract-like specs in this language)
- Possible ways to integrate EPS domain specific language and LTL spec generator to other design tools (what that language can/should capture to be useful?)
- More interesting distributed and/or hierarchical control architectures:
- allowing controllers to share contactors
- allowing decisions to be made by voting
- mapping sensing and control points to controllers
- automatically finding local contracts for controllers
- automatically explore distributed control architectures using contracts and possibly different specialized analysis and synthesis frameworks
Corresponding iCyPhy wiki page (limited access)
References:
- 767 Electric Power System Modeling in SysML, J. Finn, M. Mazumdar, and A. Sangiovanni-Vincentelli. MuSyC Public Report 2011.
- An Aircraft Electric Power Testbed for Validating Automatically Synthesized Reactive Control Protocols, Robert Rogersten, Huan Xu, Necmiye Ozay, Ufuk Topcu, and Richard M. Murray. Hybrid Systems: Computation and Control (HSCC) 2013.
- A Domain-Specific Language for Reactive Control Protocols for Aircraft Electric Power Systems, Huan Xu, Necmiye Ozay and Richard M. Murray, working paper.
- Reactive Protocols for Aircraft Electric Power Distribution, Huan Xu, Ufuk Topcu, and Richard M. Murray. 2012 Conference on Decision and Control (CDC).
- Distributed Power Allocation for Vehicle Management Systems, Necmiye Ozay, Ufuk Topcu and Richard M. Murray. IEEE Conference on Decision and Control (CDC), 2011.
- TuLiP: a software toolbox for receding horizon temporal logic planning, Tichakorn Wongpiromsarn, Ufuk Topcu, Necmiye Ozay, Huan Xu, and Richard M. Murray. International Conference on Hybrid Systems: Computation and Control, 2011.
