Machine diagnostics with fuzzy Logic
There is absolutely no doubt that fuzzy logic can contribute to the reliability and accuracy of real time diagnostics of mechanical, thermodynamic, and electro-magnetic devices.  I can state this with assurance because it exists in aeronautics products today.

One of the senior PhDs at the research facility wanted to acquire data via standard techniques and had purchased a brigade of high end Hewlett Packard workstations and instrumentation clusters.  Another senior PhD there wanted to build a fuzzy logic container to provide early warnings of failures, just as implied in the question.  There was some interplay between those two projects in their application in the field.

My direct involvement was to teach the first PhD OO and C++ and design and implement a scientific computing framework to churn the Big Data for the second PhD.  The framework provided a super-set of the union of SciPy and TensorFlow with a little PyTorch added.  That we developed these techniques before Java and Python existed is why Hewlett Packard sent engineers to study what we were doing, with DoD permission, of course.

What you want to do is this:


Become familiar with the open source options in Java, Python, and C.  The general trend is to either use Java-ML or use C wrapped in the above mentioned Py libraries.
Use 16 or 24 bit multi-channel data acquisition with time stamps and latched, concurrent A-to-D conversion at a frequency at least twice1 the 16th harmonic of the vibration base frequencies.
Ensure that you have sufficient system memory to hold what for embedded qualifies as Big Data2.
Ensure that you know how spectra (both amplitude and phase) can be obtained via FFT from channels.
Use LINUX, a single board computer, and either Intel Movidius3 or NVidia CUDA for hardware acceleration.
The fuzzy logic container and any assistive reinforced learning can be on the embedded CPU and leverage the hardware acceleration.
The fuzzy rules can be acquired from the experts to which you have access, as indicated in the question.
Read Chaos Theory Tamed by Williams, 1997 to get familiar with phase relationships between input channels and how to analyze changes in chaotic behavior between the harmonics.


Start with small POCs and generate independent components that can be connected and tested independently with input that came from the output of previously tested components.  Here are some, in rough order of development and signal path.


Data acquisition of multiple samples of multiple channels to a matrix.
FFT of acquired data to an amplitude-phase array in the frequency domain.
Analysis to determine the patterns in metrics that precede failure.
Introduce and train artificial networks (either LSTM or attention type) where indicated to remove redundancy from the information that will be input to the fuzzy logic container.
Write up the rules and place them in the container.
Train the fuzz.
Test the system.


You will need to work with the experts on most of these steps.  If you try to involve them at the rule writing stage and they weren't privy to any of the previous developments, they may be confused.

I'm not a lawyer, but, because of the involvement of failure prediction experts, I think you'll need an internationally binding NDA to ensure the experts don't walk away with the product of your research and move to another country.

These are a few considerations for product reliability you may need to consider even after you have a working system.


Develop a way to adapt the system in real time ... to tracking changes in what indicates near failure based on a centralized database related to the product.
Consider version control and deployment challenges.


I'm sorry that I have no further references.  You can try the IEEE library if you have access.  I have been too busy doing this type of work to publish what we do, but I think most of the important directions are included here already.

FootNotes

[1] Not much can be learned about impending failure from the primary harmonic of vibration.  The first 16 harmonics are sufficient.  Because of Nyquist Criteria considerations, the sample rate must be twice the top harmonic.  This means that if your vibration is 1 KHz, the sample rate must be at least 32 KHz.

[2] Big Data input rates may be necessary because with 8 channels of strain input from Wheatstone bridges of gauges, 8 channels of accelerometer, 8 channels of IR sensing and the above vibration base harmonic, we have (24 channels + 1 time stamp) x 32 KHz x 3 bytes per channel-sample = 24 Mbytes per second.  If your failure detection window holds 10 seconds of vibration data as IEEE 64 bit reals and you send 1 second (overlapping) Hamming windows to the hardware FFT, just for that alone will need 12.8 Gbyte input matrix, 6.4 for the input and 6.4 for the output.

[3] Available for embedded applications from Mouser and other distributors as properly paired single board computers and Movidius mPCIe (mini PCI express) daughter boards from makers like Aaeon.