Industrial Acoustic Anomaly Detection AI: From Microphone Placement to FAT/SAT

When considering the introduction of abnormal sound detection AI in factories, the first thing to decide is not the model name. Rather, it is “which equipment, under what operating conditions, what kind of sound changes to detect, and who will check what.” The sound of a machine changes with rotation speed, processing material, surrounding equipment, microphone orientation, and even door opening/closing. Simply inputting recorded sounds into AI does not produce alarms that the field can respond to. This article is for managers introducing acoustic monitoring for motors, conveyors, fans, reducers, etc. in Thai factories, presenting the process from measurement to RFP, FAT, and SAT as a continuous design. It does not cover specific pump cavitation diagnosis or general predictive maintenance, but focuses on implementation decisions when using airborne sound.

Conclusion: Design “Sound Difference” and “On-site Action” Together for Abnormal Sound Detection

Abnormal sound detection AI can notify when a sound deviates from what is considered normal operating sound. However, such deviation alone does not necessarily determine the fault location, remaining life, or whether a stop is required. The DCASE abnormal sound detection challenge also focuses on the reality that abnormal data is hard to cover and on “domain shift” due to changes in operating conditions and environmental noise. Therefore, the specification should not be summarized as just “AI accuracy,” but should separately describe the target equipment/operating conditions, microphone installation position, range of normal sound collection, notification recipient, confirmation procedure, and acceptance criteria. ISO 17359 presents general procedures for building equipment condition monitoring programs, following the idea of treating measurement and maintenance judgment as one operation.

In practice, do not target the entire facility from the start. Select one machine that can lead to stoppage or defects, and create a table listing observable sounds, confirmable maintenance records, and actions that staff can take. Based on this, record a small sample and have people review whether the sound change is worthy of an alarm. Record the installation conditions and thresholds used for verification; in FAT, check the imported data and interface; in SAT, check the actual equipment and work shifts. If equipment or processes change, update the definition of normal. This is the backbone of implementation.

Equipment Suitable and Unsuitable for Factory Abnormal Sound Detection AI

Rotating machines, fans, conveyors, reducers, pneumatic mechanisms, and periodically contacting transfer mechanisms that emit sound to the outside are candidates. If friction, collision, air leakage, or looseness appear as changes in the audible or target frequency range, using a non-contact microphone makes sense. However, emitting sound and reliably identifying faults are different matters. In lines where sound sources are crowded, neighboring machines may sound louder. With covers or soundproof boxes, the sound changes greatly depending on microphone position. If internal changes in equipment are not easily reflected in airborne sound, other signals such as vibration, current, or temperature may be more suitable.

At the initial site check, list for each equipment: “failure/abnormal modes,” “expected sound changes,” “reference normal sounds that can be collected on site,” “background noise,” and “confirmation method after detection.” For example, if targeting the guide contact sound of a conveyor, collect sounds including normal lots with different products, start/stop, and operation of neighboring machines. Even if a sound suggesting belt misalignment is detected, on-site staff must check the guard according to safety procedures and inspect tension and alignment before making a judgment. Do not assume that AI will automatically decide to stop as a substitute for safety functions or interlocks.

Also, clearly state unsuitable cases in advance. For equipment with no one to receive alarms, temporary lines where noise sources change frequently, sealed equipment with almost no sound leakage, or equipment without recorded maintenance event times, operational or data infrastructure should be prepared before PoC. Before claiming that abnormalities can be detected by sound, check whether humans can distinguish them under the same conditions or whether differences can be observed in waveforms or frequency bands. Narrowing down the targets in this pre-judgment is more rational than installing microphones on all equipment and then reducing alarms.

Decide “What Is Called Normal” Before Installation

Normal sound is not a single type. If you mix idle, ramp-up, steady operation, speed changes, setup changes, product switching, cleaning, short stops, and startup of adjacent equipment as the same “normal,” the model will lose sight of differences it should really distinguish. Conversely, if you subdivide each condition too much, you will lack training samples for each. First, list operating modes, speeds, product numbers, shifts, etc. that can be obtained from PLC or MES, and prioritize recording conditions that greatly affect sound. For conditions that cannot be obtained, make a plan to match them with on-site work logs or manufacturing instructions.

The DCASE 2024 task description clearly states that abnormal sound samples are rare and diverse, and that changes in operating conditions and environmental noise should be considered. In factory PoC, you can consider methods that “learn only normal sounds and detect deviations.” However, do not decide the normal sound collection period by a fixed number of days, but judge by coverage of operating conditions. Record whether you have collected multiple shifts, main product types, speed ranges, setups, and operation of adjacent equipment. Do not unconditionally regard periods without recorded abnormalities as “normal”; check for contamination with maintenance logs and worker interviews.

The definition of normal also requires an update date and approver. If there are replacements of worn parts, changes in installation position, guard replacement, model changes, software updates, or microphone replacement, the acoustic conditions change even for the same equipment name. Review the difference from the old standard and create a new standard if necessary. Do not delete old data, and make it possible to trace which model and installation conditions produced which alarms. This helps not only with model improvement but also with investigating the causes of false alarms and explaining acceptance results.

Microphone Placement: Confirm Sound Sources, Background Noise, and Maintenance Work in a Single Diagram

You cannot decide what sounds to pick up on site with just the microphone specification sheet. Check the distance and orientation to the target part, shielding by guards or enclosures, floor and wall reflections, adjacent equipment, air conditioning, air blow, and worker traffic. Narrow down candidate positions to two or three and make short comparative recordings under the same operating conditions. When attaching to fixed equipment, also check cleaning, water, chips, heat, vibration, cable routing, and access for replacement during maintenance. Do not choose positions that are hard to reach during production just for ease of recording.

OSHA’s technical manual on noise measurement explains that the measurer’s body or surrounding equipment can block sound, and that microphone orientation affects measurement. This is in the context of measuring worker noise exposure and does not directly provide acceptance criteria for equipment abnormal sound detection. However, the physical caution that “position and orientation change the sound” is useful. Mark position, height, and angle on the fixed jig, take photos, and make it possible to compare under the same conditions after relocation. If you move the microphone orientation during testing to compare accuracy, you cannot separate model differences from installation differences.

When multiple sound sources such as motors, reducers, and conveyor surfaces are close, do not force identification of the cause with a single microphone. If necessary, separate microphones, and compare when the line is stopped, when running, and when only adjacent equipment is operating. There is also the idea of placing a reference microphone to monitor ambient sound, but since additional wiring and synchronization are required, verify its value in PoC. If the targeted abnormal sound is buried in background noise, changing the sensor type may be more appropriate than adding more microphones.

Recording Data: Pair “Sound” with “Equipment Status at That Time”

The unit to be saved is not just the audio file. Link equipment ID, microphone ID, installation position and orientation, time and time zone, operating mode, product number or work condition, model version, alarm score, and maintenance judgment. Whether you need to save the entire audio for a long period depends on the application and internal rules. For normal sounds, features and short confirmation clips may suffice. Design the storage target, access rights, and retention period considering the basis for alarms, retraining later, and the possibility of personal voices being recorded. Do not make acoustic monitoring a “record everything” system.

If the inference time and PLC/MES time are out of sync, you may mistakenly link sound changes and stop events. Include time synchronization of collection terminals, local storage during communication outages, retransmission after recovery, and detection of file corruption in the RFP. The method of linking production results varies depending on equipment and upper-level systems. The OPC Foundation’s OPC UA specification for machine tools shows a common interface for exchanging machine monitoring information with MES, SCADA, ERP, and analytics systems. However, do not assume that existing equipment implements that information model; check actual tags and time quality in advance.

In Thai factories, operation records may be mixed in Japanese, Thai, and English. Simply translating classification names does not unify operations. The alarm confirmation screen should display equipment ID, time, operating status, the most recent sound clip, and candidate judgments selectable by the operator with a common meaning. When passing to work instructions or maintenance tickets, leave a reference to the original sound and the human judgment. Clearly distinguish between “detecting a sound change” and “cause confirmed” so that text generated from sound does not circulate independently.

Edge Inference or Cloud: Decide Required Processing During Communication Outage First

With inference on edge devices, you can process sound near the equipment and send only short events or features upstream. It is possible to design detection to continue locally even if communication is unstable. On the other hand, you need to operate the device on site, including installation environment, power, heat, updates, replacement, model distribution, and log collection. Cloud processing makes cross-analysis and model management easier, but you must decide on audio transfer bandwidth, latency, communication outages, storage location, and permissions. Neither is always superior.

Start the decision from alarm response time and data handling. The requirements differ between alarms that maintenance staff can check on the next round and those that must be checked immediately during operation. The design also differs between places where workers’ conversations may be recorded and places where only machine sounds are collected in sealed rooms. In the RFP, write “during network outage, which processing continues, which events are sent later, and how they are displayed on the screen.” Even if you choose edge, do not push production updates to devices arbitrarily; decide on version management and rollback procedures.

In the initial PoC, rather than choosing a heavy model first, establish the sound collection conditions and alarm units that people can check. There are various methods such as spectrograms, features, embeddings, and reconstruction errors, and DCASE research tasks also have diverse implementations. Benchmark rankings cannot be read as your own line’s detection rate as-is, because target machines, background noise, microphone positions, and false alarm costs differ. In selection meetings, show results and room for improvement compared with the same field data, rather than just model names.

How to Evaluate False Alarms and Misses

“99% accuracy” alone is not sufficient for acceptance in equipment monitoring. If most data is normal, a system that always answers “normal” will appear to have high accuracy. What should be measured is how many of the defined abnormal events were detected, how long from alarm to on-site confirmation, how many unnecessary calls occurred during normal operation, and whether the cause of the alarm can be reviewed. Clearly state the denominator and observation period for evaluation. If there are few abnormal samples, do not promise detection rates as definitive numbers; separate the range confirmed in testing from unverified abnormalities.

False alarms should be stratified not only by the number per day but also by equipment, operating mode, shift, and product number. If there are many alarms only during setup changes, you can choose to make that mode a separate normal category or suppress monitoring. However, suppressing everything will erase truly necessary alarms. If you divide alarms into “notification,” “needs confirmation,” and “urgent confirmation,” specify the basis for each stage, notification recipient, and maximum waiting time in the work procedure. Low thresholds that ignore on-site workload will result in alarms being ignored.

Misses cannot be determined simply by replaying all past stop cases. Cases where pre-failure sound is not left, conditions changed after repair, or cases before microphone installation cannot be used as comparison targets. Do not intentionally cause dangerous failures for testing. Distinguish between actual recorded cases, simulated sounds approved by the site, and safe test conditions permitted by the equipment manufacturer, and record the results. Also decide how existing monitoring such as patrol inspections or vibration measurements will supplement if abnormal sounds are not detected.

Incorporate Human Confirmation into the Alarm Flow

The person receiving the AI alarm should see the target equipment, time of sound occurrence, operating status, comparison normal sound, and recent maintenance work. Simply displaying the score in red does not advance the investigation. In the first check, first confirm the equipment status and other measurements from a safe place. On-site inspection or guard opening should follow the factory’s safety procedures. If the cause of the sound change is a work condition, mark as “normal condition change”; if a mechanical problem is suspected, mark as “needs inspection”; if undecidable, mark as “pending” and record the reason.

When feeding back post-alarm results to model improvement, do not confuse “alarm was wrong” with “cause not yet identified on site.” The former may be a threshold or training data issue. The latter may require additional sensors or maintenance records. Link replacement parts, inspection results, downtime, and quality impact to maintenance tickets, and judge the usefulness of alarms in the next month’s review. Include the workload of human labeling in PoC costs. If increasing detection cases does not speed up maintenance decisions, review the design.

Depending on line length and equipment importance, notification recipients may be maintenance, production, quality, or multiple. As in RACI, separately assign receiving, first check, stop decision, cause determination, and model change approval. Especially, “who stops the equipment” is not something to be decided in the AI vendor’s settings screen. Decide according to on-site safety, quality, and production procedures, and AI provides the information for that decision. ISO 13374-1 gives general guidelines for software specifications on condition monitoring information processing, communication, and presentation, but actual authority design is the responsibility of each factory.

Design PoC from One Machine and One Detection Purpose

Before starting PoC, write the target equipment and abnormal mode in one line. “Find something strange” cannot be evaluated. For example, “Detect changes in sound suspected to be conveyor guide contact during steady transfer, and have maintenance staff check on the same day”—define observation conditions and actions. If it is unclear whether the fault name can be determined, try as “notification of abnormal candidate.” From maintenance history and worker interviews, check if there are comparable past cases for the target equipment.

The PoC flow is: on-site measurement, position comparison, normal condition collection, initial model or rule, on-site alarm review, improvement, and acceptance judgment. The evidence left at each stage differs. For position comparison, keep layout diagrams and recordings; for normal collection, operating condition tables; for model comparison, fixed evaluation data; for on-site review, judgment history for alarms. Write evaluation periods and threshold candidates in advance, and do not change evaluation conditions after seeing results. Separate the period for improvement while viewing data from the period for freezing improvements and accepting.

PoC costs are not just microphones and terminals. Include mounting jigs, wiring, dust/water protection, time for installation during stoppage, PLC/MES integration, audio storage, on-site review, model updates, training, and maintenance. Separate initial and ongoing costs in estimates, and clearly state factory-side work time. Separate parts that can be shared when increasing equipment from those that increase per machine. The benefits of early detection should be calculated after knowing the number of past stops and the ability to take action after confirmation. Do not assume unfounded reduction rates or payback periods from the start.

Requirements to Include in the RFP

In the RFP, define the inputs and outputs from measurement to judgment, rather than just “abnormal sound AI set.” List machine name and target part, target abnormality, operating mode, background noise, installation location, required notification time, intended users, and existing maintenance systems. Ask vendors to show candidate microphone positions, reasons, and comparative recording methods. Also require audio sampling conditions, synchronization, handling of missing data, recording storage range, local and cloud data paths, and reconfiguration when replacing equipment. Specify deliverables that can be evaluated while leaving design flexibility.

For the AI part, describe the definition of normal sound, handling of operating conditions, threshold setting, model version management, triggers for retraining, and display of alarm basis. If abnormal sound names are to be displayed automatically, require training/validation data supporting that classification. For unknown abnormalities, prioritize pending and confirmation guidance over name estimation. Decide evaluation metrics according to the range of correct data actually available. Specifications that contractually guarantee “detection rate of all faults” without past fault sounds are unverifiable.

For operations, include alarm recipients, confirmation screens, maintenance ticketing, response responsibility, authority, training, logs, and failure response. If there are network boundaries or external connection rules in the factory, check with the IT department in advance. Also decide responsibility for terminal and model maintenance. If microphone cleaning, installation angle inspection, terminal updates, log capacity, equipment replacement, and reevaluation after line modification are unclear, performance degradation after production may be overlooked. Include not only function names but also this operational scope in the comparison table for competitive quotes.

Minimum Information Table to Attach to RFP

What to Check Separately in FAT and SAT

FAT (Factory Acceptance Test) is to check functions with agreed audio data and configuration before factory installation. Test audio file input, operating mode identification, abnormal score and alarm output, screen display, model version recording, authority, data loss and retransmission, notification recipient, and failure logs. If there are abnormal samples, play them; if not, clearly state “untested abnormalities.” Simulated or synthetic data is useful for connection testing but should be separated from proof of on-site detection performance. Leave the source and usage permission of test data in acceptance documents.

SAT (Site Acceptance Test) is to check fixed microphone positions, on-site background noise, multiple operating conditions, communication quality, and work procedures across shifts in the actual factory. Freeze positions and model versions before starting the test, and record any changes. Check whether alarms are not triggered repeatedly by normal events in the process, whether the flow from alarm to staff confirmation works, and whether the system recovers after equipment stops or network outages. If you simply raise the threshold on the spot to eliminate false alarms found during SAT, you will not know if misses have increased. Record reasons and before/after evaluations for changes.

Pass/fail for FAT/SAT is judged not by a single “accuracy” but by the agreed test table. For each test, record prerequisites, inputs, expected results, actual results, evidence, judge, and unresolved items. If there are insufficient abnormal sound examples, make it a conditional pass, and decide the timing and responsible person for re-evaluation after collecting additional cases post-operation. Also, contractually define that model updates after acceptance do not automatically count as passing; set change management and re-test scope. Only after deciding all this can you move from PoC to production.

Record the conditions for reassessment after acceptance in the test plan. Relocating a machine, replacing its motor or gearbox, adding a sound enclosure, remounting a microphone bracket, or changing the conveyed material or speed range may alter the acoustic path or normal sound. This does not mean retraining every model after every change. First compare the installation drawing and operating conditions, then record a new baseline under matching conditions. If the difference is small, document why monitoring can continue; if it is material, send the threshold and model for approved reassessment. Do not judge by the number of alerts alone. Review the types of events confirmed by maintenance staff to distinguish a genuine improvement from a higher risk of misses. The initial contract should specify ownership of the data needed for reassessment, how models and settings will be handed over, the vendor contact, and which settings the plant may change itself. Keep decisions and configuration changes under the same equipment ID so a new owner can trace them.

Operation in Thai Factories: Connecting Equipment Maintenance and On-site Language

In factories in Thailand involving Japanese headquarters, local manufacturing, and outsourced maintenance, alarm explanations cross languages. Keep notification texts short, with equipment ID, time, target sound source, and first on-site action as fixed items. Use the same event ID in Japanese technical reports and Thai work instructions. Do not issue stop instructions based only on the translated word “abnormal.” Standardize equipment and part names on site so they can be matched with maintenance records.

Before introduction, check the relationship between microphone and worker positions, the possibility of conversations being recorded, and the factory’s recording rules. Limit the purpose to equipment monitoring and document the operational scope so it is not used for personal evaluation. Individually check internal regulations and applicable laws regarding audio handling. If transferring to the cloud, decide storage location, contractor, access rights, and deletion method with the IT department. The value of the system is not in recording for a long time, but in being able to track necessary sound changes and confirmation results.

For integration with existing equipment, there is no need to input audio into the PLC. Consider a configuration where the audio processing terminal creates events, receives operating status from PLC or MES, and passes confirmation results to the maintenance system. The OPC UA specification for machine monitoring is a reference for designing data exchange between systems, but whether actual equipment supports it must be checked separately. Even when starting with manually entered process information, keep records of which time’s sound is linked to which operating condition. Prioritize not losing the context necessary for on-site decision-making over the integration method.

Five Mistakes to Avoid When Introducing Abnormal Sound Detection AI

First, not recording microphone positions. If initial and production recording conditions differ, model comparison becomes meaningless. Second, mixing different operating modes as the same normal sound. Misidentifying startup sounds as faults will lose on-site trust. Third, treating benchmark results as guaranteed values for your own line. DCASE is useful for research comparison, but equipment and environment differ. Fourth, not deciding post-alarm actions. Increasing notifications does not lead to inspection or repair. Fifth, updating models and equipment without change management. Continuing to use old standards even after installation angle, parts, or speed change.

These can be prevented without advanced AI technology. Consistency in ordinary management documents—installation diagrams, operating condition tables, alarm review tables, FAT/SAT test tables, and change history—is the priority. For general equipment condition monitoring, see How to Select Target Areas for Anomaly Detection AI. For analysis of alarms already recorded in PLC, etc., see Introduction of Equipment Alarm Analysis AI. This article covers the implementation conditions when measuring sound from microphones before that stage.

FAQ: Questions Before Introducing Factory Abnormal Sound Detection AI

Can abnormal sound detection AI identify the cause of failure?

There are cases where the cause of failure can be estimated, but simply detecting a sound change does not confirm the cause. For example, the same metallic sound could be contact, falling objects, adjacent equipment, or changes in work conditions. To display the cause name, training data for that classification and on-site verification are required. For initial introduction, it is easier to accept if defined as “notifying unusual sounds and having the site confirm with other information.”

If there are existing vibration sensors, is a microphone unnecessary?

Decide based on the phenomenon you want to measure. Vibration easily captures mechanical movements of housings or bearings, while sound can sometimes observe air leaks, contact, or interactions between products and machines from a distance. Both do not necessarily react to the same fault at the same time. If existing signals are sufficient, there is no need to add microphones. Conversely, if there are cases where abnormal sounds precede on site, it is meaningful to conduct a comparative PoC. Verify whether additional sensors add information.

Can AI be built without recordings of abnormal sounds?

Methods that notify outliers from only normal sounds can be considered. DCASE research tasks also handle settings using only normal sounds. However, without actual abnormal cases, it is not possible to fully evaluate how well important faults on site can be detected by that method. Rather than specifying types of abnormalities, prioritize coverage of normal conditions and alarm review. After operation, accumulate maintenance results and update performance for each target abnormality.

How many microphones are needed and where should they be placed?

You cannot decide uniformly based only on equipment size or background noise. Draw the target and surrounding sound sources and make comparative recordings at candidate positions. Decide including guards, reflections, cleaning, wiring, and replacement work. Only consider adding or changing sensors if the target sound cannot be separated with a single microphone. Rather than fixing the number of units in the estimate first, include position comparison as a PoC deliverable.

How do you estimate the cost and payback period of AI abnormal sound detection?

Separate microphones, installation, terminals, communication, data storage, model development, integration with existing systems, alarm review, and maintenance. Costs vary depending on the number of target equipment, installation difficulty, existing data, and required response time. Calculate payback period based on actual past stoppages/quality losses and the range that can actually be avoided after detection. Do not apply published reduction rates from other factories as-is. In the first RFP, compare operational burden and unverified range along with total price.

Can production acceptance be done with only FAT?

FAT can check functions, data paths, and simulated inputs, but on-site background noise, multiple shifts, fixed microphone positions, communication, and on-site response must be checked in SAT. If there are few abnormal cases, even SAT cannot prove the full range of performance. Decide on conditional acceptance and timing for additional evaluation, and re-test if model or equipment conditions change.

Summary

Introducing abnormal sound detection AI in factories is not just a matter of attaching microphones to machines, but a project to measure target sounds, manage normal conditions, and connect AI alarms to human maintenance decisions. Narrow down the targeted abnormality, fix positions and make comparative recordings, link operating modes and sounds, and clarify false alarms and unverified ranges. Specify requirements for operation and data paths in the RFP, and separate FAT and SAT for acceptance. This way, you can distinguish what was verified in PoC from what can be promised in production.

If you are at the stage of organizing candidate equipment or microphone positions in a Thai factory, please consult TOMAS TECH. Even if there are still few abnormal sound recordings, we can discuss from measurement planning, on-site review, RFP, and acceptance criteria.

References

• DCASE 2024 Task 2: First-Shot Unsupervised Anomalous Sound Detection for Machine Condition Monitoring — Explanation of normal sound learning, unknown abnormalities, and domain shift due to operating conditions and background noise.
• DCASE 2024 Task 2 description and discussion — Paper on task setting and research results.
• ISO 17359:2018 — General guidelines for equipment condition monitoring programs.
• ISO 13374-1:2003 — General guidelines for processing, communication, and presentation of condition monitoring information.
• OPC UA for Machine Tools, Part 1 — Specifications for exchanging machine monitoring information with upper-level systems.
• OSHA Technical Manual, Section III, Chapter 5 — Notes on microphone position, orientation, and shielding in noise measurement. Materials for worker exposure measurement, not standards for equipment abnormality detection acceptance.