Robustness

From Self-Organization Wiki
Revision as of 13:19, 23 June 2009 by Ifeherva (talk | contribs) (New page: ==Robustness as a Design Problem== Even though the term robustness is also quite loose we realized that it can be often routed back to design problems. Usually, only the emergent behavio...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Robustness as a Design Problem

Even though the term robustness is also quite loose we realized that it can be often routed back to design problems. Usually, only the emergent behavior can be easily observed and by this, it is not trivial how the system should be changed on its component behavior level to help it to increase its robustness.

If there is little knowledge about the local rules how can the we draw conclusions and update the system? [Elaborate this sentence more, pls.]


Internal Robustness

[Please explain the term] (We also formulated a possible threat where the designed SOS could show not anticipated possibly harmful behaviors due to bad modeling and design approaches. A solution for this would require the definiton of the term internal robustness.)


System Borders

As a final thought, we think it is important to define the current borders of the system before we start dealing with its robustness. As a simple example could be a "robust" algorithm which obviously cannot withstand a blackout. In what way is it robust then?

Research Questions

  • When properties are emergent, how can you make sure that the

emergent situation is following your intentions? Robustness from within ?