The persistent challenge of metal casting defect has long been a primary factor compromising casting quality and reducing yield rates. Throughout the long history of foundry practice, a wealth of invaluable experience for analyzing these defects has been accumulated. However, this experiential knowledge is notoriously difficult to describe using precise mathematical formulas. This gap motivated the development of an expert system dedicated to metal casting defect analysis. By encapsulating the knowledge and heuristics of numerous seasoned foundry experts, such a system can address the intricate, multifaceted problems associated with metal casting defect. Its core functions are to identify the specific type of metal casting defect, diagnose its root causes, and ultimately propose preventive measures in the foundry process. The overarching goal is to significantly enhance final casting quality. Furthermore, as an expert system is essentially a computer program, it can be easily replicated. In an era where personal computers are ubiquitous, this allows countless foundries and workshops to access and leverage expert-level knowledge. When production issues arise, consultants can directly interact with the system to obtain diagnostic solutions. Therefore, the research and development of a casting defect analysis expert system holds substantial practical importance.
Prolog, an artificial intelligence language developed in the 1970s, is particularly well-suited for building expert systems due to its strengths in symbolic reasoning and pattern matching. Consequently, I chose to design and implement the “Metal Casting Defect Analysis Expert System” (hereinafter referred to as the MCDA system) using this language. A key practical advantage is that the system was compiled into a standalone executable, allowing it to run directly under the DOS operating system without requiring the Prolog development environment.
System Architecture and Foundational Principle
The analysis of a metal casting defect relies heavily on the experiential knowledge of human experts. Since this knowledge is often heuristic and not strictly formal, it cannot be easily captured by the deterministic formulas typical of mathematics or physics. To accommodate this characteristic, my system employs a rule-based formalism to represent expert knowledge, thereby simulating the expert’s diagnostic reasoning process. The core logic flows as follows: first, based on the observed features of a metal casting defect, the system’s inference engine interrogates a knowledge base built with production rules to deduce the defect’s identity. Once identified, the system retrieves and presents the associated causes and preventive measures for that specific metal casting defect. This entire process is encapsulated within five integrated modules:
- Knowledge Base: Stores the expertise on metal casting defect.
- Inference Engine: Executes the reasoning process.
- Database: Holds factual information on causes and remedies for each metal casting defect.
- Human-Machine Interface: Manages interaction with the user.
- Explanation Facility: Provides transparency into the system’s reasoning.
The relationship between these modules is illustrated in the diagram below. The user interacts with the system through the interface. The inference engine, which is the system’s core, coordinates the process: it uses inputs from the user to drive the search through the knowledge base, consults the database for specific cause-and-effect information, and utilizes the explanation facility to justify its queries and conclusions to the user.
Integrating such a diagnostic system into a modern, automated foundry environment, like the one shown, represents the ideal application. It allows for rapid diagnosis and correction of process parameters when a metal casting defect is detected, minimizing downtime and scrap.
Structure of the Knowledge Base
The organization and representation of knowledge form the bedrock of any expert system. It must faithfully and comprehensively embody the human expert’s know-how. In the MCDA system, knowledge is organized hierarchically in a tree structure. This involves first classifying all metal casting defect into seven major categories based on their macroscopic appearance. This high-level classification serves a critical purpose: it immediately confines the scope of the diagnostic session to a specific subtree of the knowledge tree, dramatically reducing the number of questions the user must answer and making the system more efficient.
The table below summarizes this primary classification of metal casting defect:
| Major Defect Category | General Description |
|---|---|
| Excess Material Defects | Unwanted metallic projections on the casting surface (e.g., fins, swells). |
| Cavity Defects | Holes or voids within or on the surface of the casting. |
| Incomplete Casting Defects | The casting shape is not fully formed. |
| Surface Defects<!– | Irregularities confined to the casting surface (e.g., sand burn-on, scabs). |
| Shape Discrepancy Defects | The casting dimensions or geometry deviate from specifications. |
| Crack & Cold Shut Defects | Fractures or failures in metal continuity. |
| Inclusion Defects | Presence of foreign materials (metallic or non-metallic) within the casting. |
Beneath each major category, the tree branches further to specific defect types. Each specific metal casting defect is uniquely defined by a set of characteristic features. For instance, under the “Cavity Defects” category, one finds defects like blowholes, shrinkage cavities, and sand inclusions. Each is distinguished by specific traits such as cavity surface texture (smooth vs. rough), location (subsurface vs. thermal center), and morphology (large/isolated vs. small/dispersed).
The system’s knowledge is primarily sourced from decades of foundry expert experience and standard metallurgical handbooks. To represent this knowledge computationally, I employed production rules. The basic form of a rule is:
IF (Condition1) AND (Condition2) AND … THEN (Conclusion)
In Prolog, this maps naturally to a Horn clause. For example, the rule for identifying a “Shrinkage Cavity” metal casting defect can be formally stated as:
$$ \text{defect\_is(shrinkage\_cavity)} \leftarrow \text{category(cavity)} \land \text{location(thermal\_center)} \land \text{morphology(large\_concentrated)} $$
This is implemented in Prolog as a fact and rule. The knowledge base is a collection of such rules for every known metal casting defect. In the current MCDA system, the knowledge base contains approximately 40 such production rules, covering a wide range of common metal casting defect scenarios. A sample of how rules map to specific defects is shown below:
| Defect Name | Sample Rule Conditions (Simplified) |
|---|---|
| Shrinkage Cavity | Category = Cavity, Location = Hot Spot, Surface = Rough, Morphology = Large & Concentrated. |
| Blowhole | Category = Cavity, Location = Subsurface, Surface = Smooth, Shape = Spherical/Egg-shaped. |
| Sand Inclusion | Category = Cavity, Location = Any, Contains = Sand Grains. |
| Cold Shut | Category = Crack/Cold Shut, Appearance = Line with Rounded Edges, Location = Away from Gate. |
The Inference Engine: Core of the Diagnostic Logic
The inference engine is the system’s problem-solving core, analogous to how a human expert applies rules of thumb derived from knowledge and practice. The MCDA system utilizes a backward-chaining inference mechanism. This goal-driven strategy works as follows: the system starts with a potential conclusion (hypothesis), such as “the metal casting defect is a shrinkage cavity.” It then attempts to prove this hypothesis by querying the user for information. The user’s inputs (“yes” or “no” responses to feature questions) are matched against the premises of the production rules in the knowledge base. The system’s line of questioning is dynamically determined by which hypothesis it is currently trying to prove or disprove.
If all the conditions (premises) of a rule are satisfied by the user’s inputs, the rule “fires,” and the conclusion (the defect identity) is confirmed. If a rule’s conditions cannot be met, the hypothesis is rejected, and the system may then pursue another defect hypothesis. This technique is highly efficient for rule-based knowledge bases structured as a classification tree.
The process can be modeled logically. Let $H$ be the hypothesis (e.g., $\text{shrinkage\_cavity}$). The knowledge base contains a rule $R$: $H \leftarrow C_1 \land C_2 \land … \land C_n$. The inference engine’s task is to determine the truth value of $H$. It does this by recursively determining the truth of each subgoal $C_i$:
$$ \text{Infer}(H) = \bigvee_{R \in \text{KB}} \left( \text{Consequent}(R) = H \land \bigwedge_{C_i \in \text{Antecedent}(R)} \text{Infer}(C_i) \right) $$
Where $\text{Infer}(C_i)$ either retrieves a fact from the user or recursively tries to prove another rule whose consequent is $C_i$. For terminal conditions asked of the user, $\text{Infer}(C_i)$ returns $\text{AskUser}(C_i)$.
Once the specific type of metal casting defect is identified, the system proceeds to the advisory phase. It accesses a dedicated database resident in memory that stores cause-and-remedy information paired with each defect. By matching the identified defect’s attribute to this database, the system retrieves and displays the relevant analysis and recommended preventative actions for that particular metal casting defect.
Human-Machine Interface and Explanation Module
Usability was a primary design consideration. The system features a menu-driven interface to gather initial input from the user. Upon startup, a main menu offers two core modules: (1) Identify Defect and (2) Consult on Known Defect.
- If the user chooses Identify Defect, the system engages in an interactive dialog, posing a series of yes/no questions about the observed features of the metal casting defect. The inference engine drives this questioning sequence in the background.
- If the user selects Consult on Known Defect, the system presents a comprehensive menu listing all known metal casting defect by name. The user simply selects the defect, and the system immediately outputs its causes and preventive measures.
This intuitive design ensures that users, who may have no understanding of the system’s internal architecture (Prolog, rules, inference chains), can interact with it effectively. They are essentially having a direct consultation with the encapsulated expertise.
Closely tied to the interface is the explanation facility. During the defect identification dialog, whenever the system poses a question (e.g., “Is the defect located in a thermal center?”), it simultaneously provides a clear, concise explanation of what the term means (e.g., “Thermal center refers to the thickest section or the last area to solidify”) and why this question is relevant to diagnosing the metal casting defect. This transparency is crucial. It allows the user to provide accurate information based on a correct understanding of the question. More importantly, it demystifies the system’s reasoning process, allowing the user to follow and learn from the expert logic embedded within. This transforms the system from a black-box tool into an interactive tutoring aid, enabling users to build their own knowledge about metal casting defect analysis during the consultation.
System Operation and Evaluation
The MCDA system was fully coded in Prolog and compiled for standalone execution. A typical consultation session for diagnosing a shrinkage cavity metal casting defect proceeds as follows. The user selects “Identify Defect” from the main menu. The system begins the backward-chaining process. It might start with the high-level goal of categorizing the metal casting defect.
System: “Is the defect characterized by excess metal material?” (Explains: e.g., fins, swells).
User: “No.”
System: “Is the defect a cavity or hole?” (Explains: internal or surface void).
User: “Yes.”
System: (Now focused on the Cavity Defect subtree) “Is the cavity wall smooth?”
User: “No.”
System: “Is the cavity located in a thermal center or last-to-solidify area?” (Explains the concept).
User: “Yes.”
System: “Is the cavity large and concentrated, rather than many small dispersed pores?”
User: “Yes.”
System: [Inference engine matches the pattern to the rule for ‘shrinkage_cavity’] “The identified metal casting defect is: Shrinkage Cavity.”
The system then returns to the main menu. The user now selects “Consult on Known Defect,” chooses “Shrinkage Cavity” from the list, and receives detailed output:
Cause Analysis: The system lists reasons such as excessive liquid/solidification shrinkage, high pouring temperature, improper alloy composition, poor gating/risering design, sudden changes in section thickness, low mold rigidity, and gas precipitation during solidification.
Preventive Methods: Corresponding measures are listed, including promoting directional solidification, optimizing riser size/number, using chills, controlling chemical composition (e.g., carbon equivalent), reducing residual magnesium in ductile iron, increasing mold compaction, and minimizing gas content in the melt.
This seamless integration of diagnosis and advisory functions makes the system a comprehensive tool for addressing the metal casting defect problem. The logical flow from symptom observation to cause identification and finally to solution proposal mirrors the ideal expert consultant’s workflow.
Discussion, Limitations, and Future Directions
The development of the MCDA system demonstrates the effective application of classical expert system technology to a well-defined, experience-intensive domain like metal casting defect analysis. The tree-structured knowledge organization provides clarity and efficient reasoning. The production rule representation is a natural fit for the heuristic “if-then” knowledge prevalent in foundry practice. The backward-chaining inference mechanism is particularly suitable for classification tasks where the goal (defect type) is clear, and the evidence (defect features) is gathered to confirm it.
However, several limitations are acknowledged, pointing toward avenues for future enhancement:
- Knowledge Acquisition Bottleneck: The initial knowledge base of ~40 rules, while covering major defects, is not exhaustive. Manually encoding expert knowledge is time-consuming. Future versions could incorporate machine learning techniques to learn new rules from historical case data of metal casting defect occurrences.
- Static Knowledge Base: The current system cannot learn from new cases or user feedback. An adaptive system that refines its rule confidence factors or adds new rules based on successful/unsuccessful diagnoses would be more powerful.
- Handling Uncertainty: The current system operates on Boolean (yes/no) logic. In reality, an expert might be 80% sure a cavity wall is “rough.” Future systems could incorporate certainty factors or fuzzy logic to handle such uncertainties in feature description and rule matching, providing a more nuanced diagnosis for ambiguous cases of metal casting defect.
- Integration with Quantitative Data: The system primarily uses qualitative, observational features. It could be significantly strengthened by integrating with quantitative process data (e.g., pouring temperature logs, chemical analysis results, sand property tests). Rules could then include numerical thresholds, such as: IF pouring_temperature > 1550°C AND carbon_equivalent < 3.8 THEN increased_risk(shrinkage_cavity).
- Graphical User Interface (GUI): A modern GUI with images of different metal casting defect types would greatly aid users in accurately identifying features, reducing misinterpretation of questions.
Despite these limitations, the implemented MCDA system serves as a robust proof-of-concept. It validates the architecture and provides a solid foundation for building more sophisticated, next-generation diagnostic aids for the foundry industry. The core value proposition remains: capturing, preserving, and disseminating critical expertise on metal casting defect to improve quality and productivity across the manufacturing sector.
Conclusion
In conclusion, the Metal Casting Defect Analysis Expert System (MCDA) represents a practical implementation of artificial intelligence techniques to solve a persistent industrial problem. The system’s architecture, comprising a production rule knowledge base, a backward-chaining inference engine, a supporting database, a menu-driven human-machine interface, and an integrated explanation facility, provides an effective framework for diagnosing metal casting defect. By guiding users through a structured logic tree based on observable defect characteristics, it successfully emulates the diagnostic reasoning of a human foundry specialist. The system’s ability to not only identify the metal casting defect but also to elucidate its causes and recommend preventive measures makes it a valuable tool for both troubleshooting and training. While future work will focus on expanding the knowledge base, incorporating uncertainty management, and integrating with process data systems, the current system establishes a functional and accessible platform for leveraging expert knowledge to combat the costly and quality-diminishing challenge of metal casting defect in foundries worldwide.