LMES Inbound Processing Logic Explanation

1. Overview

This document aims to elaborate on the core business logic and technical implementation of the LMES system when processing Normal Parts, Inspection Parts, and Repair Parts. Before entering any station, all products must pass the identity determination and access verification of DetermineProcessActivity (Process Type Determination Activity), which is the unified entry point for all inbound logic.

The core design idea of the system is to establish a clear and orderly priority arbitration mechanism to ensure that products can be quickly and accurately guided to the correct processing path in complex production scenarios.

2. Processing Judgment Priority

Unlike the old logic, LMES adopts a new three-level priority judgment model. The system strictly checks inbound products in the following order. Once a high-priority check is hit, it directly enters the corresponding process and no longer executes subsequent priority checks.

1. Highest Priority: Inspection Part

   • Judgment Basis: The system first calls HasInspectionAsync to check if the product has a valid "Inspection Task".
   • Core Logic: If it exists, the product is immediately identified as an "Inspection Part", and its "Repair" status is ignored. The system will skip the repair check and directly enter the specific verification process for inspection parts.

2. Medium Priority: Repair Part

   • Judgment Basis: If the product is not an inspection part, the system calls ProductQualityCheckAsync to check if the product has quality judgment records (such as "Equipment Repair", "Scrap", etc.) through the IProductQualityChecker service.
   • Core Logic: If it exists, the product is identified as a "Repair Part" or "Special Status Item", and release, interception, or repair operations are performed according to its specific quality status (In Transit, Scrap, Arrived at Repair Station, etc.).

3. Normal Priority: Normal Part

   • Judgment Basis: If the product is neither an inspection part nor a repair or special status item.
   • Core Logic: The product is regarded as a "Normal Part" and must pass a series of strict, multi-level qualification verifications before it can enter the station for standardized production.

3. Core Processing Flow Details

3.1 Inspection Part Processing Flow

• Identification and Trigger: DetermineProcessActivity first checks the hasInspectionMark flag. If true, the product is confirmed as an inspection part.

• Inbound Verification Logic (ProductFormulaCheckAsync): Although inspection parts have the highest priority, they still need to pass necessary verification:

  1. Product Model Verification: Similar to normal part logic, it checks the match between the inbound product model and the inspection task or current station context.
  2. Process Route Verification: The system calls IProductTraceChecker.CanEnterStationAsync for verification, but passes the formulaCheck parameter as false. This means the system will not check formula-related configurations, but will still execute basic process route verifications such as Duplicate Code and Missing Process to ensure compliance of inspection operations.

• Outbound Logic: The logic after the inspection task is completed depends on its inspection judgment result.

3.2 Repair Part Processing Flow

• Identification and Trigger: When the product is not an inspection part, the ProductQualityCheckAsync activity is triggered. It iterates through all IProductQualityChecker implementations and calls the CanEnterStationAsync method. If any checker returns hasRepairMark = true, the product is confirmed as a repair part or special status item.

• Inbound Verification Logic: The access logic for such products is determined entirely by the return value of CanEnterStationAsync and the specific quality status of the product, mainly divided into the following four scenarios:

  • Scenario A: Allowed Inbound (Repair Channel)

    • Condition: Product status is "Equipment Repair", and canEnterStation returns true.
    • Description: Usually means the product has arrived at the repair station specified in its quality record. The system will open a "Green Channel" for it, exempting all conventional error-proofing verifications (such as duplicate code, missing process), allowing the product to enter the station for repair operations.

  • Scenario B: In-Transit Release (Bypass Channel)

    • Condition: Product status is "Equipment Repair", but canEnterStation returns false.
    • Description: The product is a repair part, but the current station is not its specified repair destination. The system will issue a "Bypass" instruction to the equipment to let the product pass safely and continue to flow to the target repair station.

  • Scenario C: NG Item Outflow (Bypass to Buffer)

    • Condition: Product status is "NG Item Outflow".
    • Description: This is a temporary suspended status. The system will not intercept but will issue a "Bypass" instruction to all stations except the specified buffer, allowing the product to flow along the line and finally be discharged at the specified defective product processing station or flow into the buffer, waiting for final judgment by QA personnel.

  • Scenario D: Interception (Interception Channel)

    • Condition: Product status is "Product Scrap".
    • Description: The system will issue a hard stop instruction and trigger an alarm, forcing the product to be removed from the production line. Scrapped items will be permanently banned from entering any production station.

• Outbound Logic: After repair is completed, the system clears the "Repair" mark of the product, restoring it to "Normal Part" status so that it can accept standard quality error-proofing verifications in subsequent processes.

3.3 Normal Part Processing Flow

• Identification and Trigger: When the product has neither inspection mark nor repair or special status mark, it is confirmed as a normal part and enters the ProductFormulaCheckAsync method for processing.

• Core Logic: Verification of normal parts is divided into two main stages: Identity Determination & Error Proofing and Historical Compliance Verification. Stage 1: Identity Determination & Error Proofing The core of this stage is to determine the "Authoritative Product Model" of the product and prevent model confusion.

  1. Check Product History: The system first calls GetProductionAsync(serialNumber) to check if the product has been processed.

  2. Scenario A: Product Processed (Has History)

     • Identity Determination: The product's identity (Product Model, Work Order, etc.) is obtained directly from its historical records.
     • Error Proofing: Product Model Mismatch Interception: The system immediately compares the product's known model with the context of its current station (determined by the work order segmentOrder issued by the current section or the formula formulaModel applied by the station). If the two do not match, it means the production line configuration has changed while the old product was sent in by mistake. The system will immediately intercept on the grounds of "Product Model Mismatch". This is the core error-proofing mechanism to prevent mixed materials.

  3. Scenario B: Product Not Processed (No History)

     • Identity Determination: For new products, the system must rely on the current station context to assign identity. At this time, the configuration of "Formula Distribution Method" becomes crucial:

       • Method 0 (Work Order Distribution Only): The system must be able to obtain the work order (segmentOrder) issued by the current section and use it to determine the product model. If there is no work order, inbound is prohibited.
       • Method 1 (Process Formula Distribution Only): The system relies on the formula (formulaModel) statically applied by the current station to determine the product model.
       • Method 2 (Distribution when Process Identifies Product): This method theoretically applies to products with existing records. If a new product appears in this mode, it usually means there is an exception in the upstream process.

  Stage 2: Historical Compliance Verification After the product's authoritative identity is determined and error-proofing verification is passed, the system calls IProductTraceChecker.CanEnterStationAsync for final historical compliance verification:

  • Product Status Verification: Trace the processing results of upstream key processes. If the preceding result is NG, inbound is prohibited.
  • Duplicate Code Verification: Check if the product has a successful processing record at the current station. If so, it is judged as "Duplicate Code" and inbound is prohibited.
  • Missing Process Verification: Check the complete processing history of the product to ensure it strictly follows the preset process route and has not "skipped stations". Otherwise, it is judged as "Missing Process" and inbound is prohibited.

• Outbound Logic: After normal processing is completed, the product flows to the next process according to the standard process flowchart.

4. Inbound Logic Decision Flowchart

5. Processing Type Comparison Summary

Processing Type	Identification Method	Core Checkpoint	Production Line Behavior	Key Note
Inspection Part	hasInspectionMark=true	Formula check exempted	Configure error proofing as needed, Prohibit Inbound if not met	Highest Priority
Repair Part (At Specified Process)	hasRepairMark=true	canEnterStation returns true	✅ Allow Inbound (Exempt conventional error proofing)	System opens repair "Green Channel"
Repair Part (In Transit)	hasRepairMark=true	canEnterStation returns false	➡️ Bypass (In-Transit Release)	Safely pass intermediate stations to specified repair point
NG Item Outflow	hasRepairMark=true NG Item Outflow status	None	➡️ Bypass (Release to Buffer)	Temporary suspended status, waiting for final judgment
Scrap Item	hasRepairMark=true Scrap status	None	❌ Permanently Prohibit entering any station	Product lifecycle ends
Normal Part	No inspection or repair mark	Identity Determination -> Historical Compliance Verification	Strictly execute all error proofing, Prohibit Inbound if not met	Standard error-proofing path ensuring production quality