Differences

This shows you the differences between the selected revision and the current version of the page.

dpuis:technicaloverview dpuis:technicaloverview 2008/10/22 12:51 current
Line 1: Line 1:
 +====== The D'PUIS framework ======
 +
 +The D'PUIS Framework (dynamic product usage information system) was developed to integrate observation functionality into complex interactive products. This page is intended to show the more technical internal parts of the D'PUIS framework; as this is on-going research this part of the soft-reliability wiki will change from time to time.
 +
 +
 +==== Distribution ====
 +
 +
 +{{dpuis:dpuis_distribution.png?450|}}
 +
 +
 +Possibly product observation spans over a large range of product instances that are distributed over various countries. A way to approach the highly diverse user models that might arise, due to different cultural backgrounds or government policies, is to first aggregate usage information according to context groups before sending the data to a global repository.
 +
 +
 +==== Architecture ====
 +
 +It is hard to generalize an architecture for self-observing systems as the field of application is large and diverse. For us, the areas of consumer electronics products and professional office products matter most, but one can think of many other domains like mobile-applications and smart / ambient environments.
 +
 +We concentrate on products that have a more or less stable connection to the internet or other effective ways to communicate with global observation units. Also hybrid data communication methods are possible, such that local devices share information over one medium like, for instance, bluetooth and periodically aggregated data are transferred via internet to a central instance of observation. So, the communication of data might have to take multiple steps until a central unit is reached.
 +
 +The transfer of captured usage data is not the only information that is exchanged between central unit and local product instances: the configuration of observation is another example. Product instances offer the possibility to be re-configured with a new observation specification. This specification determines what will be observed in the product and also how the captured information will be processed and presented. The transfer of re-configurations has to take place less often than data transfer and can also be performed using a different medium.
 +
 +{{dpuis:soarch_logical_global_view.png?600|}}
 +
 +In the figure above shows the logical structure of product integration. Observation components that access product internals require a structured way to do so. This interface can be only partly generic as the products currently do not support a seamless integration of monitoring facilities. The gray box in figure 2 marks the interface region between platform-specific (left) and platform-independent (right) parts of the overall architecture. The question how to integrate observation components is one of the hard points in this research topic.
 +
 +{{dpuis:soarch_detailed_global_view.png?600|}}
 +
 +The detailed architecture of such a system involves a lot of processing subcomponents, that are shown in figure 3. The depicted observation units (product, intermediate, global) look very same. This changes in actual instantiations of the architecture for specific observation use-cases.
 +
 +As products can offer very limited processing or data storage capabilities, the decision for a concrete instantiation of the architecture depends on these variables. Subsequently the optimal location of processing can be found and also where processing components are not necessary. In the end, a probably lean architecture comes out, that is tailored to the actual observation system.
 +
 +tbc.