Title: Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea

Authors: Lakshman Krishnamurthy, Robert Adler, Phil Buonadonna, Jasmeet Chhabra, Mick Flanigan, Nandakishore Kushalnagar, Lama Nachman, Mark Yarvis

Affiliation: Intel Corporation, Arched Rock

Published: SenSys 2005

Summary

• The paper presents experiences with sensor network deployment for predictive maintenance. There are two deployments described in the paper: an industrial environment, and a shipboard deployment.
• The paper also documents experience with two different platforms for implementing the same application.
• Predictive maintenance (PdM) has many goals:
  • Reduction in catastrophic failures
  • Move from calendar-based maintenance to indicator-driven maintenance
  • Quantify a new system within the warranty period
  • Meet factory uptime and reliability requirements
• Paper focuses on vibration analysis. Other techniques for PdM include oil analysis, infrared thermography, ultrasonic detection.
• Goals of paper:
  • Validation of requirements for PdM
  • Effect of deployment environment on sensor network
  • Assessment of sensor node platform characteristics
  • Experience from an extended period of deployment
• The possible approaches to PdM are:
  • Online system: needs to be planned at the time of industry layout; can be expensive
  • Manual system of taking vibration readings: labour is expensive, quality of prediction may not be adequate
  • Use sensor network: cost is inbetween the above two

Site planning

• Necessity of site planning:
  • Assess RF coverage
  • Check for any RF interference
  • Mechanics: where to place the various nodes
• Their site survey showed no RF interference, and in general good radio connectivity.
• Connectivity was better at larger frequencies; 433MHz had connectivity problems: could not penetrate some barriers.
• Note: the metal in industrial environments probably tends to improve connectivity through reflections, unlike office environments.

Requirements

• Fault tolerance and reliable data delivery
• Long-lived battery-powered operation
• Maintainability
• Seamless integration into existing diagnostic applications: this prevented them from using any in-network data processing; the data was fed raw into a proprietary application.
• Security (was not really an issue in their deployment)

Protocols used

• Hierarchical communication structure, with stargate gateways for every few sensor nodes
• Cluster-based power management protocol: periodic sleep wake-up. It is not clear though as to what exactly happens after a cluster is woken up. Do the nodes transfer data one after another? Presumably. Also, cluster selection mechanism is not explained very clearly.
• PSFQ was used as a reliable transport mechanism.
• Single-destination DSDV protocol is used for routing. Is this routing done every time the nodes wakeup? This is not clear.

Evaluation

• Mica2 performance was worse than that of the Intel motes, since it had 10 times lower throughput. Also, the performance of the mica2 clusters was variable across clusters. This was due to heavy interference in the 433MHz band from a nearby power line equipment, in the case of the mica2 motes. The Intel motes' performance was consistent across clusters.
• In sleep mode, the Intel platform consumes more power than the mica2 platform. This is because of the requirement of Bluetooth nodes to be in sync with one another. This can be avoided by using an external RTC (real-time clock).
• The sleep time in the shipboard deployment was in the range 5-18 hours.

Positive points

• Another concrete sensor network application, with reference to which future research/development can be driven
• Documentation of experience is useful
• Comparison between the two sensor network platforms is useful

Negative points

• The cost analysis given in Table-1 needs explanation, without which it is not very useful.
• Some more details on the various protocols (cluster formation, routing, wakeup, transport, etc) would have been more useful. Especially, more in-depth analysis of what exactly was not ideal in these protocols may have been useful for future protocol study.
• It is not clear why a different sleep schedule was used for the shipboard deployment. Also, the set of graphs shown for the shipboard deployment is completely different from the set shown for the industrial deployment.
• It appears that reliable data transfer was not used in the shipboard deployment, since there are gaps in the data collection. Why not use reliable data delivery for this deployment too?
• The diagnosis in Table-5 for the reason for failures in the shipboard deployment is superficial (especially the cases where RF interference/loss of sync is surmised as the possible reason). How exactly is the diagnosis of possible cause done?