CAN-MD

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 results 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 addresses or destination addresses.

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.