In the early 1980s, the concept of S1000D specification originated in the aerospace field within Aerospace and Defence Industries Association of Europe (ASD). Earlier in Europe various national specifications were used in technical documentation, this made data exchange between countries more difficult. During this same period, civil aviation was successfully using ATA S100 specification to deliver and exchange information internationally. The Aerospace and Defence Industries Association of Europe (ASD) had developed the S1000D specification, originated from the Air Transport Association (ATA) S100. From then on it emerged as a widely adopted standard in Europe by military projects.
S1000D also known as ASD S1000D is an international specification for the procurement and production of technical publications based on XML (extensible Mark-up Language), utilizing a Common Source Database. This specification offers a structured procedure regarding organization, processes, and management in the process of technical documentation and their publishing’s. It has become widely utilized and highly regarded across various sectors, and a good choice for documenting complex equipment with long life cycles such as defence, civil aviation, space, shipping, nuclear, automotive, rail and manufacturing. Finely tuned structures in this specification can also support sophisticated military and civil project life cycles.
The S1000D specification is now supported by the successor to AECMA, the Aerospace and Defence Industries of Europe (ASD), the Aerospace Industries Association of America (AIA) and the Air Transport Association (ATA). The specification is controlled by an international body, the S1000D Steering Committee (SC), which is responsible for maintaining it and includes members from both government agencies and industry. To address the rapid development of information technology, the SC is supported by a group of specialists known as the Electronic Publications Working Group (EPWG).
S1000D covers the planning, management, production, exchange, distribution and use of technical documentation that support the life cycle of any civil or military projects that include air, land and sea vehicles.
Business Rules
Business rules are major because they determine the implementation and processes to ensure consistent and complete content. These are decisions created by a project or an organization on how to implement S1000D. S1000D business rules are documented based on project and/or organizational requirements, and these determine and constrain all elements of a technical publication or the project.
S1000D also specifically defines Business Rules Decision Points (BRDPs). Business Rules Decision Points help us to create instructions and guidelines that affect authoring, presentation and distribution of publication for a project. Business rules written in computer language are stored in the BREX document. That BREX data module is then referenced inside each data module, hence the software and applications can validate that data module’s content to the referenced BREX.
S1000D now contains business rules categories. Combining your business rules into these business rules categories helps you with scope and normalization. The 11 business rules categories of S1000D are listed below:
1. General Business Rules
General rules cover overall decisions made by a project or an organization that are not covered by any of specific business rule categories. They serve as overall decisions for the implementation of S1000D.
These include
- What issue of S1000D suites the project.
- Parts of S1000d to be used in project implementation.
- Defining the terms used throughout the project
2. Product Definition Business Rules
Product definition business rules covers the data module coding strategy as to how the product is broken down either physical or functional. Including the model identification codes down subsystem level, supplier subsystems, applicability and identifications also need to be considered.
3. Maintenance Philosophy and Concepts of Operation Business Rules
These rules cover
- Usage of Item location codes.
- Decision on how to apply information code variants.
- Specifying information codes and information names that can be used in the project.
- Project specific information sets in detail.
- Deciding on how information code variant can be applied.
- Training and Skill levels.
4. Security Business Rules
Following are the business rules are included
- Defining of security classifications
- Copyright markings
- Use of disclosure
- Instructions for destruction
- National security restrictions
- Defining access to various “Classes” of data modules
5. Business Process Business Rules
Business process business rules cover the interaction with other disciplines into Technical Publications in an organisation, project level of organisation or project as a whole, agreed workflow procedures between manufacturer, subcontractor and customer and reuse of content across systems including training environment.
Rules to be considered in preparing a strategy for data module coding are
- The optimal reusable data granularity for screen presentation in learning products and the system maintenance philosophy for presentation in IETP.
- The development of maintenance, operational and learning content for use in interactive multimedia and simulations.
- The process of developing the appropriate amount of data modules that meet the intended need of an SCO in SCORM.
- The relationship between data module/publication module codes and the requirements for learning content registration.
6. Data Creation Business Rules
Data creation business rules give information about the creation of text, illustrations and multimedia objects.
The data creation business rules include:
- rules for creating textual data
- rules for creating graphics, 3D content and multimedia objects
(a). Data Creation Business Rules – Text
Text creation business rules consist of rules and guidelines (including terminology rules such as language and dictionaries, and the order of preference) for maximizing the amount of reuse that can be achieved within technical publications, and between technical publications and supporting training content.
Text creation business rules provide rules and guidance how the technical and learning content is to be developed. They also specify eg the use of dictionaries, how numbers must be expressed, how the author must refer to technical terms, how multimedia, maintenance, operational and learning content is to support IETP and training, and the establishment and use of a terminology database. Markup business rules provide information about which markup elements and attributes must be used and populated. These rules are often project or organization specific.
(b). Data Creation Business Rules – Illustrations and Multimedia
Illustration and multimedia creation business rules cover the creation of illustrations and multimedia objects. They are divided into style, detail and data format. Data style rules for illustrations and multimedia objects govern characteristics such as illustration sizes, use of color, line weights, fonts, projection methods (isometric or trimetric), etc.
The rules for illustrations cover for example the use of hotspots.
Data format rules cover the formats in which the information must be stored. For a CGM illustration, this will cover the elements that are permitted (eg coordinate types, polylines, restricted text). For raster images it can include the resolution and orientation. It is often difficult to separate style from format.
7. Data Exchange Business Rules
This data exchange business rules includes rules for usage of Data Dispatch Note (DDN), Data Module Requirements List (DMRL), Data Module List (DML), CSDB status lists, File based transfer protocol, Data exchange frequency. Rules for data module issue numbers and agreed criteria for acceptance and rejection between partners and customers. Acceptance and rejection are based on agreed criteria.
8. Data Integrity and Management Business Rules
These business rules enforce the referential integrity within the CSDB and are closely joined with the data exchange business rules and cover how creators and customers manage data. This includes internal, external workflow and Quality Assurance rules and processes. If required, this business rule category can contain rules determining the procedure for submission and acceptance of non-compliant information when providers are unable to generate S1000D compliant data.
9. Legacy Data Conversion, Management and Handling Business Rules
Legacy data conversion, management and handling business rules are totally different from other business rule categories which are mentioned above. This includes conversion rules containing mappings between elements and attributes of source and target specifications and rules for inclusion of legacy information in technical publications Eg: ATA ISpec 2200 project.
10. Data Output Business Rules
These data output business rules contain information over how to style elements and attribute content. The data creation business rules are associated with this data output business rule category, these rules define output formats for S1000D data and contain Interactive Electronic Technical Publication (IETP) formats, Sharable Content Object Reference Model (SCORM) formats and multimedia formats.
S1000D Data Modules
The content developed using S1000D standard stores data in the form of data modules in a Common Source Data Base (CSDB). Each data module is assigned a unique Data Module Code (DMC) that serves as a unique identifier, and implies to what type of element and data it holds. This prevents duplication of content into the CSDB. Data module codes are used to manage data modules in the CSDB. S1000D data modules are structured in accordance with their content type. At present there are 21 data module types, with content that vary from descriptive and procedural content, over to the added functionality carried by the applicability and technical repository data modules. S1000D offers SGML Document Type Definition (DTD) and XML Schemas to support these data module types. It should be noted that beginning with Issue 4.0 of the S1000D specification, only XML Schemas are defined.
Each data module is divided into two main parts, they are:
- An identification and status section (which is common to all data module types)
- A content section (particular to each data module type)
A list of current S1000D data module types are:
- Applicability cross-reference information
- Business rules exchange information
- Conditional cross-reference information
- Container information
- Crew/operator information
- Descriptive information
- Fault information
- Illustrated parts data
- Maintenance checklists and inspections
- Maintenance planning information
- Procedural information
- Process information
- Products cross-reference
- Reference information
- Common information repository
- Training information
- Wiring data information
- Wiring data description information
- Checklist
- Learning
- SCORM Content Package
As the name indicates, the ID and Status Section consists of all the data needed to find the data module in terms of its identification, or data module address. It also contains data related to its status, like its verification status, source information, security classification, applicability and other necessary information. The content section includes all content intended for the user information and is specific to the data module type. Identity of each data module is achieved using a coding system that offers unique identification code for each data module and prevents duplication. This code is also used for file identification, as it is used to form the data module’s filename. S1000D is very particular on the rules for this coding system known as the Data Module Code or DMC.
Common Source Database
The key element in information management is the CSDB. It is an information store and management tool for all objects required to produce the technical publications within projects. S1000D does not specify the design and implementation rules for a CSDB. It only specifies the data structure of the information objects, which is independent from any software implementation. All data modules applicable to the Product are gathered and managed in a database, which is here after referred to as the CSDB. A benefit of the CSDB is to enable production of platform-independent output in either page oriented or IETP. Data managed in S1000D is not duplicated in the CSDB. Data modules enable data to be stored once and used for multiple outputs. A single change to an individual data module can update multiple outputs and multiple deliveries.
DATA MODULE CODES
Data module code is partitioned into three types:
- Hardware identification
- Model identification code, System difference code, Standard Numbering System, Unit or assembly, Disassembly code, Disassembly code variant comes under hardware identification partition.
- Information type
- Information code, Information code variant, Item location code comes under information type partition.
- Learn type
- learn code, learn event code comes under learn type partition.
How to create a data module code in S1000D Specification ?
In the process of Data module creation here are the 13 steps to be followed,Once these steps are completed we will get a complete code like bellow.Example data module code: DMC-S1000DBIKE-AAA-D00-00-00-00AA-00PA- D_004-00_EN-US.
1. Creation of Model identification code
The model identification code determines the product to which data is applicable. Eg: S1000DBIKE was chosen as Model identification code. .
2. Creation of System difference code
System difference code determines another version of the system and subsystem/sub sub system. Eg: For System difference code AAA was chosen.
3. Creation of Standard Numbering System
The Standard Numbering System contains 4-5 numbers determining the system, subsystem, and sub subsystem. Eg: Following codes D00 as systemCode, 0 as subSubSystemCode and 0 as subSystemCode are chosen
4. Creation of Unit or assembly
The unit or assembly must contain two or four alphanumeric characters. Serial number starts from 01 or 0001. Eg: Here 00 was selected as Unit or assembly.
5. Creation of Disassembly code
The disassembly code must contain 2 alphanumeric characters,it determines the breakdown situation of an assembly to which maintenance information applicable. Eg: For Disassembly code 00 is selected.
6. Creation of Disassembly code variant
The disassembly code variant must contain 1-3 alphanumeric characters.It designates another item of equipment or elements differing slightly. Eg: Here AA was selected as a Disassembly code variant.
7. Creation of Information code
Information code must contain 3 alphanumeric characters, it determines the varieties of information within a data module. Eg: 00P as Information code is chosen.
8. Creation of Information code variant
The information code variant must contain 1 alphanumeric character, it determines any variation in the activity defined by the information code. Eg: Here A as an information code variant is selected.
9. Creation of Item Location Code
The item location code must contain 1 alphanumeric character, it determines the situation to which the information is applicable for example where the maintenance task will be carried out in terms of a product. Eg: D was selected as Item Location Code.
10. Creation of Issue number
Issue number code must contain 3 alphanumeric characters, for each release of a data module, the issue number should be increased by one. Eg: 004 is chosen as Issue number.
11. Creation of In work
The in-work number code must contain 2 alphanumeric characters. For In work 00 is selected.
12. Creation of Language
Two alpha characters from an international standard organization specifying the language. Eg: EN was selected for Language.
13. Creation of Country
Two alpha characters from international standard organization to specify the country where the language is spoken. Eg: US was chosen here for Country.
Here is the data module code with learn type
DMC-S1000DBIKE-AAA-D00-00-00-00AA-00PA-D-T25C
Learn code
- The Learn code must contain 3 alphanumeric characters
- In above example, learn code is represented by T25
Learn event code
- The Learn event code must contain 1 alpha character
- In above example, learn event code is represented by C
Information Control Number
Illustrations and multimedia are determined by a unique information control number. In a CSDB, ICN is the unique identifier of an illustration sheet, multimedia object, or attached data, and is used to establish the relationship to one or more data modules. The ICN is independent of file format and includes in the following mark-up elements:
Illustrations are usually
- Vector line drawings (CGM)
- Raster images (CCITT Grp/4, TIFF)
- Photos and another Artwork (JPEG, GIF, PNG)
- Multimedia can be of any defined type and are supported by the project’s business rules.
How to create a Information Control Number in S1000D Specification
In the process of Information Control Number here are the 6 steps to be followed, whereas Model Identification Code, System Difference Code, Standard Numbering System and Assembly Codes are similar and covered in the Data Module code breakup above. Once these steps are completed we will get a complete code like below. Example Information Control Number: – ICN-S1000DBIKE-AAA-DA10000-0-U8025-00512-A-004-1.
1. Creation of Responsible Partner Company Code
The Responsible Partner Company Code must contain 1 character , it is the company or organization responsible for the illustration multimedia object or other data independent of its use in the data module. It should be determine by the project or organization. Eg: 0 is chosen as Responsible Partner Company Code
.2. Creation of Originator Code
The Originator Code must contain 5 alphanumeric characters , it determines originator code originator of an illustration, multimedia object or other data. Eg: Here U8025 is selected as Originator Code.
3. Creation of Unique Identifier
The Unique Identifier must contain minimum 5 and maximum 10 alphanumeric characters , it starts from 00001 for each originating company. The identifier must be unique for each originator code. Eg: 00502 is selected as Unique Identifier.
4. Creation of Variant Code
The Variant Code must contain 1alpha character, it determines the variants of a basic illustration, multimedia object or other data. A variant is a supplemental scaled, cropped, rotated, mirrored, and/or annotated basic illustration, multimedia object or other data. Eg: A was selected as Variant Code.
5. Creation of Issue Number
The Issue Number must contain 3 digit numerical value with leading zeros, it starts from 001 for each basic illustration multimedia object or other data or variant, and is increased each time the illustration, multimedia object is updated. Eg: 004 is chosen as Issue Number.
6. Creation of Security Classification
The Security Classification must contain 2 numeric characters , it determines the security classification of the illustration, multimedia object or other data. An illustration, multimedia object or other data must use the security classification values defined by the project. The illustration, multimedia object or other data has its individual security classification independent of where it is used. If an illustration is reclassified, it is given a new issue number. Eg: 1 is selected as Security Classification.
S1000D Benefits
- S1000D specification is good for managing, creating, maintaining and publishing your technical documentation. And it reduces the maintenance costs for technical information.
- S1000D data can also be published constantly over various vendors and publications.
- Data modules support data reuse, enhances accuracy, and offers faster change cycles. Data modules are created and stored in CSDB. Re-Use of same data modules in different projects and publications reduces redundancy.
- Data module codes in S1000D offer complete system breakdown and enable a machine to understand what the file is about just by reviewing DMC. Tier level business rules allow consistency but also freedom to develop project-specific business rules.
- Provides the capability to create data repositories for part numbers, special tools, warnings, caution, and more. This means you can maintain this critical data in one location.
- Enhances the maintainer experience by using IETMs making content management easier while accessing data is quicker and more accurate.
- Information can be transferred between many IT departments, companies, and stakeholders, and successfully integrated using different common source databases (CSDB) and S1000D IETMs. It offers a single standard to support communication and data transfer among all participants in a given project.
- S1000D is Global standard, can be used across industries and a very active standard group maintaining this specification makes sure it stays up to date.
- Generally updating and maintaining technical documents takes a lot of time and is more expensive. By using data modules in place of chapters, sections and subsections as traditional page-oriented documents usage, the production costs are reduced. Different methods of delivery lower distribution costs and allow effective retrieval of the data.
- This specification gives end users a data rich and interactive document and helps to get accurate data to the end user, it makes the end user operator and maintainer’s life easier. It also enables sub set of data to be generated to meet specific user needs.
- Electronic publications are cheaper and quicker to produce than paper, users of electronic publications can be offered with updates very quickly.
