What the Data for This Category Looks Like
Lithium-ion cell manufacturing production ledger data originates from raw material batches, MES systems, slurry and coating testing equipment, dew point monitoring devices, formation and grading cabinets, and laboratory testing systems. Daily records include batching logs, coating and rolling parameters, winding or lamination records, liquid injection logs, formation and grading data, OCV and safety test reports. Data is updated in layers by production process, with update frequencies covering per batch of cells, individual cells, and real-time detection. Fields include batch number, equipment ID, detection time, parameter values, and more. Units cover mass, voltage, time, area, and other dimensions. Data from each process must be linked across stages for consistency validation.
Constraints for Database and Operations Maintenance
Multi-source, high-frequency updates require the database to support high-concurrency writes and batch queries, to avoid data delay or loss. Cross-process linked business logic requires the database to support cross-table/collection queries, plus strict field validation to prevent dirty data such as slurry solid content and areal density from being entered. Electrochemical production’s safety requirements mandate database permission isolation to limit access to sensitive detection data. As production scale grows, per-batch data volume increases, so storage and indexing strategies must be planned appropriately to avoid excessive aggregate query latency.
Configuration Settings
This configuration is based on FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://admin:${pwd}@192.168.1.100:27017/lithium_ledger?authSource=admin | Adapts to unstructured formation and grading, safety test data storage; supports permission verification and distributed deployment |
PG_URL | postgresql://postgres:${pwd}@192.168.1.101:5432/prod_ledger | Stores structured batching, rolling, liquid injection, and other ledger data; supports complex cross-process linked queries |
DB_MAX_LINK | 150–250 connections | Matches concurrent write and query requests for multi-process per batch; avoids database connection pool exhaustion |
| Database Joint Index Configuration | Create joint indexes by batch number, process ID, and detection time | Accelerate cross-process ledger aggregate queries, aligns with the process-layered data update logic |
Three Common Configuration Mistakes
- Phenomenon: Authentication failure or connection timeout occurs when using MongoDB Compass to connect to the MongoDB instance bound to FastGPT. Cause: The correct authentication source parameter is not configured in
MONGODB_URI, or port access permissions for the database server are not enabled. - Phenomenon: Cross-process production ledger aggregation results are empty or have missing fields. Cause: A joint index is not created using batch number and process ID, so associated queries cannot match records from corresponding processes.
- Phenomenon: Database write requests frequently time out. Cause: The
DB_MAX_LINKvalue is lower than the current concurrent write request volume, exhausting the connection pool and preventing new database connections from being allocated.
How to Verify Successful Configuration
- Run the command line to connect to the configured
MONGODB_URI, confirm successful login and querying of the formation and grading data collection. - Launch the FastGPT built-in text2SQL testing tool, enter "Query coating and rolling parameters for a specified batch", and confirm return of the corresponding structured ledger data.
- View the database connection pool monitoring dashboard, confirm the current active connection count does not exceed the
DB_MAX_LINKconfiguration value. - Write a complete batching record for a test batch, confirm all configured fields are present in the corresponding database collection.
The values provided are common starting points and should be evaluated against the reader's own samples.