In everyday speech, "aircraft component" can mean anything from a rivet to a complete wing. Regulators, manufacturers and maintenance organisations cannot afford that looseness, because the category an item falls into decides which approval it needs, which document accompanies it and who may install it. A records system that ignores these distinctions will sooner or later accept a part that should have been quarantined.
Aviation law in the United States and Europe recognises three products: the aircraft, the engine and the propeller. Each receives its own type certificate. Everything else that is installed on a product is a part or an appliance. The FAA's definitions (14 CFR Part 1) describe an appliance as an instrument, mechanism, piece of equipment, apparatus or accessory used in operating or controlling an aircraft in flight that is not part of an airframe, engine or propeller. A radio, a fuel quantity indicator or a cabin pressure controller is therefore an appliance; a wing rib or a landing-gear axle is a part of the airframe. European rules use the umbrella term "parts and appliances" in a similar way.
The distinction is not academic. Appliances are often built to a technical standard order (TSO in the United States, ETSO in Europe), which is a minimum performance standard that the manufacturer can meet without being the holder of the aircraft type certificate. Airframe parts, in contrast, are normally produced under the production approval of the type-certificate holder or under a parts manufacturer approval (PMA) that shows the part is equivalent to the approved design.
A second axis is how the item is removed and replaced. A line-replaceable unit (LRU) is designed to be swapped on the ramp, usually within a turnaround, with simple tools and a functional test: an avionics box, a hydraulic pump, a brake assembly. The failed unit is sent to a shop where it is repaired to the shop-replaceable unit level. Structural parts such as frames, spars, fittings and skin panels are not designed to be swapped; they are inspected in place, repaired according to approved data, and replaced only by a heavy-maintenance task.
Between these extremes sit assemblies: a main landing-gear leg is an assembly of a shock strut, a torque link, a side brace, wheels, brakes and dozens of smaller parts, several of which carry their own serial numbers and their own life limits. A good data model must be able to describe the assembly as one thing when it is fitted to an aircraft, and as many things when it is on the bench.
A part number (P/N) identifies a design. Every item built to the same drawing at the same revision, or at an interchangeable revision, shares a part number. A serial number (S/N) identifies one physical item. Two consequences follow. First, a serial number is only meaningful together with its part number and the manufacturer that issued it; serial "0001" exists in thousands of catalogues. Second, most regulatory events attach to one level or the other: an airworthiness directive may apply to all units of a part number, to a serial-number range, or to units that have not yet received a particular modification. The record system must therefore keep both identifiers, keep them separate and never let one be derived from the other.
Not every part is serialised. Standard hardware such as bolts and nuts is controlled by part number and batch or lot. Life-limited parts, rotating engine parts, landing-gear components and most LRUs are serialised, because their history of hours, cycles, repairs and inspections must follow the individual item. This individual history is what the industry calls back-to-birth traceability: an unbroken chain of records from the moment the item was manufactured to the present day.
ComponentType valuesWIA-SPACE-016 does not try to reproduce the full ATA chapter breakdown used in maintenance manuals. Its reference type definitions give a compact list of nine component categories, which this book uses as a first taxonomy. Table 1-1 relates each value to the engineering domain it covers and to the chapter in which it is discussed in depth.
| Value | Typical items | Nature | Main chapter |
|---|---|---|---|
fuselage | Frames, stringers, skin panels, pressure bulkheads, floor beams | Primary structure | 2 |
wing | Spars, ribs, wing skins, wing-to-body fittings | Primary structure | 2 |
tail | Horizontal and vertical stabiliser boxes, their attachment fittings | Primary structure | 2 |
landing-gear | Shock struts, braces, axles, wheels, brakes | Structure plus system, life-limited parts | 3 |
flight-control | Control surfaces, actuators, flight control computers | System with structural elements | 3 |
hydraulic-system | Pumps, accumulators, valves, lines | System, mostly LRUs | 3 |
fuel-system | Boost pumps, valves, quantity probes, tank structure interfaces | System, mostly LRUs | 3 |
avionics | Radios, navigation units, displays, computers | Appliances, LRUs with software | 4 |
engine-mount | Pylon fittings, mount links, fuse pins | Primary structure at the engine interface | 2, 7 |
The list is deliberately coarse. It says nothing about engines themselves, cabin interiors or electrical power, and it mixes structural zones with systems. Readers should treat it as the top-level classification of the reference implementation, not as a replacement for ATA iSpec 2200 chapters or the manufacturer's illustrated parts catalogue. Where a finer category is needed, the standard's extension rules (discussed in Chapter 4) allow additional information to be carried without breaking existing consumers.
"Airworthy" is a legal state, not a feeling. In most jurisdictions an aircraft is airworthy when it conforms to its approved type design and is in a condition for safe operation. Both halves matter. An aircraft in perfect physical condition that carries an unapproved part does not conform; an aircraft that conforms on paper but has an undetected crack is not in a condition for safe operation. Every component record ultimately exists to support one of those two statements.
The chain starts with design. An applicant shows the authority that a new aircraft design complies with the applicable airworthiness standards. For large aeroplanes these are 14 CFR Part 25 in the United States and Certification Specifications CS-25 in Europe; the two are closely harmonised, and their paragraph numbers usually match, which is why engineers speak of "25.303" without naming the authority. When the authority is satisfied, it issues a type certificate (TC). The TC covers the type design (drawings, specifications, materials and processes), the operating limitations, and a type certificate data sheet that summarises the certification basis.
The procedural rules for obtaining design and production approvals are in 14 CFR Part 21 and in the European Part 21, the annex to Commission Regulation (EU) No 748/2012. Changes to a type design made by someone other than the TC holder are approved through a supplemental type certificate (STC). A replacement part produced by a company that does not hold the TC can be approved through a PMA in the United States; Europe handles the equivalent case through design approvals for parts and through its own production rules.
A type certificate proves that a design is safe; it does not prove that the next thousand copies will match the design. That is the job of the production approval: an FAA production certificate or an EASA production organisation approval (POA). A production approval holder must run a quality system that controls suppliers, special processes, inspection and the release of finished items. Suppliers several tiers down the chain work under the quality system of the approval holder, which is why aerospace quality standards such as AS9100D and the first-article inspection standard AS9102 reach so far into the supply base. Chapter 7 maps those quality expectations to WIA objects.
When a production approval holder releases a new part, it issues an authorized release certificate: FAA Form 8130-3 in the United States, EASA Form 1 in Europe. The same forms are also used by maintenance organisations to release a part after repair or overhaul, with a different block completed. For a records system, this form is the single most important document attached to a serialised part, because it is the legal evidence that the item left an approved organisation in a condition that conforms to approved data.
Each individual aircraft receives an airworthiness certificate once it has been shown to conform to its type design. From that moment, the operator becomes responsible for continued airworthiness: keeping the aircraft conforming and safe for the rest of its life. The type-certificate holder supports that task by publishing Instructions for Continued Airworthiness (required by 25.1529 and its CS-25 counterpart), service bulletins and structural repair manuals. The authority adds airworthiness directives (ADs), which are mandatory; in the United States ADs are issued under 14 CFR Part 39. In Europe the continuing-airworthiness rules are in Commission Regulation (EU) No 1321/2014, which includes the requirements for maintenance organisations (Part-145) and for continuing-airworthiness management organisations.
Seen from a component's point of view, continued airworthiness is a stream of events: installation, removal, inspection, repair, modification, and eventually retirement. Each event must be performed by an approved organisation, using approved data, and recorded. The WIA standard's maintenance and service-bulletin operations (Chapters 5 and 6) are structured around that stream.
In the Republic of Korea, the legal basis is the Aviation Safety Act (항공안전법), and the competent authority is the Ministry of Land, Infrastructure and Transport (국토교통부, MOLIT). Type certification, production approval and airworthiness certification follow the same three-layer logic described above. The technical requirements are published as the Korean Airworthiness Standards (항공기기술기준, KAS), which are structured to align with the internationally used certification specifications, so that a transport-category design is assessed against requirements equivalent to Part 25 / CS-25. Readers should avoid informal names for the authority in formal records; the certificate issuer should be the ministry or the delegated body named on the actual document.
Certification object in the reference types has a free-text authority field. A useful convention, adopted throughout this book, is to write the authority exactly as it appears on the issued document (for example "FAA", "EASA" or "MOLIT") and to put the document type, such as "8130-3" or "EASA Form 1", in the standard or metadata field. Inventing a new abbreviation for an authority makes records impossible to match against the authority's own registers.
Structural engineers in aviation use a small, precise vocabulary for strength. The same words appear in analysis reports, test plans and the StructuralAnalysis object, so it is worth defining them carefully.
Limit loads are the maximum loads the aircraft is expected to meet in service (25.301). They come from the flight and ground load cases in the certification basis: manoeuvres, gusts, landing impacts, ground handling, cabin pressurisation and so on. Ultimate loads are limit loads multiplied by a factor of safety. Unless the regulations prescribe otherwise, that factor is 1.5 (25.303).
The two load levels come with two different pass criteria (25.305). At limit load, the structure must not suffer detrimental permanent deformation, and any deformation must not interfere with safe operation. At ultimate load, the structure must carry the load without failure for at least three seconds in a static test, or the equivalent must be shown by analysis supported by test (25.307). In short: limit load is about the aircraft still working normally afterwards; ultimate load is about the structure not breaking.
For manoeuvres, 25.337 sets the limit load factors for transport-category aeroplanes. For typical transport weights the positive limit is +2.5 g and the negative limit is −1.0 g up to the design cruising speed; multiplying by 1.5 gives ultimate load factors of +3.75 g and −1.5 g. These factors are independent of landing weight; landing loads are a separate family of load cases with their own requirements. Chapter 2 develops the full manoeuvre and gust envelope.
The 1.5 factor covers general uncertainty in loads, materials and workmanship. Certain items receive additional special factors because experience shows that the general factor is not enough. Examples include the fitting factor of 1.15 for fittings (25.625), casting factors that depend on the inspection level of the casting (25.621) and bearing factors for parts subject to rattling or wear. A structural analysis therefore records which factors were applied, not only the final result.
The simplest stress calculation divides a force by the area that carries it: σ = F / A. The result is compared with a material allowable, a statistically based strength value taken from an accepted source such as the MMPDS handbook for metals or CMH-17 for composites. A-basis and B-basis allowables are values that a stated proportion of the material population is expected to exceed with a stated confidence; Chapter 2 explains how they are derived. The comparison is expressed as a margin of safety (MS):
Tension link, cross-section A = 400 mm^2
Limit load P_limit = 60 kN
Ultimate load P_ult = 1.5 x 60 kN = 90 kN
Stress at ultimate sigma = P_ult / A = 90 000 N / 400 mm^2 = 225 MPa
Fitting factor (25.625) applies: sigma_design = 1.15 x 225 = 258.8 MPa
Material allowable (example value only) F_tu = 480 MPa
Margin of safety MS = F_tu / sigma_design - 1 = 480 / 258.8 - 1 = 0.85
MS >= 0 -> the link meets the static strength requirement for this load case
MS < 0 -> redesign, reinforce or refine the analysisTwo points in the example are easy to get wrong in software. First, the factor of safety is applied to the load, and the margin compares the allowable with the resulting stress; the 1.85 in this example (480 / 258.8) is a reserve factor at ultimate level, not a regulatory factor of safety, and a record that stores it as a bare "safety factor" invites a reader to compare it with the 1.5 of 25.303 and draw the wrong conclusion. The reference StructuralAnalysis object has one safetyFactor field, so this book stores exactly that ratio there (allowable / ultimate-level design stress, special factors included, so the pass criterion is ≥ 1.0), names the load case and factors in metadata, and keeps the margin in the analysis report referenced from metadata. Second, a positive margin for one load case says nothing about fatigue or damage tolerance, which are separate requirements with separate analyses (Chapter 7).
The SDK's ComponentAnalyzer helper exposes calculateStress, calculateSafetyFactor and isSafe, whose default minimum is 1.5. These are convenient for teaching and for sanity checks in a user interface. They do not know which load case, which allowable basis or which special factor applies, and they must not be mistaken for a certification analysis.
Strength requirements protect against loads. Systems also fail in other ways: a pump stops, a computer produces a wrong output, a valve sticks. For these, transport-category rules take a probabilistic approach set out in 25.1309 and explained in FAA Advisory Circular AC 25.1309-1A and the corresponding EASA AMC 25.1309. The central idea is that the more severe the effect of a failure condition, the less probable it must be.
A failure condition is described by its effect on the aircraft and its occupants, not by the component that fails. Losing one hydraulic system on a three-system aircraft may be a minor or major failure condition; losing all hydraulic power to the flight controls is catastrophic. The same pump part number can therefore contribute to several failure conditions with different severities, and its reliability data feed into each of them.
| Category | Effect (summary) | Qualitative probability | Objective per flight hour | Top-level DAL |
|---|---|---|---|---|
| Catastrophic | Would result in multiple fatalities, usually with loss of the aeroplane | Extremely improbable | ≤ 1×10−9 | A |
| Hazardous | Large reduction in safety margins; serious or fatal injury to a small number of occupants; crew workload such that tasks may not be completed accurately | Extremely remote | ≤ 1×10−7 | B |
| Major | Significant reduction in safety margins or functional capabilities; significant increase in crew workload; possible passenger discomfort or injuries | Remote | ≤ 1×10−5 | C |
| Minor | Slight reduction in safety margins; slight increase in workload | Probable | No quantitative objective | D |
| No safety effect | No effect on safety | — | — | E |
Two further rules shape design more than the numbers do. First, no single failure, however improbable, may lead to a catastrophic failure condition; this fail-safe principle is why flight-critical systems are redundant and why structural load paths are designed so that a cracked member does not immediately bring down the whole structure. Second, redundancy only helps if the redundant channels do not fail together. Common-cause analysis, zonal analysis and particular-risk analysis look for events such as a fire, a rotor burst or a shared software error that could defeat several channels at once. This is the background for the separated hydraulic systems and dissimilar flight-control computers discussed in Chapter 3.
For a component record, the safety assessment matters in two places. The development assurance level of an equipment item, discussed next, follows from the failure conditions it can contribute to. And the maintenance tasks that protect against latent failures, such as periodic checks of a standby system that is not used in normal operation, show up as inspection records with a nextInspectionDate.
Probability targets work well for random hardware failures, which can be measured. They do not work for design errors, especially in software and complex electronics, where there is no failure rate to measure. For these, the industry relies on development assurance: a set of planned, systematic activities that give confidence that requirements are correct and complete and that the implementation meets them. The rigour of those activities scales with the development assurance level (DAL), from A (most rigorous) to E.
Four documents form the backbone. They are referenced by the PHASE 3 document of WIA-SPACE-016, which states that its protocol messages reflect the evidence these processes produce rather than redefining them.
The DAL in Table 1-2 is the top-level assignment. ARP4754A allows the level of individual items to be adjusted when the architecture provides independence, for example two dissimilar computers each developed at a lower level together supporting a function whose failure is catastrophic. The exact rules are detailed and are applied with the certification authority's agreement; a records system should store the assigned level, not recompute it. SAE has continued to revise these documents, so implementers should record which revision was part of the certification basis for each product.
The processes are usually drawn as a V. The left side decomposes requirements from aircraft to system to item; the bottom is implementation; the right side integrates and verifies upward, each level against the requirements written at the same height on the left.
Aircraft functions & FHA --------------------------- Aircraft-level verification
\ /
System requirements & PSSA ----------- System integration & SSA
\ /
Item requirements (HW / SW) --- Item verification
\ /
Item design and implementation (DO-178C / DO-254)
Left: requirements capture and validation Right: verification evidence
Horizontal lines: traceability between a requirement and its verificationWhat does this mean for component data? An avionics LRU carries not only a hardware part number and serial number but also the part numbers of the software loaded on it, each developed at a stated level. When the software changes, the configuration of the unit changes even though no physical part has been replaced. The reference AircraftComponent type has no dedicated field for loaded software; Chapter 4 shows how to carry it in metadata and why it is a strong candidate for a future additive extension.
A serialised component goes through a recognisable sequence of stages, and different organisations are responsible for it at each stage. The reference types capture the stages in the ComponentStatus enumeration: design, testing, certified, production, maintenance and retired.
ComponentStatus states and the actors that own each transition design --> testing --> certified --> production --> maintenance --> retired
^ |
+-------------+
(return to service)
OEM / TC holder : [design]---[testing]---[certified] SBs, ICA, repair data
Supplier : drawings qualification FAI [production] CoC, 8130-3 / Form 1
Operator : install hours/cycles AD compliance
MRO : [maintenance] NDI, repair, release
Authority : TC / TSO / PMA production approval ADs surveillanceThe enumeration is a useful simplification, but its limits should be understood before it is used in a real system.
design and testing describe the design standard more than an individual serial number. Development and qualification test articles do have serial numbers, and their records matter for certification, but they normally do not become flying parts without specific disposition.certified means that the design has an approval (a TC, TSO authorisation, PMA or similar) under which production can take place. It is not the same as an individual part having a release certificate.production covers the manufactured item from first release onward. The enumeration has no separate "in service" value, so this book treats production as "released and serviceable", with installation details held in the maintenance history.maintenance is a state an item enters and leaves many times during its life. Each return to service should be recorded with a new release document; the transition back is shown by the loop in Figure 1-2.retired is terminal. A retired life-limited part must be controlled so that it cannot re-enter the supply chain, for example by mutilation, and the record should keep the reason and the disposition.Chapter 6 turns these states into an explicit transition table with the messages that trigger each change. For now, the key point is that each transition is a claim made by a specific organisation and should be traceable to that organisation's document.
| Stakeholder | Typical records | WIA object or field |
|---|---|---|
| Type-certificate holder (OEM) | Type design data, structural analysis reports, ICA, service bulletins, repair data | StructuralAnalysis, Certification, service-bulletin operations |
| Component supplier | First article inspection report (AS9102), material and process certificates, certificate of conformity, release certificate | AircraftComponent identity fields, material, Inspection, metadata |
| Operator | Installation and removal records, hours and cycles, AD and SB compliance status | Maintenance events, metadata (usage counters) |
| Maintenance organisation (MRO) | Work orders, non-destructive inspection results, repair records, release to service | Inspection (method, result, nextInspectionDate), maintenance events |
| Certification authority | Type certificates, production approvals, airworthiness directives, verification of certificates | Certification (authority, certificateNumber), certification-package operations |
Table 1-3 also explains why the standard defines protocols between organisations rather than a single central database. No single party owns the whole history of a part. The supplier knows how it was made, the operator knows how it was used, the MRO knows what was found and fixed, and the authority knows which approvals and directives apply. Traceability is achieved by linking signed statements from each party, a theme that Chapters 6 and 7 develop.
WIA-SPACE-016 is published as four PHASE documents plus supporting material. It is important to know in advance that the documents are not tidy: each PHASE has a short normative introduction that states its purpose, followed by engineering content consolidated from an earlier single-volume draft, and the engineering content does not always match the PHASE title. This book follows the introductions for the structure of the standard and uses the engineering content only where it has been checked.
| Part | Stated purpose | Consolidated engineering content | Book chapters |
|---|---|---|---|
| PHASE 1 — Data Format | Canonical structures for identification, structural envelope, material certification and traceability metadata, expressed in JSON Schema 2020-12 | Airframe structures and materials | 2, 4 |
| PHASE 2 — API Interface | REST operations for component catalogue, maintenance events, certification packages, traceability and service bulletins; OAuth with mTLS for authority callers; RFC 9457 problem details | Avionics | 4, 5 |
| PHASE 3 — Protocol | Exchanges between supplier, MRO, operator and certification authority, referencing ARP4754A, ARP4761A, DO-178C and DO-254 | Flight controls, hydraulics and fuel | 3, 6 |
| PHASE 4 — Integration | Evidence packaging with CycloneDX 1.5, signed attestations with in-toto Attestation 1.0, mapping to AS9100D and AS9145 | Landing gear, certification, maintenance | 3, 7 |
| Annexes (repeated in each PHASE) | Implementation notes, adoption roadmap, test vectors and conformance evidence, versioning and deprecation, interoperability profiles | — | 8 |
The reference TypeScript package @wia/aircraft-component contains the type definitions used throughout this book (AircraftComponent, ComponentType, ComponentStatus, MaterialType, MaterialSpecification, StructuralAnalysis, Certification, Inspection and the APIResponse<T> envelope), a client class WIAAircraftComponentClient with methods such as createComponent, addInspection, requestCertification and verifyCertification, and the ComponentAnalyzer helper mentioned in §1.3.
Two cautions apply. The client's internal request function currently returns mock data built from the request instead of calling a live service, so it demonstrates the shape of the API, not its behaviour. And the command-line tool aircraft-component.sh, with its validate, generate, check and info commands, is a skeleton: validate and check report success without examining the input. Chapter 8 shows how to build a real validator on top of JSON Schema.
A first look at the shape of a record helps to fix the vocabulary of this chapter. The fragment below shows only the identity and lifecycle fields; Chapter 4 completes it with dimensions, material, analysis, certification and inspection history.
AircraftComponent (fragment, fictitious values){
"id": "cmp-2f7a91",
"type": "landing-gear",
"status": "production",
"partNumber": "EX-4410-201",
"serialNumber": "SN-000318",
"manufacturer": "Example Gear Works",
"manufacturingDate": "2025-11-04",
"metadata": {
"releaseDocument": "FAA Form 8130-3",
"note": "illustrative record; P/N, S/N and manufacturer are invented"
}
}The companion simulator at wiastandards.com has five tabs, labelled Data Format, Algorithms, Protocol, Integration and Test. They correspond roughly to Chapter 4 (data records), Chapters 1–2 and 7 (stress and fatigue calculations), Chapter 6 (message exchange), Chapter 7 (evidence packaging) and Chapter 8 (conformance testing). The simulator is a teaching aid; its numbers are for exploration and are not certification data.
ComponentStatus models the lifecycle from design to retirement; in real systems, maintenance is a loop and each transition must be traceable to the organisation and document that justify it.