Explainer
S3000L Data Model and Tooling Explained
The Short Answer
A Shared Model, Not a Database
The S3000L specification does two jobs. Most of it describes the logistics support analysis process; its Chapter 19 defines the data that process produces, as a UML class model. Chapter 20 then defines how that data is exchanged, using XML schemas generated from the model. The result is a common vocabulary for the analysis, and not a product or a database design.
That distinction matters when you shop for software. Nothing in the specification tells you how to store the data; it tells you what a conforming exchange contains. For the process itself, start with our guide to logistics support analysis and the S3000L standard page. For where the specification sits among its siblings, see the S-Series mapped.
The Structure
Four Groups of Data
- Breakdowns hold the product structure
- A breakdown is a hierarchy of breakdown elements for a product or product variant. One generic capability represents any number of them (system, functional, physical, zonal, or a hybrid), and a type attribute says which is which.
- Parts hold the things you can buy
- Parts, their characteristics, and parts lists are defined separately from the breakdown. A hardware or software element in the breakdown is realized by one or more parts, and is not the part itself.
- Tasks hold what has to be done
- Task requirements, tasks with subtasks, the resources each needs, time limits, and where the work is performed. This is the end of the chain: the specification describes its result as a set of detailed task definitions.
- Everything else supports the analysis
- Failure modes, performance parameters, analysis candidate items, locations, facilities, substances, restrictions, baselines, and messages. Together with the three groups above, Issue 3.0 organizes the model into 61 units of functionality (UoF).
Each unit of functionality comes with a description, a class diagram, and class definitions. The suggested reading order follows the process: define the project and the product first, record the analysis data next, and finish at the task definitions.
Product Structure
Breakdowns and Breakdown Elements
A breakdown partitions a product or product variant into a parent-child hierarchy. Elements can be organized two ways. In an implicit breakdown the identifier carries the position, as in the Logistics Control Number (LCN) of GEIA-STD-0007 and the Standard Numbering System (SNS) of S1000D. In an explicit breakdown, parent-child relationships are recorded directly, which is how product lifecycle management tools work. The specification supports both, and the LSA plan decides which identification scheme a program uses. Our guide to LSA explains the LCN lineage.
- Aggregated element
- A container for other elements, typically a system, subsystem, function, or family.
- Hardware element
- A position in the product realized by one or more hardware parts, including allowed substitutes.
- Software element
- The same idea for software parts.
- Zone element
- A three-dimensional space related to the product, used for zonal breakdowns.
The key discipline is separation. A hardware element is a position in the product, and the part that fills it is a separate record with its own definition. That is what lets a part be replaced, substituted, or revised without rewriting the structure, and what lets one element carry alternates.
Parts lists follow the same logic. The specification distinguishes an engineering bill of material from a service bill of material: the first lists everything needed to build an assembly, the second only what can be replaced in a maintenance task, and the part numbers can differ. Both can be revised over time and related to each other. Allowed configurations (usable on a variant, effective for a serial number range) restrict which elements and parts apply where.
Tasks and Resources
What the Analysis Produces
The task data is the part publications and provisioning teams care about. A task is built from subtasks and can reference supporting tasks, such as gaining access, so the same removal step is not written twice. Resources fall into personnel, material (spare parts, consumables, raw material, support equipment), facilities and infrastructure, and documentation, and the guidance is to attach each resource to the activity that needs it. Tasks also record frequency, duration, and where the work is performed.
Hazard and safety information is worth a careful look. The model has no unit of functionality named for hazards. Safety appears as preconditions on the task (warnings, cautions, personal protective equipment) and as substance definitions and restrictions. If your program expects a hazard analysis, agree where it lives and how it reaches the procedures.
One more rule from the specification: narrative text in the analysis is a draft. Publications follow strict rules for language and layout, so the task text should be brief and verified before it is reused.
Downstream
How the Data Reaches S1000D and S2000M
- Into S1000D
- The specification describes LSA task data as the baseline for S1000D data modules, including the task description, required conditions, and required resources (personnel, material, support equipment). Maintenance publications use it as a direct input to the procedure. Safety, general, and personnel preconditions belong in the preliminary requirements of a procedural data module, so the task has to carry them as subtasks or roles.
- Into S2000M
- LSA data determines the range and depth of maintenance and so the materiel the product needs in service. S2000M turns that into provisioning data, compiled by its own rules. The data S2000M draws from S3000L is defined in a separate input specification, S2000X, and the guidance conference at project start settles how much LSA data the provisioning will use.
- Through shared identifiers
- The specifications align a few keys. The product identifier lines up with the S1000D model identifier, the product variant identifier with the S1000D system difference code, and the breakdown element revision identifier with the S2000M figure item identifier and the S1000D standard numbering system (SNS). Misaligned keys are where the three data sets quietly drift apart.
The specification also warns that the interface to S1000D needs a close definition, so tasks do not end up grouped into one procedural data module or split across several reusable ones by accident. Our guides on the S1000D standard and illustrated parts data show the publishing side. The data module requirements list is where a program lists which modules the task data will fill.
On the materiel side, the S2000M data model is also described in UML units of functionality, with a data dictionary and XML schemas, and it identifies the product being provisioned with a product identifier. Older text calls that the MOI, the model identification code, which is a registered code of up to 14 alphanumeric characters.
Common Data Model
SX002D, UML, and the XML Schema
The S-Series specifications share a Common Data Model, published as SX002D and maintained by a working group that includes the data modelers of every specification. It holds the elements used in at least two specifications, which is why the S3000L, S2000M, and SX000i models line up. Issue 3.0 of S3000L updated its model in line with it. SX000i explains how the specifications work together, and the IPS elements show which support functions each one serves.
For tooling, the pieces you can actually use are the published XML schemas and the UML class model, which is offered in EAP and XMI form. The schemas support complete baseline messages and update messages, so a receiver can apply changes without re-analyzing the whole data set, and they allow project-specific attributes for data the standard model does not cover.
Buying or Building
What an LSA Analyst Should Ask of a Tool
- Does it store breakdowns as separate structures per product variant, with explicit parent-child links or LCN/SNS-style identifiers, whichever your contract specifies? Can one element sit in more than one breakdown?
- Does it keep breakdown elements and parts apart, so a part number change does not rewrite the breakdown, and does it model engineering and service parts lists as separate revisions?
- Can a task be built from reusable subtasks and supporting tasks, with each resource attached to the subtask that needs it and not just to the task?
- Can you record safety preconditions, personnel requirements, substances, and restrictions in a form a publishing team can consume without retyping them?
- Does it import and export the S3000L XML schema, including update messages and not only complete baselines, and does it validate against the published schema on the way in and out?
- Does it handle project-specific attributes through the extension mechanism of the schema instead of by changing the model?
- Does it keep revision history, baselines, and effectivity (usable on variant, effective on configuration), so any change can be traced and explained?
- Can it produce the extracts your downstream teams need, in the shape of the S1000D, S2000M, and training input specifications your contract cites?
Ask for an export of a sample breakdown and one fully resourced task, and validate it against the published schema yourself. That one test shows more than a feature list.
FAQ
Questions We Hear
What is the S3000L data model?
It is the UML class model in Chapter 19 of the specification that defines the data an LSA produces and exchanges: product structure, parts, failure modes, task requirements, tasks, resources, and more. Issue 3.0 organizes it into 61 units of functionality, and an XML schema derived from it carries the exchange.
Is there an S3000L database I can download?
No. The specification publishes the model, the XML schemas, and the UML in EAP and XMI form, free from the S-Series site. SX000i states that its own data model is not a database structure and that any tool or database able to store the information and exchange it through the schemas is in principle adequate. The same reasoning applies to S3000L: it defines what to exchange, not which product to buy.
Is there S3000L or S2000M software?
The specifications are documents plus schemas; the software that implements them comes from tool vendors and in-house teams. S2000M notes that ERP systems can cover its processes and that it can serve as an interchange format for material master data between two ERP systems. Use the questions above to judge any tool against the model.
What are S2000M MOI codes?
MOI is the model identification code, the identifier that says which product a provisioning exchange concerns (a weapon system, aircraft, engine, or ship, for example). In current S2000M the element is called the product identifier, and MOI is one of its code classes, alongside the end item acronym code. An MOI is 1 to 14 alphanumeric characters, discrete values only, and registered with an administrator; the specification points to the NSPA site for the list.
How do S3000L and S2000M fit together?
S3000L decides what support the product needs, and S2000M manages the materiel behind it. LSA task and resource data drives provisioning, through the S2000X input specification, and both rely on the same common data model and aligned identifiers. S2000M also describes its model as UML units of functionality with XML schemas, built to the same common model.
What is SX002D?
The Common Data Model for the S-Series IPS specifications. It covers data elements used in at least two of the specifications, is developed and maintained by the Data Modeling and Exchange Working Group, and is the reason S3000L, S2000M, and SX000i use compatible UML and XML schemas. Issue 3.0 of S3000L updated its model in line with it.
Get In Touch
Plan the Handoff From Analysis to Manuals
Working out how LSA data will reach your technical publications? Send us the data you expect to receive and we will tell you what the manuals need from it.