1. S1000D is robust, providing the complexity needed to support complex processes.

Because S1000D is a robust specification, it has sometimes earned an undeserved reputation of inaccessibility. It's understandable how difficult S1000D can seem to someone unaccustomed to system life cycle processes. A quick look at the Robin Cover Pages will show how many specs and models are out there covering an expanse of topics…some pretty zany.

All information-based specifications have a purpose rooted in the industry they support. For technical documentation that is directly tied to parts and configuration, S1000D uses XML as an information model. S1000D describes configuration and documentation requirements using XML structures that are explicitly named for the content being managed.

2. S1000D uses XML to tie technical data to equipment and parts through life cycle configuration and applicability.

S1000D does for technical data what inventory control mechanisms do for parts management: Data becomes a configuration item that must be created, tracked, modified and distributed. The rigor applied to data management ought to come from some type of neutral source in much the same way Universal Product Codes (UPC) provide standardized barcodes for tracking inventory. S1000D is an industry standard for the life cycle maintenance of air, land, and sea vehicles, but it can also apply to any technical system that requires parts management, operation, and life cycle maintenance.

S1000D's highly specialized information models (19 in all), collectively provide mechanisms to describe operations and maintenance, fault isolation, wiring diagrams, descriptive, parts lists, and process-oriented content regardless of the system being documented. In addition, when content needs to be updated in S1000D based on a system design change, S1000D provides data filtering mechanisms from a file to match the new system configuration. A key driver for using S1000D is its ability to identify the data modules needing to be changed when a design system change is required.

This is the power of data as a configuration item. If you work as an information manager where technical data must support complicated systems, you want to know exactly what content across all information products must be reviewed and changed if the supported system requires an alteration. If the system is altered, then the data must be altered. Using S1000D, one can manage content the way an inventory specialist manages warehoused parts.

3. S1000D's power is in its unique file naming convention, bringing configuration and logistics to technical data management. S1000D names, identifies, and structures technical data in reusable, topic-oriented, data modules.

Topics modeled in S1000D are represented as data modules (DMs). Each module contains a discreet piece of information supporting a discreet aspect of a system. A discreet piece of information is a thematically related set of content mapped to a particular task (e.g. changing oil in an engine, a list of materials associated with an operation, or a test procedure for surface cracks using magnetic materials). The name of the data module is semantically discreet based on naming conventions in the specification.

Naming conventions in an XML-based specification like S1000D are possible when the information structures are standardized according to industry conventions. The conventions offer data uniformity to multiple industries where life cycle maintenance and configuration are business process requirements. Figure 1 illustrates the standard data module code breakdown structure that is applicable to any industry where system maintenance and operation is required.

S1000D is applicable to such a wide variety of technical data because industries that create technical data for equipment and systems also must provide supporting documentation on maintenance and operational information. That documentation can come in the form of installation procedures, learning and training, maintenance, testing and evaluation, parts lists, brochures, pamphlets, web sites, etc. Because the topics are maintained as discreet data modules, there is opportunity for reuse. An installation instruction may be reused as supporting content in a lesson. A piece of maintenance information may be reused in a manual and on a web site.

Figure 1 - Standard data module code breakdown structure applicable to any industry where system maintenance and operation is required.

4. S1000D's data modules can be assembled into aggregate forms called publication modules.

A data module in and of itself is not an information product, just like a single part is not a complete system. Data modules, like engine parts, must be assembled. S1000D has a data assembly mechanism to collect data module names into an XML file called a publication module. The publication module does not produce output. It's a staging area that creates an inventory of data modules intended for a particular information product. Then, an application, or a style sheet, or a processing file, identifies the data modules required for a particular output instance. That instance could be a manual, or a set of procedures, each intended for the right data for the right time.

Calling it a "publication module" is not completely accurate because the reason to collect data modules together is not always for a publication. It is merely a data module gathering point structured in XML. The publication module will not know or care whether the collection is for training, or for on-demand data, or for a 5000 page catalog. Furthermore, the publication module contains its own naming convention. But there's an additional benefit in S1000D: Publication module names reflect the information product as well as being a tool for aggregating data modules in support of a product version. Figure 2 illustrates how select data modules are aggregated into publication modules, while reusing a specific data module in two outputs.

Figure 2 - Select data modules are aggregated into publication modules, while reusing a specific data module in two outputs.

5. S1000D uses metadata to track content through the acquisition, production and delivery processes.

Each S1000D data module carries the same set of metadata structures regardless of topic type. The metadata is divided into two subjects: identification and status. The identification piece carries the naming convention through the data module code. The status piece carries production information such as security and quality assurance. One piece of metadata might link an equipment design change to a required change in a data module. When a particular component is either replaced or redesigned, that component can be matched to any data module that requires a review. Maybe the data module contains learning objectives that must be updated. Or maybe the data module contains procedures that must be revamped. Or maybe a series of test procedures must be reconstructed. Regardless of whether the data module requires a change or not, there is peace of mind knowing that all relevant content has been reviewed against approved system design changes

6. S1000D can serve as a common digital data format for related technical data upon which life cycle logistics processes can be developed.

Life cycle logistics are the accumulated processes that support a product to its final destination: the user. Logistics include storage, delivery, change management, customer support, redesign processes, sustainability, installation, disposal, acquisition … any activity that supports a product or system, other than actually using the product by the intended audience. Each logistical activity requires documentation. Some goes to the customer, some remains in-house. Regardless, if a product design change results in a logistical change, then the documentation needs to change.

Technical documentation includes technical manuals, training content, planned maintenance, testing and evaluation, parts lists, schematics, simulations…any content that represents one aspect of life cycle support. Life cycle technical documentation ought to be coordinated into an industry-specific common digital data format. When all content is named, identified and structured into a common digital data format like S1000D, common life cycle metadata structures will be carried in each data module regardless of content type.

It is particularly useful to start with a common digital data format for all related technical data. It helps reduce the number of web-based applications required to process enterprise content. For example, if a Navy base in California uses S1000D to document a ship system, and a submarine base in Connecticut uses S1000D to document a submarine, then either organization could use a common web service that identifies any data module that is subject to change, updating it on the fly and assuring both organizations distribute correct information.

Conclusion

If you care about the ability to manage technical content as an accurate enterprise asset, then take a look at S1000D. It is the one industry-based technical documentation standard that offers the ability to unify your content in coordination with your company's business rules.