English
FrançaisJoin us at a 2026 Aras Connect event near you!
Summary
Aerospace and Defense (A&D) companies need to be more responsive to rapidly changing geopolitical environments and emerging technological demands than any other industry. There is no anticipating what tomorrow’s demands will require. While these companies need to operate with tremendous agility, they also have the most highly regulated development cycles in terms of validation, security, compliance, and documentation.
To increase development agility, companies need enterprise software that allows them to pivot quickly to fit their increasingly changing needs. Yet, their engineering software ecosystem remains dated in many areas. Replacing systems is often not feasible during a running program, and strict data management practices make it unrealistic to sunset older, marginally functional systems of record. However, planning next generation programs offers an opportunity to adopt a more agile, open software platform that facilitates the increasing complexity of modern designs. The single vendor ecosystem is not tenable. Today’s A&D companies rely on a large variety of tools and systems that need to work in harmony to achieve overall program objectives. The balance between agility and compliance is key to program success.
Aerospace and Defense programs often rely on maintaining legacy technology to provide a record of the historical development process as long as an asset is in service. These legacy systems are maintained with great effort and considerable expense. However, older systems often have rigid architecture that cannot be configured rapidly enough to support the emerging, unanticipated requirements necessary to enable modern design practices. An ideal solution is to adopt an open product development platform that can integrate with any data from various previous programs along with enabling an agile product development environment for current and future programs.
An open, resilient architecture enables organizations to implement change incrementally. It can synchronize data from old systems while those systems continue to meet the business needs of the company, while addressing new requirements with simple configuration, and incremental deployment. Agile and open platforms that manage hardware, software, and electronics are necessary to complement, extend, and replace core systems that are already in place.
Challenges for the Aerospace and Defense Industry
A&D projects have always been on the cutting edge of what science can begin to imagine. The requirements of these programs evolve rapidly and often continue to develop as the project matures. The nature of these programs requires increasingly complex design of interconnected systems of hardware, electronics, and software while targeting a moving baseline for delivery. Additionally, the rapid evolution of scientific discovery requires a flexible environment for types of collaboration that haven’t been conceptualized previously.
Consumer demands are unpredictable and the characteristics of future military missions are impossible to accurately predict. While strategic fleet planning tries to anticipate the nature of future armed conflicts, there are only so many scenarios that can be projected. Rarely do these evolving missions directly reflect tested scenarios—rather, they rely on rapid product development or asset modification. This is not possible without flexible product development techniques. Quickly reacting to changing requirements is difficult with rigid product development systems that do not adapt along with the needed end product.
Traceability of complex decision-making processes adds an additional challenge to these cutting-edge programs. A common thought is that the ideal solution to this is a single database that can maintain all design related data. However, this has proven to be impractical to implement as different design disciplines have various operating requirements and require different tools to function. Design silos are very real. Traditional PLM systems have fought to control all aspects of the design process, but the reality is that they cannot effectively manage all of the design tools that various disciplines rely on and design data often becomes fragmented. Without an open, integrated design ecosystem there is no true digital thread.
Aside from the growing demands for interdisciplinary collaboration, programs are often codeveloped with a highly complex network of suppliers. Manufacturers’ IT systems must share data efficiently, while guaranteeing the necessary traceability and security of intellectual property throughout the lifecycle of the asset. While aerospace and defense industry leaders have sought to standardize common ways to exchange data along the supply chain, many PLM systems have not adapted their architecture to enable open integration.
Increasingly, customers for these assets are demanding the delivery of the full digital model used for manufacturing along with the physical asset. The absence of a unified, integrated, multidisciplinary product development platform makes this handoff difficult and often incomplete. These large, complicated data models are also quite difficult for the customer to ingest into a format useful for future development or maintenance operations.
Systems Engineering
Model Based Systems Engineering (MBSE) is critical to increasingly complex A&D programs but the way systems are modeled is also increasingly challenging. Over time, modeling of specific domains, mechanical, electrical, software, is understood but they are all done in various ways with different methodologies. Recognizing that various design disciplines have different needs and techniques is essential, but they need to converge around a unified systems model. Various disciplines have their own cadence of design iterations, but ultimately, they need to be released in concert with the master system model.
Today’s A&D programs are complex systems of systems that require more sophisticated techniques than traditional engineering methodologies. Many legacy PLM/PDM tools that evolved out of the need to manage mechanical components simply cannot manage this complexity while maintaining the flexibility necessary for digital evolution.
While it is necessary to acknowledge that various disciplines have different needs for systems models, a unified system of change management and configuration management tools are essential to ensure that systems work correctly together. The interface between disciplines is notoriously the cause of major failures due to properties that emerge as the result of unanticipated systemic interactions. According to investigators, the Boeing 737 Max failure of 2019 occurred as the result of nine different contributing causes, none of which individually would have been catastrophic. A single platform that looks at the entire model from requirements to design and through to manufacturing and maintenance is necessary to identify and mitigate these risks.
The need for a centralized systems model does not stop with the production and delivery of an asset. Systems models continue to evolve well into the maintenance and sustainment phases. These models can even be designed on existing assets for accurate maintenance. For example, maintenance on a B52 aircraft in operation. While first designed in 1952, it still requires a basic systems model to ensure that components interact properly with each other.
Multidisciplinary Collaboration
Interdisciplinary, collaborative processes are more important than ever across all aspects of the design stages. Companies can no longer afford to cascade development from one discipline’s silo to the next. Concurrent engineering has become an absolute necessity.
As the need for maintaining relationships between disciplines, early visibility, and ad hoc collaboration grows, a single, integrated data representation of the emerging design and changing requirements is increasingly necessary. At the same time, data in all its forms—documents, decisions, changes, configuration, specifications, statuses, etc.—needs to flow effortlessly from the first requirements, to engineering and production, all the way through to maintenance and end of life.
A bill of materials is no longer just a list of parts, but also contains crucial software components that have complex interdependencies with hardware that needs to be tracked and managed cohesively through an integrated change management system.
Still, the IT landscape of the A&D industry remains outdated in many areas. Legacy systems must be maintained and operated, often with great effort and considerable expense; however, these systems are still integral to the continued development of programs as well as legacy data reuse. Ideally, data management systems that can extend and complement these systems through data federation until the system itself can be rebuilt on a modern architecture, will ensure that development can continue uninterrupted. Furthermore, if these data management systems possess a capability that enables continuous integration, where development of new features and applications can always be integrated into existing applications with little to no interruption, it will lead to increased productivity and, ultimately, benefit end-users.
The Connected Enterprise
Many software vendors talk about their systems as a single source of truth, but realistically the IT ecosystem at a typical company is a conglomeration of separate tools supporting various functions. This “source of truth” is not a single vault or database, but rather a tightly integrated conglomeration of tools that perform best in the areas they support. For this to work, it is necessary for a PLM platform to be based on open data and transparent APIs and a variety of connectors that serve as the crucial backbone with a strategy of federating the data needed by various domains.
A unified product development platform that reaches across disciplines and interfaces easily with all of the domain specific tools is essential. However, disruption caused by switching product development systems can be lengthy, expensive, and highly demanding of internal resources. In the time it takes to implement many systems, they are already addressing yesterday’s needs. This is where an incremental approach to IT system design can solve many problems before they happen. Rather than ripping out and replacing all of the critical systems at once, new systems must work in tandem with legacy systems until a time when the old system can be replaced with minimal disruption to the business.
Digital Thread, Digital Twin
As the product history is captured throughout the product development process, this becomes the digital thread. For a digital thread to be robust, it must record dependencies captured throughout the entire lifecycle—not starting and stopping at the design phase, as often happens. Version histories, engineering change order specifics, and testing data must easily line up with cataloged and maintained simulation data. In today’s environment, it is essential that system requirements, software, part version histories, hardware dependencies, and simulation validation weave through the thread as well—often in ways that are not traditional in many systems.
As a product progresses throughout its lifecycle, a data driven, virtual representation is created to form a digital model. The model-based enterprise thrives in this environment as the 3D geometry and Product Manufacturing Information (PMI) become the master representation of the design, accompanied by the related metadata. However, calling this representation a twin at this point is a common mistake. Initially the digital data represents the “as designed” configuration including hardware, software, and firmware. As the product is built, each unit needs a unique dataset to serve as a twin—incorporating manufacturing data such as part serial numbers, lot effectivity, or deviation reports—resulting in an “as built” configuration.
No two assets in the A&D industries are identical, and the configuration of each individual unit must be captured as it is built. Essentially, a conceptual engineering design gives birth to multiple, slightly different units. As the product is launched into the field, that asset is unique. The data that defines that unit evolves and must be managed separately from the conceptual model. As long as these physical assets are in service—which could be over the course of decades—they need to be managed, on an individual basis, by maintenance and repair operations teams.
Even minor differences in an asset are compounded dramatically once the asset is launched into service. Replacement parts and software versions continue to change quickly as the asset is maintained and the new, true digital representation is distinctly different from the early conceptual model. Understanding the actual “as maintained” digital configuration of every asset in the field is imperative in situations where field maintenance is not performed centrally. In situations that require dispatching replacement parts to the field quickly it is essential to send the right parts the first time to avoid unnecessary delay to mission critical operations.
Down time for these assets is generally unacceptable, which increases the need for predictive and regularly scheduled maintenance. Increasingly, digital and remote sensors are playing a part in determining the performance characteristics of crucial parts, ensuring that maintenance is done as needed, rather than as scheduled, reducing operating costs and minimizing downtime. This new world of predictive analytics is shaping the development of products while requiring increases in centralized quality analytics and failure analysis.
The Role of a Product Development Platform
When selecting an optimal product development collaboration platform, A&D companies must focus on enterprise change management that spans the breadth of data coming from various disciplines.
| Platforms must have: | Platforms cannot be limited by: |
|---|---|
| Transparent & Interrogatable APIs | Proprietary APIs |
| Full API Capabilities Exposed | Proprietary Data Models |
| Open Data Model | Static/Hard Coded Data Model |
| Dynamic Data Model | Obfuscated Data |
| Open Data Access |
Product development systems are not to be confused with the applications necessary to support them. Most PLM tools are limited to engineering collaboration. Even then, the focus is largely on the traditional mechanical space. An ideal product development platform has certain aspects that are necessary to run a nimble process.
The platform must be:
- Adaptable to changing business processes supporting rapidly changing customer needs
- Customizable to work the way you want rather than the way the system is hardcoded to function
- Open and transparent to enable cross functional collaboration and end-to-end visibility with traceability and integration to legacy systems
- Evolutionary design, built to adapt and change in an agile manner, and open, to easily meet future needs that are not yet apparent
In order to address constantly changing customer, regulatory, and economic requirements a product development platform must be ready to evolve quickly. The Aras environment is built for customization. The industrial low-code platform provides an open, transparent, and multifunctional collaboration hub that’s needed for today’s agile product development process. The capability for low-code development assures A&D companies that their tools and systems will evolve with business needs rather than being stuck at a single point in time.