See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/323227871

Intelligent product quality control and defect detection: A case study

Conference Paper · March 2018

DOI: 10.1109/ASET.2018.8379841

CITATIONS READS

0 240

3 authors, including:

Saber Darmoul
Ecole Centrale Casablanca
62 PUBLICATIONS   237 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Artificial Immune Systems for Manufacturing Systems View project

SAFE-TRACS: Developing an Artificial Immune System to control roadway traffic signals and regulate traffic flow in case of emergencies View project

All content following this page was uploaded by Saber Darmoul on 16 April 2018.

The user has requested enhancement of the downloaded file.

 Intelligent product quality control and defect
detection: A case study
Khaoula Yazidi1 Saber Darmoul2
yazidikhaoula@gmail.com saber.darmoul@centrale-casablanca.ma
1
Laboratoire d’Informatique des Systèmes Industriels (LISI), Institut National des Sciences Appliquées et de Technologie
(INSAT), Université de Carthage, B.P. 676, Centre Urbain Nord, 1080, Tunis, Tunisia
2
Ecole Centrale Casablanca, Bouskoura Ville Verte, 27182, Casablanca, Morocco
Abstract— In manufacturing systems, several techniques and
approaches were developed to achieve product quality control
and defect detection based on centralized architectures and
systems. A relatively smaller number of works consider
developing distributed architectures and systems, based on
active/intelligent products that are able to achieve autonomous
quality control and defect detection, and only a few works
consider ontologies for these tasks. In this article, we design and
develop a distributed ontology-based quality control system that
enables intelligent products to detect defects autonomously. A
case study is conducted in a printed circuit board (PCB)
assembly industry to demonstrate the feasibility of the suggested
approach. We particularly show that ontologies contribute to the
transformation of raw data to useful information for improved
reliability and realization of distributed and autonomous quality
control capabilities.
Keywords— intelligent products; quality control.
I. INTRODUCTION
Printed circuit boards (PCBs) are made of numerous
components and have many features due to customization and
high number of process parameters. PCB assemblies are
manufactured using inherently variable materials and processes
[1], [2]. PCB assembly industries are subject to several kinds of
disturbances and risks [3], [4] that directly affect both the
quality of products and the overall operating costs, which
makes quality control and defect detection major concerns in
such industries. Numerous techniques were developed to
automate and boost quality control operations. Such techniques
include (but are not limited to) statistical quality control [5],
control charts [6], design of experiments (DoE) [7], as well as
data driven and classification techniques. Comprehensive
literature reviews on quality control and defect detection in
electronic industries can be found in [1], [2], [8]–[10].
Unfortunately, the majority of available quality control and
defect detection techniques are based on centralized monitoring
and control architectures and systems [10]. Although
centralized control provides global optimization features, it is
rigid and lacks responsiveness and flexibility [11].
978-1-5386-4449-2/18/$31.00 ©2018 IEEE
Sonia Hajri-Gabouj1
sonia.gabouj@insat.rnu.tn
In recent years, tremendous efforts have been dedicated to
designing and developing distributed control architectures and
systems, where products carry information, have
communication capabilities, and are endowed with intelligence
[12], [13] that enables them to perform some decision making.
Unfortunately, there is still a shortage of works that consider
developing distributed architectures and systems, based on
active/intelligent products that are able to achieve autonomous
quality control and defect detection. This article bridges part of
this gap, by considering ontologies for these tasks (see section
II for a review). We design and develop a distributed ontology-
based quality control system (see section Error! Reference
source not found.) that enables intelligent products to detect
defects autonomously. A case study (see section Error!
Reference source not found.) is conducted in a printed circuit
board (PCB) assembly industry to demonstrate the feasibility
of the suggested approach.
II. RELATED WORKS
Ontologies are knowledge management tools that allow
definition and reuse of domain knowledge, and provide
conceptual, syntactic and semantic views of data. Classes,
instances, properties and relations among instances of classes
are the main ontology building blocks [14]. Ontologies have
been developed to deal with quality issues of several types of
products, such as electronic products [15], [16], automotive
industry [17], [18], wind and steam turbines [19], [20], and
steel industry [21]. Existing works focus either on diagnosis to
find root cause analysis of defects [17]–[21], or on supervision
and monitoring of industrial processes [22], [23]. A limited
number of ontology-based approaches consider quality control
and defect detection and prediction [10]. There is a shortage of
works in literature that consider the tasks of quality control and
defect detection from the perspective of active/intelligent
products, i.e. products that are able to detect defects
autonomously, to classify potential types of defects, and initiate
investigation, analysis and decision support functions. The
suggested ontology in this article extends the ontology in [24]
and considers defects due to operational and environmental
conditions, unlike existing works, which focus on domain
specific defects [10].
 III. MAIN FUNCTIONS OF THE SYSTEM
Fig. 1 shows a UML [25] use case diagram to depict the
main functions of the suggested system, which is based on an
ontology that is instantiated on each printed circuit board inspect (fill in
(PCB) assembly using active Radio Frequency Identification symptoms)
(RFID) tags [26]. The so embedded ontology enables each Operator Ontology
product to become active, and to interact with its environment
detect and
to achieve three main functions:
classify defects
• Get nominal specifications: each active product can log
to enterprise information systems, such as Enterprise
Resource Planning (ERP) or Manufacturing Execution
System (MES), or to specific business process
software, such as Computer Aided Process Planning get nominal
(CAPP) or Computer Aided Design/Manufacturing specifications
(CAD/CAM) systems, and get information about its Intelligent PCBA Information systems
nominal design and/or process specifications, such as Fig. 1. Use case diagram.
production parameters, tolerances, norrative values,
etc. These specifications are available for each IV. ONTOLOGY DESIGN
inspection team operator.
The main functions of the system are associated to ontology
• Inspect printed circuit board assembly: in the absence classes as depicted in Fig. 2. Protégé (Stanford Center for
of automated visual inspection technologies [1] (see Biomedical Informatics Research, 2012) was used as
conclusion section for a discussion), quality control construction tool to assist the design. An instance of the class
teams have to manually inspect each printed circuit “PCB_Assembly” is associated to each PCB assembly, which is
board assembly, and to write down their observations, than described using instances of the class
usually by filling in a paper form. RFID technology “Nominal_Specifications” (to relate each PCB assembly to its
enables quality control and inspection operators to get nominal specifications), and instances of the class
rid of paper work, and to provide their observations “Obervations_Measures” (to relate each PCB assembly to its
directly by updating the appropriate ontology observed and measured indicators and parameter values).
properties embedded in each active product. Quality Instances of classes “PCB_Assembly”,
control and inspection information is therefore made “Nominal_Specifications” and “Defect_Type” are inputs to the
available instantaneously for each PCB assembly. ontology, which provides, as output, a classification of possible
defect types by inferring the instance of PCB assembly in one
• Detect and classify defects: quality control and of the sub-classes of the “Defect_Type” class.
inspection information is used as symptoms that enable
detection of defects by comparison of indicators with
nominal specifications and detection of non-acceptable
or intolerable deviations. Ontology reasoning allows
inferring possible types of defects (automatic
classification), and therefore initiate and guide more
advanced downstream investigation, analysis and
decision support functions.
The suggested ontology is compatible with existing
industrial information systems, and introduces complementary
decision support to them.

Fig. 2. System inputs and outputs.

Fig. 3 shows the taxonomy of the ontology classes. The

following sub-sections describe how the main functions of the
system are achieved based on properties, restrictions and rules
associated with each class.
 Each specification is implemented as an instance of the
class “Nominal_Specifications”. Each specification instance is
defined with data properties describing its range (upper and
lower bounds). Any instance of PCB assembly is then linked to
its specification instances using object properties. TABLE II
shows how specifications are implemented as ontology object
and data properties.

TABLE II. IMPLEMENTATION OF SPECIFICATIONS.

ObjectProperty Data property

hasRequiredConveyorSp hasLowerSpeed hasUpperSpeed
eed 0.8 1.4
hasRequiredWorkshop hasLowerHumidity hasUpperHumidity
humidity 40 60
hasRequiredWorkshop hasLowerTemperature hasUpperTemperatu
Fig. 3. Class taxonomy. Temperature re
22 29
A. Nominal specifications hasRequiredWarehouse hasLowerHumidity hasUpperHumidity
humidity 40 60
The class “Nominal_Specifications” includes information hasRequiredWarehouse hasLowerTemperature hasUpperTemperatu
about nominal (i.e. normal, acceptable, or tolerable) PCB Temperature re
assembly design specifications, process parameters and/or 22 27
hasRequiredNitrogen hasLowerNitrogenPre hasUpperNitrogenP
operational settings, such as production parameters, tolerances, Pressure ssure ressure
normative values, etc. These data are defined based on 6 8
customer requirements and in compliance with quality and hasRequiredDrying hasLowerTime hasUpperTime
environmental standards. TABLE I provides a list of PCB Time 2 5
assembly specifications that should be satisfied, along with hasRequiredAlcohol hasLowerQuantity hasUpperQuantity
their definitions. Quality control teams should inspect PCB (Flux) Quantity 20 35
assemblies with respect to these specifications. hasRequired hasLowerTime hasUpperTime
SolderContactTime 3 5
hasRequired hasLowerTemperature hasUpperTemperatu
TABLE I. LIST OF PCB ASSEMBLY SPECIFICATIONS.
ReflowTemperature re
Specification Definition 200 220
Conveyor speed Nominal conveyor velocity should be within hasRequired hasLowerTemperature hasUpperTemperatu
range [0.8; 1.4] m/min SolderTemperature re
Workshop humidity Nominal workshop humidity should be within 230 255
range [40; 60] % hasRequiredCreamQuant hasLowerQuantity hasUpperQuantity
Warehouse humidity Nominal warehouse humidity should be within ity 45 55
range [40; 60] % hasRequiredScrewingTo hasLowerScrewingTo hasUpperScrewing
Workshop temperature Nominal workshop temperature should be rque rque Torque
within range [22; 29] °C 4 5
Warehouse temperature Nominal warehouse temperature should be
within range [22; 27] °C Fig. 4 shows how an instance “PCBA_0” of PCB assembly
Nitrogen pressure Nominal nitrogen pressure per hour should be is associated with its corresponding specifications, defined as
within range [6; 8] N.m3/h object properties.
Drying time Nominal drying time should be within range [2;
5] min
Alcohol flow Nominal alcohol flow should be within range
[20; 35] g/h
Solder contact time Nominal solder contact time should be within
range [3; 5] sec
Reflow temperature Nominal reflow temperature should be within
range [200; 220] °C
Solder temperature Nominal solder temperature should be within
range [230; 255] °C
Cream quantity Nominal cream quantity should be within range
[45; 55] µm
Screwing torque Nominal screwing torque should be within range
[4; 5] Nm
Flux type Literal value within set {‘Alcohol Based Flux’,
‘Water Based Flux’ }
Wave nozzle type Literal value within set {‘Lamilent’,’Not
lamilent’ }
Conditioning mode Literal value within set {‘Racks’, ‘Box’ }
Work in process Nominal value should be ≤ 10days
Fig. 4. Instances of PCB assembly specifications.
B. Observations, measures and indicators parameters to nominal specifications and infers the
membership of a PCB assembly instance to subclasses of the
This class includes execution time information (e.g. “Defect Types” class based on the satisfaction of ontology
indicators, product and process parameters) about measured restrictions and SWRL rules.
and observed data related to a manufactured PCB assembly.
TABLE III provides an example of measured parameters of a 1) Supply failures
PCB assembly. This class predicts defects related to raw materials,
electronic parts, and suppliers. When the tested card has
TABLE III. AN EXAMPLE OF MEASURED PARAMETERS OF A PCB ASSEMBLY.
soldering balls or lack of solder filling problem and if the
Property Value manufacturing date of the PCB is expired (the date of PCB
hasMeasuredConveyorSpeed. 0.9 m/min receipt exceeds the PCB manufacturing date by more than six
hasMeasuredWorkshopHumidity. 50 % months), then the tested card will be inferred into the supplier
hasMeasuredWorkshopTemperature. 29 °C
failure class.
hasMeasuredWarehouseHumidity. 75 %
hasMeasuredWarehouseTemperature 25 °C 2) Process failures
hasMeasuredNitrogen Pressure. 9 Nm3 /h
hasMeasuredDrying Time. 3 Min This class predicts defects related to soldering processes. A
hasMeasuredAlcohol(Flux) Quantity. 30 g Process failure is generated if a process variable/parameter
hasMeasuredSolderContactTime. 4 Sec (Temperature, Nitrogen pressure, cream quantity, etc.) deviates
hasMeasuredReflowTemperature. 210 °C from its nominal specification. The deviation will violate
hasMeasuredSolderTemperature. 220 °C
hasMeasuredCreamQuantity. 50 µm
quality specifications and generate product non-conformities.
hasMeasuredScrewingTorque. 7 Nm “Process_failure” class is decomposed into “Reflow process
hasObservedFluxType. ‘BasedAlcoholFlux’ failure” class and “Soldering wave process failure” class.
hasObservedWaveNozzleType. ‘Lamilent’
hasObservedConditioningMode. ‘Racks’
a) Reflow Process failures
hasMeasuredWIP. 8 days Reflow is the process of assembling and soldering
electronic parts that do not have leads or legs, also called
Fig. 5 shows how an instance “PCBA_0” of PCB assembly Surface Mounted Devices (SMD). The aim of the reflow
is associated with its corresponding measured and observed process is to apply the optimum solder paste to the predefined
parameters, defined as data properties. zones on a printed circuit board, to place SMDs in appropriate
positions on the PCB and finally to form acceptable solder
joints. Membership to the “Reflow Process failure” class is
defined through SWRL rules, such as rule 1:
Rule1: Soldering_balls(?b), PCB_Assembly(?a),
hasDescription(?a, ?b),
hasMeasuredAlcoholQuantity(?a, ?value1),
hasRequiredAlcoholQuantity (AlchoolQuantityAQ0,
?max), greaterThan(?value1, ?max) ->
Reflow_process_failure(?a)

Rule 1 checks if the measured/real values of the reflow

Fig. 5. Instances of PCB assembly measured and observed parameters.
C. Defect types
This class provides a classification of defects that may alter
the quality of a PCB assembly and therefore make a customer
reject it. Once identified, quality defects will then need further
diagnosis and decision-making. The “Defect Types” class
contains six main sub-classes. The idea is to use reasoners
associated with ontologies, such as Pellet [28], to perform
automatic classification using ontology restrictions and rules
[29]. Automatic reasoning compares measured and observed
process specifications, such as reflow temperature, Cream
quantity, Alcohol quantity, are in the required range. If not,
then a reflow process defect is occurring.
b) Soldering Wave Process failures
Wave soldering is a method to solder electronic parts with
leads or legs that must come out through PCB holes. Soldering
wave process defects are detected based on rules that check if
the measured/real values of the soldering wave process
parameters/variables, such as solder contact time, conveyor
speed, wave nozzle type, are in the required ranges.
3) Machine failures
This class predicts defects related to machines and
equipment. A machine failure defect will be inferred if the state
of a machine or an equipment (e.g. wave frame, wave soldering
machine) does not meet nominal specifications such as rule 2:
Rule2: Badly_screwed_component(?b), PCB_Assembly(?a),
 hasDescription(?a, ?b),
hasLower_ScrewingTorque(ScreweingTorqueST0, ?min),
hasMeasuredScrewingTorque(?a, ?value1), lessThan(?value1,
?min) -> Machine_failure(?a)
Rule 2 checks if the measured screwing torque parameter is
in the required range. If not, then a machine failure is
occurring.
4) Storage failures
This class predicts defects related to storage conditions of
electronic parts and printed circuit boards, which impact final
product reliability and process efficiency such as rule 3:
Rule3: Soldering_balls(?b), PCB_Assembly(?a),
hasDescription(?a, ?b),
hasUpperHumidity(WareHouseHumidityWHH0, ?max),
hasMeasuredWarehouseHumidity(?a, ?value1),
greaterThan(?value1, ?max) -> Storage_condition_failure(?a)
Rule 3 checks if the measured warehouse humidity
parameter is in the required range. If not, then a storage failure
is occurring.
5) Operating conditions
This class predicts defects related to operating conditions
on the shop floor, such as work in process time, percentage of
rejects and rework, conditioning mode between workstations,
atmospheric conditions, etc.
Rule 4: Soldering_holes(?b), PCB_Assembly(?a),
hasDescription(?a, ?b),
hasLowerTemperature(WorkshopTemperatureWT0, ?min),
hasMeasuredWorkshopTemperature(?a, ?value1),
lessThan(?value1, ?min) -> Production_condition_failure(?a)
Rule 4 checks if the measured workshop temperature is in
the required range. If not, then an operating defect is occurring.
6) Manpower failures
This class predictts defects related to operator mistakes and
errors.
Rule 5: Soldering_cracked(?b), PCB_Assembly(?a),
hasDescription(?a, ?b), hasMeasuredDryingTime(?a, ?time),
lessThan(?time, ?min) -> Manpower_failure(?a)
Rule 5 checks if the measured drying time is in the required
range. If not, then a manpower defect is occurring.
V. REASONING AND INFERENCE
Once a PCB assembly instance is created and defined with
specific properties and attributes, the reasoner Pellet is
launched. The obtained results are the inference of the PCBA
individual in the corresponding defect type classes. Fig. 6
shows that instance “PCBA_0” previously defined in Fig. 4
and Fig. 5 is inferred as member of defect classes “soldering
wave process failure” and “storage condition failure”. Hence,
this instance of PCB assembly has to undergo further diagnosis
to determine the nature of the defect. It can be forwarded to the
maintenance department to confirm if it is a defect related to
the soldering wave process, and to the production department
to confirm if it is a defect related to storage conditions.
Fig. 6. Inference of defect types of instance PCBA_0.
VI. CONCLUSION
This article presented a case study from the printed circuit
board assembly industry to show that ontologies contribute to
realize distributed and autonomous quality control capabilities.
The suggested ontology is compatible with existing reference
manufacturing system ontologies, such as [24], [30]–[32]. This
work can be extended in several ways:
• In the case study, observations and measured data are
filled in manually by inspection operators, due to
budget constraints in the company. Intelligent
products can benefit from automated visual inspection
technologies [1] to automatically inspect each printed
circuit board assembly, and to update observations and
measured data directly without any human
intervention.
• Inferencing is based on Boolean checking and
satisfaction of rules. Fuzzy logic can be considered to
consider uncertainty in measured and observed data.
Control charts can also be considered to better analyze
deviations from nominal specifications.
• Multiple inferencing only shows potential defects.
This is a necessary first step of risk identification. A
risk assessment step is necessary to evaluate the
impact of the detected defects, and to further guide
diagnosis and decision making.
• Based on risk assessment, multi-criteria decision
making can be considered to rank defects and
prioritize diagnosis and decision making.
• A centralized knowledge base can be designed using
ontologies to capture distributed defect detection and
enable its reuse, according for example to a case-
based reasoning (CBR) approach.
REFERENCES
[1] P. S. Malge and R. S. Nadaf, “A Survey : Automated Visual PCB
Inspection Algorithm,” Int. J. Eng. Res. Technol., vol. 3, no. 1, pp.
223–229, 2014.
[2] A. F. M. Hani, A. S. Malik, R. Kamil, and C.-M. Thong, “A Review
of SMD-PCB Defects and Detection Algorithms,” in Fourth
International Conference on Machine Vision, 2012, vol. 8350, no.
Icmv 2011, pp. 1–7.
[3] D. Ivanov, A. Dolgui, B. Sokolov, and M. Ivanova, “Disruptions in
supply chains and recovery policies: state-of-the art review,” IFAC-
PapersOnLine, vol. 49, no. 12, pp. 1436–1441, 2016.
[4] S. Darmoul, H. Pierreval, and S. Hajri–Gabouj, “Handling
disruptions in manufacturing systems: An immune perspective,”
Eng. Appl. Artif. Intell., vol. 26, no. 1, pp. 110–121, Jan. 2013.
[5] R. K. Rajput, “Inspection and quality control,” in A Textbook of
Manufacturing Technology: Manufacturing Processes, Laxmi
Publications (P) LTD, 2007.
[6] M. Riaz and F. Muhammad, “An Application of Control Charts in
Manufacturing Industry,” vol. 1, no. 1, pp. 77–92, 2012.
[7] D. C. Montgomery, Design and analysis of experiments, 7th Editio.
John Wiley & Sons, 2009.
[8] T. J. Mateo Sanguino and M. Smolčić-Rodríguez, “Computer-Aided
System for Defect Inspection in the PCB Manufacturing Process,”
in IEEE 16th International Conference on Intelligent Engineering
Systems, INES 2012, 2012, pp. 151–156.
[9] C. Tsai and C. Chiu, “A case-based reasoning system for PCB
principal process parameter identification,” Expert Syst. Appl., vol.
32, no. 4, pp. 1183–1193, May 2007.
[10] M. Liukkonen, E. Havia, and Y. Hiltunen, “Computational
intelligence in mass soldering of electronics - A survey,” Expert
Syst. Appl., vol. 39, no. 10, pp. 9928–9937, 2012.
[11] D. Trentesaux, “Distributed control of production systems,” Eng.
Appl. Artif. Intell., vol. 22, no. 7, pp. 971–978, 2009.
[12] G. G. Meyer, K. Framling, and J. Holmstram, “Intelligent Products:
A survey,” Comput. Ind., vol. 60, no. 3, pp. 137–148, 2009.
[13] Y. Sallez, T. Berger, D. Deneux, and D. Trentesaux, “The lifecycle
of active and intelligent products : The augmentation concept,” vol.
23, no. 10, pp. 905–924, 2010.
[14] A. Matsokis and D. Kiritsis, “An ontology-based approach for
Product Lifecycle Management,” Comput. Ind., vol. 61, no. 8, pp.
787–797, Oct. 2010.
[15] J. J. Jung, “Ontology-based decision support system for
semiconductors EDS testing by wafer defect classification,” Expert
Syst. Appl., vol. 38, no. 6, pp. 7425–7429, 2011.
[16] S. M. Anouncia and R. Saravanan, “A knowledge model for gray
scale image interpretation with emphasis on welding defect
classification — An ontology based approach,” Comput. Ind., vol.
61, no. 8, pp. 742–749, 2010.
[17] J. Yi, S. Chen, X. Geng, and Y. Lin, “Research on Fault Diagnosis
Expert System of Automotive Engine based on Ontology,” in
Electrical and Control Engineering (ICECE), 2011 International
Conference on, 2011, pp. 5409–5412.
[18] Dnyanesh G. Rajpathak, “An ontology based text mining system for
knowledge discovery from the diagnosis data in the automotive
domain,” Comput. Ind., vol. 64, no. 5, pp. 565–580, 2013.
[19] N. Dendani-hadiby and M. T. Khadir, “A Case based Reasoning
System based on Domain Ontology for Fault Diagnosis of Steam
Turbines,” Int. J. Hybrid Inf. Technol., vol. 5, no. 3, pp. 89–104,
2012.
View publication stats
[20] A. Zhou, D. Yu, and W. Zhang, “A research on intelligent fault
diagnosis of wind turbines based on ontology and FMECA,” Adv.
Eng. Informatics, vol. 29, no. 1, pp. 115–125, Jan. 2015.
[21] S. Zillner, A. Ebel, and M. Schneider, “Towards intelligent
manufacturing, semantic modelling for the steel industry,” in IFAC-
PapersOnLine, 2016, vol. 49, no. 20, pp. 220–225.
[22] L. Mönch, M. Stehli, L. Moench, and M. S. De, “An Ontology for
Production Control of Semiconductor Manufacturing Processes,”
pp. 156–167, 2003.
[23] X. H. Li jun Sun, Fangfang Li, “An Ontology-based Model for
Typical-context Awareness in the Oil Products,” in 20th
International Conference on Knowledge Based and Intelligent
Information and Engineering Systems, 2016, vol. 96, no. September,
pp. 1156–1165.
[24] N. Bayar, S. Darmoul, S. Hajri-Gabouj, and H. Pierreval, “Using
immune designed ontologies to monitor disruptions in
manufacturing systems,” Comput. Ind., vol. 81, pp. 67–81, Oct.
2015.
[25] OMG, “About the Unified Modeling Language Specification
Version 2.5,” 2017. [Online]. Available:
http://www.omg.org/spec/UML/2.5/. [Accessed: 20-Nov-2017].
[26] F. Chetouane, “An Overview on RFID Technology Instruction and
Application,” IFAC-PapersOnLine, vol. 48, no. 3, pp. 382–387,
2015.
[27] Stanford Center for Biomedical Informatics Research, “Protégé,”
Protégé, 2016. [Online]. Available: http://protege.stanford.edu/.
[28] E. Sirin, B. Parsia, B. Cuenca, B. C. Grau, A. Kalyanpur, and K.
Yarden, “Pellet : A Practical OWL-DL Reasoner,” Softw. Eng.
Semant. Web, vol. 5, no. 2, pp. 51–53, 2007.
[29] G. Antoniou et al., “Combining Rules and Ontologies. A survey,”
2005.
[30] S. Borgo and P. Leitão, “Foundations for a core ontology of
manufacturing,” Ontologies, pp. 1–40, 2007.
[31] K. Efthymiou, K. Sipsas, D. Mourtzis, and G. Chryssolouris, “On
knowledge reuse for manufacturing systems design and planning: A
semantic technology approach,” CIRP J. Manuf. Sci. Technol., vol.
8, pp. 1–11, 2015.
[32] Z. Usman, R. I. M. Young, N. Chungoora, C. Palmer, K. Case, and
J. a. Harding, “Towards a formal manufacturing reference
ontology,” Int. J. Prod. Res., vol. 51, no. August 2013, pp. 6553–
6572, 2013.