What the data for this category looks like
Data for this category covers the entire production workflow of photovoltaic modules. Data sources include cell grading records, glass adhesive film backplane batch ledgers, workshop MES systems, string welding and lamination equipment logs, EL defect tester reports, and IV power tester reports. Daily generated documents include layout diagrams, material batch records, lamination process parameter logs, EL defect images, IV test reports, insulation withstand voltage test records, and finished product packing lists. Each individual module generates a dedicated record. Each batch of raw materials generates a batch summary record. Fields include module unique identifier, cell current grade, lamination temperature and duration, EL defect coordinates, power test value, insulation resistance value, and other relevant fields.
What constraints these characteristics impose on the database and operations maintenance link
The high-frequency update requirement for each module means the database must support high-concurrency writes and low-latency queries. This prevents production data from accumulating. The coexistence of multiple data types requires the database to support storage and associated queries for both structured ledger data and unstructured image and log data. Business logic such as cell current grade matching and lamination bubble defect association requires efficient cross-table association capabilities. Without these capabilities, defect analysis time will be extended. The rigid requirement for data traceability means the operations maintenance link must retain complete data backups and version records. This enables rapid tracing of full-process parameters when quality issues occur.
How to Set Configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://fastgpt:xxxx@192.168.1.100:27017/pv_quality?authSource=admin | EL images and equipment logs for photovoltaic modules are unstructured data. MongoDB is suited for this type of document storage, and supports fast fuzzy queries and associated retrieval |
DB_MAX_LINK | 50–80 | A single workshop can generate thousands of module records daily. The connection count must match high-concurrency write scenarios, and be calibrated based on actual measurements to avoid connection exhaustion |
REDIS_URL | redis://192.168.1.100:6379/1 | Used to cache duplicate EL defect judgment results, reducing repeated calculation overhead for vector databases and adapting to high-frequency query scenarios |
PG_URL | postgresql://fastgpt:xxxx@192.168.1.100:5432/pv_quality?sslmode=require | Structured data such as cell batches and lamination process parameters is suitable for PostgreSQL storage, which supports complex multi-condition associated queries |
Three Common Configuration Mistakes
- Symptom: Database connection fails after deployment, with the
sandbox failed to starterror message. Cause: The dependent sandbox container was not started per official procedures, so FastGPT cannot call database image resources. - Symptom: The MongoDB container fails to start on a host CPU without AVX, so FastGPT cannot connect to the database. The v4.17.2 deployment config defaults to MongoDB 5.0.32 and notes 4.4.29 for CPUs without AVX; choose the image for the host instruction set (see the official deployment configuration).
- Symptom: Timeout occurs when repeatedly initiating identical EL defect queries. Cause: Redis caching was not enabled. Each query directly calls the vector database for embedding calculation, increasing database load.
How to Confirm the Configuration Is Complete
- Run the
docker pscommand. Confirm that MongoDB, Redis, sandbox, and FastGPT application containers are all in running status, with no abnormally exited logs. - Import a simulated module batch record. Use FastGPT's knowledge base query interface to verify that corresponding lamination process records and EL image metadata can be returned in association.
- Initiate three identical EL defect queries consecutively. Check the vector database call logs to confirm that no new embedding calculation requests are generated for the second and third queries.
- View the database connection monitoring panel. Confirm that the connection count for
DB_MAX_LINKdoes not reach the preset threshold, and no connection timeout errors occur.
The values provided are common starting points, and should be evaluated against the samples relevant to the specific deployment.