Digital Transformation in Aircraft Design and Certification: Ontology Design Patterns for Modeling Regulatory Guidance Material Documentation

Abstract

Aircraft design is regulated by federal law and must comply with complex regulatory documentation. The complexity of the certification process has resulted in a growing interest in digital transformation, for which models are often used to provide explicit structure. Ontological modeling is one of the most promising approaches for the digital transformation of regulatory documentation. This paper presents a novel approach to ontology development that applies ontology design patterns to construct a knowledge representation of regulatory documentation, with a focus on guidance material. The approach includes five main processes: (i) the selection of a regulatory document; (ii) the use of a natural language processing tool; (iii) a contextual analysis; (iv) the identification of patterns in the natural language; and (v) the development and implementation of ontology design patterns. The modeling approach is demonstrated using the ARP4754B: Guidelines for Development of Civil Aircraft and Systems guidance material document and is validated with a use case AC21.101-1B—Establishing the Certification Basis of Changed Aeronautical Products guidance material document. The modeling approach is then verified against an established set of regulatory documentation modeling requirements. The systematic ontological modeling approach presented in this paper enables digital transformation of regulatory documentation, a necessary step for a more efficient and effective certification process.

1. Introduction

Aircraft are safety-critical systems regulated by federal law [1,2]. Aircraft design regulations have become progressively more stringent since the 1920s [3,4], resulting in an increasingly complex and costly certification process [5,6,7].

The certification process is governed by authorities [8] such as the European Union Aviation Safety Agency (EASA) [9], the Federal Aviation Administration (FAA) in the United States [3], and Transport Canada Civil Aviation (TCCA) [10,11]. Regulatory information is communicated from the authority to aircraft development companies in the form of documentation, which can be divided into two main categories: regulations and guidance material. Regulations contain the requirements to which an aircraft development company must comply, and guidance material documents typically include recommendations for how compliance can be demonstrated. As an example, the FAA oversees over 1800 design regulations for commercial transport-category aircraft [12,13], as well as thousands of pages of associated guidance material and supporting documentation [14,15].

Regulatory documentation is often characterized by ambiguous use of natural language, legal terminology, context-dependent definitions, and complex cross-referencing [16]. For example, the FAA regulation §25.1309 (b) states that “The airplane systems and associated components, evaluated separately and in relation to other systems, must be designed and installed so that they meet all of the following requirements: (1) Each catastrophic failure condition (i) Must be extremely improbable; and (ii) Must not result from a single failure” [17]. This section of the regulations is difficult to parse into individual requirements, as each subsection depends on the context of the introductory sentence. Additionally, none of the definitions for airplane systems, their separate and relational evaluation, design, and installation, extreme improbability or single failure are included in the regulations themselves. The information necessary to understand this section of the regulations must instead be found in thousands of pages of guidance material documentation which contain detailed information on complex compliance processes [18]. The interpretation of the regulatory documentation, the knowledge of implicit relationships between the regulations and guidance material, and the understanding of how an aircraft design is certified in practice is knowledge held tacitly by subject matter experts (SMEs), who acquire that knowledge over many years of experience [2].

The imperative to manage complex processes and information throughout aircraft design and certification programs has created an interest in digital transformation [19,20,21]. While digital modeling tools such as computer-aided design (CAD) [22], finite element analysis (FEA) [23], multidisciplinary design analysis and optimization (MDAO) [24], and digital twins [19,25,26,27] have been demonstrated to contribute to program success, digital transformation of the aircraft certification process remains in the early stages of implementation [28,29]. As regulatory documents are publicly available and common to both the regulator and the applicant, an investigation of approaches for developing a reusable regulatory digital platform based on a shared vocabulary provides value to all stakeholders. The intent of this investigation is not to replace SMEs but rather to leverage software tools to support the SMEs throughout the design and certification process [30].

1.1. Ontological Modeling for Digital Transformation of Regulatory Documentation

Models are routinely used to provide structure for digital transformation [31]. Previous research by Cartile et al. [30] establishes a set of nine requirements and compares the feasibility of process mapping, Unified Modeling Language (UML), and ontological modeling methods for the most effective approach to modeling aircraft regulatory documentation in the context of digital transformation. The previously established requirements are listed in

Table 1. Requirements for modeling aircraft regulatory documentation, established in previous work by Cartile et al. [30].

Requirement 1	Models must accurately reflect the natural language and intended meaning found in the regulatory documentation.
Requirement 2	Models must include explicit definitions.
Requirement 3	Models must be modular.
Requirement 4	Each model must be purpose specific.
Requirement 5	Each model must have a constrained scope.
Requirement 6	Models must have consistent architectures.
Requirement 7	All modeled entities must be traceable to their source document and location within that source document.
Requirement 8	Models must be generic and reusable on different programs.
Requirement 9	Models must be scalable.

.

The previous research concludes that the most promising method for further investigation is ontological modeling, as it provides capabilities for formally structuring natural language to meet requirements 1 and 2 in Table 1 [30]. Ontological modeling is therefore selected as the focus for the research that is the subject of this paper.

1.2. Research Question and Paper Overview

This research aims to answer the following question: Can ontological modeling be used to effectively represent aircraft regulatory guidance material documentation in the context of digital transformation?

Section 2 provides the current state of the literature and the gaps addressed in this research. Section 3 presents the research methodology used to produce a novel, systematic, and repeatable approach to developing generic, modular, adaptable, consistent, and explicit ontological models for the effective representation of aircraft regulatory documentation. The methodology is demonstrated using examples from the SAE International Aerospace Recommended Practice ARP4754B: Guidelines for Development of Civil Aircraft and Systems guidance material document [32]. Validation case studies are commonly used to demonstrate that a modeling approach is reproducible and can be repeatably applied to meet its intended purpose [33,34]. Section 4 validates the research methodology using the Advisory Circular AC21.101-1B—Establishing the Certification Basis of Changed Aeronautical Products guidance material document [35]. Conformance tests are conducted in Section 5 to verify and discuss the research results against the nine modeling requirements proposed in [30]. Section 6 concludes the research findings and proposes future applications for this work.

2. Literature Review

The literature review is structured as follows: Section 2.1 discusses regulatory documentation modeling research and the challenges identified in the literature. Section 2.2 introduces ontological modeling, and Section 2.3 provides an overview of ontology design pattern literature. Section 2.4 summarizes the gaps and presents the contributions of this paper.

2.1. Modeling Regulatory Documentation

The imperative to digitally transform regulatory documentation has been recognized in domains such as building and construction, environmental law, pharmaceutical drugs, finance, and nuclear safety [36,37,38,39,40]. Early logic models of the law, termed legal logic [41,42], formed the basis for recent advancements in computational law knowledgebases [43,44,45]. Examples of regulatory modeling applications include modeling compliance information to improve retrievability during audits [36,46]; developing semantic frameworks for regulatory language using Extensible Markup Language (XML) for web-based regulations [37]; and using Bidirectional Encoder Representations from Transformers (BERT), a subset of artificial intelligence (AI), for regulatory language classification [38,39].

Aerospace researchers have also recently taken an interest in modeling regulations and guidance material. Ray et al. [47] develop an aerospace-specific aeroBERT-NER large language model (LLM) using CFR Part 23/Part 25 regulatory text and CubeSat documentation. Several researchers have investigated the use of Systems Modeling Language (SysML), a systems engineering domain-specific language based on Unified Modeling Language (UML), to model regulations for small fixed-wing aircraft [48,49] and large fixed-wing aircraft [50] as elements contributing to a larger initiative of modeling the certification planning process. Harrison et al. [51] further develop this work to include modeled representations for means and methods of compliance. Modeling of compliance documents is also investigated by Paul et al. [52], who use ontological models of tasks listed in the ARP4754A guidance material document and develop a dashboard to track work completion status. Eito-Brun et al. [53] model a guidance material document for data exchange and aggregation in the space sector using a natural language processing tool and ontological modeling.

The researchers investigating regulatory modeling have identified several challenges. Fazal et al. [50] note that the ambiguity and context-dependency in the natural language render the regulations difficult to parse and represent in model entities. The semi-structured semantic capabilities of UML-based modeling languages have been recognized as a limitation and lack the necessary capabilities to address the challenges in regulatory natural language [30,54,55,56,57]. Ray et al. [47] reflect similar context-dependency challenges and note having to modify the original regulatory text into a more machine-readable format. While significant advances have been made in the use of LLMs in model development [58], challenges in modeling complex domains are also identified in LLM literature [59]. The “complex concepts, specialized terminology, and intricate relationships between entities” and the absence of a structured knowledgebase result in LLM output inconsistencies [59]. The labeling and reformatting of ambiguous regulatory language introduces risks of changes to the interpretation and intended meaning of the regulations, affecting model outcomes.

The challenges identified in the literature highlight a gap in the effectiveness of current modeling approaches for representing domain-specific, ambiguous, and context-dependent natural language of aircraft regulatory documentation. Previous research conducted by Cartile et al. [30], supported by recent literature [28,31,60], identifies ontological modeling as the most suitable method to address this gap in the context of digital transformation.

2.2. Ontological Modeling

Ontologies are models of a knowledgebase expressed in a formal ontological language [61,62,63,64]. Modern ontologies are based in description logic, a decidable subset of first-order logic that borrows formalization methods from set theory and Boolean algebra [65,66,67], of which there are several types that differ in levels of expressivity and computational complexity [68,69]. The decidable nature of description logic has facilitated advancements in the area of computational reasoning, which are used in ontological modeling tools to make inferred deductions such as class membership without explicit assertion and check for logical inconsistencies in a model [70,71,72,73]. Ontologies use open-world assumptions and are typically monotonic [74], where new information cannot be used to revise old conclusions within a model [75,76]. One of the criticisms of monotonic logic and the open-world assumption is the susceptibility to axiomatic fallacies, where new information may require manual restructuring of classification restrictions or world-model reorganization [76]. Closed-world non-monotonic frameworks such as rule-based systems are often used in conjunction with ontologies to overcome these limitations [74,77].

Ontologies have been used in many applications such as the organization of the World Wide Web [77,78]; as an interface for software systems such as model-to-model and model-to-code generation [79,80]; for capturing requirements specifications to inform software development [81]; and for knowledge management, including formal knowledge representation, search, and retrieval [60,61]. The successful adoption of ontologies for the semantic web has also led to many initiatives that have supported the use of ontological modeling for knowledge representation [82,83], including the development of standards managed by W3C [84] and open-sourced ontological modeling tools such as Protégé [85,86]. Advances in artificial intelligence, such as natural language processing and large language models, have resulted in resurging interest in ontological modeling [87].

Ontologies can be developed from source documentation or from existing models, and can be constructed manually, automatically, or semi-automatically [16,61,87,88,89,90]. Ontological model development guidelines proposed by Noy and McGuinness [63] note the importance of determining the domain, scope, and purpose of an ontology and recommend using a list of competency questions to validate whether the resulting models fulfill their intended purpose. Several large-scale upper-level ontology initiatives have also been proposed as methods for ontological model development [91,92,93,94], such as the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) foundational ontology library [95].

Debellis and Neches [77] discuss the challenges associated with the development and application of an upper-level ontology, stating, “it was simply too complicated to build an all-encompassing model, in part because practical resolution depends on context.” Bernabé et al. [96] discuss a lack of empirical evidence on the effectiveness of foundational ontologies and observe low adherence to development guidelines. Gangemi and Presutti [97] discuss the lack of consensus on modeling guidelines as one of the primary challenges of ontology implementation, which results in a tendency to develop single-use models [61,98]. One of the ways proposed to improve model development standardization is through the use of ontology design patterns (ODPs) [91,97].

2.3. Ontology Design Patterns

Design patterns are widely used in the field of software engineering to provide systematic, reusable designs for recurrent problems [99,100]. Design patterns can improve model quality by providing consistency within and across models and have been increasingly applied to ontological modeling [91,101].

An EU-funded research project, NeOn Consortium, was launched in the early 2000s to create an inventory of ontological design patterns [73,102,103,104]. The NeOn project organized patterns into several categories including content patterns, which focus on semantics and repeated patterns found in the natural language of the domain being modeled [73,105,106].

Content design patterns are used to address case-specific semantic modeling applications, referred to as “generic use cases” [105,107]. Gangemi [105] proposes selecting a generic use case when developing an ontological modeling framework to determine the scope and structure of a model for domain-specific applications. Content design patterns can be used as flexible, reusable, and self-contained building blocks to model recurring tasks within a use case, and “provide common ground for more complex ontologies” [108]. Examples of content patterns include spatial geometries, human action, and events [100]; time [109,110]; class structure [111]; part-whole composition [112,113,114,115] and group membership [116]; and sequences such as process sequence [117,118], genomic sequence [119,120], and sequence of parts assembly [121].

Combinations of content design patterns are also used to model specific applications. For example, the trajectories design pattern combines segment, geospatial, time-dependent, and sequential patterns in a single ontology [108,122]. The trajectories design pattern has been used in applications such as bird migration models and urban planning [108,123].

While the logical foundation of ontological modeling provides a means to mathematically structure natural language, it also has constraints. The use of content design patterns is one approach to structuring the natural language while still respecting these constraints. For example, one of the limitations of description logic-based ontologies is that relationships can only be asserted between individuals. Noy [124] presents several solutions to this design problem that make use of design patterns while still conforming to the rules of description logic. Other examples of ontology design challenges include the representation of part-whole relationships [114,115,125] and assigning non-measurable attributes to individuals [126]. Noy [124] explains that each design pattern has trade-offs, where the selection of the most appropriate pattern depends on the purpose of the ontology.

While many authors have proposed approaches to ontological modeling and have explored the use of ontological design patterns to develop models, a gap remains in the literature for a systematic approach to identifying areas of application, techniques for development, and guidelines for implementation of ontology design patterns for aircraft regulatory documentation in the context of digital transformation [90].

2.4. Summary, Gaps, and Contributions

The literature has identified several challenges in developing effective models of aircraft regulatory documentation, which current modeling method capabilities have been unable to address. Ontological modeling and ontology design patterns show promise for effectively representing aircraft regulatory documentation and addressing the regulatory natural language challenges identified in the literature. However, there remains a gap for a systematic and repeatable approach to model development that can be used to identify patterns in the natural language, develop generic ontology design patterns, and implement the ontology design patterns to represent recurring patterns throughout the regulatory documentation.

This paper presents a novel approach to ontology development that includes the systematic identification of recurring patterns and the development and implementation of ontology design patterns to several case studies, demonstrating a repeatable knowledge representation approach for regulatory documentation to address the gap in the literature. The approach leverages the use of natural language processing and contextual analysis to identify recurring patterns in the regulatory text and establishes a structured, generic, modular, and adaptable approach to the development and implementation of ontology design patterns to effectively represent the natural language. The approach is developed and validated using two guidance material document case studies selected from different domains within the aircraft design and certification process to support confidence in repeatability of the modeling approach: the SAE International Aerospace Recommended Practice ARP4754B: Guidelines for Development of Civil Aircraft and Systems [32]; and the Federal Aviation Administration (FAA) Advisory Circular AC21.101-1B—Establishing the Certification Basis of Changed Aeronautical Products [35]. The selection of these case studies is intended to demonstrate reusability and support the standardization of this approach across different disciplines within this domain to provide a modeling framework for the digital transformation of the aircraft certification process. The modeling approach developed in this research enables traceable, repeatable, and purpose-specific modeling of regulatory guidance material, which has not been previously demonstrated in the aerospace certification domain.

This paper makes the following scientific contributions to advance the state of the art of modeling aircraft regulatory documentation in the context of digital transformation:

(a) Methodological contributions to ontological modeling development: this approach contributes a systematic modeling methodology using natural language pattern identification and generic ontology design pattern development for repeatable implementation.

(b) Contributions to the representation of aircraft regulatory documentation: this approach addresses the ambiguity challenges of regulatory natural language and supports the complex relationships between regulatory documentation through the NLP-assisted concept identification and contextual analysis to formalize recurring regulatory natural language patterns that are characteristic of regulatory documentation (classification, process, and reference patterns) and their mapping to corresponding ontology design patterns.

(c) Empirical research contributions: the validation and verification of the proposed methodology through two non-trivial aerospace guidance material case studies, demonstrating generalizability and repeatability across regulatory contexts and value as a tool for knowledge capture by including subject matter experts and database interaction with the model.

3. Research Methodology

The research methodology presented in this section describes the process of developing ontological models from the natural language found in regulatory guidance material documentation. The research methodology is developed using examples from the ARP4754B; is validated using examples from the AC21.101-1B; and is verified against previously established modeling requirements. The model development process is illustrated in Figure 1 and described in the following sections: Section 3.1 includes the selection of regulatory documentation; a natural language processing tool used to identify candidate concepts directly from regulatory text in Section 3.2; a contextual analysis to investigate the definitions and intended meaning of concepts is conducted in Section 3.3; recurring patterns within the natural language are identified in Section 3.4; and Section 3.5 describes the selection and implementation of design patterns for ontological model development.

3.1. Regulatory Document Selection

One of the key guidance material documents used to certify civil aircraft design is the SAE International Aerospace Recommended Practice ARP4754B: Guidelines for Development of Civil Aircraft and Systems [32]. The use of this document is recognized internationally as a method for demonstrating compliance with safety regulations such as CFR §25.1309, which requires catastrophic failure conditions to be extremely improbable and hazardous failure conditions to be extremely remote [17,18,127]. The ARP4754B [32] frequently references a second guidance document, the ARP4761A: Guidelines for Conducting the Safety Assessment Process on Civil Aircraft, Systems, and Equipment [128], which further specifies processes for assessing design safety. The development of the research methodology is demonstrated using examples from both the ARP4754B and ARP4761A.

3.2. Natural Language Processing Tool Analysis

3.2.1. NLP-Identified Keywords and Noun-Phrases

The selected regulatory documentation is analyzed using the natural language processing (NLP) software tool Atlas.ti version 25.0.1 [129] “concept search” function to identify the most frequently occurring keywords and their associated noun-phrases throughout the document. The Atlas “concept search” function is distinct from a “word frequency” function. While a word frequency function identifies parts-of-speech frequencies and provides lists of word categories, such as nouns, verbs, and adjectives, the concept search provides a list of keywords in any part-of-speech and ranks their frequencies depending on the number of noun-phrases associated with that keyword [130]. The advantage of using the concept search function is that it provides an overview of the main concepts used across a document and the contextual excerpts where the noun-phrases occur to provide a comprehensive initial starting point for ontology development.

The keywords for the ARP4754B [32] are shown in Figure 2a, and the noun-phrases associated with the keyword requirement are shown in Figure 2b.

The top five keywords and corresponding number of associated noun-phrases in the main body of the ARP4754B document are system (462 noun-phrases), requirement (433 noun-phrases), process (389 noun-phrases), development (378 noun-phrases), and level (260 noun-phrases).

The listed noun-phrases require cleaning activities, such as combining singular and plural noun-phrases; combining noun-phrases that differ due to articles such as “the” and “a”; and removing duplicates of noun-phrases appearing under multiple keywords, such as the noun-phrase system development appearing under both system and development. Although this cleaning process is amenable to automation, it was performed manually for the purpose of this research. Examples of the NLP-identified keywords system, requirement, and process are shown in column 1 of Table 2, and examples of associated noun-phrases are listed in column 2 of Table 2.

3.2.2. Identification of Concepts to Be Modeled

The cleaned noun-phrases are then further analyzed to identify an initial list of ontological concepts to be modeled. Column 3 of Table 2 provides examples of concepts identified from the ARP4754B document.

Table 2. Examples of keywords and associated noun-phrases from the ARP4754B identified by NLP software and organized into ontological concepts.

Keywords Identified by NLP Software	Noun-Phrases Identified by NLP Software	Ontological Concepts to be Modeled
system	system architecture	architecture, function, development, and system
	system functions
	system development
requirement	requirement(s)	derived requirement, safety requirement, validation process
	derived requirement
	safety requirement
	requirement validation
process	development process	development, development assurance, process
	development assurance process

Table 2. Examples of keywords and associated noun-phrases from the ARP4754B identified by NLP software and organized into ontological concepts.

Keywords Identified by NLP Software	Noun-Phrases Identified by NLP Software	Ontological Concepts to be Modeled
system	system architecture	architecture, function, development, and system
	system functions
	system development
requirement	requirement(s)	derived requirement, safety requirement, validation process
	derived requirement
	safety requirement
	requirement validation
process	development process	development, development assurance, process
	development assurance process

As an example of this assessment, the keyword system in Table 2 column 1 has associated noun-phrases system architecture, system functions, and system development, listed in Table 2 column 2. The analysis results in the identification of the four different ontological concepts shown in Table 2, column 3: architecture, function, development, and system.

3.3. Contextual Analysis

A contextual analysis is conducted for each of the ontological concepts to identify explicit definitions, ambiguous use of concepts, and potential ontological modeling structures for classes, individuals, and properties. The contextual analysis is conducted using the ontological concept identification questions listed below. The use of questions to define the scope of an ontology is based on recommendations made by Noy and McGuinness [63].

• Contextual analysis questions used to identify ontological concepts

Q1.

Is this noun-phrase a technical term?

Q2.

Is the noun-phrase defined?

Q3.

What kind of “thing” is the noun-phrase? Ex: an artifact, a process, a status, a verb, a concept, etc.

Q4.

Does the noun-phrase maintain the same definition and categorization in each of its contextual instances?

Q5.

Are there any classification criteria or constraints associated with the noun-phrase?

Q6.

Are there recurring patterns within the contexts of the noun-phrases?

As an example of explicit definitions, concepts such as function and requirement are often further specified as being aircraft-level, system-level, or item-level. The ARP4754B includes definitions for both system and item; however, aircraft remains undefined. Aircraft-level activities occur throughout the document, and a lack of an associated definition is identified as a challenge for explicit modeling.

The contextual analysis process also enables the identification of additional associated concepts and the relationships between them. Examples of additional concepts related to those listed in Table 2 above are shown in

Table 3. Examples of ontological concepts identified through contextual analysis of the ARP4754B.

AFHAProcess	DevelopmentAssurancePlanningProcess	InterfaceRequirement	ProcessAssurance
AircraftLevel	DevelopmentAssuranceProcess	ItemDevelopmentIndependence	ProcessIndependence
AircraftSafety	DevelopmentError	ItemLevel	PSSAProcess
AircraftSystem	DevelopmentProcess	MaintenanceRequirement	Requirement
Architecture	FailureCondition	OperationalRequirement	SafetyAssessmentProcess
CertificationRequirement	Function	PASAProcess	SafetyRequirement
CustomerRequirement	FunctionalIndependence	PerformanceRequirement	SFHAProcess
DerivedRequirement	FunctionalRequirement	Physical Requirement	SystemLevel
DevelopmentAssuranceLevel	Independence	PhysicalIndependence	ValidationProcess
DevelopmentAssurancePlan	InstallationRequirement	Process	VerificationProcess

below.

3.4. Natural Language Pattern Identification

The contextual analysis process enables the identification of recurring patterns throughout the text that can be modeled as repeatable structures in ontologies. This assessment is also used to define how the concepts will be represented in an ontology, either as individuals, classes, or properties. Three examples of natural language patterns were identified in the ARP4754B: classification patterns, process patterns, and reference patterns, and are described below.

3.4.1. Classification Patterns

Classification is an important theme across aircraft regulatory documentation and is often used to determine which regulations and compliance activities are required for certification. As class membership inference is one of the main functions of ontological modeling, identifying classification patterns in natural language is one of the primary areas of investigation for this research.

3.4.1.1. Class Pattern

Class membership requires an initial class structure. The NLP-identified keywords shown in Figure 2a for the ARP4754B provide a starting point for the ontological class structure, which is further refined with recurring concepts identified through contextual analysis. The concepts are assessed for shared characteristics or constraints that may group them together into a class. The Process and Requirement keywords shown in Figure 2a are examples of initial classes for the ARP4754B. For example, the keyword requirement is assessed using the contextual analysis questions listed in Section 3.3. The ARP4754B ([32], pp. 43–44) identifies several types of requirements, including safety, functional, customer, operational, performance, physical and installation, maintainability, interface, certification, and derived, and provides guidance for the derivation of each type of requirement. The many types of requirements identified in the ARP4754B result in the identification of the keyword Requirement as an ontological class.

3.4.1.2. Classification Criteria Pattern

Following the identification of classes, the criteria for class membership are extracted from the document as part of the contextual analysis and pattern identification process. Continuing the same example of the keyword Requirement, safety requirements are further defined through a series of processes and methods, which begin with the Aircraft Functional Hazard Assessment (AFHA). The objective of the AFHA is to identify aircraft-level functional failure conditions and classify them according to their severity, which includes Catastrophic, Hazardous, Major, Minor, and No Effect. Each failure condition must be assessed by an SME for its effect on the aircraft, on the flight crew, and on the occupants. All three assessments must be made for each failure condition at each phase of flight, which includes taxi, takeoff, climb, cruise, descent, approach, and landing. The classification criteria are detailed in the accompanying implementation guidance material document ARP4671A ([128], p. 40). The failure classification process for a catastrophic failure is illustrated in Figure 3.

The failure classification process shown in Figure 3 depicts a single failure condition 1 (blue) being assessed in the taxi phase of flight (green) for its effect on the aircraft, effect on the flight crew, and effect on the occupants of the aircraft (orange). A Boolean true/false question is posed for each of these failure effect questions, shown in gray. An answer of true for any of the questions results in a Catastrophic classification for failure condition 1, shown in purple. This process must be conducted for all failure conditions associated with all aircraft-level functions, at each phase of flight.

Safety requirements as described in the ARP4754B and ARP4671A are developed using recurring Boolean true/false questions that result in a series of classifications, which are identified as a frequently occurring pattern across the guidance material documents and can be modeled in an ontology. The failure condition is the entity needing classification and is represented as an ontological individual. The Boolean true/false questions are represented in an ontology as data properties, where the range of each property is defined as Boolean. The failure classifications of catastrophic, hazardous, major, minor, and no effect are each represented in an ontology as a class.

3.4.2. Process Patterns

One of the main focuses of guidance material is to describe supporting compliance processes and the order in which they must be performed. Continuing with the same example, the series of processes described in the ARP4754B ([32], p. 24) that are used to define safety requirements begin with the Aircraft Functional Hazard Assessment (AFHA) and include several subsequent processes shown in Figure 4.

The ARP4754B describes the processes shown in Figure 4 as having both a hierarchy and a sequential order of operation.

3.4.2.1. Process/Subprocesses Hierarchy Patterns

The main processes shown in Figure 4 include the Aircraft Function and Requirement Development process; the Development of Aircraft Architecture and Allocation of Aircraft Functions to Systems process; and the Development of System Functions and Requirements process. Each process has several subprocesses, including the Aircraft Functional Hazard Assessment (AFHA), Preliminary Aircraft Safety Assessment (PASA), System Functional Hazard Assessment (SFHA), and Preliminary System Safety Assessment (PSSA) subprocesses.

3.4.2.2. Ordered Process Patterns

The ARP4754B also describes the order in which the processes/subprocesses should be performed. For example, the AFHA subprocess is required as input to the Development of Aircraft Architecture and Allocation of Aircraft Functions to Systems process, and therefore the AFHA must be completed first. The arrows in Figure 4 indicate the order in which the processes should occur.

The example of safety requirements is used to illustrate that recurring patterns such as Boolean true/false classification questions and process sequence patterns are used throughout the ARP4754B and ARP4671A guidance material documents and can be modeled using ontological design patterns. Each of these processes is represented in an ontology as an individual of type Process. The hierarchy and sequence between the individuals are modeled using object properties and further specified using object property characteristics to infer an order of operation for these processes.

3.4.3. Reference Patterns

Aircraft certification requires stringent documentation traceability to track changes, engineering justification, and compliance. The explicit cross-referencing within the regulations and implicit cross-referencing between regulations and guidance material require a mechanism for representation within a model for forward and backward traceability between the model and its source documentation to ensure the model is a source of truth.

3.4.3.1. Source Referencing

Each of the ontological concepts identified in the contextual analysis corresponds to one or several sections of text in which the concept is mentioned. The NLP software tool Atlas.ti [129] concept mining capability demonstrates the utility of in-text source referencing, shown in Figure 5. The example of the keyword Process selected in Figure 5a shows the in-text location and contexts in which the Process noun-phrases appear in Figure 5b.

A defined relationship between each ontological entity and its source documentation is also necessary to differentiate the type of source documentation that is being modeled to distinguish between entities sourced from law-bound regulations and entities linked to guidance material recommendations and means of compliance.

3.4.3.2. Cross-Referencing

The interdependent nature of aircraft systems is reflected in complex cross-referencing between regulatory documents. While regulations only explicitly reference other regulations, guidance material cross-references both the regulations and other guidance material documents. Examples of external document sections referenced throughout the ARP4754B include the FAA’s Code of Federal Regulations (CFRs) [131] and EASA’s Certification Specifications (CS) [132], such as the §25.1309 [17,133], as well as other guidance material documents such as the ARP4671A [128]. The relationship between the regulations and guidance material is only explicitly defined in one direction; regulations do not explicitly reference which guidance material documents are accepted as recommendations for establishing means of compliance. A modeling pattern reflecting a forward and backward relationship between regulations and guidance material would contribute to clarifying the interactions between the documents.

The source and cross-reference patterns are modeled in an ontology using the annotation property relationship. The annotation property is selected as the mechanism for this relationship as it can be linked to any modeled entity in an ontology and can therefore be used as forward and backward traceability for all ontological classes, properties, and individuals.

The classification, process, and referencing patterns identified in the natural language pattern identification assessment form the foundation for logical, repeatable modeling structures and are used to inform the design and implementation of ontology design patterns to develop an ontological representation of the guidance material documentation.

3.5. Ontological Design Pattern Implementation

Ontology design patterns are implemented using the ontological modeling tool Protégé [85,86] based in ${SROIQ}^{\left(D\right)}$ description logic [68] as a modeling solution to represent the patterns found in the natural language of the text. This paper uses guidelines presented by Noy and McGuinness [63], DeBellis [90], and Insaurralde and Blasch [88] to develop ontological models.

The proposed ontology design patterns and modeling implementation are discussed in the following section and include class, Boolean true/false classification, process, and reference ontology design patterns.

3.5.1. Class Ontology Design Pattern

The proposed Class ontology design pattern for the class pattern identified in the ARP4754B is presented in Figure 6.

The class structure in Figure 6 includes Artifact, Process, Reference, Requirement, and Role classes. The identification of a class structure is supported by the literature. Humberg et al. [111] discuss the Artifact, Process, and Role classes as being widely accepted across software modeling literature as a solution to formalizing concept hierarchies for model interoperability. Humberg et al. [111] also propose the use of a Reference class to store an explicitly defined set of source documentation references. References are related to entities in the ontology to provide forward and backward traceability between the ontological entities and their location within source documentation. In this research, the Reference class is adapted to include relationships to both source and cross-referenced documents, as described in Section 3.4.3 and modeled in Section 3.5.4. The Process and Requirement classes shown in Figure 6 model the natural language patterns identified in Section 3.4.1.1 and are specific to the ARP4754B.

3.5.2. Boolean True/False Classification Ontology Design Pattern

A Boolean true/false classification ontology design pattern is developed to represent the classification criteria pattern presented in Section 3.4.1.2, where a series of Boolean true/false questions are used to classify individuals. A generic ontological model is shown in Figure 7 to illustrate the design pattern, and an implementation example for the ARP4754B is shown in Figure 8.

The Boolean true/false pattern illustrated in Figure 7 is structured as follows. The individuals to be classified are shown in Figure 7a and are labeled GenericEntity 1–7. Three data properties are shown in Figure 7b as BooleanClassificationQuestion 1–3. The aircraft certification subject matter expert (SME) must interact with the model to answer true or false for each question in Figure 7b with respect to each individual in Figure 7a. Membership of the class TypeAGenericEntity shown in Figure 7c is constrained by requiring the value true for any one of the BooleanClassificationQuestions shown in Figure 7d, and the individuals meeting this criterion are inferred as members of class TypeAGenericEntity, shown in Figure 7d. The individuals, data properties, and classes are intentionally represented as generic entities in this design pattern, as they are intended to be replaced with specific entities when applied to an aircraft design and development program. The pattern is also designed to be scalable, where any number of entities can be added or removed depending on the program type or size.

The Boolean true/false ontology classification pattern is used to model the safety requirement failure condition severity classification criteria example from the ARP4761 described in Section 3.4.1.2 and illustrated in Figure 3. The resulting ontological model is shown in Figure 8.

Figure 8. Boolean true/false classification design pattern applied to failure condition classification criteria described in the ARP4671A, including (a) generic failure condition individuals, (b) data property assertions, (c) failure condition severity classifications, and (d) constraints.

Figure 8. Boolean true/false classification design pattern applied to failure condition classification criteria described in the ARP4671A, including (a) generic failure condition individuals, (b) data property assertions, (c) failure condition severity classifications, and (d) constraints.

Generic failure condition individuals such as FailureCondition1 are shown in Figure 8a, where in an aircraft design program, the generic individuals would be renamed with program-specific failure conditions. Figure 8b shows the Boolean true/false questions for catastrophic failure presented in Figure 3, modeled as data property assertions for each phase of flight, where an SME enters a Boolean true or false value for each assertion. The severity levels are shown in Figure 8c, and the constraints that determine the class membership criteria for each classification are shown in Figure 8d. The design pattern, when applied to this example, is demonstrated as being scalable to a larger number of data property assertions without having to modify the pattern structure.

3.5.3. Process Ontology Design Patterns

The process natural language patterns presented in Section 3.4.2 are structured using two ontology design patterns: a part-whole relationship design pattern is used to model process/subprocess hierarchy described in Section 3.4.2.1, and a sequence design pattern is used to model process order described in Section 3.4.2.2. A generic ontological model is shown in Figure 9 to illustrate the process design pattern, and its application to an example from the ARP4754B is shown in Figure 10.

The process ontology design pattern shown in Figure 9 includes (a) object properties, (b) generic process individuals, and (c) object property assertions. The individuals labeled Process 1–7 and 14–16 are randomly numbered to demonstrate the use of object property assertions in defining the process/subprocess hierarchy and order of process sequence. Object property characteristics such as inverse and transitive are used to further define relationships between processes. The object properties and associated characteristics shown in Figure 9a are further detailed in

Table 4. Object properties and associated characteristics for process ontology design patterns.

Object Property	Object Property Characteristic
hasSubProcess	transitive, inverse of isSubProcessOf
hasFirstSubProcess	functional, inverse of isFirstSubProcessOf
hasLastSubProcess	functional, inverse of isLastSubProcessOf
hasSubsequentProcess	transitive, inverse of isSubsequentProcessOf
hasImmediateNextProcess	inverse of isImmediateNextProcessOf
hasParallelProcess	transitive, inverse of isParallelProcessOf

.

3.5.3.1. Process/Subprocesses Modeled Using Part-Whole Relationship Ontology Design Pattern

The process/subprocess hierarchical relationship is represented by the transitive hasSubProcess object property shown in the first row of Table 4, which implements a part-whole relationship design pattern based on the Rector and Welty [114] “Representation Pattern 1: Representing a part-whole hierarchy.” This pattern allows the representation of a hierarchy while respecting the subsumption rule described in Section 2.1 and is scalable so that any number of subprocesses can be added without changing the design pattern.

3.5.3.2. Ordered Process Sequence Modeled Using a Sequence Ontology Design Pattern

The sequence ontology design pattern is represented by the remaining five object properties shown in Table 4, and is adapted from patterns presented by Hu et al. [108], DeBellis [117], and Gangemi [118]. The first and last subprocesses within a process are identified by hasFirstSubProcess and hasLastSubProcess, respectively. These relationships are both functional. The sequence following the first process is indicated as one of the following: a subsequent process with unspecified order using the transitive object property hasSubsequentProcess; a process that is immediately subsequent using the object property hasImmediateNextProcess; or a process that occurs in parallel using the transitive object property hasParallelProcess. The reasoner is used to infer additional sequential information from the object property characteristics, shown in yellow in Figure 9c.

Figure 10 illustrates the generic Figure 9 ontology design pattern applied to an example from the ARP4754B processes described in Section 3.4.2.

Figure 10. Process ontology design pattern applied to selected processes from the ARP4754B, including (a) individuals and (b) object property assertions.

Figure 10. Process ontology design pattern applied to selected processes from the ARP4754B, including (a) individuals and (b) object property assertions.

The individuals in Figure 10a are the selected processes described in Section 3.4.2 and Figure 4. The object property assertions in Figure 10b demonstrate how object properties are used to identify immediate next processes, subsequent processes, and subprocess relationships.

3.5.4. Reference Ontology Design Pattern

The referencing patterns presented in Section 3.4.3 are structured using a Reference ontology design pattern. The source reference pattern is shown in Figure 11, and the cross-reference pattern is shown in Figure 12 for the ARP4754B.

A Reference class and ARP4754B Reference, 14CFR Reference, and CS Reference subclasses are shown in Figure 11a and Figure 12a. The source referencing pattern is structured as an enumerated list, demonstrated in Figure 11b for the ARP4754B document sections. The cross-referencing pattern discussed in Section 3.4.3.2 is also structured as an enumerated list, demonstrated in Figure 12b using examples from Title 14 of the Code of Federal Regulations (CFR) that are referenced throughout the ARP4754B. Each concept modeled in the ontology can be related to one or more sections of corresponding reference documentation using the annotation properties hasSourceReference and hasCrossReference, respectively. This relationship between classes, object properties, data properties, and individuals and their location within source documentation provides traceability that can support model revisions to ensure models remain a current source of truth.

The classification, process, and reference design patterns identified in the ARP4754B recur many times throughout the document and represent patterns that are typical of aircraft regulatory documentation. The ontology design patterns are developed using scalable, generic entities to form a template that can be applied to other instances of the pattern throughout the same document and other regulatory documents. The modeling approach developed in this research is intended to function as a methodology for identifying those patterns as they recur throughout regulatory text and provides a mechanism for identifying and modeling new patterns using the same methodology.

4. Validation and Results

In this section, the research question, “Can ontological modeling be used to effectively represent aircraft regulatory documentation in the context of digital transformation?” is answered by validating the modeling approach proposed in Section 3 with a guidance material document use case. A guidance material document from another discipline in the aircraft certification domain is selected to validate this modeling approach and is used to demonstrate the repeatability of the research methodology to different applications.

4.1. Regulatory Document Selection

The document selected to validate the modeling approach is the Advisory Circular AC21.101-1B—Establishing the Certification Basis of Changed Aeronautical Products [35] guidance material document, which provides guidance for complying with the Code of Federal Regulations (CFRs) §21.101 [134]. The AC21.101-1B provides guidance for establishing a new certification basis for changes made to an existing aircraft, a certification challenge that is arguably more complex than for a clean-sheet design. The equivalent documents to the AC21.101-1B and CFR §21.101 for the European (EASA) and Canadian (TCCA) regulatory bodies are as follows: the EASA equivalent guidance material document is the GM 21.A.101 Establishing the certification basis of changed aeronautical products [135] and the regulation CS 21.A.101 [136]. The Canadian Advisory Circular equivalent, AC 500-016 Issue No. 1 [137], currently points to the FAA’s AC21.101-1B to provide interim guidance for complying with the equivalent Canadian Aviation Regulation, CAR 521.158 [138], in establishing the certification basis for a changed aeronautical product.

This research was conducted in collaboration with two industrial partners: a Canadian aerospace research and development company specializing in aircraft certification and a Canadian aircraft modification company. Interactions with industrial partners included author on-site internships, presentations, discussions, and research reviews with aircraft certification SMEs. The AC21.101-1B is selected for its relevance to the aircraft modification sector and for the subject matter expertise in the areas of aircraft modification and certification, contributing to this research.

4.2. Natural Language Processing Tool Analysis

4.2.1. NLP-Identified Keywords and Noun-Phrases

The selected regulatory documentation is analyzed using a natural language processing tool, Atlas.ti version 25.0.1 [129]. The most frequently occurring keywords and associated noun-phrases in the main body of the AC 21.101-1B document are shown in Figure 13.

The top five keywords and associated noun-phrases in the AC 21.101-1B are change (317 noun-phrases), design (140 noun-phrases), certification (113 noun-phrases), basis (110 noun-phrases), and product (106 noun-phrases). Table 5 provides examples of the NLP-identified keywords basis, change, and product. Noun-phrase cleaning activities described in Section 3.2.1 are conducted and examples of cleaned associated noun-phrases are presented in column 2 of Table 5.

4.2.2. Identification of Concepts to Be Modeled

The cleaned noun-phrases are then further analyzed to identify an initial list of ontological concepts to be modeled, examples of which are shown in column 3 of Table 5.

Table 5. Examples of keywords and associated noun-phrases from the AC21.101-1B identified by the NLP tool and organized into ontological concepts.

Examples of Keywords Identified by NLP Software	Noun-Phrases Identified by NLP Software	Ontological Concepts to be Modeled
basis	certification basis	certification basis/type certification basis (synonymous)
	type certification basis
	the basis
change	change(s)	change/design change/type design change (synonymous)
	design change(s)
	type design change
	substantial change	substantial change
	related and unrelated changes	related change
		unrelated change
product	product(s)	aeronautical product/product (synonymous)
	aeronautical product

Table 5. Examples of keywords and associated noun-phrases from the AC21.101-1B identified by the NLP tool and organized into ontological concepts.

Examples of Keywords Identified by NLP Software	Noun-Phrases Identified by NLP Software	Ontological Concepts to be Modeled
basis	certification basis	certification basis/type certification basis (synonymous)
	type certification basis
	the basis
change	change(s)	change/design change/type design change (synonymous)
	design change(s)
	type design change
	substantial change	substantial change
	related and unrelated changes	related change
		unrelated change
product	product(s)	aeronautical product/product (synonymous)
	aeronautical product

As a specific example, the keyword basis in Table 5 is associated with the noun-phrases certification basis, type certification basis, and the basis. Most of the noun-phrases containing the word basis are paired with the word certification, and as a result the noun-phrase certification basis is selected as the concept most relevant to the aircraft modification domain.

4.3. Contextual Analysis

The series of questions presented in Section 3.3 is used to conduct a contextual analysis for each of the ontological concepts to identify definitions, ambiguity, and additional associated concepts to form an initial modeling structure. Examples of additional ontological concepts identified through the contextual analysis of the AC 21.101-1B are shown in

Table 6. Examples of ontological concepts identified through contextual analysis of the AC21.101-1B.

AffectedArea	ExistingCertificationBasis	ProductLevelChange
AgreedCertificationBasis	ExtensiveChange	PropellerProduct
AircraftProduct	FinalCertificationBasis	ProposedCertificationBasis
AirplaneProduct	FunctionalChange	ProposedChange
AmendedSupplementalTypeCertificate	MajorChange	RelatedChangeGroup
AmendedTypeCertificate	MinorChange	ResultingCertificationBasis
Applicant	NewCertificationBasis	RotorcraftProduct
Assumption	NewTypeCertificate	SecondaryChange
BaselineCertificationBasis	NotSignificantChange	SignificantChange
BaselineProduct	OriginalCertificationBasis	SmallAirplaneProduct
CertificationBasis	PerformanceChange	SubstantialChange
ChangedProduct	PhysicalChange	SupplementalTypeCertificate
CumulativeEffectChanges	PowerChange	TransportAirplaneProduct
CurrentCertificationBasis	PreviouslyTypeCertificatedProduct	TypeCertificate
EngineProduct	PreviousRelevantDesignChanges	TypeDesign
EquivalentCertificationBasis	ProductChange	TypeDesignConfiguration
ExceptedProduct	ProductConfiguration	UnrelatedChangeGroup

.

As an example of additional concepts identified in this process, one of the instances of the concept certification from paragraph 3.1.1 of the AC21.101-1B ([35], p. 11) has the following context: “As an applicant for the certification of a type design change, you must show […].”

While certification and type design change are already included in the initial NLP-identified concepts shown in Table 5, applicant is not. Relationships between certification, type design change, and applicant are also absent from the NLP software output. A further contextual analysis of applicant shows that the applicant takes many different actions throughout the text, including identifying, showing, considering, accounting for, assessing, electing, evaluating, designating, documenting, proposing, choosing, using, changing, justifying, substantiating, demonstrating, complying, filing, applying, and submitting. The contextual analysis facilitates the identification of synonyms and selection of the most relevant relationships to be modeled in the ontology.

4.4. Natural Language Pattern Identification

The contextual analysis process enables the identification of recurring patterns throughout the natural language of the text. Similarly to the pattern identification process presented in Section 3.4 for the ARP4754B, the patterns identified in the natural language of the AC21.101-1B are classification patterns, process patterns, and reference patterns, described below.

4.4.1. Classification Patterns

Classification remains an important theme in the AC21.101-1B in determining which regulations will be required to form the basis of certification for a changed aircraft. The investigation of classes and class membership criteria in the natural language of the document is necessary to identify recurring patterns and develop an ontology.

4.4.1.1. Class Pattern

The NLP-identified keywords shown in Figure 13a provide a starting point for class structure investigation for the AC21.101-1B. The keyword Change is an example of an initial class, as changes to an aircraft require severa.

l classification activities throughout the AC21.101-1B. Additional classes of Artifact, Process, Reference, and Role that are common to software modeling literature as described in Section 3.5.1 are also relevant to the AC21.101-1B. For example, the AC21.101-1B further classifies the keyword Change as substantial changes, significant changes, and related or unrelated changes. The types of Change defined in the AC21.101-1B result in the identification of the keyword Change as an ontological class.

4.4.1.2. Classification Criteria Patterns

• Boolean true/false classification

Following the identification of classes, the criteria for class membership are extracted from the document as part of the contextual analysis and pattern identification process. Continuing in the example of the keyword Change, the AC21.101-1B provides a series of classification steps, including “Step 2. Verify the Proposed Type Design Change is Not Substantial” ([35], p. 14). The AC21.101-1B states that “… you [must] apply for a new [type certificate] for a changed product if the change in design, power, thrust, or weight is so extensive that a substantially complete investigation of compliance with the applicable regulations is required” ([35], p. 14). The statement provides criteria for classifying a change as substantial or not substantial and can be organized into a series of Boolean true/false questions illustrated in Figure 14 for a not substantial change classification.

The change classification process shown in Figure 14 depicts a change (gray) being assessed for the extent of its effect on power, design, weight, and thrust. A Boolean true/false question is posed for each of these substantiality questions, shown in white. An answer of False must be given for all questions in order for the change to be considered as not substantial (light blue). If any of the answers were to be True, the change would be classified as substantial (dark blue).

The criteria for a substantial or not substantial change as described in the AC21.101-1B illustrate another example of recurring Boolean true/false questions that result in a series of classifications, which are identified as a frequently occurring pattern across the guidance material documents and can be modeled in an ontology. The change is the entity needing classification and is represented as an ontological individual. The Boolean true/false questions are represented in an ontology as data properties, where the range of each property is defined as Boolean. The classifications of substantial change or not substantial change are each represented in an ontology as a class.

• Pairwise comparison classification

Another example of keyword Change classification criteria is found in “Step 4. Arrange Changes into Related and Unrelated Groups” of the AC21.101-1B ([35], p. 15), which states that “Related changes are those that cannot exist without another, are co-dependent, or a pre-requisite of another.” This statement addresses cases where several changes are being made within the same aircraft modification program and states the criteria against which changes are assessed for their relationship to one another. This classification process has additional complexity of relational criteria, which the Boolean true/false classification design pattern alone is unable to address. The three criteria of cannot exist without, are co-dependent, or pre-requisite of another form the basis for a pairwise comparison between each of the changes to assess whether they are related to one another. A diagram of a related/unrelated pairwise comparison matrix between three generic changes is shown in Figure 15.

Figure 15 shows one pairwise comparison conducted using three criteria to assess if changes are related to one another. Each table represents a question about the nature of the relationship between generic changes 1, 2, and 3. The changes are related if one or more of the comparisons in Figure 15 have a value of true and are unrelated if all the comparisons have values of false. A pairwise comparison is a mathematical method often used for multidimensional decision-making in complex systems design and can be modeled in an ontology. The generic changes, change 1, change 2, and change 3, are to be classified and are represented as ontological individuals. The Boolean true/false questions are represented in an ontology as data properties and specified as relational, with the range of each property defined as Boolean. The classifications of related and unrelated changes must be further specified as related to change 1, related to change 2, related to change 3, or unrelated change, and are modeled in an ontology as classes.

4.4.2. Process Patterns

The AC21.101-1B contains guidance on compliance processes and their order of occurrence. For example, assessing types of Changes involves a series of several processes which are described in the AC21.101-1B [35] and shown in Figure 16.

The processes described in Figure 16 include Verify Proposed Change is Not Substantial, Arrange Changes into Related and Unrelated Groups, Is Each Related or Unrelated Group a Significant Change, and Identify Affected Areas. The order of these processes is presented sequentially in the AC21.101-1B, where each process must be completed prior to conducting the subsequent process. Order is indicated by the arrows in Figure 16.

4.4.3. Reference Patterns

Similarly to the source referencing and cross-referencing patterns described in Section 3.4.3, the ontological modeling concepts can be sourced to sections of the AC21.101-1B, and the external document most cross-referenced is the Code of Federal Regulations (CFRs) §21.101 [134].

The classification, process, and referencing patterns identified in the natural language pattern identification assessment of the AC21.101-1B form the foundation for logical, repeatable modeling structures and are used to validate the research methodology for the design and implementation of ontology design patterns and the applicability of the systematic ontological representation of a broader scope of guidance material documentation.

4.5. Ontological Design Pattern Implementation

Ontological design patterns for the classification, process, and reference natural language patterns identified in the AC21.101-1B are proposed in the following sections and include class; Boolean true/false classification; pairwise comparison; process; and reference ontology design patterns.

4.5.1. Class Ontology Design Pattern

The proposed Class ontology design pattern for the class pattern identified in the AC21.101-1B is presented in Figure 17.

The class structure in Figure 17 makes use of both classes used in software development and classes specific to the AC 21.101-1B. Two classes in Figure 17 differ from those identified in the ARP4754B example presented in Section 3.5.1. The Requirement class has been removed because the AC21.101-1B does not contain requirements classification activities. The classes Change and Area have been added, as these contain classification activities and criteria.

4.5.2. Boolean True/False Classification Ontology Design Pattern

The Boolean true/false classification design pattern previously shown in Figure 7 is implemented in the context of the AC21.101-1B process Verify Proposed Change is Not Substantial and is presented in Figure 18.

The individuals of class Change shown in Figure 18a represent the proposed changes to the aeronautical product. The ontological representation shown in Figure 18b involves an assessment of each change against the AC21.101-1B criteria for substantiality using the following data property assertions: is power change substantially extensive; is design change substantially extensive; is weight change substantially extensive; and is thrust change substantially extensive.

The structure permits the SME to interact with the model and answer each of these questions with true or false values. As a result of the SME input, an ontological reasoner classifies changes as either NotSubstantialChange or SubstantialChange as shown in Figure 18c according to the constraints shown in Figure 18d. A non-substantial change is one in which all of the criteria for substantiality listed above are reported as false. Examples of generic changes inferred as members of the NotSubstantialChange class are shown in the bottom half of Figure 18d. The individuals classified under NotSubstantialChange therefore qualify as changes to an aeronautical product, rather than a new product design.

The classifications were tested using different combinations of data property values for each of the individuals to ensure the reasoner did not detect any logical errors.

4.5.3. Pairwise Comparison Classification Ontology Design Pattern

Pairwise comparison and part-whole relationship ontology design patterns are used to structure the related and unrelated group pairwise comparison classification criteria pattern identified in Section 4.4.1.2.

A generic ontological model is shown in Figure 19 to illustrate the design pattern, and the implementation of the design pattern to the AC21.101-1B is shown in the ontology in Figure 20.

The individuals of class Change are shown in Figure 19a, and examples of generic pairwise comparison questions are shown as data properties in Figure 19b. The SME answers true or false for each of the four questions comparing the respective changes. The class diagram in Figure 19c shows the classes named in a way that allows for group membership while respecting a subsumptive relationship between a class and its members, such as Change with no relationship to other changes. This is a part-whole group-membership design pattern based on “Representation Pattern 2: Defining classes for Parts” presented by Rector and Welty [114]. Changes are inferred to class membership by the reasoner if they meet the constraint criteria, an example of which is shown in Figure 19d. The member of this class, Change3, has data property assertion values of false for all pairwise comparison questions. This design pattern is scalable, in that any number of pairwise comparisons can be conducted by adding data properties and including them as constraints for class membership criteria.

The pairwise comparison classification ontology design pattern is applied to the AC21.101-1B Arrange Changes into Related and Unrelated Groups process and is shown in Figure 20.

Figure 20. Pairwise comparison classification ontology design pattern as applied to the Related/Unrelated groups process described in the AC21.101-1B including (a) individuals, (b) data property assertions, (c) class, and (d) constraints.

Figure 20. Pairwise comparison classification ontology design pattern as applied to the Related/Unrelated groups process described in the AC21.101-1B including (a) individuals, (b) data property assertions, (c) class, and (d) constraints.

Generic individuals Change 1–8 are shown in Figure 20a. The three related/unrelated change assessment criteria of cannot exist without, are co-dependent, or pre-requisite of another are modeled using data property assertions. Each criterion question is asked for each of the change pairs, examples of which are shown in Figure 20b and listed in

Table 7. Pairwise comparison data property assertions for related/unrelated change assessment, as described in the AC21.101-1B.

Related/Unrelated Change Assessment Criteria Category	Pairwise Comparison Data Property Assertions
Cannot exist without	Cannot exist without Change 1; cannot exist without Change 2; […] cannot exist without Change 8
Are co-dependent	Is dependent on Change 1; is dependent on Change 2; […] is dependent on Change 8
Pre-requisite of another	Is prerequisite for Change 1; is prerequisite for Change 2; […] is prerequisite for Change 8

.

The SME answers each question for each of the change individuals with true or false values in the ordered pairwise comparison. As a result of the SME input, an ontological reasoner then classifies changes into either ChangeRelatedtoChange 1-8 or UnrelatedChange classes shown in Figure 20c. These classifications are determined by the constraints shown in Figure 20d. The changes are inferred as members of a related group if any one of the data property assertion values is true and are classified as unrelated if all values are false. An example for ChangeRelatedtoChange1 is shown in Figure 20d, where Change2 and Change5 are inferred as related to Change1, and Change1 is explicitly defined as a class member.

4.5.4. Process Ontology Design Patterns

The ordered processes identified in the AC21.101-1B are structured using a process ontology design pattern. The generic process design pattern previously shown in Figure 9 is applied to selected processes from the AC21.101-1B and the results are presented in Figure 21.

The individual Arrange Changes into Related and Unrelated Groups Process is selected as an example in Figure 21a to illustrate object property assertions for the order of processes in Figure 21b.

4.5.5. Reference Ontology Design Pattern

The Reference ontological design pattern presented in Figure 11 is applied to the AC21.101-1B and shown in Figure 22.

Two subclasses are listed in Figure 22a under the class Reference. The first subclass is AC21.101-1B Reference, referring to the source referenced within the document, and the second subclass is 14CFR Reference, referring to Title 14 Aeronautics and Space of the Code of Federal Regulations (CFR) cross-reference. Each section of the respective documents is modeled as an individual in the ontology, and subclass membership is declared explicitly using an enumerated list, shown in Figure 22b. Each concept modeled in the ontology can be related to one or more sections of corresponding source documentation through the use of the annotation property hasSourceReference and related to cross-referenced documentation using the annotation property hasCrossReference.

4.6. Results

The ontological modeling approach presented in this paper aims to provide a logical, repeatable, interoperable modeling structure. The class, Boolean true/false, pairwise comparison, process, and reference design patterns, when applied to the AC21.101-1B guidance material, develop individual ontologies that are treated as a collection of modules. These modules can interact with one another, with external databases, and with subject matter experts; and provide an explicit, formal representation of the natural language within the guidance material documentation and can be used for digital transformation.

A metamodel illustrating the organization and interaction of the ontological models developed for the AC21.101-1B is shown in Figure 23. The AC21.101-1B provides an example of an aircraft design program with two modifications: a fuselage extension modification to increase the number of passengers and an avionics upgrade modification to modernize the flight deck. The metamodel presented in Figure 23 is applied to the modification program examples described in the AC21.101-1B and the results of this implementation are shown in Figure 24.

The Class pattern in Figure 23 and Figure 24a shows the Area, Artifact, Change, Process, Reference, and Role classes described in Section 4.5.1. A reference example is shown in Figure 24b, which relates the Boolean true/false questions from the (f) Significance module to the CFR §21.101(b)(1) and AC21.101-1B using the annotation property hasCrossReference and hasSourceReference, respectively.

The Process module shown in Figure 23 and Figure 24c depicts the four AC21.101-1B processes of Verify proposed change is not substantial, Arrange changes into related and unrelated groups, Is each related or unrelated group a significant change, and Identify affected areas described in Section 4.5.4. Each of these processes is represented as an individual in the owl:Class Process. Processes are related to one another by sequential object properties, examples of which are shown in blue boxes labeled has immediate next.

Each process is realized by an individual module. As shown in Figure 23 and Figure 24, the Substantiality module (d) and the Significance module (f) use a Boolean true/false classification design pattern, while the Change Groups module (e) and the Affected Areas module (g) apply the pairwise comparison ontology design pattern.

The modification example described in the AC21.101-1B states that the fuselage plug results in an increase in aircraft weight and requires an increase in engine thrust. Four Change individuals are therefore modeled in Figure 24d as Fuselage Plug Change, Weight Increase Change, Thrust Increase Change, and Avionics Upgrade Change. The Boolean true/false data properties are specified in each module according to the example. All four change individuals are classified as Not Substantial Change in Figure 24d, which are then input to Figure 24e to assess related and unrelated change groups. The resulting classifications of Fuselage Plug Change, Weight Increase Change, and Thrust Increase Change as one related Fuselage Plug Weight Thrust Increase Change Group, and the Avionics Upgrade Unrelated Change are then input to Figure 24f, which classifies both the change group and the unrelated change as Significant Change. The significant changes are then input to Figure 24g and assessed for their effect on other areas of the aircraft, such as Handling Qualities Area and Performance Qualities Area, as per the AC21.101-1B [35].

The models shown in Figure 23 and Figure 24 represent a machine-readable format of the AC21.101-1B guidance material document that explicitly captures the intended meaning of its natural language and reflects the complex interactions of its processes. The models in Figure 23 and Figure 24d–g show additional information pertaining to the implementation of a software solution based on this framework, which includes the interaction between the ontological model, the applicant, and an external database. The applicant provides proprietary inputs, such as lists of changes, and provides decisions captured as Boolean true/false questions. The applicant role is represented generically but would be assigned to an SME according to the expertise required for each project.

Preliminary database feasibility assessments have been conducted using the Cellfie spreadsheet import plugin for Protégé [139] to capture the inferred classification result output from each module to act as input to the next module. In a developed and implemented software solution based on this framework, a database would also function as a knowledge capture tool, not only to provide information for the basis of certification but also to retain compliance information that can be used in future aircraft modification programs.

The ontological modeling approach has also been successfully applied to effectively model sections of the Federal Aviation Administration (FAA) Code of Federal Regulations (CFRs). This additional validation further demonstrates the reusability of the research methodology on a broader range of authorship and document intent, and confirms that the patterns identified through this method are representative of both regulatory and guidance material documentation.

5. Verification and Discussion

This section presents the conformance verification assessment of the models presented in Section 3.5 and Section 4.5 against requirements and provides a discussion on the methodology developed in this research.

5.1. Verification of Results Against Modeling Requirements

The resulting models are evaluated for effectiveness by verifying the models against requirements established by Cartile et al. [30]. The requirements, conformance, and conformance justification are presented in

Table 8. Ontological modeling approach verification summary table.

Requirement	Do the Models Conform?	Conformance Justification
Requirement 1 Models must accurately reflect the natural language and intended meaning found in the regulatory documentation.	Yes	The use of a natural language processing tool reflects the natural language found in the regulatory documentation, and the contextual analysis process reflects its intended meaning, Section 3.2 and Section 4.2.
Requirement 2 Models must include explicit definitions.	Yes	Class membership is constrained by the necessary and sufficient conditions defining each class, seen in the classification ontology design patterns in Section 3.5.2, Section 4.5.2, and Section 4.5.3. Explicit definitions can also be related to concepts using the annotation property.
Requirement 3 Models must be modular.	Yes	Modularity is demonstrated in Section 4, specifically in the logical diagram presented in Figure 23.
Requirement 4 Each model must be purpose specific.	Yes	The monotonic nature of ontologies restricts each model to one set of classification inferences, which limits each model to a specific purpose.
Requirement 5 Each model must have a constrained scope.	Yes (contingent)	While the models developed in this research remained computationally feasible, the models would require larger-scale implementation to test the maximum level of scope constraint required.
Requirement 6 Models must have consistent architectures.	Yes	The Class ontology design patterns in Section 3.5.1 and Section 4.5.1 ensure consistent architectures across models.
Requirement 7 All modeled entities must be traceable to their source document and location within that source document.	Yes	The Reference ontology design pattern ensures traceability to source documentation and location within that source documentation, as demonstrated in Section 3.5.4 and Section 4.5.5.
Requirement 8 Models must be generic and reusable on different programs.	Yes	The generic individuals used to demonstrate model development, such as FailureCondition1 in Section 3.5.2, Process1 in Section 3.5.3, and Change1 in Section 4.5.2, ensure this modeling approach is applicable to and can be reused on any program.
Requirement 9 Models must be scalable.	Yes (contingent)	The open-world assumption of ontological models lends itself well to scalability. An example of a scalable ontology design pattern is the pairwise comparison design pattern presented in Section 4.5.3, which can be scaled to any number of individuals or comparison questions without changing the design pattern. Similarly to Requirement 5, the full scalability potential would require further testing to assess the computational feasibility limitations.

.

The ontological modeling approach presented in this paper meets seven out of the nine modeling requirements shown in Table 8 and contingently meets the remaining two requirements. This approach supports the domain-specific semantics of regulatory documentation, is modular, interoperable, traceable, and reusable. The limitations of computational feasibility and scalability remain to be tested by extending this methodology to a larger scope of regulatory documents.

The resulting ontological modeling approach is well-suited for knowledge capture. The interaction with both the SME and an external database allows the generic model, when applied to a specific use case, to capture project-specific data such as technical specifications and means-of-compliance justification for reuse in other projects. The logical flow of information and systematic structuring of the model lend themselves well to knowledge storage and retrieval, making the model usable for future programs.

5.2. Discussion

The application of the proposed modeling approach to a use case successfully validates its viability, and the assessment of the approach against modeling requirements verifies its effectiveness for modeling regulatory guidance material documentation. The advantage of the open-world assumption inherent to ontologies is that the resulting regulatory document models can scale to any program size with any number of entities, without having to restructure the design patterns. The advantage of combining open-world with closed-world assumptions is that a closed-world assumption database tool can be used to capture and store program information. The modular structure of ontological models and interface with the database allows for the ontology to behave non-monotonically, where inferences from one module are used to inform classifications in the next.

The resources required to develop models of regulatory documentation are extensive, both in terms of the required development effort and the number of subject matter experts needed for model validation. The methodology requires subject matter expertise in both ontological modeling and the domain that is being modeled and is best conducted collaboratively between subject matter experts (SMEs) in each field.

Once a model has been developed and validated for a document, it can be used for the digital transformation of that document, and the ontological modeling SME will only be required to update models to reflect changes in regulatory documentation, which occur relatively infrequently. All versions of models will remain relevant, as the continued operation of aircraft over many years requires legacy documentation to be maintained.

Subject matter expertise acquired through experience working on aircraft certification programs is necessary to be able to interpret and understand regulatory terminology and remains indispensable to the certification process and the development of models reflecting that process. A software tool resulting from the modeling framework presented in this paper is intended to support the SMEs and leverage their expertise and tacit knowledge by facilitating the navigation of regulatory documents, allowing the SMEs to focus on design justification and decision-making.

Consistency in structure and nomenclature across models is important for model interoperability. Concept identification and interpretation bias is reduced in this research through consultation with aircraft certification SMEs. However, as subject matter expert opinion and interpretation of the natural language in the regulations can vary across the aerospace industry, any bias in the development of an ontology design pattern is therefore carried throughout model implementation. Ontology synonym mechanisms such as rdfs:label are used to mitigate bias by defining nomenclature equivalencies. Once a design pattern is established, a modeling protocol ensures the design pattern is applied consistently and facilitates the identification of equivalent terms across uniformly structured models.

6. Conclusions

The research study presented in this paper proposes a novel ontological modeling approach in support of the digital transformation of aircraft regulatory guidance material documentation to address the regulatory documentation modeling gaps identified in the literature. This paper presents a modeling methodology that includes five main processes: i) regulatory documentation selection; ii) the use of a natural language processing tool; iii) a contextual analysis; iv) a natural language pattern identification process; and v) the development and implementation of ontology design patterns. The modeling approach is demonstrated using examples from the ARP4754B: Guidelines for Development of Civil Aircraft and Systems [32] guidance material document and validated using the AC21.101-1B—Establishing the Certification Basis of Changed Aeronautical Products [35] guidance material document. The resulting modeling approach is verified against an established set of modeling requirements and answers the research question that yes, ontological modeling can be used to effectively represent aircraft regulatory guidance material documentation in the context of digital transformation.

The modeling approach presented in this paper is developed to address the ambiguity and context-dependency challenges found in the natural language of aircraft regulatory documentation by providing logic-based, modular, interoperable, traceable, and reusable models. This systematic modeling approach is a necessary step towards digital transformation and enabling a more efficient and effective aircraft certification process. A digital tool developed from this modeling framework will provide a regulatory and guidance material platform that is common to both the regulator and the applicant throughout the certification process.

This modeling approach shows promise for future applications such as modeling equivalence between other regulatory bodies such as the European Union Aviation Safety Agency (EASA) and Transport Canada Civil Aviation (TCCA) and as a method for developing regulations for new technologies.