Could we see vibration added as a new haystack standard tag for VFDs? It's common among all of my VFD equips that the spindle motor vibration has a sensor attached in an industrial setting.

Indeed vibration should be a tag, however it should not be limited to a VFD as other equipment has vibration sensors such as cooling towers, chillers, fans and other machines that are prone to self-destruction.

How is it typically measured and with what unit(s)?

I'm no expert however what I've seen is an analog value expressed as inches/second as well as a simple binary value (true/false). Not familiar with industrial applications as Buddy suggests.

I think this would be a good addition.

It's typically measured with a sensor hooked directly to the piece of equipment that needs to be monitored but the units can vary widely based on the importance of the vibration being measured. I believe the most common method of measurement is to measure the frequency (in Hz) but I've also seen where the actual distance is measured as in mm/s.

edit: I agree that this probably shouldn't be limited to VFDs

Hey guys, we've encountered some vibration sensors in the field and stitched together a set of tags for modeling them that I wanted to propose here. The sensors we've seen have the following points, one for each axis X, Y, and Z:

• displacement
• velocity root-mean-squared
• acceleration root-mean-squared
• acceleration peak
• frequency

These are all computed using an accelerometer.

Proposal

To model these, I propose three new quantities:

• position: The position of an object in space in relation to an arbitrary reference point
• velocity: The rate of change of the position of an object with respect to time
• acceleration: The rate of change of the velocity of an object with respect to time

We need a way to denote the direction of position, velocity, and acceleration, so I suggest an axis tag that operates similarly to phase:

• axis: The axis of measurement, according to the reference frame. This is a Str, with a value of "X", "Y", or "Z". This tag lives only on points with the position, velocity, or acceleration tag.

We also need a phenomenon to apply these quantities to. As the posts above describe, these typically can exist on any equip entity, so drive is out. There seems to be a gap in the phenomenon tree, where equipment-centric quantities live (state might apply although it seems very control-focused). I suggest a new phenomenon:

• object: A collection of matter with a defined contiguous boundary in three-dimentional space.

I expect some push-back here, but I think it gives us the root of a tree structure that could be built out depending on what type of object is being measured (HVAC equipment, people, vehicles, elevators, etc). It also matches a physics perspective as well as common language.

This proposal has an interesting overlap with the speed & direction combo used by Wind. We could use this format instead of the proposed velocity & axis format, but the existing solution doesn't generalize well to 3-dimensions. I think that having both in the nomenclature could actually be a benefit, and aligns well with conventional understandings of speed vs velocity (speed is a non-directional scalar, whereas velocity is a directional vector).

Use Cases

• Vibration sensors
• Speedometers
• Positional data

Please respond back with any feedback, questions, or concerns! Thanks!!

I like most of Jay's suggestion.

Questions...

1. Wouldn't displacement on a vibration sensor be the maximum displacement from rest, given that the part is (presumably) oscillating? If so, I'm not sure position is the best tag there. displacement as a tag seems better, because it implies distance from a reference position and doesn't necessarily imply direction. But I could live position.
2. As a form of energy (more or less), couldn't vibration itself be a phenomenon, akin to light and elec?

object seems ambiguously similar to substance > solid.

Wouldn't displacement on a vibration sensor be the maximum displacement from rest, given that the part is (presumably) oscillating? If so, I'm not sure position is the best tag there.

I agree with this. I think displacement is more specific, where as position seems too generic and general purpose

From a general purpose physics perspective velocity and acceleration seem like good adds - I debated about speed vs velocity with wind-speed. In those cases, there seems to be several different ways to model the "direction". In a vehicle the direction is variable based on where the vehicle is heading (or maybe the vector). But in general you would just have one measurement of speed/acceleration based on that direction.

But for something like a a vibration sensor the axis would be similar to how a temp sensor has context for a discharge duct or a entering pipe. That might make more sense as a choice with marker tags xAxis, yAxis, etc. But I don't think we should codify quantities like speed/acceleration unless we cover both cases.

These are all computed using an accelerometer.

I think this is the key point, what we are really doing is defining an accelerometer. Which most likely I would classify as a new equip type, and all the other stuff is the points under it.

It could be an IMU (inertial motion unit). In my experience an accelerometer only measures acceleration, usually in g units along multiple axis - unless you model a temperature sensor as equipment I would have though it should be a sensor with multiple channels not an equip? An IMU usually contains an accelerometer, gyroscope and perhaps a magnetometer plus "sensor fusion" signal processing which combines the readings fromn the sensors using complimentary or kalman filtering or other such methods to produce derived signals (using pitch, yaw and roll) - a vibration sensor which uses an accelerometer to produce displacement would be doing something similar - basically removing the effect of gravity and integrating the accelerations? So it's similar to an IMU in that it's a package of a sensor with some compute and multi-channel output?

Do you have a multi-channel sensor concept?

Do you have a multi-channel sensor concept?

In Haystack the fundamental unit of "sensing" is the point which always maps to a single scalar value:

• bool: on/off
• number: floating point value with unit
• str: enumerated values

So if for example you have a device that provides three scalar values for the three axis then it would be modeled as three different points. In in Jay's post, if you had distinct values for displacement, velocity, and acceleration then that would be modeled as three points.

In general points are logical entities with a current scalar value and/or historized values. They often correspond directly with a sensor, but more often an object in the controller software.

Equip is what we used to model physical devices that contains points.

The issue with that approach is if you are dealing with a 3-axis sensor, you generally have to treat all 3 values as a single sample. You certainly wouldn't want to read all three points sequentially and get 2 values from one sample and one from the next sample for most applications.

I'm not sure if this issue would arise in a BAS application though, but it's not ideal for IoT IMU applications.

One option could be to extend the values to allow tuples/arrays? So any sensor maps to a single bool, number, str or number[]

The issue with that approach is if you are dealing with a 3-axis sensor, you generally have to treat all 3 values as a single sample.

That is true of many things and domains. But the focal point is the value itself and all the meta data around what the value means. Even in that case you end up needing a full point with all the associated tags, units, etc to describe what each individual value means. The fact that multiple values are sampled together is really just one small aspect of the complete model.

Wouldn't displacement on a vibration sensor be the maximum displacement from rest, given that the part is (presumably) oscillating? If so, I'm not sure position is the best tag there. displacement as a tag seems better, because it implies distance from a reference position and doesn't necessarily imply direction. But I could live position.

Sure, I'm good with displacement instead of position. I was trying to think of something that aligned with the velocity and acceleration additions, and generalized well to things like motion tracking. But you're right Stephen, in the case of the vibration sensors, displacement is more accurate.

what we are really doing is defining an accelerometer. Which most likely I would classify as a new equip type, and all the other stuff is the points under it.

Yeah, that makes sense too. I was thinking generically so we could apply the position, velocity, and acceleration readings to anything (chillers, vehicles, cats, etc). However, Brian's suggestion is more focused and straightforward - we could attach accelerometer readings onto things in the existing equip tree by using an accelerometer equip with an equipRef to a chiller, for example.

This is a good overview of vibration sensing https://www.emerson.com/documents/automation/white-paper-measurement-types-in-machinery-monitoring-ams-en-39660.pdf

As you've identified velocity, acceleration and displacement are common measurement types - generally measured as 0 to Peak, Peak to Peak or RMS rather than instantaneous.