FPGA - Vibration Analysis

Thanks Michael !

I am probably fighting battles at more than one front. You are correct, I need to sort out first the size of the DFT, how fast the processing can be done and lastly what hardware to employ for doing the maths. 

I am pretty decided on the Analog Devices CN0540 but hanging on tenter hooks for the Processing of FFT.

Got it. Shall work on the signal processing task.

Thanks again friend. 

Sincerely,

Hello Jan,

Thank you so much for your help. Shall have a look !

Could you help me with the link, kindly.

Sincerely,

Hi Scottiebabe,

This is a recent contrivance from PCB guys !

Thanks. This is nice but haven't read any reviews. 

I still need to do things by myself. 

Much obliged.

Sincerely,

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).

I haven't used one, just showed up on a quick google search. If I was working on this I would just try getting raw data to help define requirements and you are clearly on the right path. Thanks for sharing your project, its interesting to see what's happening in 2023. I did a quick search for bearing vibration analysis, here is a device that popped up. Maybe there are some helpful hints even if the product isn't a fit.

https://www.mmf.de/vibration_meters.htm#vm100 

Take care

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,

Dear Scottiebabe,

I have also used these a few times. Perhaps, these  cannot display data in real time. They need to record data first and then we can see it.

WE do these recordings / FFT, before a refit / repair period commences and record data. Once finished with the repairs, same test is repeated. Results are compared. In some cases we see improvement. It is only when the vessel is put out at sea and nothing is done till it comes next for its maintenance period. In between, damage / degradation does happen and goes un-noticed. Same routine is followed when for example engine oil change is done at say, 500 hours and next is due at 1000 hours. In between we keep eyes and ears shut. I do not do it but the operators do it. Inadvertently , of course.

Thanks.

Sincerely,

That's a massive deployment, even more reason for a small data center's worth of resources.

The connection to the DC is something that has to be secure of course.

I guarantee it's feasible (every gov has to do it, they have standards that they, and the DC or cloud provider has to adhere to - they get "special treatment" by the providers).

You have a lot of different types of vessels, different engines, different operational records. It's unlikely there will be an easy-to-obtain signature that will work for several, let alone all.

An FFT display alone won't be enough, and unless data is collected long-term, I reckon (albeit as a non-expert in ships and engines, so it's really speculation from me) that there's a risk of throwing away a lot of the value, and may end up with only being able to detect issues too late. To be clear, the purpose of the data collection is so that the system can respond in real-time. The responses (alerts in your case) happen on the ship, without any connection, thus there's only processing delay. At a high level, it's a typical example of edge computing, so it's not unusual.

I agree with you, implicitly. 

Quote;

To be clear, the purpose of the data collection is so that the system can respond in real-time.

Unquote.

That is my target. The least I can do is to pre-empt the operator before a serious damage. The response does happen on board the ship. The only processing delay is the moment operator glances at the FFT and switches off the engine or similar action to reduce speed.

CONDIOTION BASED MONITORING, the name given to such maintenance. 

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!