What the data for this category looks like
Data sources for this category include wafer test maps, manufacturing execution systems (MES), bonding and molding equipment, ATE test machines, X-ray/SAM inspection equipment, and customer specification documents. Daily documents include packaging process cards, bonding and molding parameter tables, wafer incoming material maps, test program version records, yield reports, and failure analysis reports. Data updates align with production batches, single-die test results, and daily summary cycles. Fields include batch identifiers, wafer numbers, test bin codes, equipment operating parameters, failure locations, and more. Documents at each production stage have distinct fields, requiring real-time synchronization per production link.
What constraints these characteristics impose on HTTP interfaces and external systems
Data for this category is scattered across multiple equipment and system types, with varying fields across production stages. HTTP interfaces must support pulling data from multiple sources, and must adapt to return formats of different equipment. Data update cycles cover batch-level, single-die test-level, and daily-level updates. High-frequency real-time updates require interfaces to support short-interval polling or event triggering to avoid delayed ledger data. No unified field standards exist, so custom field mapping rules must be passed via variables to adapt to differences in ledger fields across packaging processes, test parameters, and other stages. Multi-source data must be bound using batch identifiers for association. Interfaces must verify batch uniqueness to prevent cross-batch production risks.
Configuration Settings
The following configurations are based on FastGPT v4.17.0:
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
Authorization | Bearer {custom authentication key} | Complies with HTTP interface authentication specifications, adapts to the Bearer authentication requirements of external systems |
variables | {"batchId": "auto_extract", "testBin": "${responseData.binCode}"} | Adapts to batch and test bin code field mapping for semiconductor packaging and testing, matches field differences across multi-source data |
| Single request timeout | 30–60 seconds | Covers data return cycles of ATE test machines and X-ray/SAM equipment, avoids request interruptions |
responseData parsing rules | Extract parameters grouped by production stage | Ensures ledger data is aggregated by packaging, testing, inspection, and other stages to facilitate report generation |
| Authentication method | Calibrated based on actual testing | Adapts to authentication configurations of external systems, supports Basic Auth or custom tokens |
Three Common Configuration Mistakes
- Calling the interface returns a
401 Unauthorizedstatus code. The cause is incorrect configuration of theAuthorizationparameter that does not match the authentication rules of the external system. - Pulled ledger data fields are empty or have inconsistent formatting. The cause is failure to configure correct field mapping rules via
variables, and failure to adapt to exclusive field formats for semiconductor packaging and testing. - The number of interface return results does not match actual production batches. The cause is failure to bind batch identifiers as request parameters, leading to mixing of multi-batch data.
How to Confirm Proper Configuration
- Call the test interface, check if the returned
responseDataincludes preset exclusive fields for packaging and testing, and verify that the field mapping conforms to configuration rules. - Simulate a request for a single production batch, confirm that the authentication parameter
Authorizationtakes effect with no authentication errors. - Initiate multiple consecutive requests, verify that the interface response duration meets the configured timeout requirements, with no frequent interruptions.
- Compare pulled data with batch records in the MES system, confirm that batch identifiers are bound correctly with no cross-batch data.
The values provided are common starting points and should be measured against samples from the target deployment.