FPGA - Vibration Analysis

I remember talking to a pump or filter manufacturer a few years back (they clean and recirculate oil (might have been coolant or water - I can't recall but unimportant to the discussion) into engines, so it's I guess quite critical!) and it was so important to them that they created their own new datacenter for it.

We envisioned that the data would be regularly collected and whenever the ships were near a port then 5G/4G would be used to upload to their DC automatically. They would do the analysis, run reports, dispatch engineers if necessary, and transmit rules into the ship for tuning what alarms would be generated. They would have a long-term history of each deployment.

Their tech needs shopping list therefore was whatever ruggedized hardware that had lots of on-board processing, some industrial interfaces, and network and cellular connections. Your industrial interface could be Ethernet, for instance. For the processing, enough resources for virtualization or containers was pretty essential, so that applications could be implemented by different suppliers if needed.

For their use case, they planned to use several different types of sensors I think.

The display was secondary since the network could be used to access it (e.g. toughbook or tablet).

Since everything isn't possible on day one, a key first requirement would be to be able to collect the samples and send them to the DC (or cloud), but have the ruggedized future-proofed hardware for the next phases. It's your low-hanging fruit; collect the data (Michael has also suggested this), and have it in a store where you can analyze it, at least to generate reports since not everything needs to be real-time. That's then compelling enough to extend the project.

FPGA, DSP, and FFT are quite low-level considerations, you just need to make sure that you have the resources and interfaces to meet your requirements today and tomorrow.

For sure the solution described above is bigger than what you're envisioning, but on the other hand, it's still pretty small in the space of things (it is a single box or single-hand-count number of boxes, and can operate autonomously with its rules so I'd consider that standalone) and has a ton of value, although I'm guessing what you're requirements are or will be one day. Otherwise, I'd worry that you wouldn't get a lot of value from a more limited solution, so it's good to spend tons of time on the requirements.

I don't know if you're discussing rail stuff, but similarly to ship stuff, I'd consider a similar level of hardware/software, it's a comparable level I think. You have the advantage with rail that there are a lot more opportunities to be in high-throughput contact with a data center (in every station and even along the track at multiple spots, depending on what technologies are present).

Dear Friends,

I work for a government organization where we have an assortment of around 500 vessels, 16m to 70m. The propulsion system comprises upon Diesel and Petrol both reciprocating engines, ranging from 4 cylinder to 20 cylinder. The latter are Evinrude Verado 6/8 cylinders, CAT 6 / 12 /16 cylinders, MTU 8 /10 / 16 /20 cylinders, Cummins , Perkins , Yamaha & Yanmar, primarily.

The Organization does not encourage the idea of wifi / CLOUD storage / 4G or 5G. Security reasons.

Our ships / vesels remain at sea for very long periods. Consequently heavy on maintenance.

Planned Maintenance routines are religiously followed. Corrective maintenance is done in time too. The latter is pretty expensive but we do that too with original parts from the OEM.

The Manufacturer's provide certain critical alarms on the Engine Management System for the safety and efficient running of the engine. These are basically Oil pressure, Coolant temperature, Cylinder Head Temperature, Exhaust temperature and Fuel pressure set at different limits by the OEM. The OEMs also put in place shut down of the engine when limits get crossed but operator can override them. Exigencies of service.

My erstwhile experience, at the moment when any of these Alarms pop up the damage to the engine has already taken place.

Example;

Consider hypothetically, 

Oil pressure - No Alarm (gauge shows little less but within range)

Coolant Temperature - No Alarm

Cylinder Head Temperature - Around 160 C instead of 450 C (one cylinder from a bank of 16 cylinders) Alarm Condition Yellow but would be ignored / overridden as not a high temperature alarm. General human reaction is to accord priority to high temperatures only. More so no other apparent contra indications are there. 

Exhaust Temperature - No Alarm

Fuel Pressure - No Alarm

No apparent loss of power.

FAULT ; Injector misfire / malfunction. Leaking diesel oil into the sump. Oil loosing viscosity. Piston slamming against the cylinder liner for lack of correct oil viscosity. . Degraded Oil viscosity damaging the Crank bearings / connecting rod bearings. Prolonged use of engine in this condition causes loss of compression / wear and tear of the liner which entails heavy costs, engine overhaul. Faults such as the one mentioned here shall go unnoticed for long hours.

This is where the vibration analyzer would come into play.

The new FFT signature / FAULT Condition signature would change from the Master FINGERPRINT. 

It would immediately pickup the misfire / malfunction of the injector. It will identify the Piston abnormal vibration. The bearings around the CRANK / Connecting Rod would also sing differently. This is a very brief period when no Alarm Condition exists but the damage has begun. Thus needs to be nipped in the bud. The operator shall be pre-empted to take action not from the Engine Control and Management System, rather this add on system shall help.

Moreover, as engine runs certain parts loosen up and degrade without warning. Vibration sensors will identify the same and hence portray them on the FFT Display.

I hope to have conveyed some reason why I need to develop such a monitoring system.

 Thank you for the audience.

Sincerely,

Here's a plan that could have elements of plausibility (Consider it as just a kind of placeholder for a proper plan; I'm no project manager! I'm sure there are plenty of things that could be improved or there could be steps missing, this is just a start, just a stab at finding a direction. There are actual project managers on element14 who could give far better advice I'm sure).

(1) Build or buy a system that allows data collection, even if it's just to on-device storage

(2) Deploy it (one or more of those systems), and gather data (even if it is weekly or infrequently). Set a date in the future for retiring it.

(3) Meanwhile, negotiate with your IT people, or with your manager, storage space to keep it, and any tools you are planning to use

(4) Store the data (even if it is manually), post-process the data, label it, learn to extract some information from it (even if it is not initially a lot). You'd be using tools like (say) Python or Matlab.

(5) Prepare reports for your management (even if it is a manual process) say weekly or every two weeks based on the findings. Start showing say at monthly meetings that some events that required maintenance, could have been detected earlier, and the cost of the unscheduled downtime perhaps

(6) If your management starts sharing the reports or the information in them to their managers, then eventually you can start discussions about how reports can be generated daily if some of your manual procedures can be automated

(7) By this time, it may be clear to management the merit of being able to run the work you did on devices locally in real-time. Then a project manager can be assigned and the resources can then be made available from your different departments, e.g. network team, security team, software development team and so on. Your data collection system in item (1) is merely a proof of concept at best, and wouldn't be used. It would be retired, otherwise people will continue to expect reports from it and not the actual project!

It sounds like a great application for "machine learning". With a fleet that size, the investment will be worth it. Choose a platform that can handle machine learning as well as signal characteristics characterization, such as FFT.

A Raspberry Pi 5 might be a good low cost platform.

A SmartFLY Kendryte K510 CRB-KIT might be good too, but maybe a steeper learning curve.

Dear Shabaz,

I am filled with veneration over your recommendations. Indeed this is a "STAB AT FINDING THE RIGHT DIRECTION".

I believe by this move the senior management would be convinced that the Engines / Gearboxes / Rotating Machinery on board the Vessels do require a Condition Based Monitoring System. 

Could you kindly help me in integrating a VIBRATION RECORDING DEVICE ! I would wish to build one myself. 

 What I can envisage is a Piezo Sensor + ADC + Some sort of recording contraption / SSD.

I could analyze the recordings on MATLAB later; a couple of weeks later when ships return to harbor after patrol.

Sincerely,

Dear Dougw,

I am not at all savvy on such electronics ! I grew up on Thermionic Tubes. 

The idea of "Machine Learning" sounds very good. Kindly elaborate over "Choose a platform that can handle machine learning as well as signal characteristics characterization, such as FFT."

I am an avid learner. Shall appreciate all help.

Sincerely,

Surely the people at Edge Impulse would be happy to learn about your use case and accompany you.

https://edgeimpulse.com/

The problem you will have with trying to do it all yourself is that it is a LOT of work.

I've been involved in a similar project - it took maybe 5 man years to get to an 8 channel recorder with signal conditioning, IEPE inputs, FPGA doing some filtering but not FFT.

This doesn't include all the PC software at the other end of the Ethernet cable.

One of the problems with doing your own hardware is that you then will end up doing all your own software.

MK

Hello Michael,

I do not have years to continue with this Project. I need just two channels for the main engine, to begin with. This is just to set a precedence. Once the latter is accepted as a necessary part of the Propulsion System outfit, then time would not matter. We could hire a bigger team to help through.

I want a set / recording device to be installed on one engine first. This is to draw attention of the senior management towards something that is beneficial. This does not exist at the moment.

PC Software for analysis, MATLAB should serve the purpose.

My aim, at present is to apprise the senior management over the need for such a system to prevent frequent breakdowns and save on costs and time both. Start small time !

Jawad_Malik said:

PC Software for analysis, MATLAB should serve the purpose.

shabaz made MATLAB integrations for the MCC172

Dear Javagoza,

Thanks; very interesting. I shall take a serious look into it. Your suggestion is very correct.

Sincerely,

Dear Jan,

That is wonderful. I shall request him for help. 

So inching ahead ! 

I am hopeful someone would also help with the recording part too. 

Thanks. Obliged.

Sincerely,

Dear Jan,

That is wonderful. I shall request him for help. 

So inching ahead ! 

I am hopeful someone would also help with the recording part too. 

Thanks. Obliged.

Sincerely,

There's recording software here:

https://github.com/shabaz123/mcc-daq-tools/tree/main/daqproj/daqviki

However, that records to just a single file, but it would be easy to pull out the relevant files (or create from scratch).

In brief, the daqviki.cpp file has a do_scan function that repeatedly reads all data available from the ADC, and calls write_log_file (in log_file.c) repeatedly.

As suggestions, your code could write to a timestamped filename, say in /var/tmp (since that won't thrash the Flash or SSD memory), and automatically move all such timestamped files hourly, into a daily folder, so that you have a load of folders, each with 24 files. (there are many ways to do things, this is only one semi-reasonable idea).

I'd be happy to help with that when you're ready to experiment with it, since I wouldn't be able to test it too much to save time. No guarantees though (it depends on workload) but it's not too difficult for any programmer, since the code at the link above shows the main API calls etc.

Note that ideally you would have another program to monitor and re-launch the code if it ever crashes, and that would log too (say using syslog) so that you know if there were any issues. That program would be started/stopped using a service (e.g. using Linux systemd). All this is useful for a more reliable solution, but maybe not essential if you have someone who can troubleshoot on the ship if needed.