What This Category of Data Looks Like
Production ledger data for SMT mounting and electronic assembly comes from customer BOMs, Gerber coordinate files, MES systems, solder paste and component batch records, placement machines, SPI/AOI inspection equipment, and reflow oven temperature collection systems. Data is generated in real time for each work order and each line change, covering documents including BOM lists, line change sheets, stencil and furnace temperature records, first article confirmation reports, SPI/AOI defect reports, maintenance records, traceability labels, and more. Core fields include part numbers, reference designators, component batch numbers, mounting coordinates (millimeters), furnace temperature parameters (degrees Celsius), defect types, and more, covering structured work order data and unstructured device logs.
What Constraints These Characteristics Impose on Database and Operations Maintenance
Multi-source heterogeneous data sources require the database to support both structured associated queries and unstructured storage to adapt to different types of ledger documents. The high-frequency real-time update rhythm requires the database connection pool to have sufficient concurrent processing capacity to avoid connection exhaustion. Diverse document structures lead to significant field differences, requiring flexible database schema adaptation. Ledger data is directly linked to production quality, so data consistency requirements are high. The operations maintenance process must include real-time monitoring and exception alert capabilities to prevent production problems from being amplified due to data errors.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| MongoDB connection address | mongodb://[username]:[password]@[host]:27017/smt_prod?authSource=admin | SMT ledgers contain large amounts of unstructured device logs and traceability labels. MongoDB's flexible schema can adapt to multi-source heterogeneous data storage and meet fast write requirements |
| PostgreSQL connection address | postgresql://[username]:[password]@[host]:5432/smt_core?sslmode=require | Structured work orders, BOMs, and line change sheets require a relational database to ensure transaction consistency, for associated queries of core production fields such as part numbers and reference designators |
| Maximum database connections | 20–30 | Each work order and line change triggers data writes. 20-30 connections balance concurrent processing capacity and server resource usage, adapting to the high-frequency update rhythm |
| Redis connection address | redis://[host]:6379/0 | Cache frequently queried component batch and furnace temperature reference data, reduce database access pressure, and accelerate production ledger summary and report generation |
| Database write timeout | 600 seconds | For the write and query of SMT real-time data, a 600-second timeout threshold balances response speed and resource waiting time |
Three Common Misconfigurations
- An error "Authentication failed" or "Connection timed out" occurs when connecting to MongoDB. The cause is failing to specify the
authSource=adminparameter in theMONGODB_URI, or failing to open MongoDB port 27017 to the FastGPT deployment node. - Some fields are missing from the generated ledger reports. The cause is failing to adapt to the flexible schema of SMT ledgers, and failing to map unstructured SPI/AOI report fields to database indexes.
- A timeout error occurs during report generation. The cause is that the maximum database connection count is set too low, leading to connection exhaustion during frequent line changes, making it impossible to read ledger data in a timely manner.
How to Verify Successful Configuration
- Log in to the FastGPT v4.17.0 database configuration page, verify the connectivity of the MongoDB connection address and PostgreSQL connection address, and check that the connection status shows normal.
- Submit a test work order to trigger production ledger data writing, and check whether complete records including BOMs and device logs are generated in the corresponding database.
- View the Redis monitoring panel, confirm that the cache node corresponding to the Redis connection address responds normally, and the cache hit rate meets daily business expectations.
- Simulate 3 consecutive line change operations, check that there are no connection timeout or connection exhaustion errors in the database logs, and the data write success rate meets business requirements.
The values given are common starting points and should be measured against the reader's own samples.