Difference between revisions of "ICyPhy Webex Feb 4 2012"

From MurrayWiki
Jump to: navigation, search
 
(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:

Possible directions for future work:

  1. Continuous-time synthesis
  2. Modelica like component models
  3. Identify parts of the design process where logic has to be designed by hand (so that we can try out synthesis).
  4. Sensor placement/sensor logic
  5. A unified language to capture multiple views (design concerns) and/or abstraction levels (contract-like specs in this language)
  6. 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?)
  7. More interesting distributed and/or hierarchical control architectures:
    1. allowing controllers to share contactors
    2. allowing decisions to be made by voting
    3. mapping sensing and control points to controllers
    4. automatically finding local contracts for controllers
    5. automatically explore distributed control architectures using contracts and possibly different specialized analysis and synthesis frameworks

Corresponding iCyPhy wiki page (limited access)

Richard's MuSyC project page

References: