What the data for this category looks like
It typically originates from silicon wafer incoming materials, MES systems, diffusion furnaces, coating equipment, printing presses, EL and IV testing equipment, and laboratory data. Data is updated per production batch, each single-chip test result, and daily summaries. Daily documents include process cards, diffusion and coating parameters, printing and sintering records, EL test images, IV grading data, and yield reports. Fields cover batch identifiers, process window parameters, defect locations, electrical performance values, and more. Corresponding units include degrees Celsius, seconds, watts per square centimeter, and others.
Constraints during deployment and upgrade
Data sources for this category are scattered, spanning multiple production devices, testing systems, and business management systems. Deployment must include configuration for accessing and verifying multi-source data. Data updates occur frequently, following batch, single-chip test, and daily summary cycles. Deployment requires stable database and cache parameters to ensure timely data synchronization. Document types include structured process parameters, image-based test results, and numerical reports. Support for parsing and storing multi-format files is required. Process and test data have strong correlations. Deployment requires clear definition of field association rules to prevent ledger data matching errors.
How to set the configurations
The following configurations are based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
DB_MAX_LINK | 200–300 | Addresses high-frequency data write and query demands from multiple devices and batches |
MONGODB_URI | Dedicated connection address for production environment clusters | Stores unstructured and large-volume ledger data such as EL test images and IV grading data |
REDIS_URL | Local cache instance address, with cache expiration time set to 300 seconds | Caches frequently queried batch process parameters to reduce load on the core database |
STORAGE_S3_ENDPOINT | Endpoint address of the enterprise internal object storage service | Stores file-based ledger data including batch-uploaded EL test images and process cards |
FILE_TOKEN_KEY | Key generated in accordance with enterprise key management specifications | Ensures access permission security for ledger files |
Three common configuration mistakes
- The symptom is a
504 Gateway Timeoutresponse when calling the ledger data interface after deployment. The cause is failure to adjust theDB_MAX_LINKconfiguration for high-frequency data queries, leading to exhaustion of the database connection pool. - The symptom is that EL test images cannot be properly associated with the corresponding batch ledger. The cause is failure to clearly define the mapping rules between the storage collection corresponding to
MONGODB_URIand the batch field. - The symptom is failure to load ledger file previews after local deployment. The cause is incorrect configuration of
STORAGE_S3_ENDPOINT, leading to the system being unable to properly access the file storage path.
How to confirm the configuration is correct
- Run the database connection test script to verify that the connection count set in
DB_MAX_LINKmeets concurrent query requirements. Calibrate the threshold based on actual measured concurrent request volume. - Upload a single EL test image and process card file to verify that the
STORAGE_S3_ENDPOINTconfiguration can properly store and read the target file. - Import a batch of simulated photovoltaic cell production ledger data to verify that the data association rules can correctly match batch numbers with corresponding test data.
- Check the cache instance corresponding to
REDIS_URLto confirm that frequently queried process parameters can be properly cached and updated upon expiration at the set time.
The values provided here are common starting points, and should be evaluated against the reader's own samples.