What the data for this category looks like
The data for this category primarily comes from silicon wafer incoming material records, production MES systems, real-time operational data from diffusion furnaces, coating equipment, and printing presses, EL and IV test results, and laboratory inspection data. Daily output documents include process cards, diffusion and coating parameter tables, printing and sintering records, EL inspection images, IV grading data, and yield reports. Data update cycles cover each production batch, per-product inspection, and daily summaries. Fields include process window parameters, inspection values, electrical performance grading results, yield metrics, and some documents contain visual image data.
What constraints do these characteristics impose on the deployment and upgrade stage
The multi-source heterogeneous data sources, high-frequency update rhythm, and document structure containing visual images for this category impose multiple constraints on the deployment and upgrade stage. Differences in data source formats across multiple devices and systems require configuration of unified data access adaptation rules during deployment. High-frequency updates of batch and single-product inspection data require adjustments to synchronization cycles and cache configurations to avoid excessive load on production systems. Processing image documents such as EL inspection images requires supporting adapted file storage and parsing capabilities. The high precision requirements for process parameters require retaining the original data verification logic during upgrades to avoid impacting parameter judgment in production links.
How to set the configurations
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
MONGODB_URI | Point to the MongoDB instance associated with production MES and equipment data, configure read-write separation nodes | Production parameters and inspection data for this category are stored in MongoDB in mixed structured and unstructured formats. Read-write separation reduces load from high-frequency data access |
REDIS_URL | Configure as a locally deployed Redis instance with a memory quota of no less than 1000 MB | Temporary process data and inspection results for each batch must be cached to avoid repeated reads of original data sources |
STORAGE_S3_ENDPOINT | Point to an object storage endpoint adapted for image storage | Required to store unstructured documents such as EL inspection images and IV test visual data |
DB_MAX_LINK | Set to 20–30 | Balances concurrent connection counts for multiple device data sources and system resource usage |
FILE_TOKEN_KEY | Configure as an encryption key matching the object storage | Ensures access security for sensitive production documents such as EL inspection images |
Three common mistakes
- Issue: After upgrading to FastGPT v4.17.0, calling the m3e model returns empty results or an error. Cause: The environment variables required for the model were not correctly associated in the deployment configuration, causing the workflow to fail to read model call parameters.
- Issue: Calling custom environment variables in the workflow returns empty values. Cause: Custom environment variables were not synchronized to FastGPT's runtime configuration during Docker deployment, causing the workflow to fail to obtain preset database or storage keys.
- Issue: After performing an index increment operation in a loop, the output result is empty. Cause: The starting value and step size of the loop were not correctly configured, causing the index to not update as expected and failing to trigger subsequent document processing logic.
How to confirm the configuration is complete
- Log in to the FastGPT backend, check the data source connection status, and confirm that the instances corresponding to
MONGODB_URIandREDIS_URLcan perform normal read and write operations. - Upload an EL inspection image to verify that the storage service configured via
STORAGE_S3_ENDPOINTcan normally receive the image and return an access link. - Run a test workflow that includes environment variable calls to confirm that preset custom parameters can be correctly read.
- Execute a loop test task to confirm that the index can increment as expected and output valid results.
The values provided are common starting points and should be measured against the reader's own samples.