AIA/Tri-Service 2004 Publications Workshop San Antonio, TX

AIA/Tri-Service 2004 Publications Workshop San Antonio, TX 2004-02-09
S1000D Tutorial Compressed introduction to the Spec AIA/Tri-Service 2004 Publications Workshop San Antonio, TX

Mr Dennis Hoyland BA, MBA
Chairman Technical Specification Maintenance Group Assistant Director Corporate Technical Services Technical Documentation Defence Logistics Organisation, United Kingdom

Agenda History – Organization - Overview – Future AIA Activities
Dennis/Carl AIA Activities Denny/Sean/Ryan Overview of publishing Paul/Tam/Jan S1000D in the digital world Svante/Peter/Kathy/Ryan Discussion

S1000D Issue 2.0 The vision – The reality
The way to a true international tech pubs spec AECMA S1000D - Tutorial San Antonio, TX

The objective of this introduction is to
explain who AECMA and AIA are? give a historical flashback to the development history of AECMA Spec 1000D to S1000D describe the international maintenance organization present the new structure of Issue 2.0 Some new features of Issue 2.0

Who are AECMA and AIA?

Who is AECMA? AECMA is an organization
The European Association of Aerospace Industries, AECMA, represents the European defense industries in common issues, with the goal of increasing the competitiveness in the sector All EU countries are represented Belgium, Denmark, UK, Finland, France, Greece, The Netherlands, Ireland, Italy, Luxembourg, Portugal, Spain, Sweden, Germany, Austria, Czech Republic, …. Produces standards and specifications (among other things), eg Simplified English. Dictionaries and writing rules. AECMA Specification 2000M for materiel administration AECMA S1000D for Technical Publications

Who is AIA? AIA is an organization AIA corresponds to AECMA
The Aerospace Industries Association, AIA, represents the US aerospace industries in common issues, with the goal of increasing the competitiveness in the sector. AIA corresponds to AECMA BIGGER with more employees and operations Eg Boeing, Lockheed Martin, General Dynamics … Participants in development of standards and specifications (among other things), eg iSpec2200 (”owned” by ATA) Simplified English. Dictionaries and writing rules. AECMA S1000D for Technical Publications

History

History 1984 AECMA countries and MoD customers started the development of an international Specification for Technical Publications to harmonise all national and international specs into a "Western" specification based on ATA Spec 100. 1989 First release signed by Air commodore RAF, Generalleutnant GAF, Brigadergeneral SwEF, etc 1998 NCMB - Oslo meeting Goal: Develop an internationally supported Roadmap for Interactive Technical Documentation 2000 NATO ITD WG - Bonn meeting

The NATO ITD Interop Task Force

Result form NATO ITD Interoperability Task Force
S1000D Change 8 MIL-PRF-87269 U.S. DoD NATO Roadmap “ITD” IETP “X” Chap #5 Draft XML MIL-HDBK-511 The JIA Extract the Best/Complementary components from the above NATO Roadmap

Approval of final drafts
Ch9 → Ch 10 → Issue 2/S1000N Anno 2001 S1000D Ch9 CPF MIL-HBK-511 S1000D Ch10 Restructuring 1 Sea Land S1000N Restructuring 2 SGML Mid 2002 Deadline for CPFs Air Issuing of Issue 2 Approval of final drafts Issuing of Change 10 MIL-PRF-87268 MIL-PRF-87269 Roadmap from Fairmont March 2001 as the result of the NATO ITD workshops. Presented to AIA PSC in Clearwater 2001

Interactivity 1 (Process DM)
S1000D – The Roadmap 2003 Release of Change 2.x May 2003 Issuing of Issue 2 S1000D Ch9 CPF MIL-HBK-511 S1000D Issue 2 Restructuring 1 Sea Land (+GBF) S1000D Change 2.x SGML Air MIL-PRF-87268 MIL-PRF-87269 Interactivity 1 (Process DM) Interactivity 2  Oct 2003 Release of Issue 2 XML Schema The just updated and approved Roadmap 2003

Organization

S1000D Maintenance organization
AECMA - CPSC Customer & Product Support Committee TPSMG Tech Pubs Spec Maint Group D Hoyland/C-J Wilén/ Denny Raitz EPWG Electronic Publications WG Svante Ericsson/Peter Zimmermann Land Publ WG (LPWG) P Haslam /T Faleij Sea Publ WG (SPWG) Tom Malloy AIA Product Support Committee S1000D User Forum TPSMG Exec Air Publ WG (APWG) Ferry Berendi Chair Co-chair EU Co-chair US Secr Chair EPWG Chair LPWG Chair SPWG + 2 representatives from each country The “formal” decision forum Meets only “on condition”

AECMA - CPSC Customer & Product Support Committee TPSMG Tech Pubs Spec Maint Group D Hoyland/C-J Wilén/ Denny Raitz EPWG Electronic Publications WG Svante Ericsson/Peter Zimmermann Land Publ WG (LPWG) P Haslam /T Faleij Sea Publ WG (SPWG) Tom Malloy AIA Product Support Committee S1000D User Forum TPSMG Exec Air Publ WG (APWG) Ferry Berendi TPSMG Chair Co-chair EU Co-chair US Secr Chair EPWG Chair LPWG Chair SPWG Germany ind France ind Italy ind UK MoD USA DoD The common working forum - The decision forum Meets regularly 3-5/year (Europe/US)

AECMA - CPSC Customer & Product Support Committee TPSMG Tech Pubs Spec Maint Group D Hoyland/C-J Wilén/ Denny Raitz EPWG Electronic Publications WG Svante Ericsson/Peter Zimmermann Land Publ WG (LPWG) P Haslam /T Faleij Sea Publ WG (SPWG) Tom Malloy AIA Product Support Committee S1000D User Forum TPSMG Exec Air Publ WG (APWG) Ferry Berendi Customers and Vendors Arranged by TPSMG Exec Bi- annual Fall mtg – Europe Spring mtg - US

AECMA - CPSC Customer & Product Support Committee TPSMG Tech Pubs Spec Maint Group D Hoyland/C-J Wilén/ Denny Raitz EPWG Electronic Publications WG Svante Ericsson/Peter Zimmermann Land Publ WG (LPWG) P Haslam /T Faleij Sea Publ WG (SPWG) Tom Malloy AIA Product Support Committee S1000D User Forum TPSMG Exec Air Publ WG (APWG) Ferry Berendi Chair and co-chair appointed by TPSMG Exec + workers appointed by the chair/co-chairs Chair (and co-chair) appointed by TPSMG Exec + workers appointed by the chair/co-chairs

National supporting organization
AECMA - CPSC Customer & Product Support Committee TPSMG Tech Pubs Spec Maint Group EPWG Electronic Publications WG Land Publ WG (LPWG) Sea Publ WG (SPWG) AIA Product Support Committee S1000D User Forum TPSMG Exec Air Publ WG (APWG) National representative/TPSMG Ver Ver National EPWG National Land Publ WG National Sea Publ WG National Air Publ WG

Note to Dennis: The flags at the bottom are: South Africa, Norway, Hungary and The Netherlands

Some basic definitions …

Basic concepts Data module CSDB (Common Source DataBase)
A stand alone information unit comprising descriptive, procedural, operational data for a Materiel or a component thereof The unit is produced in such a form that it could be stored and retrieved from a Common Source DataBase by the data module code as the identifier Produced in SGML/XML according to specific DTDs CSDB (Common Source DataBase) A store for the data modules and publications DMC (Data Module Code) A 17- alt 37-charchter code to identify a data module and to facilitate storing and retrieving them from a CSDB ICN (Illustration Control Number) A 27- alt 45-charchter code to identify an illustration and to facilitate storing and retrieving them from a CSDB Applicability/Effectivity Defines to which version/mark/serial number of the Materiel the data module is written/The published subset of “applicability”

Restructuring Started in 1998

Four and a half years later
More than 100 CPFs has been generated, discussed, analysed, dissected, … … and some rejected 70+ CPFs has been accepted and included The Spec has become a tri-service spec incl Land, Sea, Air Materiel The spec has been completely restructured Change 9 has become Issue 2

Mr Carl Wilén M Sc Co-Chair Technical Specification Maintenance Group
Technical Fellow Informatics Saab Aerosystems Sweden

Structure of S1000D

Three becomes one Issue 2 The Materiel Change 9

Restructuring – From five to nine chapters
Issue 2 Chapter 1 Chapter 2 Chapter 5 Chapter 3 Chapter 6 Chapter 4 Chapter 7 Chapter 8 Chapter 9

Information management
Chapter 1 Introduction Chapter 4 Information management Issue 2 Chapter 2 Documentation process Chapter 5 Information and publication sets Chapter 3 Information generation Chapter 6 Information presentation/use

Information processing
Chapter 7 Information processing Issue 2 Chapter 8 Standard Numbering System (SNS) and information codes Chapter 9 Terms - Data dictionary

What’s new?

Introduction Chapter 1 1.1 Purpose 1.2 Scope
Issue 2 Chapter 1 Introduction 1.1 Purpose 1.2 Scope 1.3 How to use this specification 1.4 How to tailor for a specific project 1.5 Request for change

Documentation process
Issue 2 Chapter 2 Documentation process 2.1 Overview 2.2 Use of standards 2.3 Relations to other processes and standards Process diagram referencing S1000D chapters

Information generation
Issue 2 Chapter 3 Information generation 3.1 Introduction 3.2 Data modules 3.3 Information sets 3.4 Zoning and access 3.5 Updating of data modules 3.6 Security and data restrictions 3.7 Quality assurance 3.8 Disassembly principles 3.9 Authoring (incl Process modules)

Chapter 3 Information generation Author and illustrator support: In depth information Project decisions listed Guidance, examples and mark-up examples are added Illustration rules - Jointly with AIA/ATA - ATA iSpec2200 rules are accepted - Color - More illustration sizes

Chapter 3 Information generation Improved configuration control and security coding Process data module - a procedural flow script The first step towards full interactivity in standardized form Provides for additional functionality without impacting existing legacy data

Process data module Chapter 3 Information generation Process Data module DMNode DMNod Data module If-DM Data module Data module DM-Alts Data module Data module

Chapter 3 Information generation Wiring DTD New data module type and wiring DTD Takes wiring data from engineering into DMs and further to IETP

Issue 2 Chapter 4 Information management 4.1 Introduction 4.2 CSDB 4.3 Data module code - DMC 4.4 Illustration control number – ICN 4.5 Data module lists 4.6 Commenting 4.7 Version control of data modules 4.8 Interchange of data modules 4.9 Publication management

Chapter 4 Information management New data module code – DMC An extended, more flexible, numbering system for data module codes Ml BATTLETANK1234 -Y -040Y SNS IC/ICV ILC -YYYY SDC DC/DCV -04YYY

Chapter 4 Information management Commenting - an SGML form for commenting and reporting - on data modules or publication modules - during the verification process and the in-service

Chapter 4 Information management New concept for CSDB Publication module (PM) and Publication Module Code (PMC) has been added to control configuration of IETP content

Information sets and Publications
Issue 2 Chapter 5 Information sets and Publications 5.1 General 5.2 Information sets 5.2.1 Common information sets 5.2.2 Air specific information sets 5.2.3 Land/Sea specific information sets 5.3 Publications 5.3.1 Common requirements 5.3.2 Air specific publications 5.3.3 Land/Sea specific publications

Information and publication sets
Information set An “information set“ is the definition of scope and depth of the information required, and is listed in the DMRL. (Author’s view). Chapter 5 Information and publication sets Publication A group of DMs sensibly for the end user defined by a publication module. (User’s view).

Information presentation/use
Issue 2 Chapter 6 Information presentation/use 6.1 Introduction 6.2 Page-oriented publications 6.3 Interactive Electronic Technical Publications – IETP 6.4 Functionality

Information presentation/use
Chapter 6 Information presentation/use Page-oriented publication A linear presentation of the data modules either on paper or screen IETP A non-linear presentation of the data module in an user-interactive manner

Interactive Electronic Technical Publications – IETP
Chapter 6.3 Interactive Electronic Technical Publications – IETP Interactive Electronic Technical Publications – IETP Introduced XML-oriented IETP (IETP-X) included Removal of - IETP-L (linearly structured SGML publications) - IETP-D (database-oriented SGML/HyTime publications) - IETP-H (linearly structured HTML publications) - IETP-I (integrated processes)

Interactive Electronic Technical Publications – IETP
Chapter 6.3 Interactive Electronic Technical Publications – IETP Interactive Electronic Technical Publications – IETP Not yet in the Spec Chap IETP – Look and feel Chap IETP – Output specification Chap IETP – User interface functionality

Chap 6.3.1 IETP – Look and feel Common look and feel concept
Chapter 6.3.1 IETP – Look and Feel Chap IETP – Look and feel Introduced Common look and feel concept Purpose To establish minimum common requirements for the look and feel (style) of IETP. Background US AIA/DoD Tri-Service initiative to create a common IETM “Look and feel” document Based on Based on Mil Hbk 511 and other national requirements

Chap 6.3.2 IETP – Output specification
Chapter 6.3.2 IETP – Output Specification Chap IETP – Output specification Purpose To provide basic rules an guidance for styling of elements for display To provide basic rules an guidance for printing output of IETP

Chap 6.3.3 IETP – User interface functionality
Chapter 6.3.3 IETP – User Interface Functionality Purpose To provide general rules for implementation of standard functionality for the user interface of IETP To be used in conjunction with Chap 6.4

Chap 6.4.3 Not yet in the Spec Functionality matrix for deliverables
Chapter 6.4 Information Presentation/Use - Functionality Chap Functionality - Background and explanation Chap Functionality - Functionality matrix Chap Functionality - Acquisition management Chap Not yet in the Spec

Chap 6.4.1 Functionality - Background and explanation Introduced
IETP Functionality matrix Chapter 6.4 Functionality Purpose - Created to rid the industry of the “unofficial” IETM/IETP Classes I - V Background Revamped by AIA to update to current capabilities (technologies) - Adopted by AECMA as “Apples to Apples” comparison tool

Chap 6.4.2 Functionality - Functionality matrix Introduced
How to use the matrix chapter Chapter 6.4.1 Functionality – Background and Explanation Content - Contains the “How to use”, Category definitions, and Functionality definitions

Acquisition Management
Chapter 6.4.3 Functionality – Acquisition Management Chap Functionality - Acquisition management To be supplied in a later change IETP Acquisition Management Purpose To provide information and guidance on the acquisition of IETP (including lessons learned from fielded systems)

Issue 2 Chapter 7 Information processing 7.1 Introduction 7.2 Basic concepts 7.3 CSDB objects 7.4 Generation of publications 7.5 Information interchange 7.6 Software requirements 7.7 Guidance and examples

Chapter 7 Information processing Attribute values - flexibility - using configuration files XML Schema - Now introduced for data modules (in parallel with SGML DM DTD)

Standard Numbering System (SNS) and information codes
Issue 2 Chapter 8 Standard Numbering System (SNS) and information codes Maintained SNS: 8, eg General surface vehicles General communications Air vehicle, engines and equipment Example SNS: 18, eg Combat vehicle project Mil Std 1808 based project 8.1 Introduction 8.2 Maintained SNS 8.3 Example SNS 8.4 Information codes 8.5 Summary

Terms - Data dictionary
Issue 2 Chapter 9 Terms - Data dictionary 9.1 Introduction 9.2 Glossary of terms 9.3 Data dictionary Data dictionary Links to databases (downloadable) for definitions of all elements and attribute for SGML DTD XML Schemata

Now free on the web S1000D Issue 2.0
International Specification for Technical Publications utilising a Common Source DataBase AECMA - AIA The European Association of Aerospace Industries Aerospace Industries of America Issue Now free on the web

Mr Dennis Hoyland

What did we “miss” in Issue 2?
Future – Issue 2.1/2.2/2.3 What did we “miss” in Issue 2? New stuff

Issue 2.x Remaining CPFs Starter Tool kit - The Bike
50+ to discuss, analyze, … … and some to be rejected Starter Tool kit - The Bike Will include 45+ DMs and PMs, DDN, DMRL, … Both SGML/XML instances and output examples FOSIs, Style sheets XSL/CSS Conversion script Change 6, 7, 8 or 9 to Issue 2.0 (The Sledgehammer)

Starter Tool kit - The Bike
Bicycle data modules Descriptive Procedural Illustarted parts data Fault isolation Crew/Operator Schedules (Maintenance planning) Wiring Process data module

Exchange Data Module List - DML Data Dispatch Note - DDN Publication Module - PM Illustrations Computer Grahics Metafile (CGM) Raster

Scripts (for IETP-X neutral format) SGML to XML conversion URL/URN Resolution XLink attributes RDF/DC Meta data

Software The Sledgehammer Change 1.6 Change 1.7 Change 1.8 Change 1.8.1 Change 1.9 Change 2.0 Change 2.x Converter Converts any S1000D version change to any other (both ways)

Output XSL Stylesheets CSS PDF examples for all data module types FOSI Framemaker (?!) Epic (?!) A free basic functionality viewer (?!)

Issue 2.x The remaining chapters:
Chap x Page-oriented presentation – Layout examples Chap IETP – Look and feel Chap IETP – Output specification Chap IETP – User interface functionality Chap Acquisition management

Issue 2.x Multimedia formats
audio, video, 3D, Virtual Reality, … Completion of Interactivity and diagnostics interface An extended Process data module or A new Interactive data module Common ATA / AECMA / AIA SVG profile Applicability / Effectivity improvements Include new DM type “DACR” (Damage Assessment, Control and Repair)

Issue 2.x Exchange mechanism for project attribute configuration files
ADL/SCORM linkage (MoU in development) Close up of procedures – New model PLCS/STEP linkage (MoU in place)

Issue 2.x New CPFs New CPF procedure and more … …

S1000D – The Roadmap 2003 and onwards
S1000D Change 2.1 Cleaning Feb 2004 Release of Change 2.1 S1000D Change 2.2 Nov 04 Release of Change 2.2 New features Mid/Late 2005 Release of Change 2.3 S1000D Change 2.3 Major change May 2003 Issuing of Issue 2.0 S1000D Issue 2 Oct 2003 Release of Issue 2.0 On the web mid April

Questions!? Thanks for your attention!

Mr Denny Raitz Associate Technical Fellow – Technical Data
Co-Chair Technical Specification Maintenance Group And AIA Representative

AIA Publications Overview
Last Two Year’s Accomplishments Current/Ongoing Activities Future Plans 2004 Goals and Objectives

Accomplishments Tri-Services Support
Dec. ’03 – First S1000D Tutorial to US DoD (NAVSEA) Sept. ’03 – S1000D Published May ’03 – S1000D Issue 2.0 Released Feb ’03 – S1000D & Functionality Matrix Update, IETM Subject Matter Expert Meeting, Huntsville Jan ’03 – “Look & Feel” Requirements Meeting, Tri-Service Technology Working Group, Tyson

Accomplishments – Cont’d
Functionality Matrix Support May ’03 – AECMA Technical Publications Specification Maintenance Group (TPSMG) Meeting, Clearwater Feb ’03 – S1000D “Emergency” Look and Feel Meeting (Change 10), Washington D.C. Nov ’02 – S1000D Update, TPSMG Exec. 8th Meeting, Washington D.C. Oct ’02 – AIA Fall Conference (MOU, Workshops, Demos), Williamsburg May ’02 – S1000D Update, TPSMG Meeting, Saint Louis

S1000D (Meetings) December 2003 Tyson’s Corner, VA (Tutorial) October 2003 Poitier, FR (1st User’s Forum) June Munich, GE May Clearwater, FL January Turin, Italy December Tyson’s Corner, VA November, Wash, DC November, Glasgow, UK October Williamsburg, VA September Berlin, GE September 2002 Bordeaux, FR June Washington, DC May St. Louis, MO

Resulting In Issue 2 Impact: 12 Change Proposals with Technical Solutions Submitted and Excepted Functionality Matrix Incorporated Issue 2.X Training Incorporation Diagnostics Look and Feel Finalization

Since 2000: AIA Provided Approximately 450 Work-Weeks of Labor and 120 Trips of Domestic/International Travel

On-Going Activities Tri-Service Support S1000D Development
Will Continue to Provide Technical Expertise Upon Request Will Continue to Serve as Interface for S1000D Development S1000D Development US-TPSMG US-EPWG Change Proposal Forms DoD/ADL/AECMA/AIA MOU To Incorporate Training Requirements Into S1000D Functionality Matrix Updates Look and Feel Finalized Multimedia and Other Graphic Format Investigations

Overview of Publishing
Jan Roberson Co-Chair US TPSMG Paul Haslam Chair EU Land WG Tam Malloy Chair EU Sea WG

Areas to be Covered This session covers how information will be: generated exchanged and output We are also going to attempt to answer some of the questions raised through our last workshop We want it to be relaxed and we want to generate discussion

Questions What is done with business rules and any associated documents that support them, like program specific data module selections? And how are those put together so the same kind of manual is generated each time the author starts one? The UK MOD has a standard to tell them how to do this, but the rules documents are not available, as far as I could find. I know we have an idea of what this all means, but a practical example would be helpful. Go over examples of business rules. Explain how business rules are generated and maintained. Explain issues with integrating data modules developed by various vendors (explain how data modules for components can be built independently and lessons learned in the integration process). How are the Data Module contents related/linked to weapon system configuration?

Generation S1000D provides Data Module Business Rules Information Sets
Structure Coding Business Rules Information Sets Specific Example

Every data module has this
The Data Module Every data module has this All of DM Address Meta data about the data module Issue details Data Module Security Applicability IDSTATUS QA Status One of Descriptive IPD CONTENT Procedural Crew Fault Schedules What the user sees Wiring Process

Applicability

Applicability Part of this allows us to “link” the data contained within the content element to the physical The <model> element could be used to “tie” the content to a specific configuration, build status, etc Notice this links to last question-How are the Data Module contents related/linked to weapon system configuration?

Security Security – Data Restrictions Instructions Information
Distribution Handling Destruction Disclosure Information Copyright Security Policy Reference Special conditions

The Data Module IDSTATUS Data Module Data Module Address
Data Module Code Issue Details Model Ident System Difference SNS DC DCV IC ICV ILC

CSDB Data Module Common Source Database Data (CSDB) Module IDSTATUS
All of IDSTATUS Issue details DM Address Security Applicability QA Status Data Module One of CONTENT Descriptive Procedural Fault Crew IPD Schedules Process Wiring

Issue 2 DMC Issue 2 Data Module Code
Third part of the SNS Fixed length at 1 alpha-numeric character Identifies differences in the function of a system (No change to pre-issue 2) Variable length between 1 and 4 (inclusive) alpha-numeric characters Eg Can be used as a single character entry in the same way as pre-Issue 2 or 3 characters to capture SLUOC from b based LSAR or 4 characters to capture UOC from 49506 Modelic System Diff Code Chapnum Section Subsect Subject Dis Code Dis Code Variant Info Code Info Code Variant Item Location Code Identify the project (No change to pre-issue 2) Variable length between 2 and 14 (inclusive) alpha-numeric characters First 10 can give the project name and can be drawn from the End Item Acronym Code of a b or based LSAR Last 4 can give the equivalent of the End Item Usable On Code (3 characters from b based LSAR and 4 characters from based Fourth part of the SNS Variable length at either 2 or 4 alpha-numeric characters 4 characters can be used to cater for large number of LRUs on bigger projects First part of the Standard Numbering System (SNS) Now can carry the Material Item Category Code, as defined in Def Stan 00-60 Variable length at either 2 or 3 alpha-numeric characters Information Code No functional change from pre-Issue 2 Fixed length at 3 alpha-numeric characters with special rules as below: XXX as currently defined XXY Not given (project defined) XYY NOTGIVEN (Projects to apply to TPSMG via CPF for allocations) YYY NOTGIVEN (Projects to apply to TPSMG via CPF for allocations) Disassembly Code Variant Same basic function as pre-Issue 2 Variable length at 1, 2 or 3 alpha-numeric characters Eg 1 characters for use as in pre-Issue 2, 2 characters to capture the ALC from b based LSAR and 3 characters to capture the Alternate Indenture Product Code from 49506 Item Location Code No functional change from pre-Issue 2 Fixed length at 1 alpha-numeric character Disassembly Code No change in function from pre-Issue 2 Fixed length at 2 alpha-numeric characters Second part of the SNS Fixed length at 1 alpha-numeric character Same structure as pre-Issue 2, therefore maintains backward compatibility Information Code Variant No functional change from pre-Issue 2 Fixed length at 1 alpha-numeric character

Implementation Allocate project name as pre-Issue 2 and register with NAMSA Allocate SDC as pre-Issue 2 but can use for example the UOC Optionally use a MICC to allow multiple SNS types Model Ident System Difference SNS DC DCV IC ICV ILC

Implementation Allocate SNS as pre-Issue 2 but
8 SNS‘s that are maintained by TPSMG by CPF 17 example SNS‘s not maintained If none fit – write your own! Allocate disassembly under the rules for disassembly as pre-Issue 2 Model Ident System Difference SNS DC DCV IC ICV ILC

Implementation Allocate Disassembly Code Variant as pre-Iss 2 but you can populate it with the ALC or AIPC Allocate Information Codes as pre-Iss 2 but with more scope Allocate Information Code Variant as pre-Iss 2 Allocate Item Location Code as pre-Iss 2 Model Ident System Difference SNS DC DCV IC ICV ILC

Interoperability Basic Structure Data Module IDSTATUS DM Address
Issue Details Security Applicability QA Status Content Procedure

Integration Issues Integration is only a problem if you do not solve it at initial program stages Traditionally S1000D has not dealt with this aspect, however! Lessons learned from implementation require: A project infrastructure be created The next section deals with this

Management – Program Needs
S1000D deals with data generically Requirement still exists to establish program constraints Dictated by documents detailed within program: TDMP DMP DMRL Business Rules Illustration guide

Document Management Plan
Detailed plan covering Scope of Technical Documentation Coding, Generation and Storage Data Module Requirements List (DMRL) Publishing and Distribution Amendment Process Programme Management, Quality, Security Risk Management

Document Management Plan
High level plan detailing documentation requirements for the project Covers Scope of documentation Security QA Programme Standards

Scope of Technical Publications
Covers the type of information required and its scope and depth Corrective maintenance Logical, concise, step-by-step procedures shall be produced for tasks detailed in the LSAR. Corrective maintenance includes repair, alignment and adjustment. Repair procedures are to contain instructions for removing, replacing and re-assembling defective equipment. Special procedures for removing, replacing and testing PROMs and similar devices are to be detailed. Where the maintenance procedures require several data modules at a given SNS, then the ICV is to be used commencing with alphanumeric characters 1 – 9 then A onwards. The IC 282 shall not be used on ASTUTE

DMRL What is a DMRL A Data Module Requirements List identifies all data modules required for a given program It can detail links to source data (eg LSAR) It is recommended

DMRL (cont) The DMRL includes:
The elements of the IDSTATUS section required within it and their definitions Uses the SNS and Information Codes as its prime reference

In the S1000D Context S1000D contains rules in the specification and its DTD/Schema However, Areas of the specification are open to interpretation by projects The content of elements may be decided by projects There is more than one way to mark-up information using the DTD/Schema

Business Rules Business rules are required to:
Provide help, interpretation and guidance in using S1000D Remove ambiguity in the specification by giving examples Ensure consistency in CSDB deliverables Highlight to projects where decisions need to be made

Business Rules Each project may need to define its own project specific Business Rules which will cover: The population of the content of mandatory elements How to tailor the content and usage of elements Element level Attribute level

Business Rules Essential in: Managing customer requirements
Collaborative projects Providing a requirement to suppliers Avoiding re-work or disputes

Business Rules IDSTATUS Elements: Detail how to use the address and status section and relate the rules to the DTD eg: DMC, how to construct and how to mark-up Relationship between DMC and DMTITLE Issue Date Language, etc

Business Rules Example: <dmtitle>
The element <dmtitle> is mandatory for the Type 45. The element comprises technical name <techname> element and information name <infoname> element. The title gives the meaning to the SNS and information code elements of the DMC. To ensure the data modules are generated in a standardised manner, the following rules apply: The <techname> is related to the item identifier, detailed in the Terminology database (Reference 6) and contained within the elements <chapnum>, <section>, <subsect> and <subject> in the DMC. In this example AE indicates “Internal Telephones”. The <infoname> is the short definition of the element <incode> in the DMC. In this example, “520” indicates “Remove Procedures”. Data module titles are to be entered in Title Case (e.g. “Internal Telephones” rather than “Internal telephones”). Markup example: <techname>Internal Telephones</techname> <infoname>Remove Procedures</infoname> </dmtitle>

Business Rules Content Section Mark-up Required conditions
Rules for all data module types Required conditions Rules completion of procedural data module, including mark up Rules for Descriptive, including rules for primary paragraphs, sub paragraphs etc. Rules on use illustrations, tables, lists etc

Business Rules The AECMA business rules are at the core.
Partner company business rules The AECMA business rules are at the core. Eg for RPC record the NCAGE Project Business Rules: The responsible partner company shall identify itself by: Use of its NCAGE. Company A = K9999. Company B U5647 Company C = D3432 Partner Company Business Rules Responsible Partner Company shall contain the company NCAGE Project Business Rules S1000D Business Rules Here the Aecma Business rules, for this project, mandate the use the NCAGE. The project business rules define the companies and NCAGE. The RPC rules state that for information generated by us enter our NCAGE

Business Rules Summary
They are required and projects need to recognise this Issue 2 contains many examples where projects can make a choice Other choices will be project specific Business rules are essential for success Example Business Rules will be available for Bike Test Pack

Business Rules Summary (cont’d)
Agreed between parties and recorded Guide to the different types of data modules and explanation of their purpose Covers optional elements Records population and content of elements Details the use of specific values in the configuration file (Svante to explain) Relates the rules in the specification to the construct of the DTD/Schema Contains Authoring guide

Info Set/Publication An Information Set defines the scope and depth to meet the requirement (author view) A publication is the compilation and publishing of information for a customer (customer view) Note that a publication can be a subset of or equal to an info set, but it may also be a superset of several info sets or parts of them

Generic Set S1000D information sets were reviewed by each of the working groups and a generic set was agreed that could be used by all three environments Look at the structure of traditional publication versus S1000D publications. Click to map across. Pages have no direct equivalent in a data module world. This is one of the issues regarding outputting paper pubs from a CSDB that needs to be resolved. This is discussed later.

Generic Info Sets Crew/Operator information Equipment Weapon loading
Description and Operation Maintenance Information Wiring diagram data Illustrated parts Data Maintenance Planning Mass and Balance Recovery Equipment Weapon loading Cargo loading Stores loading Role change Battle damage repair Illustrated tool and support equipment Service bulletins Material data Common information and data Look at the structure of traditional publication versus S1000D publications. Click to map across. Pages have no direct equivalent in a data module world. This is one of the issues regarding outputting paper pubs from a CSDB that needs to be resolved. This is discussed later.

Specific Info Sets for Land and Sea
Crew/operator descriptive information Crew/ operator operation Crew/ operator sequential operation Crew/ operator fault detection, isolation and resolution International, national and regulatory scheduled Look at the structure of traditional publication versus S1000D publications. Click to map across. Pages have no direct equivalent in a data module world. This is one of the issues regarding outputting paper pubs from a CSDB that needs to be resolved. This is discussed later.

Crew/Operator Operation Information
What does an Information Set look like? Dust conditions Recovery or tow away Crossing of stretch water NBC conditions In case of fire at the land/sea Materiel Make unserviceable or destruction of the land/sea materiel Emergency procedures Transportation Equipment stowing Land/sea Materiel operation Operation (physical breakdown orientated) Operation (functional breakdown orientated) Land/sea Materiel operating data Operating under special conditions Heat conditions Cold conditions Look at the structure of traditional publication versus S1000D publications. Click to map across. Pages have no direct equivalent in a data module world. This is one of the issues regarding outputting paper pubs from a CSDB that needs to be resolved. This is discussed later.

Information Sets Operation (physical breakdown orientated)
What information is presented in an information set? Operation (physical breakdown orientated) The operation data modules shall include all descriptions necessary to perform the operation of Materiel to put into operation, to operate during use or to turn off the defined Materiel. The operation description shall be created as a step by step structure. It shall also include all preliminary requirements as a description or as a reference to the related data modules. Safety conditions and – instructions must be included inside the data modules or inserted as a reference to the related data modules. Data modules shall be coded YY-A-YY-YY-YY-YXA-XXXA-A, where value for IC shall be 111, 112, 121, 131, 141 or 151 Note that this is a 17 character code and is not a mandatory length This defines the scope of the required information This is how that information is coded on data modules

Publications List of Applicable Publications Maintenance
User Reference Guide (or Operator’s handbook) Crew/operator information – Description Crew/operator information – Operation Crew/operator information – Sequential operation Crew/operator information – Fault detection, isolation and resolution Crew/operator information – National checks Crew/operator information - Maintenance Mass and Balance Maintenance Description Maintenance procedures Check lists Work cards Fault detection, isolation and resolution Schematic diagrams Wiring data Cross servicing Structure repair Non-destructive testing Corrosion control Illustrated parts data Illustrated tools and equipment Battle damage repair

Publications Maintenance planning Maintenance requirements Check lists
Work cards Loading and storage Cargo loading Weapon loading Stores loading Storage Operation Role change Recovery Material data Material data sheets List of consumables/expendables Service bulletins

Exchange S1000D used to provide the Mil Std 1840 profile
This process has been replaced: The transfer “file type” has to be agreed within the project, and can include: GZIP, ZIP, TAR, etc

Exchange Several types of packages can be transferred within S1000D, however each must have A Data Dispatch Note (DDN) and at least one of the following: One or more data modules and associated illustrations One CSDB Status List (CSL) One Data Module Requirement List (DMRL) One or more Comment forms (COM) One or more Publication Modules (PM)

Exchange What S1000D mandates is the contained file types and naming conventions Example Data dispatch note (DDN) CONTROLNUMBER is the data dispatch note identifier in the form: MI-SSSSS-RRRRR-XXXX-NN_III-WW MI = model identifier SSSSS = NCAGE code of sending Agency or Partner Company (A/PC) RRRRR = NCAGE code of receiving A/PC XXXX = Year (eg 1999, 2001) NN = Unique sequential hex interchange number per year starting with value "00" III = Issue number WW = inwork number DDN-AE-C0419-K _ SGM

Output S1000D has two output mediums: Page Oriented
IETP (IETD,ITD,IETM etc) This is probably the area that will have the most significant input from the US and is currently being developed

Output - Page Oriented Page oriented within the specification is detailed in various areas and covers: Rules for the page layout of standard and oversize pages Rules for headers and footers are detailed together with basic rules for paper publications Rules for all layout elements used to present the SGML/XML information in the data modules to the S1000D standard Formatted Output Specification Instances (FOSI), XML Style Sheets (written in the XML Style Sheet Language) or cascading style sheets Examples of S1000D standard presentations of front matter, descriptive, procedural, etc

Output - IETP S1000D will provide details of presentation and use, however this is under development Various browsers will be shown at the AIA Technology Demonstration and some of these will reflect the S1000D constructs

IETP Navigation There are many methods of IETP navigation currently available. These include but are not limited to: Table of Contents Graphical

IETP Navigation (TOC) A breakdown of the equipment based on the system structure Main Equipment System Level Sub System Level etc.

IETP Navigation (Graphical)
A sequence of figures linked to provide a ‘drill-down’ provides rapid access to data Rapid access to required data At each level of drill-down access to Descriptive, Maintenance, Fault Diagnosis and Parts list information may be given by buttons

Simplified Viewer Graphical User Interface (GUI)
Interface is clean and simple Buttons provided on tool bar for advanced functions Menu options also provided

Navigation S1000D will define: Use of Windows The control pane
Data pane templates Typographic guidelines Display of tables Display of warnings cautions and notes Display of animation and video Display of links Use of colour, etc Draw picture of screen and panes

Navigation The minimum functional Navigation aids are as follows:
Frame forward / backward / return to start Search (simple search) - To start of module only to avoid possible oversight of Warnings, Cautions or other safety related information Mark (with a bookmark) Retrace (list of previous steps) This is the minimum requirement in the specification. Spec is happy to have more detail but as usual you have to consider the impact of this.

Output – The Future The following issues are under development:
Look and Feel Navigation Functionality This is the minimum requirement in the specification. Spec is happy to have more detail but as usual you have to consider the impact of this.

Overview of Publishing Summary
The following issues have been covered: The generation of data modules The exchange of information Output This is the minimum requirement in the specification. Spec is happy to have more detail but as usual you have to consider the impact of this.

Questions

Svante Ericsson, Chairman EPWG
S1000D in a digital world Svante Ericsson, Chairman EPWG Sörman I&M, Sweden

Session agenda Technical concepts, entities and techniques (Svante Ericsson, SI&M) S1000D, XML and the web (Peter Zimmermann, EADS) S1000D data distribution strategy in perspective (Kathy Rainbolt, US AF) S1000D relation to PLCS and Scorm (Ryan Augsburger, CDG) What will happen next? (Svante Ericsson)

Concepts, entities and techniques
The Digital Data objects Data modules, publication modules, data dispatch notes, comments, data module lists (illustrations) The Common Source Database (CSDB) Legacy data Tailoring

The Data Module From the very beginning S1000D has provided a standard way for represen- tation of technical publications in a digital format Marked-up using SGML A number of DTDs for various types of data modules Marked-up using XML

The Data Module (contd)
This is the content section of a data module. It contains all the factual information in one specific respect, applying to a certain materiel item …….. content id & status This is the content section of a data module. It contains all the factual information in one specific respect, applying to a certain materiel item …….. Consists of a number of files a text file a number of illustration files Contains its meta data identification status Doesn’t contain any layout information

The Publication Module
Provides a method to collect data modules into publications Hierarchical structures Configurations By referencing A marked-up file (SGML/XML)

Contains a list of the data objects included in the transfer
The Data Dispatch Note Contains a list of the data objects included in the transfer Mandatory part of an S1000D information interchange A marked-up file (SGML/XML)

Used to identify required data modules in a project (DMRL)
The Data Module List Used to identify required data modules in a project (DMRL) Used to identify status about data modules in a project (CSL) A marked-up file (SGML/XML)

Used to submit comments between parties in a project
The Comment Used to submit comments between parties in a project Question, preliminary and final answer A marked-up file (SGML/XML)

Can be in one of the formats
The Illustration Can be in one of the formats CGM, CALS raster, TIFF, PNG, JPEG, GIF, PDF Can contain hotspots (CGM) S1000D tries to follow ATA iSpec 2200

Can be implemented in any thinkable way
The CSDB Is a storage for the various digital objects, in particular the Data Modules incl. their illustrations Can be implemented in any thinkable way It doesn’t have to be a DBMS It can be any proprietary file system Usually it is some sort of document administration tool

Encapsulation in a data module (as an “illustration”)
Legacy data There are a couple of ways of addressing legacy data in accordance with S1000D: Conversion Encapsulation in a data module (as an “illustration”) Contained in an publication (referenced by a Publication Module)

An implementation of S1000D can be tailored in many respects
Tailoring of S1000D An implementation of S1000D can be tailored in many respects Either of SGML or XML Implement a subset of DTDs/Schemas Implement a subset of a certain DTD/Schema (!) Apply a subset of attribute values (project.cfg)

Apart from the specification chapters:
Apart from the specification chapters: DTD/Schema packages for SGML/XML (downloadable) Data dictionaries for all DTDs and Schemas – on-line and downloadable More to come ….

Thank you!

Peter Zimmermann (EADS Germany)
S1000D – XML – The Web S1000D Tutorial San Antonio, TX, USA Peter Zimmermann (EADS Germany)

First step with Issue 1.9 taken in 2001
Transition to XML First step with Issue 1.9 taken in 2001 New IETP category (XML-oriented) CSDB data modules only in SGML Transformation to XML for IETP delivery Why XML? Optional SGML features not needed/utilized Make CSDB objects usable over the Internet More widespread use (not only Tech Pubs) Supported by more and cheaper tools

Retained as CSDB format All textual information objects in SGML
SGML in Issue 2.0 Retained as CSDB format All textual information objects in SGML Data modules (wiring + process types are new!) Publication modules (new!) Data dispatch notes Comments (new!) Data module lists

XML DTDs supporting the publication process object types
XML in Issue 2.0 XML DTDs supporting the publication process object types Publication modules Data dispatch notes Comments Data module lists

XML Schemas supporting all textual objects
XML in Issue 2.0 (contd.) XML Schemas supporting all textual objects Data modules Publication modules Data dispatch notes Comments Data module lists XML Schemas 2.0 reflect SGML DTDs

Arguments for XML Schemas
XML in Issue 2.0 (contd.) Arguments for XML Schemas Schemas are XML instances (same “language”) Data typing possibilities Technological trend Potentials for S1000D with XML Schemas First step in Issue 2.0 taken (1:1 from SGML) Incorporation of project business rules Reduction of effort for guidance document / project specific style guides

Generation of IETP XML neutral translation CSDB source data + Xlink + RDF/DC: Translate SGML to XML - Add Xlink attributes - Add RDF/DC metadata IETP display transformation XML neutral form + IETP generated data: Apply output transformation (XSLT, XSL-FO) Resolve URN to URL - Add navigational links - IETP state management IETP Entities XML + XLink xlink:href with URN IETP neutral repository Authored source XML or SGML - Data modules - Publication modules CSDB source data files Rendered IETP XML output spec - CSS/XSL - Hyperlinks (URL) - View in web browser IETP end user display form repository

Location independence of S1000D resources
Resource resolution Location independence of S1000D resources Data modules and publication modules Illustrations Catalog sequence numbers (references to IPD) Comments URN Namespace registration: S1000D Example for a unique data module web address URN:S1000D:DMC-AE-A … Resource resolution (URN to URL translation)

Publication module namespace
XML Namespaces Publication module namespace <pm Data module namespace xmlns:pm=“ xmlns=”http: xmlns:xlink=” xmlns:rdf=” <dmodule xmlns:dc=”http ://… XLink namespace xmlns:dm=” xmlns:xlink=” xm lns:rdf=” <refdm xmlns:dc=” RDF and DC namespace xmlns:xlink=” xmlns:rdf=” xmlns:dc=” xmlns:rdf=” xmlns:dc=”http ://… ”

XML Namespaces (contd.)
ddn dml comment

Link transformation example Reference to another data module

refdm – SGML CSDB <refdm> <avee> <modelic>AE</modelic><sdc>A</sdc> <chapnum>07</chapnum> <section>0</section> <subsect>7</subsect> <subject>0400</subject> <discode>00</discode><discodev>A</discodev> <incode>040</incode><incodev>A</incodev> <itemloc>A</itemloc> </avee> </refdm>

refdm – XML Repository <refdm xlink:type="simple"
xlink:actuate="onRequest" xlink:show="replace" xlink:title="IETP resource resolution" xlink:href="URN:S1000D:DMC-AE-A A-040A-A"> <avee> <modelic>AE</modelic><sdc>A</sdc> <chapnum>07</chapnum> <section>0</section> <subsect>7</subsect> <subject>0400</subject> <discode>00</discode><discodev>A</discodev> <incode>040</incode><incodev>A</incodev> <itemloc>A</itemloc> </avee> </refdm>

refdm – HTML display <a href="http://www.s1000d.org/
DMC-AE-A A-040A-A.XML"> AE-A A-040A-A</a>

Questions? Thanks for your attention Peter Zimmermann
EADS Military Aircraft D Munich / Germany Phone: Fax:

What is ADL? Advanced Distributed Learning DoD initiative
Purpose: “Ensure access to high-quality education and training materials that can be tailored to individual learner needs and made available whenever and wherever they are required.”

What is SCORM? Shareable Content Object Reference Model
Suite of Standards Defines Content Aggregation Model Defines Run Time Environment SCORM defines meta-data to describe reusable content objects SCORM does not define structure of training content objects (ala S1000D DTD)

Content Aggregation Assets are aggregated into Shareable Content Objects which are sequenced and structured into packages that meet specific learning objectives. CSF SCO Tagged Content Aggregation Meta-data Asset WAV HTML Fragment GIF XML Doc JavaScript Functions Flash Object JPEG SCO content.htm Api=getAPI(); Var result = api.LMSInitialize(“”); Var val = api.LMSGetValue(cmi.abc.xyz”); Var result = api.LMSFinish(“”);

S1000D / ADL / AIA MOU Memorandum of Understanding between S1000D, ADL, and AIA In signature cycle “The Parties wish to co-ordinate their activities to develop an integrated approach to development and distribution of learning and technical data/information.”

S1000D / ADL / AIA MOU Benefits
Position work with respect to other groups Minimize duplication of effort & unintended differences Minimise effort in preparing future Tech Pub and Training objects by improving alignment of technical data with SCORM. Develop standardized linkage between tech data modules and learning information objects Assist the ADL to achieve the Training Transformation Initiative

S1000D / PLCS What is PLCS? Product Life Cycle Support
Extension to STEP (ISO ) STEP is traditionally focused on engineering and manufacturing PLCS extends STEP to the maintained fleet Organized by product structure Model includes maintenance data as well as operational data

S1000D / PLCS Four pillars of PLCS Configuration Management
As-maintained Bill of Material Enhanced master records center/database Maintenance and Feedback Management and execution of maintenance tasks Maintenance Feedback / Records Maintenance history Configuration changes Support Engineering Logistical Support Analysis Reliability Centered Maintenance Maintenance Tech pubs and service bulletins Resource Management Supply Chain, Spares People, skills, tools, facilities

S1000D / PLCS Memorandum of Understanding between S1000D and PLCS
Dated Established framework of cooperation Agreed initial work plan Potential future work

S1000D / PLCS Agreed Initial Work Plan (verbatim)
Initial agreed work program under the Memorandum of Understanding between PLCS and S1000D. PLCS will review AECMA 1000D Change 9 to: Identify potential gaps in PLCS Requirements Identify a set of PLCS Ref Data which is consistent with S1000D The Parties will co-operate in developing a process diagram illustrating how the S1000D process would interact with the PLCS Application Activity Model. PLCS will offer the Data Modules Requirement Statements for Task & Resource and Document Modules for review by S1000D participants. S1000D will identify volunteer(s) to work with PLCS to develop a common set of requirements for effectivity/applicability management. S1000D participants will seek to identify and release compliant sample Data Modules from S1000D for use in testing PLCS. PLCS will investigate and advise how the S1000D Data Module Code breakdown could best be represented in PLCS and to develop appropriate Reference Data. The Parties will meet to plan a joint campaign to promote awareness of this co-operation and its potential benefits to both communities.

S1000D / PLCS S1000D and PLCS will be able to peacefully co-exist
PLCS will be able to provide the baseline for writing instruction DMs PLCS will be able to provide configuration data for use in applicability/effectivity PLCS will be able to interpret S1000D Data Module ID and Status section

Overview What is a publication? Data Distribution Concepts Summary
Linear IETM S1000D Data Distribution Concepts Summary

Tech Data Structures A weapon system using linear electronic tech pubs (eg 38784)… Each pub is a separate, individually configurable object All Pubs for the materiel Descriptive Information Procedural Information Operator Manual LOAPs Fault Isolation Procedures Etc. Illustrated Parts Data Their primary relationship to each other is that they are associated with the same materiel Linear tech pubs do not require the use of a DB or a logic engine

Tech Data Structures A weapon system using an 87269 IETM…
Presentation Engine Logic Engine Descriptive Information Procedural Information Illustrated Parts Data Fault Isolation Procedures Operator Manuals LOAPs etc. A single IETM DB contains all* the technical data associated with the materiel (*with exception of externally referenced data) The entire IETM DB is the smallest* configurable object (*with exception of graphic objects) 87269 does not provide for a means to distribute and update objects smaller than the entire IETM. Boeing (and perhaps Raytheon) have established methods for updating individual nodes. However, these are proprietary methods and may not apply in an enterprise environment. The logic and presentation engines are separate from the data

Tech Data Structures A weapon system using S1000D… Logic Engine
Common Source Data Base (CSDB) contains all the technical data associated with the materiel as individual data modules Presentation Engine Logic Engine The Data Module is the smallest configurable object allowed by the spec A pub is a collection of Data Modules The logic and presentation engines are separate from the data

Linear Distribution Concept
ETM or Linear Electronic Tech Data Example: Linear Pub (eg 38784) All Pubs for the materiel Descriptive Information Procedural Information Operator Manual LOAPs Fault Isolation Procedures Etc. Illustrated Parts Data Individual Pubs TO–2B TO-1A Procedural Information Fault Isolation Procedures Newly Requested Pubs TO-3C TO–4D Newly Requested Pubs Modules TO–4D TO-3C Entire CSDB CSDB sub-set (w/out Process Data Module) S1000D 38784 tech data can be distributed as individual TOs from origination point to end user. Changes, within the context of the AFCV, are distributed as TO-sized objects. Graphic objects are distributed as individual objects, separate from the text, from origination to end user. S1000D (as an ETM instance) can be distributed as individual Data Modules (DM) from origination point to end user. DMs distributed from local repository to end user would be distributed in the form of DMs linked by a Pubs Module – roughly equivalents of TOs. Changes can be distributed as individual DMs. Repository User eTool This is meant to represent the concept of distributing electronic TO content to an end user (not Paper). It is not meant to represent an actual architectural view.

Linear Distribution Concept
ETM or Linear Electronic Tech Data Change Example: Linear Pub (eg 38784) All TOs for the materiel Descriptive Information Procedural Information Operator Manual LOAPs Fault Isolation Procedures Etc. Illustrated Parts Data TO–4D TO-3C Individual Pubs TO–2B TO-1A TO–2B TO-1A Operator Manual Illustrated Parts Data Changed data TO–2B – change 001 TO-1A – change 001 Entire CSDB CSDB sub-set (w/out Process Data Module) S1000D 38784 tech data can be distributed as individual TOs from origination point to end user. Changes, within the context of the AFCV, are distributed as TO-sized objects. Graphic objects are distributed as individual objects, separate from the text, from origination to end user. S1000D (as an ETM instance) can be distributed as individual Data Modules (DM) from origination point to end user. DMs distributed from local repository to end user would be distributed in the form of DMs linked by a Pubs Module – roughly equivalents of TOs. Changes can be distributed as individual DMs. Repository User eTool This is meant to represent the concept of distributing electronic TO content to an end user (not Paper). It is not meant to represent an actual architectural view.

IETM Distribution Concept
IETM or Non-Linear Tech Data Example: No standard for distributing IETM sub-sets Entire IETM DB Entire IETM DB Entire IETM DB Entire IETM DB 87269 Newly Requested Pubs Modules Entire CSDB CSDB sub-set (w/ Process Data Module) S1000D 87269 does not provide for a means to distribute and update objects smaller than the entire IETM. Boeing (and perhaps Raytheon) have established methods for updating individual nodes. However, these are proprietary methods and may not apply in an enterprise environment. Repository User eTool This is meant to represent the concept of distributing IETM TO content to an end user. It is not meant to represent an actual architectural view.

IETM Distribution Concept
IETM or Non-Linear Tech Data Change Example: Changed data No standard for distributing IETM sub-set changes Entire IETM DB Entire IETM DB Entire IETM DB Entire IETM DB 87269 Changed data Changed data Entire CSDB CSDB sub-set (w/ Process Data Module) S1000D 87269 does not provide for a means to distribute and update objects smaller than the entire IETM. Boeing (and perhaps Raytheon) have established methods for updating individual nodes. However, these are proprietary methods and may not apply in an enterprise environment. Repository User eTool This is meant to represent the concept of distributing IETM TO content to an end user. It is not meant to represent an actual architectural view.

Summary S1000D has discrete data modules with well-defined metadata
This allows for more granular configuration management This enables the development of architectures and support process that can handle linear and non-linear data in a consistent and standard manner

Svante Ericsson, Chairman EPWG
What will happen next? Svante Ericsson, Chairman EPWG Sörman I&M, Sweden

Consolidated use of XML Support of multimedia objects
Ongoing development To pick some: Consolidated use of XML Support of multimedia objects Mechanism for formalized exchange of business rules Interactivity further developed (US EPWG meeting Tuesday!) Enrichment of online data dictionaries

Thanks again! Questions?

AIA/Tri-Service 2004 Publications Workshop San Antonio, TX

Similar presentations

Presentation on theme: "AIA/Tri-Service 2004 Publications Workshop San Antonio, TX"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

AIA/Tri-Service 2004 Publications Workshop San Antonio, TX

Similar presentations

Presentation on theme: "AIA/Tri-Service 2004 Publications Workshop San Antonio, TX"— Presentation transcript:

Similar presentations

About project

Feedback