Distributed prognostics is the next step in the evolution of prognostic methodologies. As prognostic systems get more intricate with multiple sensors and subsystems deploying complex algorithms, architectures that comprehensively combine the capabilities of new and emerging sensors and powerful computing devices are required. Distributed prognostics collectively refers to such architectures and their enabling technologies. An example of such a distributed prognostics system is shown in the figure below.
Distributed prognostics system
Note that the connection between the sensor devices may be wired or wireless. A wireless connection would enable more flexibility in the system design with regards to placement of sensors. However, wireless connections lead to communication issues, for example a significant amount of time would be spent in ensuring that all the data packets are received and in the correct order.
We envision a system where given a complex system a network of sensors monitor as well as manage the health of the various subsystems. This implies the use of sensor devices that have sufficient computing power as well. Such “smart sensor” devices have already started emerging in the market. Our aim is to utilize this emerging technology using a two-pronged approach. The first approach involves devising suitable system architectures that exploit the characteristics of prognostics systems for efficient performance and includes design of network architectures, communication protocols, memory architectures, task scheduling and so on. The other approach deals with formulation of prognostics algorithms that can optimally utilize the computing power of such distributing processor systems while minimizing penalties incurred by communication between processors.
Central versus distributed system
Current implementations of PHM (Prognostics and Health Management) systems utilize centralized processing units that manage the overall system’s health. In parallel, sub-system providers are working on health management solutions for their products. Most of the time, the CPU of these sub-systems is at idle. An elegant, low-weight solution might tap into this collective CPU idle time, thereby increasing the systems readiness while at the same time preserving other mission critical resources.In addition, centralized systems suffer from problems of problems of potential shutdown and long recovery of the whole system when the central hub breaks down.