Meeting 23. Mar 2011¶
Essential¶
We need- modeling of data-flow and
- modeling of states (FSM)
- States select the active / inactive sub-graphs
- State changes have to care for graceful switching/blending between control modes
We don`t want to imply to hard restrictions on (real-time capable) nodes, but rather test and monitor timing capabilities.
Random notes¶
- Distribution of nodes: low-level
- Welche Teile des Graphen sind unabhaengig (parallelisierung)
- reicht connectivitate
- Arbitrierung vs. priorisierung/scheduling
- instantiation / modeling
- Modeling needs modeling of node parallelization
- contract-based node connection
- error handling
- in data-flow
- in switching modes/graphs/subgraphs
- counting robot errors?
- context (which tasks/control modes are active?)
- robert: not a single point for exception handling
- data-flow vs. hierarchical graph
- submodelules / layers / node groups
- parallelisierung:
- auf data-flow-ebene
- auf node-ebene
- Wir muessen resource-aware sein
- Nodes muessen ueber ihren bedarf informieren
- Nodes bekommen resourcen zugeteilt
- Resource/Speicherzugriff ueber datenzugriff (data nodes) modellieren?
- robert: unguenstig
- Realtime: muss selber speicher alloziieren/memlocken und damit zurechtkommen
- eher weniger restrictions, sondenr ueberwachen
- malloc ueberwachen (eigenen warning-wrapper) definieren
- SCMP reicht nicht
- Syncrhonisierung
- ist queue eine node
- System exception
- User exceptions (aborting task)
- Data-flow model vs state modelm
- State changing capabilities via interfaces
- We need FSM/State
- Wo steht Control-Domaenenwissen (wie kann ich zusatndswechsel machen)
- Parallelisierbarer task
- Abort task while converging
- Pause task while converging and switch to gravcomp (for a while), then return to task