AS9100 does not define a specific aircraft software configuration management (CM) method, but it does expect you to have a documented, effective, and auditable process for controlling software that affects product conformity, airworthiness, or safety. In practice, that means treating software and its associated data as configuration-controlled product, tightly integrated with your overall configuration management and change control processes.
What AS9100 actually expects (at a high level)
Across its configuration management, design & development, and production control clauses, AS9100 expects you to:
- Identify software as configuration items with unique identifiers (part numbers, software loadable unit IDs, or equivalent), including version, build, and applicable aircraft or LRU/line-replaceable unit.
- Define a configuration baseline for software at appropriate levels (e.g., LRU, system, aircraft) that includes the approved software version and any required data (parameters, databases, documentation).
- Control changes to software using formal change control: impact assessment, approval, verification/validation evidence, and documented release authorization.
- Maintain traceability from released software to requirements, changes, problem reports, test evidence, and the specific hardware/aircraft where it is installed.
- Control interfaces to external authorities and customers, including how you receive approved software, distribute it, and demonstrate control to auditors, customers, and regulators when requested.
AS9100 allows flexibility in how you implement this, but expects the process to be consistent, documented, and demonstrably effective.
Key elements of aircraft software configuration management
In regulated aerospace environments, a conforming approach typically includes the following components:
- Configuration item (CI) definition
Clear criteria for when software or data is treated as a CI (e.g., flight controls, avionics, engine control software, configuration files that influence performance or safety). Each CI should have defined ownership, required documentation, and change routes.
- Unique identification and versioning
Each software CI is uniquely identified and versioned so you can answer, for any aircraft or LRU: exactly which software revision is installed, and which documentation and test evidence applies.
- Baseline management
Documented baselines (e.g., aircraft-level configuration, LRU-level configuration) that specify the valid combinations of software, hardware, and data. You must control who can change these baselines and how those changes are authorized and recorded.
- Controlled build and release process
Repeatable, documented processes for building, testing, and releasing software. This includes build environment control, verification/validation steps, and formal release approval prior to distribution or installation on aircraft.
- Installation and removal control
Procedures and records ensuring that only approved software is installed, and that field changes (updates, downgrades, patches) are logged against the correct tail number, serial number, or LRU.
- Problem report and change linkage
Non-conformances, field issues, and problem reports linked to specific software configurations and changes. Your CAPA/NCR workflows should reference the specific software versions involved.
How this works in brownfield system landscapes
AS9100 does not require you to replace existing MES, ERP, PLM, or MRO systems. In most mature aerospace environments, software configuration data is distributed across several systems:
- PLM / PDM holding the design definition, software part numbers, effectivity, and baselines.
- QMS managing change control, approvals, and problem reports/CAPA.
- ERP holding part masters and sometimes high-level configuration or effectivity logic.
- MES / execution systems managing installation, shop-floor instructions, and as-built / as-maintained records.
- MRO / fleet systems tracking tail-number configuration, service bulletins, and maintenance actions.
AS9100 expects you to define and control the interfaces between these systems so configuration data is consistent and traceable. Full replacement of one system with another often introduces more risk than benefit in the short term, given:
- Qualification and validation burden for tools used in safety-related contexts and regulated environments.
- Downtime risk if configuration or as-maintained history is disrupted during cutover.
- Integration complexity when multiple airframers, suppliers, and authorities are involved.
- Long asset lifecycles that require preserving legacy configuration data and formats for decades.
Incremental integration and clear data ownership is typically more realistic than a single “system of everything.”
Traceability expectations
Although AS9100 is not as prescriptive as certification standards (e.g., DO-178C), it expects software configuration to be traceable enough to answer questions like:
- Which software version is installed on this aircraft, LRU, or serial number today?
- What changes were made between version A and B, and which approvals and tests support that change?
- Which aircraft or parts are affected by a software defect, service bulletin, or airworthiness directive?
- Can you reconstruct the configuration at a past point in time, including for incident/accident investigation or audit?
Your CM records, change logs, and as-maintained data must be reliable enough to support these questions, and you must be able to demonstrate this with objective evidence.
Change control and risk
AS9100 links software CM to risk-based thinking. For safety- or airworthiness-related software, you are expected to:
- Assess the potential impact of each change on safety, performance, and regulatory obligations.
- Scale verification/validation and independent review according to risk.
- Ensure that configuration changes are coordinated across software, hardware, documentation, and maintenance instructions.
- Control emergency patches and temporary workarounds with the same rigor as planned changes.
The standard does not define specific test coverage or analysis methods, but it expects your internal rules to be defined, consistently applied, and auditable.
Practical constraints and dependencies
How you implement aircraft software CM under AS9100 will depend heavily on:
- Your role in the ecosystem (OEM, Tier 1, MRO, operator, or component supplier) and which party owns design authority for the software.
- Existing tools and data quality in PLM, MES, ERP, MRO and QMS systems, and how cleanly they interoperate.
- Regulatory environment (civil, defense, export-controlled programs) and any additional regulatory or customer-specific CM requirements beyond AS9100.
- Process maturity in change control, incident investigation, and audit readiness. Weak upstream processes cannot be “fixed” by a new CM tool alone.
AS9100 requires a defined, controlled process and objective evidence of its effectiveness, but it does not guarantee compliance or certification outcomes. Each organization must design and validate a CM approach that fits its actual aircraft programs and system landscape.
