New to S1000D? Read our S1000D FAQ

If you are new to S1000D you probably have a LOT of questions about the specification.

So we asked our S1000D training and support team to come up with a set of questions they most commonly encounter when they are working with clients. This is by no means a substitute for S1000D training – which we can also offer – but will hopefully act as a useful reference for anyone starting our on an S1000D project or looking to implement S1000D for the first time.

If you have a question that isn’t mentioned below, please do reach out and we will make sure that we get you the answer.

A Data Module – or ‘DM’ as it’s more commonly referred to – is the single smallest standalone container of information relating to a platform, system, assembly, or part.

For example, a description of a system, a procedure to remove a component, or procedure to test something would all be contained within Data Modules. DMs heavily inter-reference one another, and this modular concept is one of the main contributors to maximum reuse of data and helps avoid duplication and redundancy.

Data Modules are coded and filed uniquely with a string of characters proceeded by “DMC-“ (Data Module Code). The length of that string can vary depending on the project, but the string gives important pieces of information related to the subject matter, system, and various other information pertaining to the DM’s content. So just from looking at the code, it’s possible to tell a lot about what data is inside.

ICN is short for Information Control Number (or Illustration Control Number in earlier versions of the S1000D spec).

Like the DMC (see above), the ICN is a code which is allocated to graphic and media entities. Again, like the DMC, it tells us various information about the part of the system or component to which it relates.

Every graphic, video or any other piece of supporting media will have an allocated ICN which is then referenced from within the relevant DMs.

The Standard Numbering System (SNS) is essentially your product’s breakdown structure with specific numbering convention. These numbers are allocated to each part of the breakdown/tree structure.

Depending on the product in question, much of the codification may already exist. For example, if your product is an aircraft, or a missile, then much of the hard work has been done for you as it’s already defined by the S1000D specification (down to a sub-system level). You’ll just need to allocate your system to the applicable areas of the SNS and build on what’s there to get you to your component level.

The SNS is one of the first things you need to plan at the start of a project, because the DMRL is largely dependent on the SNS to be able to correctly codify the DMs that you’ve listed.

The Data Module Requirement List (DMRL) or Data Management Requirement List in later versions of S1000D, is a maintained list of required data modules related to a project.

The DMRL is a living document and not something to be created and forgotten about. The DMRL would usually take the form of an Excel spreadsheet and would be built-out as the planning phase of the project progresses.

Often, the DMs which are required for a project (particularly maintenance procedures) will be derived from other activities within the Integrated Product Support (IPS) / Integrated Logistic Support (ILS) range of engineering activities. These activities analysis specific systems and sub-systems of the product.  From that analysis it’s possible to specify which parts or components need scheduled maintenance, what that maintenance is and at which periodicity it needs doing.

This information is ultimately used by the Technical Publications team to start writing their content.

Each DM listed in the DMRL will be assigned a data module code (DMC), and in order to do this, your SNS will need to be defined.

A Publication Module (PM) is a type of data module used specifically to design the final published document, for example the end user PDF maintenance manual for your product.

The PM contains a list of the DMs that you want to include in your publication, but crucially, also the structure of that publication (think sections and chapters and where each DM sits within that structure).

PMs are used for both PDF output as well as the more advanced Interactive Electronic Technical Publications (IETP).

XML is a markup language much like HTML. It is open by design so not designed for one specific use case. This means that when we create XML we can use an industry specific schema.

Schemas are essentially a structured set of rules for the XML. These rules dictate, among other things, what we can write and where. The schema is what binds us to specific rules and gives our data structure.

S1000D is a set of schemas which enable us to use XML as the language, restricted to a set of rules for each document type that we write.

S1000D provides the schemas, along with a large specification document on how to use them.

Just to further complicate the situation, S1000D had had various iterations over the years. Each slightly (or completely) different from the previous. The good news is that the specific version of S1000D you need to use would normally be instructed to you as part of the requirements of the project.

S1000D goes all the way back 1995 at its initial release (Issue 1.6) and new issues have been released incrementally since then. The release numbers over time are as follows:

1.6, 1.7, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3. 3.0. 4.0, 4.1, 4.2, and most recently 5.0 released in June 2019.

There are a few minor patch releases in between some of these but I’ve omitted those for simplicity.

Some of the updates are more significant than others, the biggest leap was almost certainly between Issue 3.0 and Issue 4.0, where there was a huge change to the element and attribute naming conventions. For this reason, S1000D is often thought of in terms of modern and legacy versions of the spec, with pre-4.0 being considered legacy and anything 4.0 up being the more modern versions.

Whatever project you work on, you need to make sure that any other partner companies or contributors are also working in the same issue of the spec. This is agreed at the start of the project and documented in business rules which are shared between companies.

In short, no.

Or at least not necessarily because the version/issue of the specification you use will not normally be your choice.

If you’re working on a project which spanning across the whole supply chain, the version of the S1000D specification you use will have been chosen by the responsible partner company (RPC) – the company to whom the data is ultimately integrated into the final publication – and will have been documented as part of the business rules which you’ll have been given. Or, in the case of defence products, it’s possible that your defence department will have a version they have chosen as their default version to be used for any new projects. And this is often not necessarily the latest version.

There is no point in trying to play catchup with the specification. If you have ‘legacy data’ in versions of the spec which have long been superseded, unless there is a good business case for migrating all that data, the chances are it just isn’t worth it. The effort and planning involved in migrating a dataset to a newer version of the spec is often very difficult to justify as the benefits are often few and far between. However, this is quite a sweeping statement and there may of course be a good reason for the effort.

Document types, or doc-types is what we use to describe the different types of document that S1000D supports at a data module level.

S1000D supports lots of document types such as Descriptive, Procedural, Illustrated Parts data, fault diagnosis and numerous others depending on the issue of the spec you’re working with.

An S1000D Common Source Database (CSDB) is a fundamental part of using the S1000D specification.

The S1000D CSDB is essentially a content management system that manages all your data and ensures conformity to the S1000D specification. Typically, a CSDB would manage things like version control, workflow, users, permissions, metadata, and various other aspects of your data depending on the vendor of the CSDB in question.

Most have the above functionality to one degree or another, but some offer far more than others and some are simpler to use. You can have a look at the details of the CSDB in our Xignal solution here and see the features ours offers.

S1000D CSDBs can be complicated.

Complicated to set up, complicated to manage and complicated to use in some instances. Not to mention dated in their approach. In fact that’s the very reasons we started from scratch when developing our S1000D CSDB, we wanted a modern approach to S1000D content management and to remove the complexities and knowledge barriers to entry.

XML, and specifically S1000D schemas, do not care about the page layout or formatting.

One of the advantages of using this structured language approach, is that we, as authors, do not need to worry at all about the way the final publication will look or what output format it is in.

As long as all the data is structured in accordance with the rules of the S1000D schema, we can output that data in any way we want, in any format we want, with any look and feel we want, at a later date.

We can publish to PDF, web, interactive publication viewers or any other electronic or printed medium we wish, using specific S1000D publishing tools.

BREX is an abbreviation for Business Rules Exchange. It is a specific data module whose job is to hold a set of computer readable rules, against which each and every data module gets validated against to make sure it conforms to the rules. The BREX file which is checked against is specified in the DMs themselves.

BREX is used to tailor the S1000D specification for your project needs. The BREX is typically shared between partner companies to ensure each company write their DMs against the same set of project specific rules, over and above that of the S1000D rules. The BREX contains Business Rule decisions which can be checked via electronic checkers.

Business Rules are a set of documented rules which are typically agreed at the start of a project. There are a large number of Business Rule Decision Points (BRDPs) within each issue of the S1000D specification that leave you, the user, to decide.

In very recent versions of the spec, a specific BrDoc schema was introduced, enabling you to document the business rules with an S1000D data module. Prior to that, these were typically just documented in Word documents to be distributed between partner companies on the respective project.

Applicability is a very powerful part of S1000D.

It allows you to mix and reuse data for multiple variations of products and various conditions, or states, under which that product might be at any given point.

For example, if we have a car, we may have various models of the car, which is 80% similar but may have some different procedures depending on which engine is installed, and depending under what temperatures the car is operated in. As opposed to duplicating vast amounts of data, we can allow for these deltas using applicability, which can later be filtered, giving the end user the specific data they need for their product and condition.

Conceptually not that complicated, but it can get complex and we will revisit applicability in a future post as it deserves its own spot!

Sure you can. But is it easy? No.

There is a lot of planning involved in converting large amounts of data to the S1000D specification.

Before you start, you need to think about the SNS of your product to enable you to codify your data and create a DMRL.

You need to think about how well your data naturally fits into S1000D, and you need to consider the legwork of actually getting the data out of the existing format and into S1000D XML.

Fortunately, there are tools which make this easier. We developed a tool specifically for this process and you can find out more about our S1000D conversion tool here.

The three main tools you need for most S1000D projects are the S1000D CSDB (to manage your data), the S1000D editor (to create your data) and the S1000D publisher… yep you guessed it, to publish your data.

There are various tools out there to do one or all these things.

To answer the question more specifically, to create S1000D you need an S1000D editor.  Most of these are generic XML editors which can be configured to work with S1000D. This can make adoption of the S1000D spec more difficult due to the steep learning curve in using the XML editor and or the need for a deep understanding of S1000D. The good news is that our S1000D editor which is a component of our Xignal S1000D Suite is designed to be as easy and intuitive as writing in Microsoft Word!

The supporting document that explains how to use and implement S1000D is 3,500 pages. It’s not the kind of thing you can skim-read and start using in earnest to create your documents or manuals for your equipment. So what do you do?

For most organisations implementing S1000D for the first time, an introductory S1000D training course is usually the best first step. Whether this is something you do remotely or in a classroom, it means that your team can learn the basics of the S1000D specification and how to get things right from the outset.

Our S1000D training is always tailored to suit you and your project, and we look at real world scenarios as well as some hands-on authoring.  This is an important aspect to look for if you think training is a good next step for your team as you want to be able to learn how to implement S1000D for your specific needs.

If you would like to talk to our team about S1000D training options and prices then please email us [email protected] or reach out to Kate Hawkins on LinkedIn.