Journal of Manufacturing Systems 68 (2023) 270–288

Contents lists available at ScienceDirect

Journal of Manufacturing Systems

journal homepage: www.elsevier.com/locate/jmansys

Technical paper

An Ontology-based Engineering system to support aircraft manufacturing

system design
Rebeca Arista a,c , Xiaochen Zheng b ,∗, Jinzhi Lu b , Fernando Mas a,d
a
University of Seville, Seville, 41092, Spain
b
École polytechnique fédérale de Lausanne, Lausanne, 1015, Switzerland
c
Airbus SAS, Blagnac, 31700, France
d
M&M Group, Cádiz, 11500, Spain

ARTICLE INFO ABSTRACT

Keywords: During the conceptual design phase of an aircraft manufacturing system, different industrial scenarios need
Ontology-based Engineering to be evaluated against performance indicators in a collaborative engineering process. Domain experts’
Decision support knowledge and the motivations for decision-making is a crucial asset for enterprises which is challenging
Ontology
to be captured and capitalised. Ontology-based Engineering (OBE) systems emerge as a new generation of
Knowledge graph
Knowledge-based Engineering techniques with advancements of ontology engineering methods and computer
Aircraft manufacturing system
Knowledge management
science technologies. Ontologies enable to capture both explicit and implicit domain knowledge from historical
Cognitive Digital Twin records and domain experts. These Ontology-based Engineering systems can stand highly complex collaborative
design processes involving multidisciplinary stakeholders and various digital tools. This paper proposes a
tradespace framework with Ontology-based Engineering features included on top of existing Model-Based
System Engineering and interoperability capabilities. These additional Ontology-based Engineering features
reuse formalised knowledge via knowledge graph technologies and generative algorithms, changing the
cognitive process from the designer, to an automatic process which generates design alternatives for the
designer. The tradespace framework is demonstrated in a case study to design the aircraft fuselage orbital
joint process, helping the designer to take better strategic decisions at conceptual phase and proving to be an
advantageous paradigm for the design process.

1. Introduction Only part of the design process knowledge is captured explicitly using
different documentation approaches and very little information persists
An aircraft manufacturing system design at concept phase starts by from one design to another. Designers use modelling and simulation
considering the concept product to be manufactured and the manu- tools to define an imaginable number of relevant scenarios and carry
facturing system requirements for market competitiveness. With that,
out decisions based on their assessments and experience.
multiple scenarios are analysed and optimised against performance in-
The combination of Ontology-based Engineering (OBE) techniques
dicators in a collaborative engineering process with the product design,
and interoperable digital design tools can improve the manufacturing
making key engineering decisions regarding the product functional
design, manufacturing technologies to be used, product breakdown, system design by capturing and reusing domain knowledge for design
assembly sequences, logistic plans, industrial resources to reuse, among automation [7]. These systems, including Model-Based System Engi-
others [1,2]. After that, several product and process design stages are neering (MBSE) techniques, provide means for generative design and
carried out as described in the product development plan [3]. trade-off analysis, as well as complex modelling and simulations, thus
Modelling and simulation techniques are commonly used to analyse to propose solutions to the designers and support decisions to get the
the different scenarios to provide decision support [4,5]. However, lack best performance and flexible systems.
of interoperable tools hinders full trade-off analysis, resulting in partial According to different definitions, meanings and fields of appli-
assessments, local optimisations and decisions. It decreases the manu- cability, the term ‘ontology’ could be considered as: a classification,
facturing system performance during its complete lifecycle. On another
categorisation, and type of entities of a domain [8]; an exhaustive list
hand, the design process relies on the designers’ knowledge [6] which
of all that exist in a domain [9]; or a model that defines some aspects of
is difficult to collect or capitalise due to limited methods and tools.

∗ Corresponding author.
E-mail address: [email protected] (X. Zheng).

https://doi.org/10.1016/j.jmsy.2023.02.012
Received 20 September 2022; Received in revised form 3 February 2023; Accepted 20 February 2023
Available online 13 April 2023
0278-6125/© 2023 The Authors. Published by Elsevier Ltd on behalf of The Society of Manufacturing Engineers. This is an open access article under the CC BY
license (http://creativecommons.org/licenses/by/4.0/).
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

integration of the information between well known commercial indus-

Abbreviations trial software (ERP, CRM, PDM) more efficiently than the classical XML
3LM Three-Layer Model approach. As examples, Product Semantic Representation Language
BFO Basic Formal Ontology (PSRL) proposed by Patil et al. [16], an ontology to interoperate
CDT Cognitive Digital Twin between CAD and CAPP systems was proposed by Dartigues et al. [17],
and a novel ontology for Product Development Process (PDP) interop-
CPM Core Product Model
erability and information sharing proposed by Szejka et al. [18] which
DAG Directed Acyclic Graph
could be considered an approach to link ontology-based products with
DES Discrete Event Simulation ontology-based applications.
DOLCE Descriptive Ontology for Linguistic and Finally ontology-based engineering (OBE) systems describe a partic-
Cognitive Engineering ular and well-defined domain from different perspectives: classification,
DPDM Distributed Product Data Management interoperability, behaviour, and semantics. OBE systems cover the
FAL Final Assembly Line scopes of ontology-based product and applications adding the knowl-
GOPPRRE Graph, Object, Point, Property, Role, Rela- edge domain by integrating and transitioning from Knowledge-based
tionship and Extension Engineering (KBE) methodologies, and giving continuity between the
iDMU Industrial Digital Mock Up KBE concepts. Some examples of OBE systems include: an integrated
IOF Industrial Ontologies Foundry knowledge-based assembly planning system called ‘‘IKAPS’’ with suit-
KARMA Kombination of ARchitecture Model specifi- able modelling environments for processing knowledge of various types
cAtion in assembly design and planning [19]; and the work of Zheng et al. [20]
KBE Knowledge-based Engineering which proposes a KBE system for defining robotic manufacturing sys-
tem architectures, using an ontological knowledge model and a multi-
LFT Light Flex Track robot
attribute decision-making model to alleviate the burden on designers
M-SysML Manufacturing Systems Modelling
in this process and evaluate the architecture alternatives to determine
Language
the optimal solution.
MASON MAnufacturing’s Semantics ONtology
Models for Manufacturing (MfM) is a recent OBE methodology [21]
MBSE Model-Based System Engineering to capture manufacturing domain knowledge in ontologies by using
MfM Models for Manufacturing different modelling tools. It is derived from MBSE methodology, us-
MOFLP Mission, Operation, Function, Logic, Physic ing models and their associated behavioural abstraction for enabling
MORFLP Mission, Operation, Requirement, Function, a more robust engineering definition [22]. OBE systems implement
Logic, Physic these collaborative engineering tools in an interoperable environment,
MSO Manufacturing System Ontology supporting the Cognitive Digital Twin (CDT) concept to guarantee at
OAM Open Assembly Model the end of the design phase a validated manufacturing system solution
OBE Ontology-based Engineering for the complete system lifecycle. CDT is an enhanced version of
PDP Product Development Process the current digital twin paradigm augmented with certain cognitive
capabilities and support to execute autonomous activities; comprises
PLM Product Lifecycle Management
a set of semantically interlinked digital models related to different
PRONTO PRoduct ONTOlogy
lifecycle phases of the physical system including its subsystems and
PSRL Product Semantic Representation Language
components; and evolves continuously with the physical system across
RMPFQ Resource, Material, Processes, the entire lifecycle [23].
Functions/Features, Quality This paper proposes a manufacturing system design tradespace
SOM Semantic Object Model framework based on OBE, MBSE and semantic technologies following
STEP Standard for Exchange of Product model MfM methodology guidelines, where an application ontology is de-
data veloped to integrate assembly system domain knowledge, industrial
XLR eXtra Long Range requirements and system architecture model information. The same
ontology is later used and enriched with design rules and constraints,
to generate design alternatives for automatic assembly process design.
The framework is demonstrated in a case study to support the design
a domain [10]. Focusing on the ontologies applied to computer science of the aircraft fuselage orbital joint process, highlighting the benefits of
and engineering, the use of ontologies can fall in three categories this type of design and decision support tools. The research motivations
described next: ontology-based products, ontology-based applications, of this work are:
or ontology-based engineering systems.
Ontology-based products use ontologies applied to technological • to demonstrate the reusability of the explicit knowledge, which
fields and are centred on the definition of the product. Some ex- was captured in the OBE features of the tradespace framework
amples are: STEP (Standard for Exchange of Product model data) following the MfM methodology, to automatically generate new
defined in ISO 10303 standard [11]; the Core Product Model (CPM) design solutions of complex systems such as the aircraft manufac-
developed by NIST in 2004 [12] to describe the function, form and turing system.
behaviour of a product or artefact; OAM (Open Assembly Model) • to move the cognitive and modelling process from the designer
including assembly and tolerances representation [13]; PRoduct ON- only, as proposed by current MBSE methodologies, to an auto-
TOlogy (PRONTO), DPDM (Distributed Product Data Management) mated modelling and decision support process enabling the de-
and OntoPDM created by the academic community to model complex signer to explore a wider design space of not just pre-conceivable
products [14]; and finally the open and principles-based ontologies scenarios.
created by initiatives like Industrial Ontologies Foundry (IOF) from • to propose and demonstrate a tradespace framework with the
which other domain dependent or application ontologies can be derived capacity of enabling trades between different industrial scenar-
in a modular fashion [15]. ios and design solutions, facilitating ontology-based requirement
Ontology-based applications use ontologies to enable semantic in- definition and requirement validation through simulations during
teroperability between product development systems and perform the manufacturing system design phase.

271
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

• to enable the CDT concept by leveraging from the potential of an efficient capitalisation of historical knowledge of the company to
MBSE methods to trade promising design solutions, of semantic support the different domain designers in their complex tasks. Such
web technologies to capture explicit knowledge and enable tools a multi-domain design process needs to be correctly addressed with
integration, and of OBE features to add the cognitive part of the special attention to manufacturing performance drivers, helping design-
design and decision-making process. ers to explore and evaluate not only traditional manufacturing design
options but infinite options from where to select the most promising
The next sections of this paper are organised as follows. Section 2
ones.
describes the related work of aircraft manufacturing systems design and
the use of OBE systems in this design process. Section 3 presents the
2.2. Ontology-based engineering implementation in the manufacturing sys-
architecture of the OBE system proposed as a tradespace framework tem design
to support the aircraft manufacturing system design. Section 4 covers
the case study used to verify the feasibility of the proposed framework Some of the first OBE systems addressing the manufacturing system
and the implementation of the OBE features in it. Section 5 discusses design focused on concurrent integrated design environments inter-
the findings and benefits of the combined capabilities of the tradespace facing knowledge between different CAD and CAM systems. Based on
framework. The paper ends in Section 6 with the conclusions and the generic product assembly model, STEP-based strategies and agent
further work. concepts are used for agent-based concurrent integration of design and
assembly planning. Zha et al. [33] developed a knowledge intensive
2. Related work multi-agent system for cooperative/collaborative assembly modelling
and process planning in a distributed design environment. A unified
2.1. Aircraft manufacturing systems design class of knowledge intensive Petri nets is defined using an object-
oriented knowledge-based Petri net approach and used as an Artificial
The aerospace industry was a pioneer in the 90s designing and in- Intelligence protocol for knowledge objects cooperation formalisms.
dustrialising aircraft using Concurrent Engineering techniques [24,25]. Hunter et al. [34] used MOKA methodology to elicit knowledge
At that time, the industry pursued new working methods with the need using IDEF0 and UML to represent the fixture design process. Fix-
to reduce time-to-market, introducing Product Lifecycle Management ture functional requirements were defined and formalised consider-
(PLM) methods, processes and tools. ing material structure constraints, process constraints and resource
The term Concurrent Engineering, also called ‘‘Simultaneous Engi- constraints. Links of functional requirements with typical commercial
neering’’, was used for the first time in the United States in 1989. It fixture components were defined via tables and rules mapping, and a
is primarily an expression for the ambition to increase the competi- knowledge-based prototype application was developed to validate the
tiveness by decreasing the lead-time and still optimising quality and proposal.
cost. The main methodology is to combine product and manufacturing Considering mainly the integration of different software tools owing
system development. In this way Concurrent Engineering is a label for to the interoperability offered by a common data model, Colledani
a development era of manufacturing technology [26]. Collaborative et al. [35] proposed a virtual factory environment providing to all
Engineering is a systematic approach to control lifecycle cost, produc- the applications a common language to exchange data. This allowed
tion quality and time to market, by concurrently developing products integrating heterogeneous software tools supporting factory design ac-
and their related processes with response to customer expectations. tivities over a common platform. On this platform basis, Terkaj and
Each decision-making ensures input and evaluation of all lifecycle Urgo [36] presented an ontology-based data model supporting the
disciplines, including suppliers [27]. Information Technology is applied design and performance evaluation of production systems. The for-
to support information exchange where necessary [28]. malisation of the performance history of a production system and its
Design practices, concurrent or not, tend to quickly converge on a components are used to enrich the performance evaluation.
solution point from the design space and modify until reaching design To support automated process selection in foundry-style manufac-
objectives [29]. To avoid the problem of selecting the wrong starting turing of military ground vehicles, Melkote [37] developed a digital
point, MBSE methods propose to consider a design space of possible library and modelling environment, containing the key characteristics
solutions and perform multi-disciplinary analysis and optimisations, in and production capabilities of manufacturing processes and associated
order to gradually narrow and converge to the final solution [30,31]. resources. A Manufacturing Systems Modelling Language (M-SysML)
Similar to an aircraft product, the aircraft manufacturing system was developed to model the various manufacturing concepts involved.
has its own design and development process, running in parallel to A complex knowledge graph-based approach is used to represent the
the product one and interconnected during both systems lifecycles. It relevant manufacturing knowledge of six major classes of manufactur-
is divided in three phases: design, resilient production and dismantle. ing processes including material removal, metal forming, polymer and
The design phase has the different maturity gates, creating a unique composite manufacturing, additive manufacturing, joining (welding),
final deliverable with the product design in a Collaborative Engineering assembly (mechanical fastening), and finishing processes. The library
process, following concepts like the Industrial Digital Mock Up (iDMU) is validated using several realistic test cases. In the same case study,
described by Mas et al. [32]. Reconfigurability is analysed in detail Yukish et al. [38] addressed the foundry tradespace configuration and
during the design phase, either to reuse existing resources or to include exploration, to assess the existence of a foundry that can fabricate the
flexibility in the design of new resources. This allows reconfiguring the military ground vehicle, and can choose one option among multiple
industrial resources during the resilient production phase or reuse them ones considering a multi-objective of costs and schedule which conflict
in a next development phase. with each other.
Remaining challenges to fully introduce collaborative engineering Mas et al. [3] and Ríos, et al. [39] described a knowledge-based
concepts in the aerospace industry lies in methods and tools that can application to support conceptual design of aeronautical assembly lines,
support complex studies from early design considering product’s tech- documenting the process using IDEF0 and proposing knowledge mod-
nological complexity, physical dimension and customisation, assembly els using UML, to support a Knowledge-based application prototype
lines reconfigurability during their long lifecycle, and the manufactur- integrated with CAD/CAM commercial software systems. The authors
ing system resilience, among others. Until now only a partial set of test and validate this prototype in several Final Assembly Line design
the manufacturing system characteristics are considered in the different case studies, using time and cost indicators to support decision-making.
collaborative design methods and tools observed in the literature, with Later, using MfM methodology, Mas et al. [40] created an ontology
local trade-off studies and partial optimisations that do not propose for aerospace assembly lines in Airbus, with the introduction of a

272
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

novel way to characterise the adherence concept in the design process Verification Module for design solution evaluation through dis-
of aerospace assembly lines. Based on this work, Arista et al. [41] crete event simulations and 3D simulations; and the visualisation
defined an ontology capturing the industrial system design knowledge Module for presenting simulation results and trade-offs among
at concept phase, and demonstrating its application in a reconfiguration different indicators to the end user for decision-makings.
case study. • The Ontology layer in the middle uses an application ontology
Page Risueno and Nagel [42] describe an OBE framework for mod- to capture domain knowledge from data sources of the Data
elling aircraft production, separating knowledge and its application to layer and relevant experts. Meanwhile certain top-level ontologies
improve reuse and maintenance of knowledge. The prototype consists and middle-level ontologies are adopted as the foundation of the
of a knowledge module to formalise production knowledge in OWL, application ontology to enhance its interoperability making it pos-
an assessment engine connecting the knowledge stored in the ontolo- sible to reuse other existing ontologies such as MBSE ontologies
gies and the design process, and an inference engine to execute the and requirement ontologies. By this approach, the application
logic rules in SWRL and select an appropriate production process. The ontology can be used to integrate knowledge about physical man-
prototype is demonstrated for a stringer production process, and the ufacturing systems, system design requirements and architecture
assembly of a fuselage section. On a similar basis, Meski et al. [43] models etc. An ontology-based knowledge graph database can be
demonstrate knowledge-based decision support in the aeronautical me- constructed to support new system design by instantiating the
chanical machining industry. The authors presented a semantic-driven captured knowledge. For example, during the design phase of a
tradespace framework in [44] where MBSE and interoperability ca- new system, the industrial requirements defined by the Require-
pabilities were used to accelerate the aircraft manufacturing system ment Management module can be fed to the knowledge base
design, proving the feasibility of linking cross-domain information and trigger corresponding querying and reasoning algorithms to
though an application ontology and helping the designer to perform automatically generate alternative design solutions for the new
complex trade-offs among defined design alternatives. system. The generated solutions can then be fed to the Architec-
The different ontology-based implementations described above have ture Definition Module for creating system architecture models,
improved the collaborative engineering process, providing means to de- and to the Verification Module for simulation and evaluation.
sign performant products and flexible industrial systems. Nevertheless,
The implementation of the Ontology layer functional modules is
domain modelling complexity, the level of effort needed to capture
based on an application ontology that is specifically developed accord-
and capitalise knowledge, and remaining technological limitations of
ing to the use case. Application ontologies are highly customised and
ontology based applications, prevent from a wider implementation of
heavily dependent on the corresponding application scenarios. Without
OBE tools and techniques to support aircraft products industrialisation.
a common specification they are difficult to interoperate and reuse. To
Motivated by the potential of OBE systems to support the manu-
improve the interoperability and reusability, it is necessary to follow
facturing system design, and to address the current limitations, this
the hierarchical strategy by reusing certain upper-level ontologies,
work presents an extension of the tradespace framework presented
which can be further divided into top-level and middle-level ontologies.
in [44] with new OBE features that will allow to reuse formalised
A top-level ontology defines a set of general vocabularies that are
knowledge and change the cognitive process from the designer to the
commonly used across all domains. These vocabularies are properly
framework, proposing automatically design alternatives to be traded
structured and formally defined according to certain methodology.
that could fulfil the design requirements. The architecture of this Examples of popular top-level ontologies include the Basic Formal
tradespace framework is described in the next section. Ontology (BFO) [46] and the Descriptive Ontology for Linguistic and
Cognitive Engineering (DOLCE) [47]. At a lower level, a middle-level
3. Ontology-based engineering system architecture ontology focuses on a certain application domain such as the MASON
(MAnufacturing’s Semantics ONtology) [48] and the MSO (Manufac-
Focusing on the aerospace industry, the MfM methodology was turing System Ontology) [49] for manufacturing domain. The IOF [15]
proposed based on the MBSE methodology to support the generation is an ongoing initiative aiming to co-create a set of open domain-
and management of manufacturing ontologies [21]. The core of the level ontologies to support the manufacturing for industrial needs and
MfM methodology is a three-Layer Model (3LM), consisting of a data to promote data interoperability. Depending on its scope, a middle-
layer, an ontology layer and a service layer. It enables OBE systems level ontology can be further narrowed down to certain domain and
for knowledge acquisition, semantic processing and engineering sup- sub-domain ontologies.
port [45]. Based on this three-layer model, a tradespace framework is The development of application ontology in this study follows the
created to accelerate aircraft manufacturing system design. This frame- IOF hierarchical principle as shown in Appendix Fig. A.1 [15], and
work extended the three-layer model by encapsulating the functions adopts the middle-level IOF-Core ontology as the foundation, which
and activities into multiple functional modules. The architecture and further refers to the BFO as the top-level ontology. IOF-Core contains
key functional modules are depicted in Fig. 1. a set of formally defined vocabularies that can be used for creating
The overall architecture and functions of each functional module application ontologies in the manufacturing domain. The adoption of
have been introduced in a previous work [44]. To provide a general IOF-Core enables the developed application ontology to interoperate
understanding of the tradespace framework, the functions of the key with other application ontologies that are also based on IOF-Core.
modules are briefly introduced as follows: The Ontology layer is the core of the proposed tradespace frame-
work. A first version of the framework was developed and presented
• The bottom Data layer holds different types of data sources that in [45,50], addressing the interoperability problem of the tradespace
contain information and knowledge about manufacturing system system and the information transformation between different modelling
requirements, historical system information, domain standards languages, as represented in Fig. 2. At this stage, the designer was
and specifications etc. It provides input to the Ontology layer for in charge of modelling the architecture model options using an MBSE
knowledge capturing and instantiating. methodology, and through the ontology layer the designer was able to
• The top Service layer provides different services to correspond- automatically generate simulation models of each option, execute and
ing stakeholders through a set of functional modules including: compare its results to support the design decisions.
the Requirement Management Module for requirement definition Later work was performed to enable design automation, collecting
and requirement tracing; the Architecture Definition Module for design rules and constraints from the designer’s experience in the
industrial system definition and trade-off scenario definition; the ontology layer. Through them, the tradespace framework now allows

273
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 1. Architecture and key functional modules of the proposed tradespace framework for manufacturing system design.

the designer to set a design problem boundary and by use of gen- cases. It can provide a common knowledge source to improve interop-
erative design algorithms automatically generate all possible design erability and reduce redundancies and human errors. The developed
alternatives, removing the manual MBSE modelling activity where only ontology can also be used as the basis to create a knowledge graph,
selected design options were explored and modelled by the designer. which further enables the generation algorithm to create all possible
The evolution of the tradespace framework into an OBE system, rep- design solutions automatically considering different variations.
resented in Fig. 3, is supported by the previously existing functions of In addition to domain knowledge, the ontology also enables inte-
transformation between different modelling languages, as well as the grating information about system requirements and architecture mod-
automatic generation of simulation models, to execute and compare els. As shown in Fig. 1, the requirement management module, the
their performance. This wider design space exploration improves the architecture definition module and the verification module are all
analysis of promising design solutions while supporting the decision connected to the ontology-based graph database. This enables infor-
making process. mation consistency and automation of the entire design process from
The ontology is developed based on common knowledge extracted requirement definition, design solution generation, architecture mod-
from multiple existing assembly systems and is optimised by domain elling to requirement verification. Compared with the existing MBSE
experts. In practical applications, the knowledge capturing process approaches, which is widely used in systems engineering domain, this
needs deep domain knowledge and is time consuming in many cases, ontology-based method allows a wider design space exploration, as well
however, once the ontology is developed, it can be reused in different as advanced trade-off and decision making capabilities.

274
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 2. Functional diagram of the interoperable MBSE tradespace system.

Fig. 3. Functional diagram of the Ontology-based Engineering and interoperable tradespace framework.

This paper focuses on the latest functionalities of the tradespace 4.1. Application scenario
framework, describing the core capabilities including the application
ontology developed, the ontology-based knowledge database construc- The use case subject of this work is part of the manufacturing
tion, the automatic generation of design solutions and their interactions system design for a new aircraft model of the A320 family called
with different functional modules in the Service layer. The framework ‘‘XLR’’ (eXtra Long Range). More specifically, it focuses on the design
was validated through a representative case study of an assembly of the fuselage orbital joint process, to be performed between the front
process design for a new aircraft. and rear aircraft fuselage sections through a riveting process, at one
of the assembly stations of the aircraft Final Assembly Line (FAL). A
4. Case study representation of this process is shown in Fig. 4.
The fuselage orbital joint process is a critical assembly process in the
To verify the feasibility of the proposed OBE-based design FAL due to the product design tolerances that need to be defined and
tradespace framework and demonstrate the implementation process, respected in this intersection, the accessibility to some areas to perform
a case study is conducted based on the development of an aircraft the joining process operations, and that during this assembly process
fuselage assembly system. This section first introduces the application no other activity can be performed on the aircraft. During the design
scenario of the case study; then presents the development of the of this assembly process, the designers need to trade between possible
application ontology and ontology-based knowledge graph; and finally assembly process sequence scenarios, evaluating key performance indi-
introduce the generative design algorithm and the validation of the cators like process lead time, recurring and non-recurring costs, process
generated solutions. automation level, autonomous quality level, among others.

275
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Table 1
Examples of typical operations of the orbital joint process.
ID Operation name Rate Type Resourcea Time Pre.
02 Set up working environment Orbital Manual 2MO, 1SP 10 min 01
03 Set in position Rails and LFT 1/2 Orbital Auto 2AO, 1LFT, 1SP 10 min 02
04 Camera at stating holes 1/4 Orbital Auto 1AO, 1LFT, 1SP 15 min 03
05 Drilling orbital 4.8 1/4 Orbital Auto 1AO, 1LFT, 1SP 125 min 04
10 Drilling template installation 1/4 Orbital Manual 2MO, 1SP 25 min 02
11 Fixation drilling template suite manual 1/4 Orbital Manual 2MO, 1DT, 1SP 30 min 10
a
The full name of the resource items see Table 2.

technical options results in different design solutions for the orbital

joint process. Moreover, certain constraints have to be considered, for
example, the FLT covers half of the orbit, meaning that once chosen as
an automatic option, the corresponding two quarter-orbital processes
have to be sequentially executed. One example solution is presented in
Fig. 5.
The target of the case study is to create a tradespace system based
on the proposed framework and demonstrate it in the use case of the
orbital joint process. It should be able to support automatic orbital
joint process design and performing trade-offs according to the needs
of different stakeholders.

4.2. Application ontology

4.2.1. Application ontology for interoperability of the trade-off system

For this case study, three application ontologies are developed
including the assembly system domain knowledge ontology capturing
knowledge about existing aircraft assembly systems, requirement ontol-
Fig. 4. Representation of the fuselage orbital joint process. ogy capturing knowledge about requirement specifications, and MBSE
ontology capturing knowledge about architecture models. They are
Table 2 developed separately by experts from the corresponding domains based
Example of resources of orbital joint process. on the IOF-Core middle-level ontology and then integrated into one
Name Abbr. Cost Calendar Qty complete application ontology to link the knowledge about physical as-
Mechanical operator MO 100 e/h 40 h/week 8 sembly systems, virtual models and related industrial requirements. The
Automation operator AO 100 e/h 40 h/week 8 general hierarchical structure of the developed application ontology is
Light Flex Track Robot LFT 75 e/h 24 × 7 2
depicted in Fig. 6, in which the key vocabularies of IOF-Core and BFO
Station platform SP 80 e/h 24 × 7 2
Hand drilling machine HD 10 e/h 24 × 7 6
used by the application ontology are presented. The original IOF-Core
Drilling template DT 10 e/h 24 × 7 5 ontology can be retrieved from the IOF website,1 and the main classes
defined in the application ontology are available on Github2 in Turtle
(.ttl) format.
As shown in Fig. 6, at the domain and application ontology levels,
4.1.1. Product, process and resources catalogue the three parts, i.e. domain knowledge, requirement and MBSE ontolo-
The orbital joint process is composed of a set of operations such gies, are inserted to relevant classes that are defined in IOF-Core and
as positioning, fastening, drilling, riveting, cleaning and inspection. BFO. More details are explained as follows.
Each operation requires a certain number of resources such as a station
platform, drilling machine, drilling template, workers, etc. The entire • The Requirement ontology captures knowledge of different lev-
joining process can be made in a continuous single sequence, or split els of requirements for the manufacturing system, including the
in orbit sections (e.g. upper and lower half-orbital or quarter-orbital) top-level industrial requirements and regulations, functional and
that can be done in parallel depending on the technical constraints and non-functional requirements. The obtained requirements can be
available number of resources to perform them. traced to functions following the RFLP approach (Requirement,
Standard components of products, processes and resources are de- Function, Logical, Physical) [51]. Then they are included into a
fined as catalogues. Specific attention is given to the standard processes MOFLP model (Mission, Operation, Function, Logic, Physic) [52]
defined, including standard parameters values, and the same for stan- by using requirements as links between mission and objectives
dard resources. These components are used as meta-objects to generate as well as functions towards a MORFLP model. Some exemplary
the objects of the different design options. It is worth mentioning that classes that are defined in the developed Requirement ontology
the operation details used in this use case are different from the ones are presented in Appendix Fig. B.1.
used in real production. They have been shortened and anonymised to • The MBSE ontology aims to formalise a certain MBSE approach
respect the data privacy regulations of the case owner. Some examples with ontology entities including classes, individuals and rela-
of the involved products, processes and resources are presented in tionships. In this study. the GOPPRRE ontology [53] is reused
Tables 1 and 2. together with the KARMA (Kombination of ARchitecture Model
Some key operations like drilling and riveting, can be executed specificAtion) modelling language [54]. Meta-models from UPDM
manually by mechanical operators or automatically by a robot called
Light Flex Track Robot (LFT). Each option requires different resources
and time duration, which will impact the final cost and lead time of 1
https://www.industrialontologies.org/top-down-wg/.
2
the entire FAL. The combination of different operation sequences and https://github.com/zhengxiaochen/ontology_aircraft_system.

276
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 5. Example of an orbital joint process sequence.

and SysML specifications for formalising the mission view, opera- and relationships can be extracted from these specifications by
tion scenarios and diagrams for formalising the functional views, decomposing each of the processes and operations as listed in
logic views and physical structure of the assembly processes are Table 1. An example of the decomposition is illustrated in Fig. 7.
developed by using KARMA language. Some exemplary classes The operation ‘‘Drilling orbital 4.8’’ is one of the typical assembly
that are defined in the developed MBSE ontology are presented ‘‘automated’’ operations for the orbital joint process. It occurs
in Appendix Fig. B.2.
‘‘per 1/4 orbit’’; has duration of ‘‘125 min’’; requires resource
• The domain knowledge ontology captures knowledge about ex-
‘‘Light Flex Track Robot’’; and happens after operation ‘‘Camera
isting manufacturing systems from historical documented sources,
at stating holes’’. The operation and resource items are defined
domain experts’ empirical knowledge and other public knowledge
as classes in the ontology, and the other attributes are defined as
sources. Some exemplary classes that are defined in the developed
domain knowledge ontology are presented in Appendix Fig. B.3. properties of the operation as shown in Fig. 7. It is worth mention-
It is the main focus of this paper and its development process is ing that the properties in ontology include object properties and
further explained in the following dedicated section. data properties. The former link two ontology entities (classes or
individuals), and the latter link a data type to an ontology entity.
Aircraft manufacturing systems domain knowledge ontology. The knowl- • Domain experts’ knowledge is collected to refine the ontology
edge sources for the domain knowledge ontology include the following created based on documented sources. As an example, the avail-
three categories: able options to perform a certain operation, the typical structure
• The documented knowledge about historical manufacturing sys- of a process, the classification of the different operations and
tems such as the assembly process specifications, material and resources etc. This type of knowledge is usually common sense for
resource catalogues, labour and resource cost etc. Vocabulary domain experts and critical for knowledge reuse. It is challenging

277
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 6. Hierarchical structure of the application ontology based on IOF-Core and BFO.

to gather such knowledge since there are no efficient tools avail- • The operations are linked to the assembly process as essential
able. In this study, we mainly used surveys and interviews with operations if they have no alternatives, such as ‘‘Set up working
multiple iterations. environment’’; or as optional operations if they have alternatives,
• Public knowledge is the knowledge collected from public sources such as ‘‘Riveting buttstraps and stabiliser’’ which can be au-
of relevant domains. For example, the RMPFQ (Resource, Mate- tomated or manual. These relationships can be expressed with
rial, Processes, Functions/Features, Quality) [50,55,56] model is triples. For example:
used in this study to support the definition of the relationships
– ‘‘OrbitalJoiningProcess’’ - ‘‘hasSubProcess’’ - ‘‘LowerOrbital
between different classes of the ontology. RMPFQ is a quality- Joining’’;
oriented semantic model that aims to identify the main influential
– ‘‘OrbitalJoiningProcess’’ - ‘‘hasEssentialOperation’’ - ‘‘Set up
factors related to product quality during manufacturing processes. working environment’’;
More details about this model are introduced in [56]. In this
– ‘‘LowerOrbitalJoining’’ - ‘‘hasOptionalManualOperation’’ -
case study, we mainly focus on the Resource, Material, Process ‘‘Riveting buttstraps and stabiliser manual’’;
and Quality aspects. During a typical assembly process, multiple – ‘‘Set up working environment’’ - ‘‘requiresResource’’ - ‘‘Sta-
Materials are assembled to realise certain Quality requirements tion platform’’.
through a planned Process consisting of a series of operations,
which requires relevant manufacturing Resources. These rules and constraints are specifically extracted for this case
study. They are reusable in the scope of this case study for different
orbital joint process designs of new aircraft programs, but they are
4.2.2. Design process rules and constraints not expected to be reused for other cases with different manufacturing
Some essential knowledge about the targeted assembly process processes and different application scenarios. For example, this case
has been stored in the ontology which can be reused to create new study is validated with the application scenario of the Airbus A320-
solutions. In addition to the information about the operations, such XLR model, and the rules are reusable for the fuselage orbital joint
as operation duration, required resources etc., the following rules and process design of new derivative aircraft models (like the Airbus A350
constraints are also included in the application ontology: freighter model) or for new aircraft families which require a fuselage
orbital joint. They are added to complement the domain knowledge
• The target assembly process joins two fuselages, named Front captured in the application ontology and enable the development of
fuselage and Rear fuselage. automatic process generation algorithms which is explained in the next
• The assembly process can be divided into upper and lower half- sections. It is worth clarifying that most of the rules and constraints
orbital subprocesses, each of which can be further divided into are already captured in the application ontology during the ontology
two quarter-orbital subprocesses, as shown in Fig. 8. development process, for example the sequence of certain operations
• Each resource at the target station has fixed available quantity and the required resource of each operation. These captured rules and
and cost per use. constraints are the main foundation for the generative algorithm.

278
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 7. Example of extracting ontology classes and properties from existing aircraft assembly processes.

Fig. 8. Hierarchical structure of an orbital joint process.

4.3. Ontology-based knowledge graph database reasoning scenarios. To facilitate the knowledge reuse in this study,
the developed application ontology is imported to a graph database
The application ontology was developed using ontology editors named Neo4j which supports more flexible and powerful reasoning
Protégé and WebProtégé. Such ontology editors support basic reasoning tasks. For example, it is impossible to add properties to relationships
functions enabled by different reasoners based on predefined inference between entities (e.g. number of resources required by an operation)
rules. However, they are not sufficient for complex and large scale in ontology, whereas in Neo4j, the relationships are also stored as

279
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

nodes which allows to have customised properties. Moreover, Neo4j • sequencing between subprocesses, which can be sequential or
provides a graph query language named Cypher3 to enable retrieving parallel. It occurs at half-orbital level between the upper and
and editing graph data stored in Neo4j database. It also offers drivers lower orbit joint processes, and at quarter-orbital level only under
for most programming languages making it possible to integrate Cypher manual operation type since the automated operations must be
queries into these languages thus to conduct more complex querying sequential.
and reasoning tasks.
The combination of these two variables produces three alternatives
To facilitate the manipulation of ontologies, a plugin named Neose-
for each of the two half-orbital joint processes: automated-sequential,
mantics4 is provided by the Neo4j community which enables the use of manual-sequential and manual-parallel. They can then be connected
RDF in the Neo4j graph database. It allows importing and exporting sequentially or in parallel to form a complete orbital joint process.
ontologies in various formats including OWL, RDF, XML and Turtle Based on the aforementioned rules and variants, a customised
etc. Once imported to Neo4j, different querying and reasoning can be Python script integrating a set of Neo4j-Cypher queries is developed
executed based on tailored query conditions and reasoning rules. to automatically generate all possible solutions based on the Neo4j
In this study, several stakeholders from different organisations are graph database. The pseudocode of the algorithm is shown in Appendix
involved including the requirement engineers, system architects, simu- Algorithm 1.
lation engineers and ontology experts. To enable remote access to the The reasoning of the generative algorithm is executed based on the
graph database, a cloud server deployed on Microsoft Azure cloud is knowledge graph stored in the Neo4j database instead of the ontology.
used to hold the Neo4j database. Technical details about cloud server More specifically, the ontology was developed in OWL format and
setup, graph database configuration and the source Cypher code for imported to Neo4j as RDF format. The generation algorithm is based
importing and editing the application ontology etc. are provided on on the Cypher language provided by Neo4j which is embedded in the
GitHub2 . aforementioned Python program. Comparing to conventional ontology-
based reasoning mechanisms, such as description logic-based or SWRL-
4.4. Generative design algorithm based, the algorithm can be considered as a hybrid mechanism, i.e. the
execution logic of the algorithm is similar to the description logic-based
reasoning, and the generation of each new detailed entities (nodes and
In this case study, the main target for knowledge reuse is to auto-
edges) is based on Cypher querying which is similar to SWRL-based
matically generate possible solutions for the future aircraft assembly
reasoning. The key steps of the algorithm are explained in the next
system based on predefined industrial requirements. A set of design subsections.
rules are defined considering the system design process of designers.
4.4.1. Generate essential operations
• New solutions are created hierarchically, meaning that process-
The generation of the orbital joint processes starts with creating
level operations, such as the orbital level operations will be
a new individual of the ‘‘S40_Orbital Joint Process’’ class defined in
queried first, such as ‘‘Jig in’’ and ‘‘Set up working environment’’;
the ontology. In order to differentiate different alternatives, a prefix
then the half-orbital level operations, such as ‘‘Set in position
containing an incremental integer is added to the name of the generated
Rails and LFT’’; and finally the quarter-orbital operations, such
individual, for example ‘‘N01_S40_Orbital Joint Process’’. It can be
as ‘‘Camera at stating holes’’ as listed in Fig. 5.
performed with the following Cypher code:
• Individuals of essential operations of each level are created for
every solution; in contrast, when an optional operation is de- MATCH (p:Class{label: ’S40_Orbital Joint Process’})
tected, an alternative solution will be created corresponding to CREATE (o:Individual{label:N01_’+p.label})-[:isIndividualOf]->(p)
the available option. In this case, the half-orbital assembly process
has two options for the first operation i.e. ‘‘Set in position Rails
and LFT’’ and ‘‘Drilling template installation’’ as listed in Fig. 5. After creating the new process individual, a query is conducted in
• For sequencing of the operations, the minimum unit is the the Neo4j database to fetch the essential operation classes related to
quarter-orbital process because the sequence of the operations the ‘‘S40_ Orbital Joint Process’’ class and then create an individual for
in a quarter is fixed, such as the manual operations ‘‘Drilling each of these essential operation classes.
template installation’’ to ‘‘Deburring, positioning, attach’’ as listed MATCH (p)-[:hasEssentialOperation]->(e:Class)
in Fig. 5. CREATE (f:Individual{label:’N01_’+e.label})-[:isIndividualOf]
->(e), (o)-[:hasEssentialOperation]->(f)
• For the automated half-orbital process, which starts with optional
operation ‘‘Set in position Rails & LFT’’, as shown in Fig. 5, the
corresponding two quarter-orbital processes can only be executed
sequentially, because the LFT robot covers half of the orbital. In The sequence of the operation individuals can also be inherited from
contrast, manual options can be either sequential or concurrent. the ontology:

MATCH (e)-[:hasPredecessor]->(e1)<-[:isIndividualOf]-(f1)
There are two variables to be considered for generating new orbital CREATE (f)-[:hasPredecessor]->(f1)
joint process solutions:

• operation type, meaning the operations are conducted automati- The individuals of the essential operations for the half-orbital pro-
cally with the FLT robot or manually by manually operators. This cess and their sequence can be created following the similar query
variable is determined at the half-orbital process level considering steps. It is worth noting that two individuals need to be created for
the last rule defined above, i.e. the LFT robot covers half of the each essential operation class in the ontology corresponding to upper
orbital. It means that a half-orbital process cannot be composed and lower half-orbital processes. Suffixes, such as ‘‘_1’’ and ‘‘_2’’, can
of two different types of quarter-level processes. be added to the names to differentiate them from each other. This step
is realised by the ‘‘CreateEssetialOperations’’ function as shown in the
pseudocode. An example of a generated solution is shown in Fig. 9, in
3
https://neo4j.com/developer/cypher/. which the grey nodes (‘‘Exx’’) and their relationships (solid arrow) are
4
https://github.com/neo4j-labs/neosemantics. created during this step.

280
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 9. An example of automatically generated orbital joint process.

4.4.2. Generate half-orbital processes and operations connected to ‘‘E02’’ to create a sequential manual half-orbital process.
The optional operations for half-orbital processes can be retrieved It is worth clarifying that the dotted and solid arrows used in Fig. 9 aim
from the ontology using the properties ‘‘hasOptionalManualOperation’’ to indicate that they are generated at different steps in the algorithm.
and ‘‘hasOptionalAutoOperation’’. Similar to essential operations, cor- They represent the same meaning in the generated processes. In some
responding individuals are created for each of the retrieved classes. The special cases, some isolated operations can be generated, such as ‘‘E20’’,
difference is that when an optional operation is defined at the quarter- which has no neighbouring operations. Their location in the generated
orbital level, two corresponding individuals need to be created to form process needs to be specially marked.
a half-orbital process. Suffixes can be added to the names to differenti-
ate them from each other. The created quarter-orbital level operations 4.4.4. Generate resources and other properties
are first connected according to the ‘‘hasPredecessor’’ property in the After all the operations of a complete process are generated, the
ontology. Then they are connected sequentially or parallelly during required resources for each operation can be retrieved from the corre-
different iterations which will be further explained in the following sponding class in the ontology querying with the ‘‘requiresResource’’
section. property. For each process, one individual of each resource class is cre-
This step is realised by the ‘‘CreateAutoSubProcess’’, ‘‘CreateManSeq- ated and linked to relevant operations through the ‘‘requiresResource’’
SubProcess’’ and ‘‘CreateManParSubProcess’’ functions as shown in the relationship. An example of the generated process is shown in Fig. 10,
pseudocode. The corresponding Cypher codes are available in the in which the grey nodes represent the generated operations, the green
source file of the Python script (Github). As the example shown in nodes represent resources, the blue node represents the process name,
Fig. 9, the white nodes (‘‘Axx’’ and ‘‘Mxx’’) and their relationships (solid the pink nodes represent the relevant classes defined in the application
arrow) are created during this step. ontology, and the lines represent different types of relationships. The
other properties such as the duration of each operation, quantity and
4.4.3. Connect quarter-orbital and half-orbital processes cost of required resources etc., are also added in this step through the
During the previous steps, corresponding individuals of essential ‘‘AddResourceTime’’ function in the algorithm.
and optional operation classes are created by retrieving knowledge
stored in the ontology. They are partially connected (i.e. solid arrows 4.4.5. Generate process alternatives based on different combinations of
in Fig. 9) based on the ‘‘hasPredecessor’’, producing multiple operation operation types and sequences
segments. To form a complete orbital joint process, these operation The last step of the algorithm is to iterate among different combina-
segments need to be connected. It requires identifying the beginning tions of operation types and sequences at the half-orbital level. Three
and ending operation of each operation segment. This can be realised options are available for each half-orbital (upper and lower) process,
by pattern matching with the ‘‘hasPredecessor’’ property. If an op- and they can be connected sequentially or parallelly. In this study the
eration only has input ‘‘hasPredecessor’’ relationship without output upper and lower orbitals are treated as different processes. Therefore,
relationship, it can be identified as beginning operation, such as ‘‘E01’’, totally 18 alternative solutions are automatically generated. This is
‘‘E18_1(2)’’, ‘‘A03’’ and ‘‘M10_1(2)’’ in Fig. 9. In contrast, if an operation realised through three nested loops in the main thread of the algorithm.
only has output ‘‘hasPredecessor’’ relationship, it is an ending operation
such as ‘‘E02’’, ‘‘E19_1(2)’’, ‘‘A09’’ and ‘‘M17_1(2)’’ in Fig. 9. 4.5. Validation of the ontology-based engineering system
Once the beginning and ending operations are identified, they can
be connected with each other using the ‘‘hasPredecessor’’ relationship The aforementioned application ontology, the knowledge graph
(dotted arrows in Fig. 9). Different connections can be added producing database and the generative design algorithm enables the main func-
different processes alternatives. For example, in Fig. 9, the quarter- tions of OBE system. In industrial applications, the aircraft manufactur-
orbital level ‘‘M10_1’’ and ‘‘M10_2’’ operations are connected to the ing system design starts from the definition of system boundary by the
‘‘E02’’ operation producing a parallel manual half-orbital process. Al- system architect. The performance requirements for the manufacturing
ternatively, ‘‘M10_2’’ can be connected to ‘‘M17_1’’ and only ‘‘M10_1’’ system are first defined. For example, in the case study the defined

281
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. 10. An example of the generated process in Neo4j graph database. (For interpretation of the references to colour in this figure legend, the reader is referred to the web
version of this article.)

industrial requirements include minimum throughput of 150 aircrafts architecture modelling tool used in this study is a commercial off-the-
per year, automation level higher than 60% from the total number of shelf software named MetaGraph.5 The architecture models created
operations, and total process lead time below 350 h. The requirement using KARMA language based on the GOPPRRE ontology. KARMA
management system is used by the designer in the Service layer to language enables the creation of metamodels including SysML diagrams
define these requirements. Based on the requirement ontology, the for formalising the functional views, logic views and physical structure
corresponding requirement individuals are generated and added to the of assembling processes. The automatically generated 18 assembly
Neo4j graph database in OWL format. system solutions are exported from Neo4j as OWL models and then
Next, the generative design algorithm previously is triggered, gener- transformed to architecture models using a plugin of the MetaGraph
ating all possible solutions for the future assembly system. The standard software. Then the designer can filter, manipulate and reconfigure
product, process and resources catalogue is used to create the instances the imported architecture models in different formats such as SysML
of all possible process sequence alternatives that fulfil the requirements activity diagrams and BPMN diagrams. The selected models are then
defined, providing as well the standard values to the properties of send back to the graph database following the reversed workflow using
the process and resources elements. In this case study, 18 solutions the same tools.
of the assembly process are generated. Each solution includes a set Later on, the designer trigger the simulation models generation, to
of individuals (e.g. operations and resources) and the relationships simulate the process sequence option and compare their performance
between them. Each pair of them can be represented by a vertex and values. A customised parser is developed to fetch the process sequence
an edge respectively in the graph database. Thus, the topology of an options and requirement individuals from the Neo4j graph database
assembly process can be represented by a Directed Acyclic Graph (DAG) hosted on the cloud server. The returned graph entities are parsed and
which leads to a generalised representation that also fits other scenarios information about the assembly process are extracted corresponding
in the same context. to different solutions. The extracted information is transformed into
certain intermediate formats, such as DataFrame and JSON, to cache
The different process sequence options can be exported and visu-
the extracted data. The topology of each solution is represented by an
alised as architecture models in the MBSE modelling tool in the Service
adjacency matrix, which enables the creation of a tool-agnostic model
Layer. The transformation between knowledge graphs and architecture
to be consumed by different simulation models. This final step follows
models is a separate research topic in the MBSE domain which is out
of the scope of this study. The approaches used in this study have
been explored in some previous research articles [53,54,57]. However,
5
some key information is briefly introduced as follows. The system http://www.zkhoneycomb.com/productinfo/101503.html.

282
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. A.1. The IOF hierarchical ontology development principle.

the co-modelling approach [58] which allows different simulations to captured with application ontologies which can be integrated under the
utilise the same model. same upper-level ontologies such as the IOF-Core and BFO used in this
Two types of simulation, including Discrete Event Simulation (DES) study.
and 3D simulation, are performed in this study. The DES models Moreover, this work reveals a step-change for MBSE methodolo-
mainly focus on the duration of each operation and the architecture gies, automating the manufacturing system design modelling through
information (e.g. operation predecessor and successor etc.). In DAG, ontology-based knowledge capture and reuse. By this mean, a wider
each operation has an in-degree and out-degree, which corresponds to design space exploration can be explored and not only imaginable
its predecessors and successors. The DES engine recognises the topology options by the designer, improving the analysis of promising design
and simulates the lead-time. The 3D simulation simulates the real work- solutions and supporting the trade-off and decision making process.
ing environment, operation details and interactions between operators
and parts. It configures the required data like operation duration, 3D In addition, this study leverages on the potential of MBSE and se-
model paths and coordination information. Subsequently, the routes, mantic web technologies to semantically integrate various systems and
actions of operators and interaction between operators and parts as well sub-system from concept design throughout different lifecycle phases,
as resources are simulated. In addition, by enriching the data of virtual by bringing the cognitive side of ontology-based engineering systems,
objects, such as the weight of jigs and tools, ergonomic factors can be essential to realise the CDT concept [23] in the future. CDT is an
calculated regarding the operator’s body posture and working time. ambitious target of intelligent systems which requires information in-
Finally, the results of the simulations are visualised through a graph- tegration not only during the design phase of the system lifecyle, but
ical user interface, showing the value of the performance indicators of also extend to the following manufacturing, operation and maintenance
each process sequence option. The designer is able to compare the op- phases. It also consider the integration across different system levels
tions between them, and verify if an option fulfilled or not the defined and hierarchical levels within an enterprise. Some existing work [60–
requirement in the problem boundary defined. More details about the 62] in relevant fields provides potential methods for realising this
simulation process have been introduced in previous studies [45,59] target.
based on a similar case. Finally, this work demonstrates the proposed framework’s capability
of enabling trade-off between different industrial scenarios and design
5. Discussion solutions, facilitating ontology-based requirement definition and re-
quirement validation through simulations during manufacturing system
The proposed OBE functionalities of the tradespace framework were design phase, thus to support decision-making.
implemented to support the design automation of an aircraft orbital This case study served as proof-of-concept, therefore different con-
joint process using pre-existing knowledge of the design process, the siderations need to be taken for the implementation of such OBE
selected toolchain and following MfM-3LM architecture. These func- tradespace framework:
tionalities were supported by existing interoperability functionalities
of transformation between different modelling languages and auto- • The application scenario was based on a simplified assembly
matic generation of simulation models to execute and compare results. system design which covers only one process in one station of the
To summarise, this study demonstrates the reuse of knowledge cap- aircraft final assembly line. The problem space considered only
tured in the Ontology layer of the 3LM architecture, to automatically operation types (automated and manual) and resource availability
generate new solutions of complex systems like the aircraft assem- constraints (shared resources among operations), leading to a
bly system, by means of querying and reasoning enabled by graph design space with a controllable number of alternatives. The
databases and relevant algorithms. Information and knowledge is first real application factors of a complex design problem lead to an

283
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. B.1. Classes defined in the Requirement application ontology.

Fig. B.2. Classes defined in the MBSE application ontology.

exponential number of alternative solutions. In this case, it is made attempting to address this challenge such as the ongoing
necessary to adopt more advanced graph computing algorithms. projects OntoCommons6 and OntoTrans.7
• The interaction between different functional modules need to • In this study, the development of the ontology and the generation
be unified and integrated into one common platform for in- of new entities through reasoning are independent. The new
dustrial applications, avoiding the use of intermediate files and entities are stored in the knowledge graph and will not impact the
middleware provided by different technical providers. ontology. However, the maintenance and update of the ontology
• The redundancy and mismatching of existing ontologies is a chal-
lenge for ontology-based applications. In this study, we adopted
the upper-level ontologies like BFO and IOF-Core to partially
6
mitigate this challenge. Some research efforts have also been https://ontocommons.eu/.
7
https://ontotrans.eu/.

284
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Fig. B.3. Classes defined in the Domain Knowledge application ontology.

using the new generated knowledge is a limitation to be addressed knowledge domain from different perspectives. More efforts are needed
in future research. to define methodologies and tools which can enable knowledge cap-
turing considering different expert/user-oriented formalisation stages.
6. Conclusion Methodologies like MfM can improve capturing knowledge from de-
signers and domain experts, while machine learning techniques such
This paper proposes an OBE system to support the aircraft manu- as Natural Language Processing technology and graph computing might
facturing system design. The OBE features included on top of existing provide possible solutions for explicit knowledge.
MBSE and interoperability capabilities of the tradespace framework, The real application factors of a complex design problem as the
have proven to be an advantageous paradigm for the design process manufacturing system will lead to an exponential number of alternative
supporting decision-making. This enables to change the cognitive pro- solutions to be analysed, reaching unsolvable limits of the design
cess performed by the designer when modelling the process sequence space. Heuristic methods and genetic algorithms, as well as integrated
options to the OBE features (application ontology and generative de- simulation–optimisation loops are already providing solutions up to a
sign algorithm). The designer is now in charge to define a problem certain level. In the authors’ opinion, the cognitive process captured
boundary set in the form of performance requirements to be fulfilled by OBE systems and its reasoning capabilities can provide possible
by the assembly process, and trigger the automatic generation of design solutions to control and manage the complexity of the generative design
alternatives reusing formalised knowledge in the OBE features. The al- and decision-making processes.
ternatives can be further verified in the tradespace framework through Finally, the aircraft manufacturing system design is a highly com-
automatically generated DES and 3D simulations and validated by plex process involving multiple domains and hierarchical system levels
comparing the simulation results against the performance requirements at different lifecycle phases. The strategic design decisions taken at
defined. To summarise, the main contributions of this work include: conceptual phase should be broadened to every stage of the lifecycle
in order to reach the full capabilities of a Cognitive Digital Twin.
• combining and enriching the knowledge base used for semantic
integration of the MBSE tradespace framework with additional Declaration of competing interest
knowledge to generate design alternatives for an automatic design
process; The authors declare the following financial interests/personal rela-
• moving the cognitive process from the designer to the design tionships which may be considered as potential competing interests:
toolchain using an ontology-based system; Rebeca Arista reports financial support was provided by European
• providing the designer the possibility to analyse a larger design Union. Xiaochen Zheng reports financial support was provided by
space and support the decision-making process; European Union. Jinzhi Lu reports financial support was provided by
• enabling information consistency of the entire design process European Union.
from requirement definition, design solution generation, architec-
ture modelling to requirement verification based on an ontology- Data availability
based system;
• exploring a possible solution to enhance the cognitive capability The authors confirm that the data supporting the findings of this
of industrial systems by combining ontology-based systems and study are available within the article. Additional data such as source
MBSE methods. code and software instructions are available on GitHub.8

The ontologies developed as part of this proof-of-concept still need

8
to fulfil the OBE objective to describe a particular and well-defined https://github.com/zhengxiaochen/ontology_aircraft_system

285
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

Acknowledgements Algorithm 2 The assembly process generation algorithm — Part 2

31: #function to generate manual-parallel half-orbital assembly process
The work presented in this paper has been partially supported by 32: Define 𝐶𝑟𝑒𝑎𝑡𝑒𝑀𝑎𝑛𝑃 𝑎𝑟𝑆𝑢𝑏𝑃 𝑟𝑜𝑐𝑒𝑠𝑠(𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛, 𝑁𝑎𝑚𝑒_𝑝𝑟𝑒𝑓 𝑖𝑥):
the EU H2020 project QU4LITY (825030) - Digital Reality in Zero 33: 𝑠𝑡𝑟𝑖𝑛𝑔5 = ‘‘Cypher string for creating 2 quarter manual
Defect Manufacturing, and EU H2020 project FACTLOG (869951) - operations’’
Energy-aware Factory Analytics for Process Industries. 34: #names of the first and last operations of the 2 created operations
The authors would like to recognise Fraunhofer IAO, Visual Com- 35: 𝑛𝑎𝑚𝑒5 = 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑠𝑡𝑟𝑖𝑛𝑔5)
ponents, Seville University, EPFL and Airbus colleagues for their sup- 36: return 𝑛𝑎𝑚𝑒5
port during the development of this work, and thank them for their 37:
contribution. 38: #function to add required resources and duration to created
operations
39: Define 𝐴𝑑𝑑𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑇 𝑖𝑚𝑒(𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛, 𝑁𝑎𝑚𝑒_𝑝𝑟𝑒𝑓 𝑖𝑥):
Appendix A. Hierarchical ontology network defined by IOF
40: 𝑠𝑡𝑟𝑖𝑛𝑔6 = ‘‘Cypher for adding resource/duration to created
operations’’
See Fig. A.1. 41: 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑠𝑡𝑟𝑖𝑛𝑔6)
42:
43: #the main thread
Appendix B. Examples of the classes defined in the application
44: if name == ’’__main__’’:
ontology
45: #create connection to Neo4j database
46: 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛 = 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑢𝑟𝑖, 𝑢𝑠𝑒𝑟𝑛𝑎𝑚𝑒, 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑)
See Figs. B.1–B.3. 47: #increasing integer to differentiate created solutions
48: 𝑁𝑎𝑚𝑒𝑝𝑟𝑒𝑓 𝑖𝑥 = 1
49: #available alternatives for half-orbital level processes
Appendix C. Pseudocode of the assembly process generation algo- 50: 𝑂𝑝𝑡𝑖𝑜𝑛𝑠𝑉 𝑒𝑐𝑡𝑜𝑟 = [‘‘automated-sequential’’, ‘‘manual-sequential’’,
rithm ‘‘manual-parallel’’]
51: 𝑈 𝑝𝑝𝑒𝑟𝑃 𝑟𝑜𝑐𝑒𝑠𝑠 in 𝑂𝑝𝑡𝑖𝑜𝑛𝑠𝑉 𝑒𝑐𝑡𝑜𝑟: 𝐿𝑜𝑤𝑒𝑟𝑃 𝑟𝑜𝑐𝑒𝑠𝑠 in 𝑂𝑝𝑡𝑖𝑜𝑛𝑠𝑉 𝑒𝑐𝑡𝑜𝑟:
𝑆𝑒𝑞𝑢𝑒𝑛𝑐𝑒 in [’’sequential’’, ’’parallel’’]:
Algorithm 1 The assembly process generation algorithm — Part 1 52: #generate essential operations
53: call 𝐶𝑟𝑒𝑎𝑡𝑒𝐸𝑠𝑠𝑒𝑡𝑖𝑎𝑙𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝑠()
1: Import library 𝐺𝑟𝑎𝑝ℎ𝐷𝑎𝑡𝑎𝑏𝑎𝑠𝑒 from Neo4j Python API
54: #generate two half-orbital processes
2: #define a connection class to connect to the graph database
55: call 𝐶𝑟𝑒𝑎𝑡𝑒𝐴𝑢𝑡𝑜𝑆𝑢𝑏𝑃 𝑟𝑜𝑐𝑒𝑠𝑠() or 𝐶𝑟𝑒𝑎𝑡𝑒𝑀𝑎𝑛𝑆𝑒𝑞𝑆𝑢𝑏𝑃 𝑟𝑜𝑐𝑒𝑠𝑠() or
3: Class 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛:
𝐶𝑟𝑒𝑎𝑡𝑒𝑀𝑎𝑛𝑃 𝑎𝑟𝑆𝑢𝑏𝑃 𝑟𝑜𝑐𝑒𝑠𝑠() accordingly
4: Define 𝑖𝑛𝑖𝑡(𝑠𝑒𝑙𝑓 , 𝑢𝑟𝑖, 𝑢𝑠𝑒𝑟𝑛𝑎𝑚𝑒, 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) 56: connect half-orbital processes with essential operations
5: Define 𝑞𝑢𝑒𝑟𝑦(𝑠𝑒𝑙𝑓 , 𝑞𝑢𝑒𝑟𝑦_𝑠𝑡𝑟𝑖𝑛𝑔) 57: #add relevant resources and duration to created operations
6: return 𝑞𝑢𝑒𝑟𝑦_𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒 58: call 𝐴𝑑𝑑𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑇 𝑖𝑚𝑒()
7:
8: #function to generate orbital and half-orbital essential operations
9: Define 𝐶𝑟𝑒𝑎𝑡𝑒𝐸𝑠𝑠𝑒𝑡𝑖𝑎𝑙𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝑠(𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛, 𝑁𝑎𝑚𝑒_𝑝𝑟𝑒𝑓 𝑖𝑥):
10: 𝑠𝑡𝑟𝑖𝑛𝑔1 = ‘‘Cypher string for creating orbital essential operations’’ References
11: 𝑠𝑡𝑟𝑖𝑛𝑔2 = ‘‘Cypher string for creating half-orbital essential
[1] Roy R, Williams G. Capturing the assembly process planning rationale within an
operations’’
aerospace industry. In: Proceedings of the 1999 IEEE international symposium
12: #names of orbital level essential operations on assembly and task planning (ISATP’99)(Cat. No. 99TH8470). IEEE; 1999, p.
13: 𝑛𝑎𝑚𝑒1 = 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑠𝑡𝑟𝑖𝑛𝑔1) 319–24. http://dx.doi.org/10.1109/ISATP.1999.782978.
14: #names of half-orbital level essential operations [2] Maganha I, Silva C, Klement N, dit Eynaud AB, Durville L, Moniz S. Hy-
15: 𝑛𝑎𝑚𝑒2 = 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑠𝑡𝑟𝑖𝑛𝑔2) brid optimisation approach for sequencing and assignment decision-making in
reconfigurable assembly lines. IFAC-PapersOnLine 2019;52(13):1367–72. http:
16: return 𝑛𝑎𝑚𝑒1, 𝑛𝑎𝑚𝑒2
//dx.doi.org/10.1016/j.ifacol.2019.11.389.
17: [3] Mas F, Rios J, Menendez JL, Gomez A. A process-oriented approach to modeling
18: #function to generate automated-sequential half-orbital process the conceptual design of aircraft assembly lines. Int J Adv Manuf Technol
19: Define 𝐶𝑟𝑒𝑎𝑡𝑒𝐴𝑢𝑡𝑜𝑆𝑢𝑏𝑃 𝑟𝑜𝑐𝑒𝑠𝑠(𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛, 𝑁𝑎𝑚𝑒_𝑝𝑟𝑒𝑓 𝑖𝑥): 2013;67(1–4):771–84. http://dx.doi.org/10.1007/s00170-012-4521-5.
[4] Askin RG, Askin RG, Standridge CR, Standridge CR. Modeling and analysis of
20: 𝑠𝑡𝑟𝑖𝑛𝑔3 = ‘‘Cypher string for creating 2 quarter-level automated
manufacturing systems. John Wiley & Sons Incorporated; 1993.
operations and connect them sequentially’’ [5] Mourtzis D. Simulation in the design and operation of manufacturing systems:
21: #names of the first and last operations state of the art and new trends. Int J Prod Res 2020;58(7):1927–49. http:
22: 𝑛𝑎𝑚𝑒3= 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑠𝑡𝑟𝑖𝑛𝑔3) //dx.doi.org/10.1080/00207543.2019.1636321.
23: return 𝑛𝑎𝑚𝑒3 [6] Davies M. Knowledge–Explicit, implicit and tacit: Philosophical aspects. In:
International encyclopedia of the social & behavioral sciences, Vol. 13. 2015,
24:
p. 74–90.
25: #function to generate manual-sequential half-orbital assembly [7] Mas F, Ríos J, Gómez A, Hernández JC. Knowledge-based application to define
process aircraft final assembly lines at the industrialisation conceptual design phase. Int J
26: Define 𝐶𝑟𝑒𝑎𝑡𝑒𝑀𝑎𝑛𝑆𝑒𝑞𝑆𝑢𝑏𝑃 𝑟𝑜𝑐𝑒𝑠𝑠(𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛, 𝑁𝑎𝑚𝑒_𝑝𝑟𝑒𝑓 𝑖𝑥): Comput Integr Manuf 2016;29(6):677–91. http://dx.doi.org/10.1080/0951192X.
2015.1068453.
27: 𝑠𝑡𝑟𝑖𝑛𝑔4 = ‘‘Cypher string for creating 2 quarter-level manual
[8] Smith B. Ontology. In: The furniture of the world. Brill; 2012, p. 47–68. http:
operations and connect them sequentially’’ //dx.doi.org/10.1163/9789401207799_005.
28: #names of the first and last operations [9] Horrocks I. Ontologies and the semantic web. Commun ACM 2008;51(12):58–67,
29: 𝑛𝑎𝑚𝑒4 = 𝑁𝑒𝑜4𝑗𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛(𝑠𝑡𝑟𝑖𝑛𝑔4) URL https://dl.acm.org/doi/fullHtml/10.1145/1409360.1409377.
30: return 𝑛𝑎𝑚𝑒4 [10] McCarthy J. Circumscription—a form of non-monotonic reasoning. Artificial In-
telligence 1980;13(1–2):27–39. http://dx.doi.org/10.1016/0004-3702(80)90011-
9.

286
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

[11] Pratt MJ, et al. Introduction to ISO 10303—the STEP standard for product data [36] Terkaj W, Urgo M. Ontology-based modeling of production systems for design
exchange. J Comput Inf Sci Eng 2001;1(1):102–3. http://dx.doi.org/10.1115/1. and performance evaluation. In: 2014 12th IEEE international conference on
1354995. industrial informatics. INDIN, IEEE; 2014, p. 748–53. http://dx.doi.org/10.1109/
[12] Fenves SJ, Foufou S, Bock C, Sriram RD. CPM2: a core model for product data. INDIN.2014.6945606.
J Comput Inf Sci Eng 2008;8(1). http://dx.doi.org/10.1115/1.2830842. [37] Melkote S. Development of iFAB Manufacturing Process and Machine Library.
[13] Baysal MM, Roy U, Sudarsan R, Sriram RD, Lyons KW. The open assembly model Tech. Rep, Georgia Institute of Technology; 2012, URL https://apps.dtic.mil/sti/
for the exchange of assembly and tolerance information: overview and example. citations/ADA565243.
In: International design engineering technical conferences and computers and [38] Yukish M. Configuring and exploring the foundry trade space. Tech. rep.,
information in engineering conference, Vol. 46970. 2004, p. 759–70. http: PENNSYLVANIA STATE UNIV STATE COLLEGE APPLIED RESEARCH LAB; 2012,
//dx.doi.org/10.1115/DETC2004-57727. https://apps.dtic.mil/sti/citations/ADA564500.
[14] El Kadiri S, Kiritsis D. Ontologies in the context of product lifecycle management: [39] Ríos J, Jiménez J, Pérez J, Vizán A, Menéndez J, Más F. KBE application
state of the art literature review. Int J Prod Res 2015;53(18):5657–68. http: for the design and manufacture of HSM fixtures. Acta Polytech 2005;45(3).
//dx.doi.org/10.1080/00207543.2015.1052155. http://dx.doi.org/10.14311/698.
[15] Industry-Ontology-Foundry. Industry Ontology Foundry (IOF) - Technical prin- [40] Mas F, Racero J, Oliva M, Morales-Palma D. Preliminary ontology definition for
ciples. Tech. rep., 2020, URL https://www.industrialontologies.org/technical- aerospace assembly lines in Airbus using Models for Manufacturing methodology.
principles/. Procedia Manuf 2019;28:207–13. http://dx.doi.org/10.1016/j.promfg.2018.12.
[16] Patil L, Dutta D, Sriram R. Ontology-based exchange of product data semantics. 034.
IEEE Trans Autom Sci Eng 2005;2(3):213–25. http://dx.doi.org/10.1109/TASE. [41] Arista R, Mas F, Morales-Palma D, Oliva M, Vallellano C. A preliminary ontology-
2005.849087. based engineering application to industrial system reconfiguration in conceptual
[17] Dartigues C, Ghodous P, Gruninger M, Pallez D, Sriram R. CAD/CAPP integration phase. In: Proceedings, Vol. 1613. 2020, p. 0073, http://ceur-ws.org ISSN. URL
using feature ontology. Concurr Eng 2007;15(2):237–49. http://dx.doi.org/10. http://ceur-ws.org/Vol-2969/paper20-FOMI.pdf.
1177/1063293X07079312. [42] Page Risueno J, Nagel B. Development of a knowledge-based engineering
[18] Szejka AL, Júnior OC, Loures ER, Panetto H, Aubry A. Proposal of a model-driven framework for modeling aircraft production. In: AIAA aviation 2019 forum. 2019,
ontology for product development process interoperability and information p. 2889. http://dx.doi.org/10.2514/6.2019-2889.
sharing. In: IFIP international conference on product lifecycle management. [43] Meski O, Belkadi F, Laroche F, Ritou M, Furet B. A generic knowledge manage-
Springer; 2016, p. 158–68. http://dx.doi.org/10.1007/978-3-319-54660-5_15. ment approach towards the development of a decision support system. Int J Prod
[19] Zha XF, Du H. A PDES/STEP-based model and system for concurrent integrated Res 2021;59(22):6659–76. http://dx.doi.org/10.1080/00207543.2020.1821930.
design and assembly planning. Comput Aided Des 2002;34(14):1087–110. http: [44] Zheng X, Hu X, Arista R, Lu J, Sorvari J, Lentes J, Ubis F, Kiritsis D. A semantic-
//dx.doi.org/10.1016/S0010-4485(01)00186-5. driven tradespace framework to accelerate aircraft manufacturing system design.
[20] Zheng C, An Y, Wang Z, Qin X, Eynard B, Bricogne M, Le Duigou J,
J Intell Manuf 2022;1–24. http://dx.doi.org/10.1007/s10845-022-02043-7.
Zhang Y. Knowledge-based engineering approach for defining robotic manu-
[45] Hu X, Arista R, Zheng X, Lentes J, Sorvari J, Lu J, Ubis F, Kiritsis D.
facturing system architectures. Int J Prod Res 2022;1–19. http://dx.doi.org/10.
Ontology-based system to support industrial system design for aircraft assembly.
1080/00207543.2022.2037025.
IFAC-PapersOnLine 2022;55(2):175–80. http://dx.doi.org/10.1016/j.ifacol.2022.
[21] Mas F, Racero J, Oliva M, Morales-Palma D. A preliminary methodological
04.189.
approach to models for manufacturing (MfM). In: IFIP international conference
[46] Arp R, Smith B. Function, role, and disposition in basic formal ontology. Nat
on product lifecycle management. Springer; 2018, p. 273–83. http://dx.doi.org/
Preced 2008;1. http://dx.doi.org/10.1038/npre.2008.1941.1.
10.1007/978-3-030-01614-2_25.
[47] Borgo S, Ferrario R, Gangemi A, Guarino N, Masolo C, Porello D, Sanfilippo EM,
[22] Holland OT. Model-based systems engineering. In: Modeling and simulation in
Vieu L. DOLCE: A descriptive ontology for linguistic and cognitive engineering.
the systems engineering life cycle. Springer; 2015, p. 299–306.
Appl Ontol 2022;(Preprint):1–25. http://dx.doi.org/10.3233/AO-210259.
[23] Zheng X, Lu J, Kiritsis D. The emergence of cognitive digital twin: vision,
[48] Lemaignan S, Siadat A, Dantan J-Y, Semenenko A. MASON: A proposal for an
challenges and opportunities. Int J Prod Res 2021;1–23. http://dx.doi.org/10.
ontology of manufacturing domain. In: IEEE workshop on distributed intelligent
1080/00207543.2021.2014591.
systems: Collective intelligence and its applications (DIS’06). IEEE; 2006, p.
[24] Delpiano M, Fabbri M, Garda C, Valfrè E. Virtual development and integration of
195–200. http://dx.doi.org/10.1109/DIS.2006.48.
advanced aerospace systems: Alenia aeronautics experience. Tech. rep., ALENIA
[49] Negri E, Fumagalli L, Macchi M, Garetti M. Ontology for service-based control of
AERONAUTICA SPA TORINO (ITALY); 2003, URL https://apps.dtic.mil/sti/pdfs/
production systems. In: IFIP international conference on advances in production
ADP014152.pdf.
management systems. Springer; 2015, p. 484–92. http://dx.doi.org/10.1007/
[25] Pardessus T. Concurrent engineering development and practices for aircraft
978-3-319-22759-7_56.
design at Airbus. In: Proceedings of the 24th ICAS conf., Yokohama, Japan, Vol.
[50] Zheng X, Lu J, Arista R, Hu X, Lentes J, Ubis F, Sorvari J, Kiritsis D. Development
1. 2004, URL http://icas.org/ICAS_ARCHIVE/ICAS2004/PAPERS/413.PDF.
[26] Sohlenius G. Concurrent engineering. CIRP Ann 1992;41(2):645–55. of an application ontology for knowledge management to support aircraft
[27] Mousavi BA, Azzouz R, Heavey C, Ehm H. A survey of model-based system assembly system design. In: FOMI 2021: 11th international workshop on formal
engineering methods to analyse complex supply chains: a case study in semicon- ontologies meet industry, held at JOWO 2021: Episode VII the Bolzano summer
ductor supply chain. IFAC-PapersOnLine 2019;52(13):1254–9. http://dx.doi.org/ of knowledge, September 11–18, 2021, Bolzano, Italy, Vol. 1613. 2020, p. 0073,
10.1016/j.ifacol.2019.11.370. URL http://ceur-ws.org/Vol-2969/paper21-FOMI.pdf.
[28] Kiritsis D. Semantic technologies for engineering asset life cycle management. [51] Mejía-Gutiérrez R, Carvajal-Arango R. Design verification through virtual proto-
Int J Prod Res 2013;51(23–24):7345–71. http://dx.doi.org/10.1080/00207543. typing techniques based on systems engineering. Res Eng Des 2017;28(4):477–94.
2012.761364. http://dx.doi.org/10.1007/s00163-016-0247-y.
[29] Jørgensen N. The Boeing 777: development life cycle follows artifact. In: World [52] Li T, Lockett H, Lawson C. Using requirement-functional-logical-physical models
conference on integrated design and process technology. IDPT, Citeseer; 2006, to support early assembly process planning for complex aircraft systems integra-
p. 25–30. tion. J Manuf Syst 2020;54:242–57. http://dx.doi.org/10.1016/j.jmsy.2020.01.
[30] Batarseh O, McGinnis L, Lorenz J. 6.5.2 MBSE supports manufacturing system 001.
design. In: INCOSE international symposium, Vol. 22. Wiley Online Library; [53] Lu J, Ma J, Zheng X, Wang G, Li H, Kiritsis D. Design ontology supporting
2012, p. 850–60. http://dx.doi.org/10.1002/j.2334-5837.2012.tb01375.x. model-based systems engineering formalisms. IEEE Syst J 2021;1–12. http://dx.
[31] Oliva M, Mas F, Eguia I, Valle Cd, Lourenço EJ, Baptista AJ. An innovative doi.org/10.1109/JSYST.2021.3106195.
methodology to optimize aerospace eco-efficiency assembly processes. In: IFIP [54] Lu J, Wang G, Ma J, Kiritsis D, Zhang H, Törngren M. General modeling language
international conference on product lifecycle management. Springer; 2020, p. to support model-based systems engineering formalisms (Part 1). In: INCOSE
448–59. http://dx.doi.org/10.1007/978-3-030-62807-9_36. international symposium, Vol. 30. Wiley Online Library; 2020, p. 323–38. http:
[32] Mas F, Menéndez JL, Oliva M, Gómez A, Ríos J. Collaborative engineering //dx.doi.org/10.1002/j.2334-5837.2020.00725.x.
paradigm applied to the aerospace industry. In: IFIP international conference [55] Zheng X, Psarommatis F, Petrali P, Turrin C, Lu J, Kiritsis D. A quality-oriented
on product lifecycle management. Springer; 2013, p. 675–84. http://dx.doi.org/ digital twin modelling method for manufacturing processes based on a multi-
10.1007/978-3-642-41501-2_66. agent architecture. Procedia Manuf 2020;51:309–15. http://dx.doi.org/10.1016/
[33] Zha XF, Lim SY, Lu WF. A knowledge intensive multi-agent system for j.promfg.2020.10.044.
cooperative/collaborative assembly modeling and process planning. J Integr [56] Zheng X, Petrali P, Lu J, Turrin C, Kiritsis D. RMPFQ: A quality-oriented
Des Process Sci 2003;7(1):99–122, URL https://dl.acm.org/doi/abs/10.5555/ knowledge modelling method for manufacturing systems towards cognitive
1242339.1242346. digital twins. Front Manuf Technol 2022;2. http://dx.doi.org/10.3389/fmtec.
[34] Hunter R, Rios J, Perez J, Vizan A. A functional approach for the formalization 2022.901364.
of the fixture design process. Int J Mach Tools Manuf 2006;46(6):683–97. [57] Ding J, Reniers M, Lu J, Wang G, Feng L, Kiritsis D. Integration of modeling
http://dx.doi.org/10.1016/j.ijmachtools.2005.04.018. and verification for system model based on KARMA language. In: Proceedings
[35] Colledani M, Pedrielli G, Terkaj W, Urgo M. Integrated virtual platform for of the 18th ACM SIGPLAN international workshop on domain-specific modeling.
manufacturing systems design. Procedia CIRP 2013;7:425–30. http://dx.doi.org/ New York, NY, USA: Association for Computing Machinery; 2021, p. 41–50.
10.1016/j.procir.2013.06.010. http://dx.doi.org/10.1145/3486603.3486775.

287
R. Arista et al. Journal of Manufacturing Systems 68 (2023) 270–288

[58] Gomes C, Thule C, Broman D, Larsen PG, Vangheluwe H. Co-simulation: a survey. [61] Chirumalla K, Bertoni A, Parida A, Johansson C, Bertoni M. Performance
ACM Comput Surv 2018;51(3):1–33. http://dx.doi.org/10.1145/3179993. measurement framework for product–service systems development: a balanced
[59] Hu X, Arista R, Lentes J, Lu J, Zheng X, Sorvari J, Ubis F, Kiritsis D. Ontology- scorecard approach. Int J Technol Intell Plan 2013;9(2):146–64.
centric industrial requirements validation for aircraft assembly system design. [62] Mourtzis D, Panopoulos N, Angelopoulos J. Production management guided by
In: 10th IFAC conference on manufacturing modelling, management and control, industrial internet of things and adaptive scheduling in smart factories. In: Design
Nantes, France, June 22-24. 2022. and operation of production networks for mass personalization in the era of
[60] Chryssolouris G. Manufacturing systems: Theory and practice. Springer Science cloud technology. Elsevier; 2022, p. 117–52. http://dx.doi.org/10.1016/B978-0-
& Business Media; 2013. 12-823657-4.00014-2.

288