The Standard Numbering System (SNS)
The Standard Numbering System (SNS) is the product breakdown that S1000D uses to organise technical information. It answers one question for every data module: where on the product does this apply? The SNS is a numbering convention. It maps each part of the product to a code, so that every data module about that part shares the same number. The SNS sits inside the Data Module Code as part of the system-related fields.
The SNS works from the whole product down to a single assembly. It has four levels: system, subsystem, sub-subsystem, and assembly (unit). Read together, they pinpoint a place in the product. In a Data Module Code the SNS is written as three groups joined by hyphens — the system group, then a group that carries one character for the subsystem and one for the sub-subsystem, then the assembly group — for example 29-10-05:
| Level | Field | Characters in 29-10-05 | Example meaning |
|---|---|---|---|
| 1 | System | 29 | Hydraulic power |
| 2 | Subsystem | 1 | Main system |
| 3 | Sub-subsystem | 0 | (no further split) |
| 4 | Assembly / unit | 05 | Reservoir (tank) |
So the worked example 29-10-05 reads as Hydraulic power → Main system → Reservoir. The system code says hydraulic power. The subsystem digit narrows it to the main hydraulic system. The assembly code points at the reservoir. A different unit in a different subsystem would carry a different number, and every data module about that one reservoir — its description, its servicing, its removal — would share 29-10-05.
Product breakdown — illustrative SNS
Illustrative example only. This SNS walks the four levels S1000D defines — system → subsystem → sub-subsystem → assembly — using ATA-style chapter numbers (e.g. 29-10-05 = Hydraulic Power → Main system → Reservoir/Tank). Real projects adopt one of the standard/default SNS variants in the specification or define their own, recorded in their business rules. Codes here teach the structure and are not a normative reference.
How the codes nest
The four SNS levels are written as three hyphen-separated groups: the system code (up to three characters), then the subsystem and sub-subsystem characters, then the assembly code. Each group refines the one before it. The codes are usually numeric, but the specification allows alphanumeric characters, which is why the s1kd-tools tutorial uses codes like DA1-10-00 for a bicycle example.
The s1kd-tools tutorial documents a fictional bicycle project. Its SNS uses DA1 for the brakes system and DA1-10 for brake pads — so a brake-pads data module carries the SNS DA1-10-00. The wheels system is DA0. These are illustrative examples that teach the structure. They are not real aircraft numbers.
Below the SNS, the Data Module Code adds a disassembly code. The disassembly code is a separate field, not part of the SNS. It extends the breakdown further, often to mark the order in which parts come apart. Keep the two ideas distinct: the SNS locates the assembly; the disassembly code drills inside it.
Standard SNS versus project SNS
S1000D does not make every project invent its numbering from scratch. The specification ships maintained (standard) SNS in its chapter on the Standard Numbering System. These standard sets allocate the system and subsystem codes — and sometimes the sub-subsystem codes — for whole domains.
The maintained SNS that the specification provides — the same set that the s1kd-tools s1kd-newdm command exposes through its --maintained-sns option — are:
| Standard SNS set | Used for |
|---|---|
| Generic | Products that do not fit a specific domain set |
| Support and training equipment | Ground support and training gear |
| Ordnance | Weapons and ordnance items |
| General communications | Communications equipment |
| Air vehicle, engines and equipment | Aircraft and their systems |
| Tactical missiles | Missile systems |
| General sea vehicles | Surface and subsurface vessels |
The air-vehicle SNS grew from the ATA chapter system long used in civil aviation. That is why chapter 29 means hydraulics across so many projects. Reusing a common breakdown lets teams, suppliers, and tools share one mental model of the product.
A project has two choices. It can adopt a standard SNS for its domain, which means much of the numbering is already defined. Or it can define its own SNS when no standard set fits the product well. Many real projects do a mix: they start from a standard set and extend it.
Whatever SNS a project picks, it must record that choice in its business rules, and the same SNS must be used consistently across the project. A data module's SNS is validated against those rules. So a project cannot quietly number the same part two different ways.
Why the SNS matters
The SNS is what makes S1000D content findable and reusable without reading it.
- One number, one part. Every data module about a given assembly shares its SNS. A tool can gather all of them by code alone.
- Stable across information types. The description, the servicing task, and the removal task for the tank all start with
29-10-05. Only the information code changes. - Machine-checkable. Because the SNS is a structured, fixed-position field, a toolchain like
s1kd-toolscan sort, filter, and validate data modules from their codes. Show every fault report (4xx) for the hydraulics system (29) becomes a simple query over file names.
That is the payoff of a shared numbering scheme: the product breakdown is written once, in the SNS, and reused everywhere.