What You Should Know About S1000D. Background and Benefits of this Revolutionary Documentation Standard

Transcription

1 What You Should Know About S1000D Background and Benefits of this Revolutionary Documentation Standard

2 S1000D Then and Now The full name of the specification is actually The International Specification for Technical Publications Utilizing a Common Source Data Base S1000D, commonly known as S1000D. S1000D was initially developed in 1984 by the Association Européenne des Constructeurs de Matériel Aérospatial (AECMA), (The European Association of Aerospace Industries). AECMA represented the aerospace industry of fifteen European Union nations in common technical interest matters. The group started with the Air Transport Association (ATA) Spec 100, which was widely used in the commercial aviation community, and used it as the basis for development of a new European military specification. This new specification was first released in 1986, and given the name Spec 1000D. Issue 2.0 version, released in May 2003, signaled the first collaborative effort between Europe and the US. It incorporated a major restructuring of the spec, and added options of XML schema in addition to SGML DTDs. Issue 2.0 also addressed support of land and sea systems, the use of the spec became free of charge and was officially renamed to S1000D. The original contributions of the ATA (Air Transport Association) of its SPEC 100 as the basis for the S1000D specification have come full circle. In June of 2005, the ATA signed a memorandum of understanding with the Aerospace & Defense Industries Association of Europe (ASD) and Aerospace Industries Association of America, Inc. (AIA) to collaborate on the development of publication standards for aviation maintenance. The stated goal behind this agreement is to incorporate commercial aviation requirements (currently addressed by the ATA s ispec 2200 and envisioned in the Future Data Exchange project) into S1000D, and establish a worldwide single specification for both military and commercial aviation industries as well as land and sea systems. S1000D is in continual development and has gone through several revisions. Below is a list of the S1000D Issue release dates. Issue 2.0 May 2003 Issue 2.1 February 2004 Issue 2.2 May 2005 Issue 2.3 February 2007 Issue 3.0 July 2007 Issue 4.0 August 2008 Issue 4.1 December 2012 Issue 4.2 February 2017 Today, the S1000D standard is 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. It is controlled by the Steering Committee (SC), which has the full responsibility of maintaining the specification. The SC includes members from both government agencies and industry. To address the rapid development of information technology, the SC is supported by several standing working groups and temporary task teams that conduct the day-to-day work of developing, reviewing, and managing changes to the specification and XML schemas. Although currently targeted at technical publications, basic principles of data re-use in S1000D could also have much wider applications for all types of publications. Even the US Internal Revenue Service (IRS) and the Federal Aviation Administration (FAA) are experimenting with use of the specification on document management initiatives. S1000D is already widely used by the European military community, and is in fact mandated by the UK Ministry of Defence (UK MoD) as the required specification for delivery of technical documents supporting any large scale military program. There are also several US military programs that have already adopted S1000D, such as the Air Force F-117A and Global Hawk unmanned vehicle programs, the Naval Air Systems Command Joint 2

3 Strike Fighter (JSF) program, and the Army Future Combat System. Recently more Requests for Proposals (RFPs) from US military programs are also starting to include delivery of S1000D publications as a requirement for contractors submitting bids on the proposals. Paper vs. Interactive Electronic Publications Technical publications can be distributed in a number of different ways and via different media. The two primary categories for technical publications distribution are either (1) traditional page-oriented publications (for delivery on paper), or (2) Interactive Electronic Technical Publications or Manuals (referred to as IETPs or IETMs). A common terminology has emerged by which to categorize different types of publications according to their level of complexity (with regard to functionality for users). As depicted in the table below, publications are referred to at a high level as either Type I or Type II. Within each Type, there are specific Classes of publications. Class 0, I, II, and III are designated under the Type I category, and Class IV and Class V publications are assigned as Type II publications. The Type I publications generally adhere to a more traditional page-oriented presentation method, while Type II publications provide for delivery of fully interactive electronic manuals, with varying degrees of integration with other systems and resources as well. While Class V publications may be seen as the utopia or holy grail of technical publications that most manufacturers (and equipment users) would like to achieve, the reality is that today very few programs have successfully implemented Class V publications in accordance with their pure definition. Media Delivery Method Guide for Classes of Publications Type I Type II Class 0 Class I, II, III Class IV Class V Paper Electronic Interactive Class IV IETM Technical Electronic Technical plus Electronic Manual (ETM) Manuals (IETM) Infrastructure Formatting/ Presentation Methods Multiple volumes Electronic Emulation of Paper Manual Fully Interactive IETM IETM is linked to Maintenance Systems Level of Integration Capabilities Not linked or integrated at all May include electronic page turner and hyperlink functionality Includes functionality to automatically guide a maintainer through a maintenance troubleshooting process Integrated with Intrusive Diagnostics Systems Unlike most prior publication standards, S1000D is not exclusively focused upon the traditional concepts of a publication being structured based solely upon page-oriented book elements such as chapter, section, subsection, page, etc. The current ATA (Air Transport Association) ispec 2200, could be considered a standard 3

4 for delivery of Type I publications, as it is still largely based upon the premise of a technical publication being a published book (supporting a page-oriented format). Specific chapter numbers, sections and subsections in publications are designated as the primary identifiers to designate how certain pieces of equipment and/or repair processes related to that equipment are presented, and in what sequence. As an example, in an ATA standards-compliant Illustrated Parts Catalog for commercial aircraft, Chapter 32 always contains information about landing gear equipment and parts. This is true across the board, without regard to which manufacturer produced the aircraft, or which model of aircraft. Likewise, in the Aircraft Maintenance Manual, Chapter 32 always addresses the repair and maintenance procedures for you guessed it the landing gear. So with the ATA ispec 2200 and other standards, the structure of the book or the standard appearance of each page itself dictates how the information is tagged and organized. The end result is that in most cases, new technical documents are written and maintained independently as standalone books for each individual product, without regard to whether the document may contain components or subcomponents that are also used in other similar products (or publications) as well. In its early phases of development, the Spec 1000D standard was designed to support page-oriented publications (Type I). As electronic publishing and database technologies evolved, S1000D was later adapted to also encompass delivery of electronic publications with a high level of interactive functionality (Type II). S1000D is focused on individual, re-usable data elements, or data modules that are not necessarily associated with a page-oriented organization structure. However, S1000D can still support output in a paper-based book type structure (Type I) if required. With S1000D, the header and content sections of a data module are tagged in accordance with relevant S1000D SGML Document Type Definitions (DTDs) or XML Schemas as defined by the standard. With the release of Issue 4.0, the specification is XML only. It is these electronic tags and their attributes that provide the functionality that allows the information to be presented dynamically in an Interactive Electronic Technical Publication (IETP). In an IETP, data does not necessarily have to be presented in a static, page-oriented format, but can in fact be dynamically generated on the fly, based upon product configuration, operating conditions, and other knowledge obtained by other systems (such as a Maintenance Management System) or entered by a user of the IETP system. Individual data elements are called up over and over as needed to be presented in different display scenarios and publications. With an IETP, the very same landing gear data module that appears in a parts catalog may be retrieved again to appear in the troubleshooting or fault isolation manual, depending on what type of information the user wants to view. How Does S1000D Work? How is it Applied? A Modular Approach As discussed previously, S1000D differs from some other standards in that it is based on the principle of a data module, and not centered on the premise of delivery of a published (paper-based) book. A data module is defined as the smallest self-contained information unit within a technical publication. The most important part of this definition is self-contained. Each data module must be able to stand alone or be integrated into a larger publication. It must contain enough information to be standalone, in that it must have sense and meaning when viewed without any supporting data other than graphics. On a technical level, each data module must contain identification and status metadata about itself, as well as actual technical content. 4

5 The size of a data module is not mandated, but a module typically represents one discrete task, ranging from a couple of steps to many. For example, turn off electrical power, open access panel, and remove unit may each be created as a separate data module. You might be asking Why not create all three of these related steps as a single data module? If all of these three items were created as a single data module, then individual common tasks such as turning power off could not be easily reused and shared. All data modules that are applicable to the subject equipment are stored and managed in a database, which is referred to as the Common Source Data Base (CSDB). The benefit of a CSDB is to enable production output in either page-oriented or an Interactive Electronic Technical Publication (IETP) that is consistent regardless of the IT platform used. Information is not duplicated in the CSDB although individual data modules can be used and reused many times in the output. Data Modules Every data module has a unique data module code (DMC) that serves as an identifier and provides a mechanism for preventing duplication of data. Along with the issue number the DMC also ensures that every data module in the CSDB is unique. The standard provides detailed schemas and explanations to guide the determination of the DMC. S1000D uses a Standard Numbering System (SNS), tailored for each project. This SNS is aligned to the product structure, therefore because the SNS forms part of the DMC. The DMC also identifies how the sub-components being documented relate to the other components that comprise the product. Currently, S1000D data modules are structured to represent fourteen specific types of data. The IDSTATUS section of every data module is identical; only the CONTENT section is different. The data module types that DTDs and Schemas are provided for are: Descriptive Information Procedural Information Crew/Operation Information Fault Information Maintenance Planning Information Maintenance Checklists and Inspections Information Illustrated Parts Data Wiring Data Wiring Data Descriptions Interactive Procedural Information Business Rules Exchange Business Rules Documentation Front-Matter Information Service Bulletin Information Between issue 2.3 to 4.2, several more data module types were added. These new data module types are a break from the traditional view of a publication. They provide capabilities more in line with supporting data management and reuse. The new data module types that DTDs and Schemas are provided for are: Alternate DM Container Product Cross Reference Information Technical Condition Cross Reference Information Technical Repository Information Common Repository Information Applicability Cross Reference Information Training Information Update Information 5

6 All information in both header and content sections of a data module is tagged in accordance with the relevant S1000D SGML Document Type Definition (DTD), or XML DTD or Schema as defined by the standard. It is these tags and their attributes that provide the functionality that allows the information to be presented dynamically in an IETP. They provide the mechanism by which the logic and behavior required for the IETP to display the information is determined. Data Module Codes Data modules are identified by a Data Module Code (DMC). The DMC is used within the IDSTATUS section to identify the data module, and is also used to form the SGML or XML source file name. The DMC is structured as follows: Structure of an S1000 D Data Module Code (DMC) YYYYYYYYYYYYYY YYYY YYY-YY-YYYY YYYYY YYYY Y Model Identification Code System Difference Code Standards Numbering System Disassembly Code Disassembly Code Variant Information Code Information Code Variant Item Location Code The Data Module Code (DMC) is comprised of a total of 37 characters. Each section of the code identifies a specific portion of the information. In addition to the DMC, the identification also includes a title, issue number, issue date, language and country code. By analyzing this structure, one can tell (1) what product the data pertains to, (2) where the assembly that this data pertains to fits into the functional breakdown of the product, (3) where in the sequence of disassembly the task fits, and (4) what the detailed type of task is. S1000D is very specific on the DMC coding scheme. In fact, it devotes approximately 800 pages of the specification just to this one topic. 6

7 High Level Benefits Most experts will agree that the single greatest benefit offered by S1000D is the ability to reuse data. Reuse of data is in fact one of the primary drivers behind why S1000D was created in the first place. Similar to the stated vision of CALS in the past, the mantra of S1000D proponents has also become: Create once, use many times. With S1000D, once you have created a specific data module (containing either text or graphics), the data module is then stored in the Common Source Database (CSDB). You can then reuse and redistribute that very same data module in many other different projects or publications. This can bring a tremendous amount of time savings to the authoring process, as data modules are simply plugged in to any publication or project documentation as needed. Even greater gains can be realized through the life cycle of a long term project. Changes to the technical data only have to be made in one place as opposed to everywhere that data is used. In short, with S1000D there is no longer a need to recreate the same information over and over again for each individual publication. For example, the same descriptive information about a radar system that appears in a Flight Operations Manual used by pilots could also easily be inserted or referenced in a Maintenance Manual used by technicians, or an Illustrated Parts Catalog used by a parts procurement or inventory specialist. Three different publications, the same data, authored only once. As the technical publications world continues to transition away from delivery of paper manuals in favor of more interactive electronic technical manuals, leading standards like S1000D have become essential, and the driving force to support this technology trend. Yet it is important to note that the S1000D standard is also extremely flexible, in that it can easily support delivery of publications in a variety of electronic formats, while continuing to support delivery of traditional paper-based publications as well. As the transition from legacy paper publications to electronic delivery doesn t always happen overnight, S1000D is ideally suited as a roadmap to support organizations throughout this transition process. The revolutionary thinking behind the development of the S1000D standard is today beginning to come full circle, by bringing its substantial benefits to numerous military and commercial publications projects worldwide.

8 The Americas Europe India Corporate Headquarters 4060 N. Lakewood Blvd Building 801, 5th Floor Long Beach, CA USA Toll Free: +1 (800) Phone: +1 (562) First Floor, Building 1 Albany Place, Hyde Way Welwyn Garden City Hertfordshire AL 7 3BG UNITED KINGDOM Phone: +44 (0) Continental DataGraphics Technical Services India Pvt Ltd a Boeing Company Building #99-B37 Block 9A, 3rd Floor, DLF IT Park SEZ 1/124 Shivaji Gardens, Mount Poonamalle Road Manapakkam, Chennai INDIA Phone: S1000D-WYSK-0917-I