How to convert legacy
manuals to S1000D.

What does converting to S1000D actually mean?

Converting a manual to S1000D is not a change of file format. There is no export button that turns a PDF into data modules. The content has to be taken apart, sorted and written again: every description, procedure and parts list becomes its own data module, with its own code, in the structure the specification prescribes for that kind of information. The S1000D consultancy ONEIL puts it in one line: “conversion isn’t just mapping, it’s restructuring”.

That is why conversion projects are planned like engineering projects. The decisions come first, the writing second, and the checking runs through all of it. The seven steps below are the order that works.

Step 1: Agree the business rules

S1000D leaves many choices open, so every project writes its own business rules before the first module. They fix the issue of the specification, the breakdown of the product into systems, the information codes in use, how applicability is expressed and how warnings are worded. The rules a machine can check go into the project’s business rules exchange module, the BREX.

Rules decided halfway through a conversion mean reworking every module written before. An hour spent here saves weeks later.

Step 2: Plan the modules in a DMRL

The data module requirement list, the DMRL, lists every module the project will produce, with its code and title. It is the plan of the documentation, and the bridge between the old manuals and the new modules.

Start with an inventory of the sources: how many manuals, in which formats, from which suppliers, at which revision, scanned or digital. Then map each chapter of each manual to the modules it will feed. The gaps show up here, too: procedures the new modules need that no manual contains.

Step 3: Split the content into modules

A supplier manual mixes everything: a description of the pump, the safety notes, the removal steps, a parts table and a troubleshooting chart, often on the same page. Each of these goes into a different module type.

• Descriptions of how something is built and works go into descriptive modules.
• Removal, installation, inspection and test go into procedural modules, one task each.
• Parts lists go into illustrated parts data, with each part linked to its figure.
• Fault finding goes into fault isolation modules.
• Warnings, cautions, tools and supplies that recur everywhere are kept once, in common information repositories, and referenced from the modules.

The hard part is granularity. A module should cover one topic completely and nothing else. Too coarse and it cannot be reused. Too fine and the publication falls apart into fragments.

A worked example: one pump manual

Take the supplier manual of a seawater pump, installed in system 21-31 of a ship whose project code is HULL412. Four of its sections become four kinds of content:

The information code in the middle of each code tells the type: 040 a description, 520 a removal, 941 parts data. Everything else in the code stays the same, because all three are about the same pump.

Step 4: Rewrite into the structure

A procedure in S1000D is not free text. It has preliminary requirements: the conditions, the people, the support equipment, the supplies and spares, and the safety measures needed before work starts. Then the steps, then the closing requirements. Supplier manuals rarely put things this way, so most of the information has to be found and moved into place.

Values and units are checked on the way, references between modules are set, and if the project requires it, the text is written in ASD-STE100 Simplified Technical English.

Step 5: Bring the graphics along

Every illustration in S1000D has an information control number, the ICN, and is referenced from the module that uses it. Drawings from supplier manuals often need cleaning up or redrawing, and parts illustrations need hotspots that link each item number to its row in the parts data. Graphics are the part of a conversion that is most often underestimated.

Step 6: Validate and review

Every module is checked twice by machine and once by a person. The machine checks it against the schema of its type and against the project’s BREX. The person checks the content against the source: is every step there, in the right order, with the right values and warnings?

The second check is where conversion projects lose most of their time, because the reviewer has to find the passage in the old manual for every statement in the new module.

Step 7: Publish and keep it current

Publication modules assemble the data modules into the manuals the customer receives, as PDF or as an interactive electronic publication. Then the documentation enters its real life: suppliers revise their manuals, equipment changes, and every change has to reach every module it touches.

The mistakes that make conversions expensive

The same mistakes come up in every account of failed or overrun conversions, from the conversion specialists at Data Conversion Laboratory to ONEIL:

• Converting before the content has been analysed, so duplicated procedures are converted twice.
• Setting the business rules and the BREX late, so finished modules have to be reworked.
• Treating the conversion as a one-off project instead of the start of a new way of keeping documentation.
• Underestimating poor sources: scans, inconsistent terms, missing values.
• Tagging by hand what software could check.

Where does the effort go?

What this adds up to in money, and which numbers are public, is the subject of what S1000D really costs.

Where AI helps, and where it must not decide

Reading, sorting and first drafts are where AI saves the most time. A model can read hundreds of supplier manuals, find the passages that belong to a module, draft the module in its structure and check it against the schema and the BREX. Tracium does that, and links every step it drafts to the page it came from, so the review in step 6 becomes a check against the source instead of a search for it. Why that matters is in why every step needs a source.

What AI must not do is decide. When manuals contradict each other, when a value is missing or a step needs a drawing that does not exist, a person has to make the call. In Tracium these cases are flagged, and an expert approves every module before it is published.

How to start

Do not convert everything at once. Pick one system of the product with all the module types you will need, write the business rules, convert it end to end and measure each step. The pilot tells you what the rest will cost, and it tests the rules before hundreds of modules depend on them. On a naval programme, settle the questions in our contract checklist for yards first.