Skip to main content

Data modules

The data module (DM) is the basic building block of S1000D. It is a single, self-contained unit of information. You write it once, store it once, and reuse it in many publications.

A data module holds one piece of technical information. This can be a description, a procedure, a fault check, a parts list, or another defined type. Each data module is an XML file. Each one has a unique identifier called the Data Module Code (DMC).

Source-once, use-many

A data module is created one time and reused wherever the information is needed. When you update the data module, every publication that references it shows the change. You do not edit the same text in many places.

Two parts: identification/status and content​

Every data module has the same top-level shape. It is split into two parts.

PartWhat it holdsPurpose
Identification and statusThe DMC, title, issue number and date, security classification, quality status, applicability, and the BREX referenceMetadata used to manage the module inside the CSDB
ContentThe actual technical information: the description, procedure, fault data, or parts dataThe information the reader or system uses to do the task

The identification and status section is metadata. It tells the database how to find, version, and control the module. The content section is the information the user reads or the system displays.

Self-contained

A data module does not depend on the page or chapter around it. It carries its own identity and status. This is why it can move between publications without rework.

A unique code for every module​

Each data module is identified by its Data Module Code (DMC). The DMC is a structured code, not a free-text name. It encodes where the information sits in the product breakdown and what kind of information it is.

The DMC lets a database store and retrieve the module reliably. Two modules never share a code. The DMC gets its own page in this guide.

Example DMC (illustrative only):

DMC-1B-A-29-10-05-00A-720A-A

This example follows the DMC pattern: a model identification code, a system difference code, the Standard Numbering System position (system, subsystem/sub-subsystem, assembly), a disassembly code and variant, an information code and variant, and an item location code. See The Data Module Code for the field-by-field breakdown.

Stored in the CSDB​

Data modules live in the Common Source Database (CSDB). The CSDB is the single store for all information objects in a project. This includes data modules, illustrations, multimedia, publication modules, and management data.

The CSDB can be simple or large. It can be a folder of files on disk, or it can be enterprise software that manages the full lifecycle. S1000D defines the data, not the database software.

Because the modules sit in one shared store, many publications can pull from the same source. This is the reuse model in practice.

One schema per data module type​

S1000D defines several data module types. Each type has its own XML schema. The schema sets which elements are allowed and in which order. This keeps each type consistent and machine-checkable.

Data module typeUsed for
DescriptiveHow a system or item works; what it is
ProceduralStep-by-step tasks (remove, install, service)
FaultFault reporting and fault isolation
IPD (illustrated parts data)Parts catalogues with illustrations
ProcessAutomated or interactive process logic
WiringWiring and harness data
BREXA project's business rules (see below)

Other types exist, including crew/operator, container, maintenance planning, learning, and applicability cross-reference modules. The full set is covered in Data module types.

When you write a descriptive module, an editor validates it against the descriptive schema. When you write a procedure, it is validated against the procedural schema. A module that breaks its schema is not valid S1000D.

Validate against the schema and the BREX

Every data module must reference a BREX (Business Rules EXchange) data module. The BREX encodes a project's own rules. A module is checked first against its type schema, then against the project BREX. Tools like s1kd-tools run both checks from the command line.

How the parts fit together​

One module, stored once, feeds many publications. Its identity and status travel with it. Its content is validated against the right schema and the project rules.

Sources​