Data Conversion Strategies for Effective Aviation Technical Support as a Service

Abstract

Small airlines face significant challenges in maintaining operational efficiency and ensuring compliance with regulatory standards due to limited resources, fragmented technical support ecosystems, and high operational costs. Aviation Technical Support as a Service (ATSaaS) offers an innovative, scalable framework to address these issues by providing centralized or decentralized platforms for technical support. This study examines the advantages, disadvantages, and life cycle costs of centralized and decentralized data conversion architectures within the ATSaaS model. Using mathematical models and a numerical example, the research highlights the trade-offs between initial investments and long-term operational costs, with centralized systems benefiting from economies of scale and decentralized systems offering flexibility. This study also identifies limitations and future research directions.

1. Introduction

1.1. Background and Motivation

Small airlines play a vital role in connecting remote regions, enhancing accessibility, and fostering economic development. However, they face significant challenges in maintaining operational efficiency and ensuring compliance with stringent safety and regulatory standards. These challenges typically arise due to several interconnected factors: smaller airlines operate with fewer financial and human resources than larger carriers, often lacking the in-house technical expertise required to oversee and execute all aspects of aircraft maintenance. They also face obstacles in obtaining spare parts and components quickly and at a reasonable cost. Moreover, despite their limited resources, they are required to comply with the same strict regulatory standards as major airlines to maintain airworthiness and safety. At the same time, they encounter difficulties in adopting new technologies, whether due to financial limitations, insufficient technical knowledge, or organizational resistance to change.

Compounding these difficulties, small airlines often face limited access to reliable market providers, as large players may avoid engaging with them due to the high transaction costs relative to business volume. This results in elevated service costs and challenges in building partnerships with larger, well-established industry players. Financial risks are further exacerbated by unsecured financial transactions and underutilized infrastructure, creating significant barriers to sustainability and growth. Addressing these issues requires innovative solutions tailored to the unique needs and operational contexts of small airlines.

Aviation Technical Support as a Service (ATSaaS) represents an innovative approach in the aviation industry that transforms how technical support is delivered to small airlines [1]. This concept emerged as a response to the unique challenges faced by small airlines in maintaining their aircraft, particularly their struggles with limited resources, technical expertise, and access to efficient support services.

ATSaaS operates through a comprehensive framework that combines several key elements. At its core, the service provides customized support offerings tailored to each airline’s specific needs, considering their unique operational contexts, fleet compositions, and regulatory obligations. This customization ensures that technical support solutions are precisely aligned with individual client requirements, setting ATSaaS apart from traditional support models.

A crucial aspect of ATSaaS is its collaborative ecosystem. The ATSaaS ecosystem operates through a central platform that serves as the connecting hub between multiple stakeholders (Figure 1).

The ecosystem features an ATSaaS provider who connects directly to the platform and manages the overall service delivery. Multiple service providers connect to the platform, including aircraft manufacturers, spare parts suppliers, maintenance, repair and overhaul (MRO) providers, training centers, research institutions, technology providers, and industry associations—each offering specialized technical services. Multiple airlines connect to the platform as the primary service users, with a particular focus on small airlines who can access technical support services they might otherwise find difficult to obtain independently. The platform facilitates communication, service delivery coordination, data exchange, resource sharing, documentation management, performance monitoring, and knowledge sharing between all parties. This integrated ecosystem enables airlines to efficiently access technical support services while allowing providers to effectively deliver their services, all coordinated by the ATSaaS provider through the centralized platform.

This ecosystem facilitates seamless communication and information sharing, promoting the exchange of best practices and expertise among participants. The collaborative nature of ATSaaS enhances overall efficiency and effectiveness of technical support operations.

The ATSaaS model is built to be both scalable and flexible, enabling organizations to tailor their technical support services as their needs evolve. This flexibility allows support levels to be modified in response to fluctuations in fleet size, operational demands, and strategic business priorities. By utilizing a pay-as-you-go or subscription-based approach, the model provides access to high-quality technical support without the need for substantial initial investments.

By providing access to specialized technical expertise and resources that might otherwise be challenging to acquire individually, ATSaaS helps small airlines optimize their maintenance operations while maintaining cost-effectiveness. The ATSaaS enhances operational efficiency through advanced technologies, improves collaboration among industry stakeholders, and streamlines both maintenance operations and regulatory compliance processes.

A critical component of the ATSaaS is the integration of disparate information systems from various organizations involved. These systems often have different data formats and compositions, which poses significant challenges for seamless data integration and communication. This paper explores two primary architectural approaches to address these challenges: centralized and decentralized data conversion.

A centralized approach offers consistency, control, and simplified client integration but introduces a single point of failure and potential latency issues. Conversely, a decentralized approach distributes risk, facilitates real-time data availability, and allows for customization but requires complex implementation and coordination efforts.

The main goal of this article is to evaluate and compare centralized and decentralized architectures within the Aviation Technical Support as a Service (ATSaaS) framework, with a particular focus on their applicability to small airlines. To achieve this goal, this article develops mathematical models to evaluate the life cycle costs of centralized and decentralized architectures, highlighting their respective advantages and limitations.

A critical aspect of implementing ATSaaS is the ability to standardize and integrate technical data across multiple stakeholders, including airlines, maintenance providers, and aviation regulatory bodies. The aviation industry operates with a wide range of heterogeneous information systems, each using different data formats, structures, and communication protocols. This lack of uniformity creates significant challenges in ensuring seamless data exchange, automated decision making, and regulatory compliance within the ATSaaS framework.

Data conversion refers to the process of transforming data from one format, structure, or representation to another to enable interoperability between different systems. In the context of ATSaaS, data conversion involves translating, normalizing, and structuring data from diverse sources such as maintenance logs, aircraft health monitoring systems, and inventory databases into a standardized format that can be efficiently processed by the ATSaaS platform. This transformation is essential for ensuring that technical data from different stakeholders can be accurately interpreted, analyzed, and utilized for predictive maintenance, regulatory reporting, and operational optimization.

The effectiveness of data conversion directly impacts the scalability, cost-efficiency, and reliability of ATSaaS. The two primary approaches to data conversion—centralized and decentralized architectures—each present distinct advantages and trade-offs, which must be carefully evaluated when designing an optimal ATSaaS implementation.

1.2. Related Works

Data exchange in the aviation industry operates within a framework of regulatory requirements and technical standards to ensure consistency and reliability across stakeholders, including airlines, manufacturers, and maintenance organizations. These frameworks emphasize structured and secure protocols for managing and sharing operational and maintenance data.

The European Aviation Safety Agency (EASA) establishes foundational requirements for maintenance data management. EASA mandates that maintenance data must be up to date, readily available, and governed by formal modification procedures. Organizations are required to implement work card or worksheet systems to ensure accurate transcription and maintain systems to monitor amendment statuses. Strict regulations prohibit the use of damaged, altered, or inaccurate maintenance data, ensuring high standards of data quality control [2].

Major aircraft manufacturers have developed advanced platforms to facilitate data management and analysis. Airbus Skywise, for example, organizes data into four domains: (1) aircraft technical data, including post-flight reports and condition monitoring system outputs, (2) maintenance information such as work orders and component replacement records, (3) flight operations data, including flight data recorder and quick access recorder parameters, and (4) engineering documents like service bulletins and technical follow-up records [3]. Similarly, Boeing’s Airplane Health Management (AHM) platform comprises three modules: real-time fault management, which monitors ACARS (Airborne Communications Addressing and Reporting System) messages and distributes alerts; performance monitoring, which tracks engine and system trends; and configuration management, which oversees parts installations and modification statuses [4].

The Air Transport Association’s (ATA) Spec 2000 provides a standardized framework to optimize data exchange and business operations within the aviation sector. Spec 2000 covers various aspects, including component data management, aircraft transfer documentation, and digital record specifications. Reliability data requirements encompass component removal frequencies, failure mode classifications, and mean time between unscheduled removals. While Spec 2000 improves operational efficiency, enhances traceability, and supports cost control, challenges related to system integration, workforce training, and data privacy remain critical considerations [5].

The Federal Aviation Administration (FAA) establishes guidelines for the implementation of Aircraft Health Management Systems (AHMS), emphasizing advantages such as enhanced safety, operational efficiency, regulatory compliance, and cost savings. These standards define key aspects, including data collection methods, sampling rates, data quality requirements, and transmission protocols. They also specify analysis procedures such as trend monitoring, alert generation, and response strategies. However, operators encounter obstacles such as the complexity of implementation, reliance on advanced technologies, and the need for specialized training to fully leverage the benefits of AHMS [6].

PROGNOS, a predictive maintenance suite, utilizes advanced analytics to forecast potential component failures, enabling proactive maintenance [7]. This reduces unscheduled repairs, minimizes aircraft-on-ground incidents, and enhances fleet reliability. However, the accuracy of its predictive capabilities depends on high-quality, complete input data. Integration with existing IT systems is complex and resource intensive, necessitating time and effort for effective adaptation.

Aircraft Maintenance and Operational Software (AMOS) is a comprehensive solution for managing maintenance activities. AMOS centralizes data such as technical records, component histories, and operational logs, ensuring consistency and accessibility for stakeholders. AMOS reduces manual data entry, minimizes errors, and expedites workflows. However, its implementation requires significant customization, data migration, and staff training. Challenges such as user interface design, system integration, and costs must be addressed for optimal use [8].

Despite the advantages of these platforms and standards, several challenges remain. Seamless data integration with existing systems is critical but often resource intensive.

Condition-Based Maintenance (CBM) is a maintenance philosophy that bases repair or replacement decisions on the current or projected condition of equipment [9]. This approach involves a maintenance program that recommends actions based on insights derived from condition monitoring and comprises three primary steps: data collection, data processing, and maintenance decision-making. The primary goal of CBM is to reduce the overall cost of inspections and repairs by analyzing intermittent or continuous data on the operational status of critical components [10].

CBM can range from simple to highly complex implementations. The most common form adopted across industries focuses on data collection, prediction, and corrective actions, with varying levels of automation. Maintenance actions are initiated when these indicators reach predetermined levels of deterioration, ensuring that the equipment is only taken out of service when direct evidence of degradation exists [11]. This evidence-based approach minimizes unnecessary maintenance and optimizes operational efficiency, as maintenance actions are only performed when required to return the equipment to its desired state [12].

ATSaaS functions as a web-based platform that closely follows the Software-as-a-Service (SaaS) cloud computing model [13]. In this model, the software is owned, hosted, and managed remotely by the provider, utilizing a one-to-many architecture. Customers access the services through a pay-per-use or subscription model, relying on a shared framework of code and data definitions [14].

In the broader context of digital business, a platform is a product that enables or supports other products or services. Platforms can range from high-level systems facilitating platform business models to low-level collections of business and technology capabilities that underpin other products or services [15]. This paper [16] expands this definition by describing web platforms as online structures that support a wide range of human activities.

The SaaS model emerged as an alternative to traditional enterprise software implementation, addressing high costs associated with licensing, implementation, hardware, and maintenance [17].

The study in [18] describes the digital platform economy as an expanding domain of digitally facilitated business, political, and social interactions centered around digital platforms. These platforms integrate software, hardware, operations, and networks, offering shared technologies and standardized interfaces to a broad user base.

As user communities grow, network externalities [19] come into play, enhancing the platform’s value. Users benefit from reduced costs, increased certainty about service continuity, access to complementary services and add-ons, and an overall improvement in service quality [20].

For SaaS providers, scalability is crucial. By using economies of scale, SaaS transforms computing infrastructure from a capital expense into an operational expense, offering cost reductions for providers and end-users alike [21].

The functionality and scope of the platform determine the type of information provided and the user experience [22]. By aligning with the SaaS model, these platforms ensure streamlined, accessible, and efficient management solutions for diverse user needs.

Data serve as a cornerstone for the operation of web platforms. Data are also integral to modern business environments, enabling business analysis, operational decision-making [23], fostering innovation [24,25], and driving competitive differentiation. The volume and variety of data influence all aspects of operations, making it a critical strategic asset [26]. However, managing data systematically and efficiently is vital for leveraging opportunities and addressing challenges in today’s dynamic business landscape.

As digital organizations grow and handle ever-increasing amounts of information, key challenges in data management include rising data volumes, dataset complexity, and persistent data quality issues. A comprehensive data management strategy is essential to achieving organizational goals. This strategy includes communication, data management functions, business case development, and securing funding [27]. Among these functions, data migration remains one of the most critical and challenging tasks [28]. Data migration involves transferring data from one or more storage systems to new platforms or locations to improve scalability, accessibility, and portability, while also reducing IT operational costs [29].

Many businesses are now opting to migrate data from proprietary database management systems to open-source alternatives [30]. This shift underscores the complexity and risks of data migration. Without appropriate techniques, failed migrations can result in unreliable data, service interruptions, financial losses, and reputational damage [31]. Inadequate planning and execution of data migration efforts can even lead to business disruptions or failures [32]. Therefore, implementing robust data migration strategies and frameworks is essential for ensuring reliable data management, maintaining business continuity, and supporting long-term organizational objectives.

1.3. Research Gap, Contributions and Paper Structure

Despite extensive research on aviation technical support, digital platforms, and maintenance optimization, there remains a significant gap in how small airlines access and integrate technical support services in a cost-effective and scalable manner. While existing studies have explored various aspects of aviation maintenance, data standardization, and predictive maintenance systems, they do not comprehensively address the fragmented and resource-constrained operational environment of small airlines.

Several key areas of prior research provide valuable insights but lack integration into a unified service-oriented framework like ATSaaS:

• Studies on predictive maintenance and AHMS focus on large airlines and high-resource environments (e.g., Airbus Skywise and Boeing AHM) but do not consider the financial and technical constraints faced by small carriers.
• Research on data exchange protocols in aviation (e.g., ATA Spec 2000 and iSpec 2200) provides structured frameworks but does not offer implementation strategies that accommodate the heterogeneous IT capabilities of small aviation service providers.
• Literature on digital platforms and cloud-based aviation solutions highlights the potential of shared services models but lacks an in-depth exploration of how these platforms can be optimized for cost-efficiency, scalability, and regulatory compliance in small airline operations.

This study bridges these gaps by introducing the ATSaaS model, a novel service-based digital platform designed to optimize technical support for small airlines. The main contributions of this research are as follows:

• Identification of the challenges faced by small airlines in accessing reliable and cost-effective technical support, emphasizing the need for an ATSaaS framework.
• Development of a structured ATSaaS model, analyzing both centralized and decentralized architectures for data conversion and integration, including their respective advantages and limitations.
• Mathematical modeling and life cycle cost analysis, evaluating the trade-offs between initial investments, operational costs, and long-term scalability of centralized vs. decentralized ATSaaS architectures.
• Introduction of a multi-criteria decision-making framework that considers cost, performance, security, scalability, and sustainability, providing a structured approach for selecting the optimal ATSaaS architecture.
• Addressing real-world implementation challenges, including data standardization, cybersecurity risks, and regulatory compliance, offering practical strategies for integrating ATSaaS into small airline operations.

This paper is structured as follows. Section 2 presents alternative ATSaaS platform architectures, examining centralized and decentralized approaches and their implications for data conversion. Section 3 introduces mathematical models for life cycle cost analysis and multi-criteria decision making. Section 4 discusses the results through numerical examples, analyzes the extended decision-making model with dynamic indicators, and explores the integration of additional factors for comprehensive ATSaaS evaluation. This section also addresses study limitations and suggests future research directions. Finally, Section 5 concludes by summarizing key findings and their implications for implementing ATSaaS in the aviation industry.

2. Alternative ATSaaS Platform Architectures

2.1. Centralized ATSaaS Platform Architecture

In a centralized architecture, the conversion of all non-standard data formats is managed on the provider’s side. This model involves a central platform where data from various organizations are collected, processed, and converted into a standardized format that the ATSaaS provider can use. The data flow diagram for the centralized ATSaaS platform architecture (Figure 2) illustrates the complete data journey from airlines to standardized reports through distinct processing layers.

At the airlines input layer airlines generate raw data in their native formats, which flows into the platform’s data ingestion layer through a unified data source registry. Within the data processing layer, the flow progresses sequentially through three main processes: the data validation process verifies data integrity, the format conversion process standardizes data formats (supported by the format rules DB), and the Data Processing Engine performs core data processing (utilizing the standardized data DB). Finally, in the output generation layer, the report generation process creates standardized reports as the final output. The diagram uses solid lines to show the main data flow from input to output, while dotted lines indicate database dependencies, clearly depicting how all data standardization and processing occur within the centralized platform structure. This unified flow ensures consistent handling of data regardless of its source, maintaining standardization throughout the entire process.

Advantages of centralized architecture:

• By centralizing the data conversion process, the ATSaaS provider can ensure consistency in data handling and processing. This approach allows for uniform application of data standards and protocols, reducing the risk of errors and discrepancies.
• Client organizations do not need to modify their existing systems. They can continue to operate using their local information systems without the need to invest in new technology or training, making the transition to ATSaaS smoother and more cost-effective.
• A centralized system can be more easily scaled to accommodate additional clients and data sources. The centralized approach allows for a single point of upgrade and maintenance, simplifying system management.
• Centralizing data processing can enhance security by reducing the number of entry points that need to be secured. The ATSaaS provider can implement robust security measures at the central hub to protect sensitive data.

Disadvantages of centralized architecture:

• A centralized system introduces a single point of failure. If the central hub experiences a technical issue or security breach, it can impact all client organizations connected to the ATSaaS platform.
• Collecting and converting data at a central location can introduce latency, particularly if the client organizations are geographically dispersed. This can affect the timeliness of data availability for decision making.
• Setting up and maintaining a centralized data conversion hub requires significant investment in infrastructure and resources. The provider must ensure sufficient computational power and storage capacity to handle large volumes of data.

The limitations mentioned above can be partially addressed by clustering the underlying hardware and software of the platform, as well as increasing the performance and capacity of computing power, storage, and data processing resources. However, this approach would result in significantly increased complexity in platform maintenance, higher costs for acquisition and support, and greater complexity in platform development.

2.2. Decentralized ATSaaS Platform Architecture

In a decentralized architecture, each organization is responsible for converting its data into the required format before transmitting it to the ATSaaS provider. This model relies on standardized data exchange protocols and interfaces that client organizations must implement locally. The data flow diagram for the decentralized ATSaaS platform architecture (Figure 3) shows a distributed processing system where data flow through both local and centralized components.

At the local level, multiple parallel processing streams exist—one for each airline. Each local stream follows the same pattern: data flow from the airline source through local data generation, then through local conversion, resulting in standardized format output. All these standardized local outputs then converge into the central ATSaaS platform, entering through a single validation process. Within the platform, the validated data flow into the central standardized DB, then through the data processing engine, and finally through the report generation process to produce standardized reports.

Advantages of decentralized architecture:

• By decentralizing the data conversion process, the risk is distributed across multiple organizations. A failure in one organization’s system does not affect the entire ATSaaS network.
• Local data conversion can facilitate real-time data transmission and availability, as there is no need for data to travel to a central hub for processing.
• Each organization can tailor the data conversion process to meet its specific needs and requirements, allowing for greater flexibility and customization.
• Decentralizing data conversion reduces the load on the central ATSaaS infrastructure, potentially lowering the provider’s operational costs and improving system performance.

Disadvantages of decentralized architecture:

• Each organization must implement and maintain its data conversion mechanisms, which can be complex and resource intensive. This approach requires significant coordination and standardization efforts.
• Decentralized data conversion can lead to inconsistencies in data quality and format, especially if organizations do not adhere strictly to the standardized protocols. To prevent such issues, it will be necessary to establish clear standards and requirements for input data. However, this will significantly increase the complexity of system development and make integration more challenging for clients. Decentralized data conversion, without strict adherence to standardized protocols, risks inconsistencies in data quality and format.
• Ensuring the security of data during transmission from multiple decentralized locations can be challenging. Each organization must implement robust security measures, increasing the overall complexity of the system.
• While decentralized systems may reduce long-term operational costs, the initial setup costs for each organization to implement the necessary data conversion infrastructure can be high.

In the decentralized ATSaaS architecture (Figure 3), local processing plays a crucial role in data conversion, validation, and security at the participant level. Unlike the centralized model, where the ATSaaS provider manages data conversion within a unified platform, in a decentralized setup, each participant (e.g., small airlines, MRO providers, and parts suppliers) is responsible for implementing and maintaining its own local processing capabilities. This means that the cost of local processing infrastructure—such as computing power, software, data validation mechanisms, and security compliance—falls primarily on individual participants rather than the ATSaaS provider.

However, while decentralized processing shifts computational responsibility away from the central platform, it also introduces variability in system implementation and security standards among participants, which could increase integration and interoperability challenges. To mitigate this, ATSaaS providers may offer middleware solutions, standardized APIs, or technical guidelines to assist participants in adapting their local systems to the platform’s requirements, thereby reducing fragmentation.

Additionally, a hybrid cost-sharing model could be considered, in which the ATSaaS provider offers technical support, subsidies, or shared infrastructure solutions to help smaller participants implement local processing efficiently. This could involve cloud-based processing extensions or a tiered service model where participants select from different levels of integration support depending on their technological capacity. Such an approach could balance the operational flexibility of decentralized architectures with the cost-efficiency and scalability advantages of centralized processing while ensuring system-wide interoperability and security compliance.

2.3. Data Conversion in the Context of ATSaaS

2.3.1. Data Conversion Approaches in ATSaaS

The implementation of ATSaaS relies on the seamless integration of data from multiple stakeholders, including airline companies and maintenance organizations. Each of these stakeholders typically operates independent information systems with unique data formats and structures. To enable effective communication and data processing within ATSaaS, robust data conversion strategies are essential. These strategies ensure that non-standardized data from diverse systems is transformed into a format compatible with the ATSaaS platform, regardless of the underlying architecture.

Data conversion refers to the process of transforming data from one format, structure, or representation to another. Data conversion involves modifying the way data are organized, encoded, or stored to make it compatible with a different system, application, or platform. Data conversion is often necessary when exchanging information between systems that have different data requirements or when migrating data from one system to another.

In the context of the ATSaaS model, data conversion specifically refers to the transformation of data from the format used by the individual information systems of the participating organizations (such as airline companies and aviation maintenance organizations) into a format that is compatible with the information system of the ATSaaS provider.

The need for data conversion arises because each organization may have its own unique way of structuring, storing, and representing data, which may not align with the data format expected by the ATSaaS provider’s system. For example, an airline company may use a different database schema, data types, or naming conventions compared to the ATSaaS provider’s system.

Data conversion can involve various tasks, such as

• Identifying the relationships between the source data fields and the target data fields and defining the rules for transforming the data from one format to another.
• Retrieving the relevant data from the source system, which may involve querying databases, parsing files, or accessing APIs.
• Applying the defined mapping rules to convert the extracted data into the desired format. This may include tasks such as data type conversions, data normalization, data aggregation, or data splitting.
• Inserting the transformed data into the target system, ensuring that it adheres to the required format and constraints.
• Insufficient volume and completeness of data that fails to meet the platform’s minimum requirements for the specified data objects.

Data conversion can be performed using various tools, technologies, and programming languages, depending on the specific requirements and the complexity of the data. Effective data conversion is crucial for ensuring the seamless exchange of information between the participating organizations and the ATSaaS provider. Effective data conversion enables the ATSaaS provider’s system to accurately interpret and process the data received from the organizations, facilitating the delivery of comprehensive technical support services and the optimization of maintenance operations in the aviation industry.

The choice of ATSaaS platform architecture, whether centralized or decentralized, directly influences the complexity, cost, and location of data conversion processes. Aligning data conversion strategies with the selected architecture is crucial to ensuring the efficiency, cost-effectiveness, and long-term sustainability of ATSaaS.

2.3.2. Practical Challenges and Implementation Strategies for Data Standardization in ATSaaS

Achieving data standardization across multiple stakeholders in the ATSaaS ecosystem is a complex challenge due to varying organizational capabilities, legacy IT systems, and differences in regional regulatory requirements. While standardization is essential for seamless data exchange and interoperability, real-world constraints must be addressed to ensure practical implementation.

One of the key challenges in achieving standardization is the diversity in technological capabilities among participants. Small airlines, maintenance providers, and parts suppliers operate with different levels of digital maturity. While larger organizations may already use standardized data formats, smaller entities often rely on outdated systems or manual processes, making compliance with strict data standards difficult. Furthermore, many aviation stakeholders continue to use legacy IT systems that were not designed to support modern data exchange protocols. Retrofitting these systems to accommodate standard formats can be technically complex and costly, requiring middleware solutions or a phased transition approach.

Another significant barrier to standardization is the variation in regional regulations imposed by different aviation authorities such as EASA, FAA, and local civil aviation agencies. These regulatory bodies define distinct requirements for maintenance records, compliance reporting, and data storage formats, necessitating a flexible approach that accommodates multiple regulatory frameworks. Additionally, concerns related to data security and confidentiality pose further challenges. Standardizing data formats requires open communication between stakeholders, yet proprietary concerns and legal restrictions, such as GDPR compliance, may limit the willingness of organizations to share and exchange sensitive data.

To address these challenges, the ATSaaS framework must implement flexible and adaptive data standardization strategies. One effective approach is the adoption of interoperability standards and API-based integration. Rather than enforcing a rigid data structure, ATSaaS can leverage widely accepted aviation data exchange protocols, such as ATA Spec 2000, S1000D, and iSpec 2200, which facilitate compatibility across different systems. APIs can further support real-time data conversion and mapping, allowing organizations to maintain their existing IT infrastructure while ensuring compliance with ATSaaS data requirements.

For organizations using legacy IT systems, middleware solutions can serve as a bridge between old and new data formats. Middleware acts as an intermediary layer that translates non-standardized data into a compatible structure, reducing the need for costly system replacements. This approach enables a gradual transition toward standardization, allowing organizations to modernize their systems at their own pace without disrupting operations.

Given the diversity of regional regulations, a hybrid data standardization model can be adopted. This model establishes a core set of standardized data fields while permitting custom extensions that accommodate region-specific compliance requirements. Such an approach ensures that stakeholders meet both international aviation standards and local regulatory obligations without compromising interoperability.

To facilitate the transition to standardized data formats, ATSaaS can introduce a phased implementation strategy. Initially, only essential data exchange requirements would be mandated, allowing organizations to integrate fundamental standardization elements into their workflows. Over time, additional layers of standardization can be introduced as stakeholders update their systems and gain familiarity with the framework.

Collaboration among industry stakeholders is also crucial in overcoming standardization barriers. The establishment of ATSaaS standardization working groups—comprising representatives from airlines, MRO providers, regulatory agencies, and software vendors—can drive the development of practical, consensus-based standardization policies. These groups can play a key role in defining best practices, resolving integration challenges, and ensuring continuous alignment with evolving industry standards.

Furthermore, automated data validation and compliance monitoring tools can be integrated into ATSaaS to enhance standardization efforts. These tools can assess incoming data against predefined standard formats, flag inconsistencies, and suggest corrective actions. By embedding automation into the data exchange process, ATSaaS can minimize errors, improve data integrity, and reduce the burden of manual verification for participants.

3. Results

3.1. Life Cycle Cost Analysis of Centralized and Decentralized Architectures in ATSaaS

When implementing ATSaaS, organizations must carefully consider the life cycle costs (LCC) of two competing system architectures: centralized and decentralized. Each approach involves different cost structures over the system’s life cycle, starting from initial development and extending to long-term operation and maintenance. The Figure 4 illustrates these differences, where $C_1\left(U_1,t\right)$ represents the life cycle cost of a centralized architecture and $C_2\left(U_2,t\right)$ represents the cost for a decentralized system over time $t$. The key turning point, labeled $T_1$, signifies when one architecture becomes more cost-effective than the other.

Figure 4 illustrates the theoretical life cycle cost dynamics of centralized and decentralized ATSaaS architectures. The curves represent the expected cost evolution over time for each architecture, considering initial investment, operational expenses, and scalability-driven cost changes. While the figure provides a conceptual visualization, the specific parameters defining the curves are derived from the model equations presented in the following section. This ensures that the cost trends align with the theoretical framework used to compare architectural approaches in ATSaaS.

A centralized architecture typically involves substantial initial investment. This includes the cost of developing a single, unified system that can manage and integrate data from all involved organizations. The design, infrastructure, and scalability requirements for such a system are significant, resulting in higher upfront costs.

Once implemented, the centralized system benefits from economies of scale. Maintenance and operational costs grow at a relatively low rate because the system is centrally managed, and efficiency improvements can be implemented across the entire network without significant additional expense. These lower incremental costs over time are represented by the relatively flat slope of $C_1\left(U_1,t\right)$ in the Figure 4.

In contrast, a decentralized architecture typically involves lower initial costs. Each participating organization develops and manages its own system, which can lead to reduced development costs compared to a large-scale centralized system. The decentralized system is more modular, making it cheaper to implement at the outset.

However, the decentralized approach results in higher operational costs as time progresses. Because each organization must maintain and update its own system independently, the cumulative costs rise more steeply over time. This is shown in the figure by the steeper slope of $C_2\left(U_2,t\right)$, indicating more intensive growth in maintenance, upgrade, and synchronization costs as time increases.

The difference in the growth patterns of operational costs between centralized and decentralized systems stems from their fundamental architectural characteristics, especially in how they handle scaling, resource utilization, and management.

In a centralized system, operational costs grow linearly due to economies of scale and centralized management. A centralized system pools resources, such as computing power and storage, into a single platform. Scaling up requires proportionally adding resources, resulting in predictable cost increases. For example, adding more users or processing additional data may only involve upgrading servers or storage infrastructure, which grows in cost linearly. Centralized management further reduces costs by enabling uniform updates, maintenance, and security measures across the entire system. The cost of managing additional users or data are predictable and grows linearly with time or workload.

In contrast, a decentralized system experiences exponential or non-linear growth in operational costs due to its inherently distributed nature. Each user (e.g., airline company) operates an independent local system, and scaling requires individual users to upgrade their systems independently. This leads to inefficiencies and redundancy, as each user must perform similar tasks, such as updates, backups, and security patches, separately. Additionally, decentralized systems face significant coordination overhead to synchronize data across independent systems, which becomes increasingly complex as the number of users grows. The cost of managing these connections increases quadratically or exponentially with the number of nodes due to the growing number of interconnections. Unlike centralized systems, decentralized systems do not benefit from economies of scale.

3.2. Life Cycle Cost-Based Decision-Making Model

The research question focuses on determining which system architecture, centralized or decentralized, is more cost-effective over its life cycle, considering initial investment, operational costs, and their dynamics over time. Below is a generalized mathematical model to address this question. The main notations are presented in the

Table 1. Main notations of the model.

Notations	Description
$U_1$	Centralized architecture
$U_2$	Decentralized architecture
$t$	Time in years
$S$	Scalability factor which represents the system’s workload or capacity (e.g., number of users, data size, or transactions)
$C_{init}$	The fixed cost incurred during system implementation
$C_{op}\left(t,S\right)$	Time-dependent costs for operating the system, influenced by scalability
$\gamma$	Scalability cost coefficient for centralized systems
$\beta$	Growth rate of operational costs in decentralized systems
$C_{init}^{\left(1\right)}, C_{init}^{\left(2\right)}$	Initial costs for centralized and decentralized architectures, respectively
${\alpha }_1,{\alpha }_2$	Base operational costs for centralized and decentralized systems, respectively
$C_{op}^{\left(1\right)}, C_{op}^{\left(2\right)}$	Operational costs for centralized and decentralized architectures, respectively
$k$	Impact of scalability on reliability in decentralized systems
$T_{max}$	Maximum allowable response time
$T_1,T_2^{base}$	Base response times for centralized and decentralized systems
$\rho$	Response time degradation rate in decentralized systems
${\mu }_1,{\mu }_2^{base}$	Base complexity factors for centralized and decentralized systems
$\lambda$	Complexity growth rate for decentralized systems
${\epsilon }_1,{\epsilon }_2$	Environmental impact factors for centralized and decentralized systems
$\psi$	Time-dependent environmental impact factor for centralized systems
${\varphi }_{max},{\chi }_{max}$	Maximum values for scalability and sustainability metrics used for normalization
$B_1,B_2$	Time-independent constants for security represent the fixed security scores assigned to the centralized and decentralized architectures, respectively

.

3.2.1. The Cost Function for Centralized Architecture

Let us make the following assumptions:

• The centralized architecture has higher initial costs due to the need for robust infrastructure to handle future scalability.
• Operational costs grow sub-linearly with scalability, as centralized systems benefit from economies of scale.

Operational cost with scalability:

$$C_{op}^{\left(1\right)}\left(t,S\right)={\alpha }_{1}t+\gamma \log S$$

Total life cycle cost:

$$C_1\left(U_1,t,S\right)=C_{init}^{\left(1\right)}+{\int }_0^t{C}_{op}^{\left(1\right)}\left(\tau ,S\right)d\tau$$

Substituting $C_{op}^{\left(1\right)}\left(t,S\right)$:

$$C_1\left(U_1,t,S\right)=C_{init}^{\left(1\right)}+{\int }_0^t\left({\alpha }_1\tau +\gamma t\log S\right)d\tau$$

Evaluating the integral:

$$C_1\left(U_1,t,S\right)=C_{init}^{\left(1\right)}+{\displaystyle \frac{{\alpha }_1{t}^2}{2}}+\gamma t\log S$$

3.2.2. The Cost Function for Decentralized Architecture

Let us make the following assumptions:

• The decentralized architecture has lower initial costs since each organization manages its own system.
• Operational costs grow super-linearly due to scalability requirements across multiple independent systems.

Operational cost with scalability:

$$C_{op}^{\left(2\right)}\left(t,S\right)={\alpha }_{2}S{e}^{\beta t}$$

where ${\alpha }_{2}S$ is linear dependence on scalability $S$, $e^{\beta t}$ is exponential growth in operational costs over time due to compounding inefficiencies in decentralized systems.

Total life cycle cost:

$$C_2\left(U_2,t,S\right)=C_{init}^{(2)}+{\int }_0^t{C}_{op}^{\left(2\right)}\left(\tau ,S\right)d\tau$$

Substituting $C_{op}^{\left(2\right)}\left(t,S\right)$:

$$C_2\left(U_2,t,S\right)=C_{init}^{\left(2\right)}+{\int }_0^t{\alpha }_{2}S{e}^{\beta t}d\tau$$

Evaluating the integral:

$$C_2\left(U_2,t,S\right)=C_{init}^{\left(2\right)}+{\displaystyle \frac{{\alpha }_2{t}^2}{\beta }}·(e^{\beta t}-1)$$

3.2.3. Point of Intersection $T_1$ (Figure 4)

To find the point $T_1$ where the two architectures have equal life cycle costs $C_1\left(U_1,t,S\right)$ and $C_2\left(U_2,t,S\right)$:

$$C_1\left(U_1,T_1,S\right)=C_2\left(U_2,T_1,S\right)$$

Substituting the cost functions:

$$C_{init}^{\left(1\right)}+{\displaystyle \frac{{\alpha }_1{T}_1^2}{2}}+\gamma T_1\log S=C_{init}^{\left(2\right)}+{\displaystyle \frac{{\alpha }_2{T}_1^2}{\beta }}·(e^{\beta T_1}-1)$$

3.3. Extended Decision-Making Model for Optimal ATSaaS Architecture Selection

Selecting the optimal architecture for ATSaaS platform requires a comprehensive evaluation of multiple criteria beyond just cost. To address this, a decision-making model is introduced in this section, using a multi-criteria decision-making (MCDM) approach. This model considers essential factors such as cost, performance, reliability, security, flexibility and scalability, control and management, and sustainability. By integrating a weighted scoring system, the model enables a structured comparison of centralized and decentralized architectures, providing a robust framework for stakeholders to identify the architecture that best aligns with their operational priorities and long-term goals.

3.3.1. Criteria and Weights for MCDM

Let $C{R}_k, k=\overline{1,7}$ represent the criteria:

$C{R}_1$—cost (total life cycle cost, including operational and scalability costs).

$C{R}_2$—performance (system efficiency and response time).

$C{R}_3$—reliability (probability of failure-free operation over time).

$C{R}_4$—security (resistance to cyber threats or breaches).

$C{R}_5$—flexibility and scalability (ease of scaling to accommodate growth and adapting to changes).

$C{R}_6$—control and management (level of control and complexity of management).

$C{R}_7$—sustainability (environmental impact and resource efficiency).

Each criterion $C{R}_k$ is assigned a weight $w_k$, where:

$${\displaystyle \sum }_{k=1}^7{w}_k=1$$

Weights reflect the relative importance of each criterion and can be adjusted based on organizational priorities.

Each architecture $U_1, U_2$ is assigned a score $S_k\left(U_j\right),j=1,2$ for each criterion $C{R}_k$. Scores are normalized to a range of $\left[0,1\right]$ with:

$S_k\left(U_j\right)=1$, if the architecture performs optimally for criterion $C{R}_k$.

$S_k\left(U_j\right)=0$, if the architecture performs poorly for criterion $C{R}_k$.

The overall performance score for architecture $U_j$ is calculated as:

$$P\left(U_j\right)={\displaystyle \sum }_{k=1}^7{w}_k·S_k\left(U_j\right)$$

The architecture with the higher score $P\left(U_j\right)$ is selected:

$$U_{opt}=arg\underset{U\in \left\{U_1,U_2\right\}}{\max }P\left(U\right)$$

The cost score is inversely proportional to the total life cycle cost:

$$S_1\left(U\right)={\displaystyle \frac{1}{1+\frac{\tilde{C}\left(U\right)}{C_{max}}}}$$

where $\tilde{C}\left(U\right)$ is total life cycle cost of architecture $U$, $C_{max}$ is maximum allowable cost.

The performance score is based on system efficiency, with lower response times achieving higher scores:

$$S_2\left(U\right)={\displaystyle \frac{1}{1+\frac{T\left(U\right)}{T_{max}}}}$$

where $T\left(U\right)$ is average response time of architecture $U$, $T_{max}$ is maximum allowable response time.

The reliability score is directly proportional to the reliability function:

$$S_3\left(U\right)=R\left(U,t\right)$$

where $R\left(U,t\right)$ is reliability of the architecture over time.

The security score depends on the level of protection against cyber threats:

$$S_4\left(U\right)={\displaystyle \frac{\sigma \left(U\right)}{{\sigma }_{max}}}$$

where $\sigma \left(U\right)$ is security score of architecture $U$, derived from assessments or audits, ${\sigma }_{max}$ is maximum achievable security score.

Flexibility and scalability score consider the ease of accommodating growth:

$$S_5\left(U\right)={\displaystyle \frac{\varphi \left(U\right)}{{\varphi }_{max}}}$$

where $\varphi \left(U\right)$ is scalability factor of architecture $U$, ${\varphi }_{max}$ is maximum achievable scalability score.

The control and management score reflect the ease of system administration:

$$S_6\left(U\right)={\displaystyle \frac{{\mu }_{min}}{\mu \left(U\right)}}$$

where $\mu \left(U\right)$ is complexity of managing architecture $U$, ${\mu }_{min}$ is minimum complexity, representing the simplest management.

The sustainability score reflects the environmental efficiency of the system:

$$S_7\left(U\right)={\displaystyle \frac{{\chi }_{max}}{\chi \left(U\right)}}$$

where $\chi \left(U\right)$ is environmental impact (e.g., carbon emissions and resource consumption) of architecture $U$, ${\chi }_{max}$ is maximum allowable environmental impact.

3.3.2. Extended Decision-Making Model with Dynamic Indicators for the System Life Cycle

To account for the possibility of changing indicators during the system life cycle, the proposed multi-criteria decision-making model can be extended to include time-dependent criteria and weights. This dynamic approach allows the model to reflect variations in costs, performance, reliability, security, scalability, control, and sustainability over time, ensuring a more realistic evaluation of centralized and decentralized architectures.

Let each criterion $C{R}_k$ depend on time $t$, such that $C{R}_k=C{R}_k\left(t\right)$. Correspondingly, the score $S_k\left(U\right)$ for each architecture $U$ and criterion $C{R}_k$ also becomes time dependent:

$$S_k\left(U\right)=S_k\left(U,t\right)$$

where $S_k\left(U,t\right)$ is the evaluation function for criterion $C{R}_k$ at time $t$.

For example, cost may increase with operational and scalability costs over time, reliability may degrade due to aging infrastructure or increased complexity.

Weights $w_k$ can also vary over time to reflect changing priorities. Define $w_k\left(t\right)$ as the weight of criterion. $C{R}_k$ at time $t$:

$${\displaystyle \sum }_{k=1}^7{w}_k\left(t\right)=1$$

For example, early in the system life cycle, cost $(w_1)$ may dominate as initial investments are critical, later, scalability $(w_5)$ and sustainability $(w_7)$ may become more important as the system expands and environmental concerns grow.

The time-dependent overall performance score for architecture $U$ becomes:

$$P\left(U,t\right)={\displaystyle \sum }_{k=1}^7{w}_k\left(t\right)·S_k\left(U,t\right)$$

The architecture is selected based on the time-averaged performance over the system’s life cycle $\left[0,T\right]$:

$$\overline{P}\left(U\right)={\int }_0^{T}P\left(u,t\right)dt$$

The optimal architecture is:

$$U_{opt}=arg\underset{U\in \left\{U_1,U_2\right\}}{\max }\overline{P}\left(U\right)$$

For each criterion $C{R}_k$ the score $S_k\left(U,t\right)$ is modeled to reflect changes over time. Examples include in the

Table 2. Examples for time-dependent evaluation functions for each criterion.

Criteria	Centralized System	Decentralized System
$\mathrm{Cost} C{R}_1\left(t\right)$	$S_1\left(U_1,t\right)={\displaystyle \frac{1}{1+\frac{{\tilde{C}}_1\left(U_1,t\right)}{C_{max}}}}$ ${\tilde{C}}_1\left(U_1,t\right)=C_{int}^{\left(1\right)}+{\displaystyle \frac{{\alpha }_1·t^2}{2}}+\gamma ·\log S·t$	$S_1\left(U_2,t\right)={\displaystyle \frac{1}{1+\frac{{\tilde{C}}_2\left(U_2,t\right)}{C_{max}}}}$ ${\tilde{C}}_2\left(U_2,t\right)=C_{int}^{\left(2\right)}+{\displaystyle \frac{{\alpha }_2·S}{\beta }}·\left(e^{\beta t}-1\right)$
$\mathrm{Performance} C{R}_2\left(t\right)$	$S_2\left(U_1,t\right)={\displaystyle \frac{1}{1+\frac{T_1}{T_{max}}}}$	$S_2\left(U_2,t\right)={\displaystyle \frac{1}{1+\frac{T_2^{\left(t\right)}}{T_{max}}}}$ $T_2\left(t\right)=T_2^{base}+\rho ·S·t$
$\mathrm{Reliability} C{R}_3\left(t\right)$	$S_3\left(U_1,t\right)={\displaystyle \frac{1}{1+{\delta }_1·t}}$	$S_3\left(U_2,t\right)={\displaystyle \frac{1}{1+{\delta }_2·t+k·S}}$
$\mathrm{Security} C{R}_4\left(t\right)$	$S_4\left(U_1,t\right)=B_1$	$S_4\left(U_2,t\right)=B_2$
$\mathrm{Scalability} C{R}_5\left(t\right)$	$S_5\left(U_1,t\right)={\displaystyle \frac{\log S}{{\varphi }_{max}}}$	$S_5\left(U_2,t\right)={\displaystyle \frac{S{e}^{\beta t}}{{\varphi }_{max}}}$
$\mathrm{Control} \mathrm{and} \mathrm{Management} C{R}_6\left(t\right)$	$S_6\left(U_1,t\right)={\displaystyle \frac{1}{1+{\mu }_1}}$	$S_6\left(U_2,t\right)={\displaystyle \frac{1}{1+{\mu }_2\left(t\right)}}$ ${\mu }_2\left(t\right)={\mu }_2^{base}+\lambda ·S·t$
$\mathrm{Sustainability} C{R}_7\left(t\right)$	$S_7\left(U_1,t\right)={\displaystyle \frac{1}{1+\frac{{\epsilon }_1·S+\psi ·t}{x_{max}}}}$	$S_7\left(U_2,t\right)={\displaystyle \frac{1}{1+\frac{{\epsilon }_2·S^2·t}{x_{max}}}}$

.

The decision-making algorithms includes the next steps:

• Define life cycle horizon $T$.
• Input time-dependent parameters $w_k\left(t\right)$ and $S_k\left(U,t\right)$.
• Calculate time-dependent scores $P\left(U,t\right)$.
• Calculate the average performance score for each architecture $\overline{P}\left(U\right)$.
• Choose the architecture with the higher $\overline{P}\left(U\right)$.

This extended model captures dynamic changes in costs, reliability, scalability, and other criteria throughout the system’s life cycle. By incorporating time-dependent weights and indicators, the model allows for a more realistic and flexible decision-making process, ensuring that the selected architecture aligns with evolving priorities and conditions.

4. Discussion

4.1. Numerical Example for Life Cycle Cost-Based Decision-Making Model

This section presents an example of how to analyze and compare the life cycle costs of centralized and decentralized architectures using specific input data. The analysis demonstrates the practical application of the mathematical models discussed earlier and illustrates the decision-making process based on operational costs, initial investments, and scalability requirements. By simulating real-world scenarios with predefined parameters, the example provides a clear understanding of how the two architectures perform over time and under varying conditions.

The calculation for this example is based on the model presented in Section 3.2, using the following input data: $C_{init}^{\left(1\right)}=\mathrm{1,200,000} \mathrm{USD}$; $C_{init}^{\left(2\right)}=\mathrm{800,000} \mathrm{USD}$; ${\alpha }_1=\mathrm{70,000} \mathrm{USD}/\mathrm{year}$; ${\alpha }_2=\mathrm{120,000} \mathrm{USD}/\mathrm{year}$; $\beta =0.05$; $\gamma =\mathrm{20,000}$ USD/log-unit; $S=500$, e.g., users or transactions.

The Figure 5 illustrates the cumulative costs of centralized and decentralized system architectures over a 20-year period, providing insights into the decision-making process for choosing between the two.

The Figure 5 compares the total costs over time between centralized and decentralized architectural approaches. The break-even point occurs at approximately 6 years. Initially, the decentralized architecture has a lower total cost due to its smaller initial investment. However, due to the exponential growth of operational costs in the decentralized approach, it eventually becomes more expensive than the centralized solution. By year 20, there is a significant cost difference favoring the centralized approach due to the exponential growth of decentralized operational costs.

Scalability plays a critical role in this decision. As scalability requirements grow, the decentralized system becomes increasingly inefficient due to its exponential cost growth. In contrast, the centralized system handles scalability more predictably, making it the better option for operations expected to scale significantly.

4.2. Extended Decision-Making Model with Adaptive Indicators for the System Life Cycle

This section presents a numerical case study to demonstrate the application of the extended decision-making model with Adaptive indicators for the system life cycle. This model evaluates centralized and decentralized architectures for ATSaaS platform by incorporating multiple time-dependent criteria. Unlike traditional cost-focused models, this extended framework considers a comprehensive set of factors: cost, performance, reliability, security, flexibility and scalability, control and management, and sustainability.

This case study presents a comprehensive evaluation methodology for comparing centralized and decentralized IT architectures across a 15-year operational period. The analysis employs seven key performance indicators with a dynamic weighting system that evolves over time, reflecting changing priorities between early deployment (≤5 years) and long-term operation (>5 years). The evaluation framework considers cost efficiency, performance, reliability, security, scalability, control and management, and sustainability. Each criterion is assessed using specific mathematical functions described in Section 3.3 that model the behavior of both architectural approaches over time.

The analysis integrates initial deployment conditions with a 300-unit system scale and incorporates time-dependent factors affecting each criterion. The dynamic weight distribution shifts at the 5-year mark, acknowledging that organizational priorities and system requirements change as the deployment matures. This approach enables a more nuanced understanding of each architecture’s strengths and weaknesses across different operational phases.

Table 3. Weight distribution by time period.

Criterion	Weight (≤5 Years)	Weight (>5 Years)
Cost (w1)	0.35	0.20
Performance (w2)	0.10	0.25
Reliability (w3)	0.10	0.20
Security (w4)	0.05	0.15
Scalability (w5)	0.30	0.10
Control and Management (w6)	0.05	0.05
Sustainability (w7)	0.05	0.05
Total	1.00	1.00

and

Table 4. Initial parameters by criterion.

Criterion	Parameter Type	Centralized (U1)	Decentralized (U2)
Cost	Base Cost	1,200,000	800,000
	Time Factor	70,000 × t2/2	Growth rate: 0.08
	Scale Factor	50,000 × ln(300) × t	(100,000 × 300/0.08)
Performance	Response Time	0.5	1.0
Reliability	Time Degradation	0.01 t	0.02 t
	Scale Impact	-	0.001 × 300
Security	Fixed Score	0.9	0.8
Scalability	Scale Factor	ln(300)/10	300 × [exp(0.08 × t)]/5000
Control	Complexity Factor	0.5	1.0
Sustainability	Base Impact	10,000 × 300	-
	Time Impact	5000 t	20,000 × 300 t

present the initial parameters, weighting distributions, and scoring functions used in the analysis.

The Figure 6 illustrates the comparative performance of both architectures over the entire evaluation period. The calculation demonstrates how individual criteria contribute to the overall assessment scores, ultimately revealing the conditions under which each architectural approach proves more advantageous.

The Figure 6 illustrates the comparative performance evaluation of centralized and decentralized architectures over a 15-year period using a dynamic weighting method. The graph demonstrates three distinct phases in the architectural performance comparison:

• Initial phase (years 1–5) where the decentralized architecture maintains a superior score around 0.57 while the centralized solution remains stable at approximately 0.50;
• Transition phase (years 6–8) showing a significant improvement in centralized architecture’s performance, crossing over the decentralized architecture’s score;
• Maturity phase (years 9–15) where the centralized solution continues to improve gradually, reaching a score of 0.62, while the decentralized approach stabilizes at approximately 0.58.

This behavior reflects the impact of the dynamic weight redistribution at the 5-year mark, which shifts emphasis from initial deployment priorities to long-term operational considerations, ultimately favoring the centralized architecture in the later years of system operation.

4.3. Extending the Model by Integrating Additional Factors for Comprehensive ATSaaS Evaluation

While the cost analysis of centralized and decentralized architectures provides valuable insights into the financial implications of implementing ATSaaS, a holistic evaluation requires consideration of additional critical factors. These include user experience, scalability in dynamic technological environments, and the qualitative aspects of stakeholder satisfaction and ease of use. Ignoring these dimensions may limit the practical applicability and adoption of the ATSaaS model.

The usability of ATSaaS platforms is paramount for ensuring widespread adoption among small airlines and their partners. User-friendly interfaces, intuitive workflows, and responsive support services are essential to minimizing resistance and fostering trust within the ecosystem. Future designs of ATSaaS platforms should incorporate feedback from end-users, including airline operators, maintenance personnel, and regulatory agencies, to ensure the platform meets their specific needs and expectations. A positive user experience not only enhances operational efficiency but also builds stakeholder confidence in the system.

The scalability of ATSaaS platforms is crucial for accommodating growth in the aviation sector, such as increased fleet sizes or expanded service networks. Centralized architectures typically handle scalability with predictable cost growth, while decentralized systems may struggle with compounding inefficiencies as the number of stakeholders increases. Future studies should explore hybrid architectures or modular design principles that balance scalability with performance and cost efficiency.

4.4. Cybersecurity Risks and Mitigation Strategies for ATSaaS Architectures

Ensuring cybersecurity in the ATSaaS ecosystem is critical, as both centralized and decentralized architectures present unique security challenges that could impact system integrity, data confidentiality, and operational reliability. The interconnected nature of ATSaaS, involving multiple stakeholders, cloud-based platforms, and real-time data exchange, increases the risk of cyber threats such as data breaches, unauthorized access, malware attacks, and system vulnerabilities.

A centralized ATSaaS architecture consolidates data processing, storage, and security governance within a single infrastructure, enabling consistent security management. However, this model introduces specific cybersecurity risks. A single point of failure is a major concern, as a cyberattack targeting the central platform such as a distributed denial of service attack or ransomware could disrupt all ATSaaS operations, preventing multiple airlines and service providers from accessing critical maintenance data. Moreover, data breaches and insider threats pose a significant risk, as storing all sensitive aviation data in one repository increases the potential impact of an attack. If compromised, maintenance records, flight logs, and operational data could be leaked or manipulated. Unauthorized access and privilege escalation vulnerabilities further threaten data integrity, where an attacker could gain access to privileged systems and modify or delete critical records. Additionally, regulatory compliance risks arise, as centralized systems must adhere to strict international cybersecurity frameworks such as GDPR, ISO/IEC 27001, and NIST, requiring extensive security controls to ensure compliance.

To mitigate these risks, centralized ATSaaS platforms must implement redundant and distributed backup systems to ensure business continuity in the event of an attack. The adoption of a zero-trust security model with multi-factor authentication, strict role-based access control, and continuous user behavior monitoring can reduce the risk of unauthorized access. Moreover, data encryption and secure communication protocols, such as AES-256 encryption for data at rest and TLS 1.3 for data in transit, can safeguard sensitive information from interception. AI-driven intrusion detection systems that monitor real-time traffic and detect anomalies indicative of cyberattacks can further enhance security and incident response.

A decentralized ATSaaS architecture distributes data management across multiple participants, reducing the risk of a single catastrophic failure. However, it introduces other security vulnerabilities. The inconsistent security controls among stakeholders create weak links that attackers can exploit, as different organizations may apply varying levels of cybersecurity protection. Additionally, the increased attack surface makes the system more vulnerable to man-in-the-middle attacks, as each decentralized node represents a potential entry point for cyber threats. Complex identity management across multiple independent systems also increases the risk of credential leaks and identity spoofing, making secure authentication challenging. Furthermore, data synchronization and integrity issues arise, as ensuring real-time consistency of security patches and updates across multiple stakeholders can be difficult, potentially allowing data tampering or outdated security measures to persist.

To enhance cybersecurity in decentralized ATSaaS systems, blockchain-based data integrity solutions can be implemented, ensuring that data remain immutable across decentralized participants. Federated Identity Management using single sign-on can streamline access control while maintaining robust security. Additionally, decentralized threat intelligence sharing among ATSaaS participants can facilitate early detection and response to emerging cyber threats, while secure gateways and endpoint protection solutions at each decentralized node can prevent unauthorized access and mitigate the risk of cyberattacks.

A comparison of cybersecurity risks highlights the fundamental differences between centralized and decentralized architectures (

Table 5. Comparative analysis of cybersecurity risks in ATSaaS architectures.

Security Factor	Centralized ATSaaS	Decentralized ATSaaS
Risk of Single Point of Failure	High (centralized attack risk)	Low (distributed architecture)
Data Breach Impact	High (large-scale data exposure)	Medium (localized breaches)
Access Control Complexity	Low (centralized role management)	High (multi-organization identity control)
Regulatory Compliance	Easier (centralized security standards)	Harder (varying regional security policies)
Attack Surface	Limited (one main entry point)	Large (multiple independent entry points)
Data Integrity and Consistency	Strong (controlled updates)	Weak (potential synchronization issues)

). Centralized systems face a higher risk of a single catastrophic failure and large-scale data breaches but benefit from easier access control management and regulatory compliance. Decentralized systems, on the other hand, distribute risk across multiple nodes, making them less vulnerable to a single attack, but introduce greater complexity in managing security policies and ensuring consistent data integrity across stakeholders.

Given the distinct security risks in both architectures, a hybrid cybersecurity approach may be the most effective solution for ATSaaS implementation. This approach could combine centralized security oversight with decentralized resilience, ensuring robust security governance while allowing flexibility for individual stakeholders. A federated cybersecurity governance model would enable centralized enforcement of security policies while granting localized security autonomy to different ATSaaS participants. Collaboration with aviation cybersecurity organizations, such as EASA’s Cybersecurity Strategy and FAA Cybersecurity Programs, can further align ATSaaS security measures with industry best practices. Additionally, continuous threat assessment and AI-driven adaptive security frameworks can dynamically respond to evolving threats, ensuring proactive risk mitigation and maintaining system resilience.

By integrating these cybersecurity principles into the ATSaaS framework, both centralized and decentralized architectures can achieve a secure, reliable, and resilient technical support system for aviation stakeholders. Addressing cybersecurity risks from the early stages of ATSaaS implementation is essential for ensuring long-term sustainability and trust within the industry.

4.5. Limitations of This Study

This study provides important insights into the implementation of Aviation Technical Support as a Service (ATSaaS) for small airlines, particularly the comparison of centralized and decentralized data conversion architectures. However, it has several limitations that must be acknowledged.

The research is primarily conceptual, relying on theoretical models and generalized assumptions to evaluate the life cycle costs of the two architectures. While the mathematical framework offers a solid basis for analysis, real-world validations and empirical data are limited.

This study assumes uniform adherence to data standards and protocols across stakeholders in the ATSaaS ecosystem. In practice, achieving such standardization can be challenging due to variations in organizational capabilities, legacy systems, and regional regulations.

This study does not address potential cybersecurity risks inherent in both centralized and decentralized systems.

Addressing these limitations in future research through real-world pilots, stakeholder engagement, and a broader exploration of operational and security challenges will enhance the robustness and practical relevance of the findings.

4.6. Future Research Directions

Future research on ATSaaS should aim to address the limitations identified in this study and explore new dimensions to enhance its feasibility, scalability, and impact. One key direction is conducting empirical validations through pilot implementations in diverse operational contexts. This would involve collaborating with small airlines, maintenance providers, and regulatory bodies to gather real-world data and refine the theoretical models presented. Such practical applications would help uncover challenges related to stakeholder coordination, system integration, and the adoption of standardized data protocols. Existing studies on aviation technical support platforms (e.g., predictive maintenance systems such as Airbus Skywise and Boeing AHM) focus on large-scale operators, with limited consideration of scalable, cost-efficient service models for small airlines. Future research should involve pilot implementations of ATSaaS, allowing for data collection, performance assessment, and refinement of service models in diverse operational environments.

Another critical area for exploration is the incorporation of advanced technologies such as artificial intelligence, blockchain, and the Internet of Things. These technologies could significantly enhance data processing, predictive maintenance, and cybersecurity in both centralized and decentralized ATSaaS architectures. Research should evaluate how these innovations can improve operational efficiency and reliability while maintaining cost-effectiveness.

Future studies should also investigate hybrid architectural models that combine the strengths of centralized and decentralized approaches. For example, a hybrid model could centralize data validation while allowing decentralized data conversion at the stakeholder level, balancing flexibility and consistency. Additionally, sensitivity analyses could be expanded to account for variations in regulatory requirements, technological maturity, and economic conditions across different regions and airlines.

Future studies should also investigate contractual and economic models for ATSaaS adoption. The cost-sharing mechanisms, service-level agreements, and regulatory compliance frameworks for ATSaaS have yet to be fully explored. Previous research on Software-as-a-Service (SaaS) models in aviation has demonstrated the benefits of subscription-based services but has not evaluated customized pricing models based on airline size, operational complexity, and real-time service demands. A more in-depth economic analysis would help determine the most viable business models for widespread industry adoption.

The human and organizational factors influencing ATSaaS adoption warrant deeper examination as well. Research could explore the training needs, resistance to change, and collaborative dynamics among stakeholders within the ATSaaS ecosystem. Understanding these factors will be crucial for designing systems that are not only technically robust but also user-centric and widely adoptable.

By addressing these areas, future research can further advance the ATSaaS framework, making it a transformative solution for small airlines and the broader aviation industry.

5. Conclusions

This study explores the potential of ATSaaS as an innovative solution to address the unique challenges faced by small airlines. By offering a scalable, collaborative, and technology-driven framework, ATSaaS enables these carriers to access high-quality technical expertise, streamline operations, and achieve cost efficiencies. The research specifically examines two architectural approaches—centralized and decentralized—for data integration and conversion, analyzing their respective advantages, disadvantages, and life cycle costs.

The findings highlight the importance of aligning architectural choice with the operational needs, scalability requirements, and resource availability of small airlines. Centralized architectures, while involving higher initial costs, benefit from economies of scale, streamlined management, and consistent data handling. In contrast, decentralized systems offer greater flexibility and real-time capabilities but incur higher operational costs over time due to their fragmented structure and coordination complexity.

This study acknowledges several limitations, including its reliance on theoretical models and hypothetical data. These constraints underline the need for further empirical research to validate the proposed frameworks and address critical issues such as cybersecurity, stakeholder collaboration, and sustainability. Additionally, the integration of emerging technologies like AI and IoT presents promising opportunities to enhance the effectiveness of ATSaaS.

ATSaaS represents a transformative approach to supporting small airlines in overcoming their operational challenges and competing in an increasingly demanding aviation market. By addressing the limitations and pursuing the outlined research directions, this model has the potential to revolutionize the technical support landscape, contributing to a more efficient, safe, and sustainable aviation industry.