Smart sensing is here! CAN-MD® is a new digital sensing platform for machinery diagnostics.
Vibration sensors (unlike temperature, pressure, inertia, load, and other slowly changing physical measurement parameters) produce incredible volumes of dynamic data. Streaming raw vibration data from multiple nodes in a bussed environment is not possible given the limitations of bus processing speeds. Prior to CAN-MD®, dynamic vibration sensors capable of sophisticated machinery diagnostic functions were all-analog and had not transitioned to digital bus communication. CAN-MD® has now solved the toughest machinery sensing challenge: going all-digital with high level, broadband vibration data processed at the source.
Digital solutions offer simpler wiring schemas by reducing down to one primary cable as opposed to the multitude of individual cable runs required by analog systems. User-configurable firmware in the CAN-MD® platform optimizes each individual monitoring location for the best possible results. The CAN-MD® platform can coexist and operate within a variety of CAN protocols and if needed, bridges can be sourced to convert to other bus protocols such as ethernet, RS232/RS485 and ARINC protocols to name a few.
CAN-MD® accelerometers post Condition Indicators (processed features from resident algorithms) on the bus automatically and/or, when instructed. They can also manually acquire data from one or more of the 63 acquisitions and 127 CI’s, then generate and output that result to the bus.
Working Principle CAN is a broadcast-type bus. A message transmitted by one line replaceable unit (LRU) is received by all the LRUs connected to the bus. Each LRU will have a filter to accept the message relevant to it. Data messages transmitted from any terminal on a CAN bus do not contain source address or destination address. A data message is transmitted as a frame. In each frame, the message is labeled by an identifier that is unique throughout the network that includes the Node ID and sensor serial number. All other LRUs on the network receive the message and each performs an acceptance test on the identifier to determine if the message and its content are relevant to that particular LRU. Since the information from each sensor includes the “Node ID” and sensor “serial number”, data verification is easily accomplished via a visual inspection of the sensor location to ensure the serial number matches the data.
A Condition Indicator (CI) is the result of the onboard DSP and algorithm processing functions performed by CAN-MD® sensors. CIs are provided as outputs on the CAN bus and are the primary bits of information sent to dashboards, either locally or in the Cloud. This is the most significant part of the CAN-MD® system. CIs can be used to trend developing faults, predict failures, or to signal “normal, warning, shut down, alarm, green, yellow, red” or other operating conditions as selected.
CAN-MD® sensors can boot up and start collecting and processing CIs automatically. These CIs can later be filtered with additional information to classify “operating mode” dependent results. CAN-MD® sensors can respond to commands over the data bus. These commands can be an order to collect synchronous or asynchronous measurements and output processed or raw data on the CAN bus. Sensor data can be requested from a particular sensor and stored in a data logger via a simple user interface. While raw data is not typically stored on a repetitive basis due to the large file size and long transfer times, it is tremendously useful in debugging or analyzing difficult vibration problems and setting up associated CIs in the future.
CAN-MD® distributes data processing across the entire network rather than through one central processor. This built-in redundancy reduces the “single point failure” associated with traditional monitoring systems. This means that each sensor has its own address and the setup configuration is stored at the sensor level rather than on a central processor. By default, the firmware on each sensor is physically partitioned so that changes are made locally down at the sensor, thus simplifying validation and verification (V&V) of any firmware updates. In traditional VHM (Vibration Health Monitoring) systems, simple changes can force complete “end to end” testing to prove those changes don’t affect other operations on the main LRU. Is your current system maxed out? CAN-MD® can be used to augment existing VHM systems as the host processor would only have to allocate the additional bus traffic from CAN-MD®. This is especially useful when an existing VHM system has reached analog vibration sensor capacity (channel count is maxed out); CAN-MD® can augment the system with additional channels without having to force an LRU change or a system redesign.