Challenges and Design Issues in a Distributed Measurement scenario

1. Special session in Distributed Measurement Systems INGRID/2008 Challenges and Design Issues in a Distributed Measurement scenario PADOVA UNIVERSITY Dept. of Information Engineering Padova Italy Luigino Benetazzo Matteo Bertocco Giovanni Gamba Alessandro Sona

2. summary • introduction • topology issues • design issues

3. Introduction why communication & measurements should meet?

4. An historical note ... How have instruments evolved in recent years? from analog (only) instrumentation... to... digital instrumentation where A/D and D/A converters, and signal processing provided considerable improvements

5. How have instruments evolved in recent years? from analog (only) instrumentation to... digital instrumentation virtual instruments where digital instrumentation, interfaces, and measurement software provide a new “virtual instrument”, having added functionalities with respect to the actually available physical instruments

6. How have instruments evolved in recent years? internet from analog (only) instrumentation to... digital instrumentation virtual instruments networked instruments where a set of virtual instruments, and computers through some communication links provide a way for remote interaction with instrumentation

7. How have instruments evolved in recent years? from analog (only) instrumentation to... network digital instrumentation virtual instruments networked instruments distributed instruments where a measuring devices are distributed in some geographical areas, while many (hardware & software) components cooperates in order to provide some useful final results

8. How have instruments evolved in recent years? from analog (only) instrumentation to... wireless network digital instrumentation virtual instruments networked instruments distributed instruments wireless distributed instruments where “wireless” has a number of interesting consequences, from mobility, to ad-hoc architectures ...

9. wireless network in the above (wireless distributed measurement system) scenario communication engineer instrumentation & measurement engineer (metrologist)‏ often have a different point o view computer science engineer some key issues are considered, in order to stimulate joint work & research

10. topology issues a snapshot, as seen from the measurement point of view...

11. a DMS, for what ? Distributed Measurement Systems (DMS), can be designed having in mind different applications some examples power quality, land surveillance, pollution monitoring, ... hence, bandwidth, connectivity reliability, time synchronization, etc. may have very different numerical specifications ... this does not mean that any topology can be adopted as far as bandwidth constraints, for instance, are satisfied, because this is a measurement system ... so, let us see what does it means for some topologies...

12. Ad-hoc topology AD-HOC (P2P)‏ advantages consensus-based algorithms greatly simplified (fast convergence)‏ prevents “single point of failure” (redundancy), hence prevents data loss when information flows toward a “master” node data loss means loss of accuracy! scalable, hence the number of nodes may considerably grow

13. Ad-hoc topology AD-HOC (P2P)‏ disadvantages the nodes must be sufficiently “clever” this implies sufficient processing power, energy consumption, and raises costs management of the system is not so easy yes, it is scalable, but since management is somewhat complicated, is this topology really the best choice for a large DMS (possibly with low-cost sensors) ? in practice, a (hopefully) good choice for not too-low-cost sensors, and not too far away located, and not for a large number of nodes

14. STAR Star topology advantages the node can be rather “stupid”, (low computing power, low communication energy, low cost)‏ real-time constraints can be satisfied in an easier manner (with resp. to ad-hoc)‏ disadvantages “static” topology: less flexible, less scalable (round-robin time increases with the number of nodes), ... a good choice for many “industrial applications”, where measurements meets automatic control

15. CLUSTER TREE Cluster-tree topology CLUSTER CLUSTER advantages an improved version of cluster topology inherits advantages, and mitigates drawbacks balances an increased complexity with scalability, even though the hierarchy that it implies can be exploited in order to simplify the management of the network itself disadvantages still exposed to single point failures, and hence its usage may be questionable when a loss of measured data is a detrimental fact a compromise solution choice with respect to ad-hoc and star topologies

16. design issues please, add a dimension to your “usual” perspective...

17. Deployment A DMS is physically created by inserting new measurement nodes, controllers (management items), clients, etc. one aspect in telecom apps. often the nodes are very similar each other in a measurement context, instead, the nodes can significantly differ and hence plug&play features are “a must” for an efficient management of the nodes a “middleware” may be required, that allows dealing with nodes in a unified manner

18. Mobility in a measurement context, mobility means in practice mobility of the Equipment Under Test (EUT), rather than mobility of people performing tests (with some exceptions!)‏ sometimes, mobility is not really required: a wireless connection is adopted just in order to simplifying deployment (cabling, connections, ...)‏ some interesting “exceptions”: - rotating machines - sensors “inside” a product along a production plant

19. Mobility coverage area for telecom apps. means “almost worldwide”, for measurements coverage area means “reach the EUT” in many cases, the area is sufficiently limited so that cell handover is an issue almost out of scope when multiple cells are actually needed, the possible data loss associated to handover implies: in a telecom scenario: degradation of speech/video, delays in a measurement context: loss of measures - more critical, since it implies a worse accuracy

20. Hetereogeneity research works tend to standardize as far as possible the nodes, so that they can be considered almost equal ... but in many practical applications, measurements node significantly differs development of a “middleware layer” that standardize the way nodes are seen from other system components many solutions (de facto, standards, proprietary s/w drivers,...) promise interoperability, in practice this is still a hard task instead of letting proprietary applications do the job, why not to rethink a “compatibility” network layer in a similar manner to the one offered by the widely-known HTTP protocol for the data exchange of web contents? research work!

21. Energy ... Energy-constrained networks is a large research topic different points of view (a meaningful example): signal processing optimize distributed detection and estimation network task while minimizing use of communications communications support network specific goals while minimizing idle listening, network setup and network maintenance systems exploit low power hardware and external assets, to the greatest possible extent metrology how to optimize energy-hungry calibration tasks?

22. Energy Energy-constrained networks is a large research topic different point of view (example): metrology how to optimize energy-hungry calibration tasks? calibration means accuracy! energy optimization can be viewed as the search for compromise solutions that optimize overall accuracy rather than signal processing, communication, or system parameters research work!

23. Synchronization another large research topic many good reasons to provide synchronization: from MAC scheduling, to intrinsic nature of the observed phenomenon the degree of synchronization can greatly vary: coarse synchronization many nodes detect the same event 1s 10-6W accuracy energy ADC sample time accuracy two ADC sample data with a timing accuracy comparably better than the sampling rate 1ns 0.1W many side-effects to be considered: from component's aging to temperature drifts ...

24. Synchronization distributed algorithm measurement synchronization is a key aspect timing requirements may considerably vary, i.e. simultaneous means ensure a “skew” no larger than a given amount, and with a a priori defined accuracy interesting research area: extend the concepts of “trigger” to a “distributed trigger” research work! LXI is an interesting proposal, but a wireless, mobile scenario needs further study

25. Localization many aspects, technologies, proposals... ... and a new requests are daily arising interesting practical applications could benefit from low-cost radio localization technologies, accurate (<1m) but non GPS-based (low-cost, indoor)‏ research work! security (machine-workers interaction) people/devices localization an open question is calibration of a whole localization system

26. Routing & Medium access control distributed measurement systems are - data-centric, - data may have a redundancy nature different from a “video content” - often a preferred flow of information can be stated (eg. towad a host)‏ routing schemes are designed having in mind a general context as far as possible, but is this the right choice, when - timing constraints are rather severe - data flows a “known” (hierarchical) scheme - a “cooperation model” among nodes is stated - nodes are moving research work! ?

27. Reliability a lost packet in a multimedia communications context means quality worsening (psychological or economic aspect)‏ a lost packet in a distributed measurement context means accuracy worsening the concept of reliability needs some investigation how accuracy depends on reliability? which is the relationship between the accuracy loss and well-known network parameters? ... research work!

28. Testing in electronics, “design for testability” concepts are well-known in short, complicated equipments are provided with additional functionalities (hardware, software), so that system testing could be performed in a reasonably easy way a distributed measurement system is complicated in a number of ways: hardware challenges, interference, protocol stacks, software agents,... but testing needs understanding the interaction between the above quite different aspects why not to embed (e.g. in a “protocol stack”) mechanisms that simplify testing, i.e. add a “design for testability” perspective to the already known (or new) architectures? research work!

29. final remarks many other issues: e.g.: cross-layer design, bandwidth, role of signal processing,... ... and “comfort noise”: design of IC in “fast motion” big research groups are hard working but from above discussion, one need should be (at least) clear: researchers on telecommunication instrumentation and measurement computer science should more deeply interact, this will definitely provide an improved value to results!

30. Thank you! Challenges and Design Issues in a Distributed Measurement scenario luigino.benetazzo@unipd.it