SDL-S1000D Training

S1000D Training Workshop

Overview of S1000D

The information contained in this presentation was gleaned and/or copied from the S1000D International specification for

technical publications, Issue 4.0,1 2009-05-12.

Information was also gleaned from The Aerospace Industries Association, A Recommendation to

the Department of Defense to Adopt the S1000D – the International Specification for Technical Documentation,

April 25,2008

Overview of S1000D

Information in this training covers the following:

• A brief history and the benefits of S1000D

• Discussion of the S1000D data types and associated codes:Data ModulesInformation Control NumbersData Module Requirements ListPublication ModulesData Dispatch Notes

• Applicability

• Business Rules

“S1000D is an international specification for producing technical publications. It is co-owned by the European Association of Aerospace Industries (ASD), the Aerospace Industries Association (AIA) and the Air Transport Association (ATA).

Although its roots are in the aviation industry, the specification supports any type of air, land or sea system or machinery that requires maintenance, operation and configuration to parts and supplies.”

Aerospace Industries Association, A Recommendation to the Department of Defense to Adopt the S1000

What is S1000D?

Overview of S1000D

“Amongst many S1000D working groups, the U.S.-based U.S. Specification Management Group (USSMG) and the international Technical Publication Specification Maintenance Group (TPSMG) have taken the lead in developing and maintaining the S1000D specification.”

“To assist the USSMG in defining and submitting U.S. interests toward the specification, the U.S. Specification Implementation Group (USSIG) was established under the USSMG to recommend detailed technical solutions, perform feasibility reviews, submit change proposals, and advise USSMG on a course forward.”

“AIA manages the USSMG and the USSIG.”

Aerospace Industries Association, A Recommendation to the Department of Defense to Adopt the S1000

Overview of S1000D

Why was S1000D developed?

In the 1980s, documentation for military projects in Europe used various national specifications, making data interchange between nations difficult.

During this same period, civil aviation was successfully using ATA S100 to deliver and interchange information internationally.

To ease interchange between nations, the AeroSpace and Defence Industries Association of Europe (ASD) (formerly AECMA) developed the S1000D specification; derived from ATA S100, it was widely adopted in Europe by military projects.

Overview of S1000D

Why has S1000D continued to evolve?

Documentation for military projects in the various U.S. joint services were written to various standards, making interchange difficult and often requiring each service to support multiple military specifications.

Documentation for military variants of commercial aircraft had to be converted into various mil-specs from civil aviation standards.

Overview of S1000D

“The most important factor in the development and oversight of S1000D is that it is an industry specification. Industry is the primary advocate for developing government-procured systems, and it is industry that sees the benefit in developing documentation in S1000D”

“Hundreds of individual DoD contractors that specialize in life cycle technical documentation have volunteered tens of thousands of hours over seven years to shape S1000D into a specification that can support all services and their equipment.”

Overview of S1000D

The Benefits of S1000D

“Most experts will agree that the single greatest benefit offered by S1000D is the ability to re-use data.

With S1000D, specific data modules are created (containing text and/or graphics), and 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.”

So, why use S1000D and what are the benefits?

For instance, output is controlled by a publication module (PM) that organizes data modules (DM) and multiple publication modules can reference the same data module.

Content is reusable across systems, configurations, and delivery formats.


Why use a CSBD? Because the spec calls for it!

It uses a Common Source Database (CSDB)



The Business Rules

Business Rules

Business rules are decisions that are made by a project or an organization on how to implement S1000D.

Business rules cover all aspects of S1000D and are not limited to authoring or illustrating.

Throughout the specification, business rule decision points have, wherever possible, been identified. However, in many cases, they have been marked as "None identified". Projects and organizations must decide whether certain business rules decisions must be made in these cases.

Business Rules

S1000D recognizes that a number of decisions related to its implementation are made not only on a project level but often also on an organizational level (eg national Ministries or Departments of Defense (MoD or DoD), international consortia such as Civil Aviation Working Group (CAWG), etc).

The structure and content of business rules between projects and various organizations can differ considerably.

In support of the business rule categories, a layered model of business rules is introduced.


S1000D Data Modules

Data Modules

Data Modules are defined in the S1000D issues as:

“The smallest self contained information unit within a technical publication.”

Data modules (DMs) focus on fulfilling a single self-contained purpose.

Data modules (DMs) focus on fulfilling a single self-contained purpose.

For example, a DM may contain a:

• Procedure

• Description of Function• Fault isolation• Illustrated Parts Data

Data Modules

Data Module Types

• Descriptive

• Procedural

• Illustrated Parts Data

• Fault Isolation

• Wiring Diagram

• Maintenance Scheduling

• Crew/operator

• Technical Information Repository

• Business Rules Exchange (BREX)

• Container

New in 4.0 are:

• Checklist• Learning• SCORM Content Package

Data modules types identify a purpose for the data. The types are:

Data Module Codes

Each data module has unique data module code (DMC) that indicates to what component it applies and the information it contains and conveys.

“The data module code is the standardized and structured identifier of a data module.

The data module code is used to manage data modules in the CSDB, to retrieve them or to gain access to them in an electronic environment.”

Data Module Codes

Data Module Codes

“S1000D does for technical data what inventory control mechanisms do for parts management:

Data becomes a configuration item that must be created, tracked, modified and distributed.

The rigor applied to data management ought to come from some type of neutral source in much the same way Universal Product Codes (UPC) provide standardized barcodes for tracking inventory.

S1000D is an industry specification for the life cycle maintenance of air, land, and sea vehicles, but it can also apply to any technical system that requires parts management, operation, and life cycle maintenance.”

DMC-S1000DBIKE-AAA-D00-00-00-00AA-00PA-D_004-00_EN-US.xml

Model Identification Code “The model identification code identifies the Product to which the data applies ...”

The following is a sample DM xml file. The DMC is highlighted in grey.

Data Module Codes (DMCs)


Model Identification Code



System Difference CodeThe system difference code identifies alternative

versions of the system and subsystem/subsubsystem





System Difference Code

Standard Numbering System

The standard numbering system is comprised of 4-5 numbers identifying the system, subsystem, and sub-subsystem.

In the case where it is necessary to indicate the type of SNS used, an

additional single alphanumeric character is placed in front of the SNS. The

character is called the materiel item category code.

In this example it is indicated by D in the System Code.







The materiel item category code is used to indicate different SNS coding

structures that are applicable to an individual project at the system,

subsystem and sub-subsystem level within the SNS.







“The unit or assembly is two or four alphanumeric characters. It is a sequential

number starting from 01 or 0001. The use of four characters provides

identification for units in complex systems.”

Unit or Assembly







Unit or Assembly

Disassembly Code / Disassembly Code Variant

“The disassembly code identifies the breakdown

condition of an assembly to which maintenance information

applies.” (2 alphanumeric characters - 00)

“The disassembly code variant designates alternative

items of equipment or components differing slightly in design, but not enough to

warrant a change of the system difference code.”

(1-3 alphanumeric characters - AA)






Unit or Assembly


Information Code / Information Code Variant


“The information code identifies the type of

information within a data module.”

(3 alphanumeric characters – 00P)

The information code variant identifies any

variation in the activity defined by the information

code(1 alphanumeric character – A)






Unit or Assembly




Item Location Code

“The item location code indentifies the

situation to which the information is

applicable, eg wherethe maintenance task will be carried out in terms of a Product.”

<dmIdent><dmCode modelIdentCode="S1000DBIKE" systemDiffCode="AAA" systemCode="D00" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="AA" infoCode="00P" infoCodeVariant="A" itemLocationCode="D"/><language countryIsoCode="US" languageIsoCode="en"/><issueInfo issueNumber="004" inWork="00"/></dmIdent>

Element Tags in the XML for the DMC

In the document, the DMC is stored within the <dmCode> element. The data in the xml file indicating the DMC in

<dmCode> for the example above is (highlighted in grey):





Assembly Code


Item Location Code


The remainder of the codes (within dmIdent) are part of the XML filename.

Issue Number


For every release of a

data module, the issue

number must be incremented

by one.





Assembly Code


Item Location Code


Issue Number

In Work



The inwork number is used to track drafting of changed

information during the information generation process.




The data in the xml file indicating the issue number and in work codes:






Assembly Code


Item Location Code


Issue Number

In Work



Language and Country codes

Language: two alpha characters from International Standards Organisation (ISO)

specifying the language.

Country: two alpha characters from ISO to denote the country where the language is

spoken.



The data in the xml file indicating the language and country codes:



The basic structure or hierarchy of the elements in the DM is shown to the right.

The data module code information is contained in the Data Module Address section. The code is metadata, it is not data that is displayed in the publication itself.

Workshop Exercise

Defining the DMCs

XML and the DMC

Specify the data module code considering the following XML:

<dmIdent><dmCode modelIdentCode="S1000DLIGHTING" systemDiffCode="AAA" systemCode="D00" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="AA" infoCode="056" infoCodeVariant="A" itemLocationCode="A"/> <language countryIsoCode="US" languageIsoCode="en"/> <issueInfo issueNumber="007" inWork="00"/></dmIdent>

XML and the DMC

Specify the XML filename in which this data appears:

<dmIdent><dmCode modelIdentCode="S1000DLIGHTING" systemDiffCode="AAA" systemCode="D00" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="AA" infoCode="056" infoCodeVariant="A" itemLocationCode="A"/> <language countryIsoCode="US" languageIsoCode="en"/> <issueInfo issueNumber="007" inWork="00"/></dmIdent>

The D in the systemCode indicates: ________________________

The 00 in the system and subsystem codes indicate: _____________________________________________________

XML and the DMC

Refer to the S1000D International specification for technical publications, Issue 4.0, 2008-08-01 and interpret the following:

systemCode="D00" subSystemCode="0" subSubSystemCode="0“

Defining the Data Module Codes

Below is an example for the lab that follows—assume that you are asked to create a DMC that contains a procedure for draining the gas tank on the Jeep Wrangle as part of routine servicing.

In addition, note that your Business Rules specify that the MIC is JEEP and the SDC is defined as 01 for the Wrangler, 02 for the Liberty, and 03 for the Commander and that other codes should be obtained from the specification.

MIC SDC System Subsystem & sub-subsystem

Unit Assembly

DC DCV IC ICV ILC

JEEP 01 12 10 00 00 00 200 0 A

Defining the Data Module Codes

MIC SDC System Subsystem & sub-subsystem

Unit Assembly

DC DCV IC ICV ILC

Using the Business Rules and other information provided previously and create a DMC for the procedure to disassemble and remove the brakes on the Jeep Liberty. This is to be done as part of an examination and check for proper functioning.


S1000D Information Control Numbers

Illustrations and Multimedia

Illustrations and multimedia are identified by a unique Information Control Number (ICN).

Illustrations are typically• Vector line drawings (CGM)• Raster images (CCITT Grp/4, TIFF)• Photos and other artwork (JPEG, GIF, PNG)

Multimedia can be of any type defined and supported by the project’s business rules.

ICN-S1000DBIKE-AAA-D000000-0-U8025-00502-A-004-01.CGM




Information Control Number (ICN)

The following is a sample Model Identication Code based ICN.

Assembly Code

Responsible Partner Company Code

Orginator Code (NCAGE)

Unique Identifier

Information Variant Code

Issue Number

Security Classification





Assembly Code

The ModelIC, SDC, SNS and Assembly Code is the same as that for the Data Module.




The Responsible Partner Company Code is the company or organization responsible for the illustration independent of its use in the data module.

Format: 1 character, defined by the project.

Example: In the example of the bike data’s ICN (shown above) the Responsible Partner Company Code is represented by 0.


ICN – Originator Code

The Originator Code specifies the originator of the illustration. It is used as a status element in the identification and status section of the data module. characters.

Format: 5 alphanumeric characters NCAGE code

Example: In the example of the bike data’s ICN shown above, the Originator Code is represented by U8025

ICN – Unique Identifier

The Unique Identifier starts from 00001 for each originating company.

• The identifier must be unique for each originator code. • For each model identification code, the identifier must be unique

for each originating company.

Format: 5 digits

Example: In the example of the bike data’s ICN shown above, the Information Sequential Number is represented by 00502



ICN – Variant Code

The Variant Code identifies the variants of a basic illustration. A variant is a supplemental scaled, cropped, rotated, mirrored, and/or annotated basic illustration.

Format: 1 alpha character The variant A identifies a basic illustration and B identifies the variant.

Example: In the example of the bike data’s ICN shown above, the Variant Code is represented by A.


ICN –Issue Number

The Issue Number starts from 001 for each basic illustration and is incremented each time the illustration is updated.

Format: 3 digits

Example: In the example of the bike data’s ICN shown above, the Issue Number is represented by 004 .


ICN – Security Classification

The Security Classification identifies the security classification of the illustration. The same classes as the data modules must be used. 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.

Format: 2 numeric characters

Example: In the example of the bike data’s ICN shown above, the Security Classification is represented by 1.

ICN – Unique Identifier

Note that these two graphics were supplied by the same originator (identified by the NCAGE code S7282) and have the same MIC, SDC, and the SNS.

However, they can be differentiated by the Unique Identifier.

ICN – CAGE code based

The CAGE code based ICN is illustrated to the right. It is comprised of five parts whereas the

Model Identification Code based ICN is ten parts.

It is similar to the Model Identification Code based ICN except it starts with

the Originator code.

Workshop Exercise

Defining a CAGE Code Based ICN

Defining the Information Control Number


Using the Model Identification Code based ICN above, create the CAGE code based ICN for the same module.


S1000D Applicability

What is Applicability?

It provides the mechanism to identify the context for which a data module or parts of a data module is valid.

The term Applicability refers to a set of rules and directives used to determine if a particular piece of content is applicable to the end user.

The S1000D applicability model supports simple to very complex implementations.

Applicability

Suppose a master data module contains the information for all deliveries for all customers.

When publishing, the data module can be filtered on data tagged for applicability so that the publication is appropriate to the delivery, and specific for the customer.

Applicability Demo

Applicability is demonstrated using LiveContent.

The applicability mechanism is supported by:

• the applicability annotation within data modules• three specific data module types


The three specific data module types are:

• the Applicability Cross-reference Table (ACT) data module• the Conditions Cross-reference Table (CCT) data module• the Products Cross-reference Table (PCT) data module

Although not prohibited, these data modules are not intended to be displayed to the end user.


The ACT Data Module is used to declare product attributes.

These are attributes that are not likely to change during the product life cycle. They are typically set at manufacturing time.

For example:• Manufacturers serial number• Aircraft registration number• Model number

ACT Data Module

ACT Data Module

ACT Data Module

Reference to the ACT is in the Data Module’s status section, for example:

<applicCrossRefTableRef>

<dmRef xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace" xlink:href="URN:S1000D:DMC-S1000DBIKE-AAA-D00-00-00-00AA-00WA-D"> <dmRefIdent>

<dmCode modelIdentCode="S1000DBIKE" systemDiffCode="AAA" systemCode="D00" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="AA" infoCode="00W" infoCodeVariant="A" itemLocationCode="D"/></dmRefIdent>

</dmRef><

/applicCrossRefTableRef>

The infoCode 00W specifies the Attribute Cross Reference Table.

CCT Data Module

The CCT Data Module is used to declare conditions that affect the applicability of the data, such as:

• Technical• Operational• Environmental

For example: • Icy conditions yes or no• Pre or post Service Bulletin SB1• Combat situation yes or no• Temperature• Wind speed

CCT Data Module

PCT Data Module

The PCT Data Module is a repository for defining product instances.

• More a product database• Defines attributes and conditions for an actual instance

For example:Car 1 Car 2 License plate PR-XG-63 License plate AL-32-22 Model: V40 Model: Daffodil Year: 1998 Year: 1964 Manufacturer: Volvo Manfacturer: DAF

PCT Data Module

An instance is a single physical occurrence of the product.

ACT Data Module

Consider the following contents of an ACT data module:

ACT=application cross reference table

ACT Data Module

“One of the attributes is serialno

another attribute is Model

another is version...”

“The following is a list of attributes...”

continued...

ACT Data Module-con’t

Identifies the CCT

continued...

by its DMC

Identifies the PCT by its DMC

Identifies the CCT

Identifies the PCT

The infocode 00Q specifies a Conditions Cross Reference Table

The infocode 00P specifies a Product Cross Reference Table

ACT Data Module-con’t

The DM and Cross Reference Tables

So, the ACT is identified in the Data Module...

... and the CCT and PCT are defined in the ACT:

Data Module<applicCrossRefTableRef>

<dmRef xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace" xlink:href="URN:S1000D:DMC-S1000DBIKE-AAA-D00-00-00-00AA-00WA-D"> <dmRefIdent>

<dmCode modelIdentCode="S1000DBIKE" systemDiffCode="AAA" systemCode="D00" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="AA" infoCode="00W" infoCodeVariant="A" itemLocationCode="D"/></dmRefIdent>

</dmRef><

/applicCrossRefTableRef>

Attribute Cross Reference Table

Conditions Cross

Reference Table

Product Cross

Reference Table

We’ve seen that the Brook trekker and Mountain storm have already been established as a model and Mk1 and Mk9 have been established as versions.

S1000D Applicability within DMs

Assume that you want to test for the Mk1 Brook trekker or the Mk9 Mountain storm.

<assert> use for a single test which resolves to a boolean True or False

<evaluate> use as a means to group a set of assertions using the operators and or or

These elements groupings can be nested, resulting in very complex expressions.

The test consists of the following elements:


Test for the Mk1 Brook trekker or the Mk9 Mountain storm.

<assert> contains the following components:

• The attribute applicPropertyIdent containing the identifier of

a product attribute or condition to test.

•The attribute applicPropertyValues containing the values and ranges to test against

S1000D Applicability—assert

<assert applicPropertyIdent=“model”applicPropertyType=“prodattr” applicPropertyValues=“Mountain storm”/>

<assert applicPropertyIdent=“version”applicPropertyType=“prodattr” applicPropertyValues=“Mk1”/>


In this example, the test is for the model Mountain Storm version Mk1.






<evaluate andOr="and">

</evaluate>

Wrap the <assert> tags with <evaluate> tags to group the assertions, and specify if both need to be true (boolean “and”) or if only one has to be true (boolean “or”) for the assertions to be true.

<applic>

<displayText><simplePara>Mountain bicycle and (Mountain stormMk1 or Brook trekker Mk9)</simplePara></displayText>

<evaluate andOr="and"><assert applicPropertyIdent="type" applicPropertyType="prodattr"applicPropertyValues="Mountain bicycle"/><evaluate andOr="or"><evaluate andOr="and">

<assert applicPropertyIdent="model"applicPropertyType="prodattr" applicPropertyValues="Mountainstorm"/>

<assert applicPropertyIdent="version"applicPropertyType="prodattr" applicPropertyValues="Mk1"/></evaluate>

<evaluate andOr="and"><assert applicPropertyIdent="model"applicPropertyType="prodattr" applicPropertyValues="Brooktrekker"/>

<assert applicPropertyIdent="version"applicPropertyType="prodattr" applicPropertyValues="Mk9"/>

</evaluate></evaluate></evaluate></applic>

These and operators specify to test for model AND version for each of the bicycles.

Starting from the inside evaluate expressions...


DMC-S1000DBIKE-AAA-D00-00-00-00AA-941A-D_006-00_EN-US.xml

The first and tests for the model Mountain Storm and version MK1.

The second tests for model Brook trekker and version Mk9.

<applic>









DMC-S1000DBIKE-AAA-D00-00-00-00AA-941A-D_006-00_EN-US.xml

The outside “or”denotes if either of the evaluate annotations are 'true' then the entire applicability results in the Boolean value of 'true'.

This applicability annotation tests for either a "Mountain storm Mk1" or a "Brook trekker Mk9”.


<applic>








<applic>








Computable assert annotation

The attribute in the assert statement in the DM (DataModule) is matched to the attribute in the assign statement in the PCT (Products Cross-Reference Table):

In the data module:

<evaluate andOr="and"> <assert applicPropertyIdent="model" applicPropertyType="prodattr" applicPropertyValues="Mountain storm"/> <assert applicPropertyIdent="version“ applicPropertyType="prodattr" applicPropertyValues="Mk1"/></evaluate>


For example – where the result = true

In the PCT:

<product><assign applicPropertyIdent=“serialno” applicPropertyType="prodattr“ applicPropertyValue=“1B07001”//><assign applicPropertyIdent="model“”applicPropertyType="prodattr“ applicPropertyValue="Mountain storm"/><assign applicPropertyIdent=“version” applicPropertyType="prodattr“ applicPropertyValue="Mk1"/><assign applicPropertyIdent=“SB-S001” applicPropertyType="prodattr“ applicPropertyValue=“Pre"/></product>

In the data module:

<evaluate andOr="and"> <assert applicPropertyIdent="model" applicPropertyType="prodattr" applicPropertyValues="Mountain storm"/> <assert applicPropertyIdent="version“ applicPropertyType="prodattr" applicPropertyValues="Mk9"/></evaluate>


For example – where the result = false

In the PCT:

<product><assign applicPropertyIdent=“serialno” applicPropertyType="prodattr“ applicPropertyValue=“1B07001”//><assign applicPropertyIdent="model“”applicPropertyType="prodattr“ applicPropertyValue="Mountain storm"/><assign applicPropertyIdent=“version” applicPropertyType="prodattr“ applicPropertyValue="Mk1"/><assign applicPropertyIdent=“SB-S001” applicPropertyType="prodattr“ applicPropertyValue=“Pre"/></product>


<applic>








Where does the data within the <applic> ... </applic> tags appear in the DM?

To specify applicability for the data module enter the markup as shown in the identification and status section of the data module.


The applicability information has the same construct whether applied to the whole data module or a part of the content.

To apply to the whole data module, enter it as previously described in the DM’s status section.

However, when defined for use for part of the content, surround the <applic> tags with <referencedApplicGroup> ... </referencedApplicGroup> tags.

This says that it will be referenced in the content section of the DM and it is not to be applied to the whole DM.

In addition, add an id attribute to the <applic> tag. The id is used in the content section of the DM to identify and target the applicability test to use.

For example: <applic id=“appl-001”>


Use this ID in the DM’s content section to “target” use of this applicability test.


<applic>








Add <referencedApplicGroup>

Add </referencedApplicGroup>

Add the id attributefor example:<applic id=“appl-001”>

<applic>








<referencedApplicGroup><applic id=“appl-001”>







</evaluate></evaluate></evaluate></applic></referencedApplicGroup>


This specifies that the applicability test is only to be applied in the content section

where and when the applicability id is specified.

<referencedApplicGroup><applic id=“appl-001”>







</evaluate></evaluate></evaluate></applic></referencedApplicGroup>


To reference the applicability id in the

content section of the DM......use the applicRefId

attribute—for example, applicRefId=“appl-001”

(refer to the example in your notes)

S1000D Applicability – Textual Assert

In addition to computable assert annotations as discussed, you can add textual assert annotations.

For instance, the assert annotation in the DM reads:

<assert applicPropertyIdent="model"applicPropertyType="prodattr" applicPropertyValues="Brook trekker"/>

Note that the textual assert annotation contains no computable components. Since it is not computable the result is a Boolean value of true.





Note that the textual assert annotation contains no computable components. Since it is not computable the result is a Boolean value of true.

The Applicability Cross Reference Table (ACT) is referenced—if the product attribute declaration from ACT reads:

<productAttribute id="model" valuePattern="."><name>Model name</name><displayName>Model:</displayName><descr>Model of the bike</descr><enumeration applicPropertyValues="Brook trekker|Mountain storm"/></productAttribute>





The human readable format is:

"Model: Brook trekker”





Workshop Exercise

Applicability

Applicability Exercise

Consider the following and indicate the appropriate boolean value result.

<assert> annotation in the data module:

<assert applicPropertyIdent="serialno"applicPropertyType="prodattr"applicPropertyValues="1B070643~1B070799"/>

<assign> annotation from PCT:

<assign applicPropertyIdent="serialno"applicPropertyType="prodattr" applicPropertyValue="1B070642"/>

Boolean value result: true false

Applicability Exercise

Consider the following and indicate the appropriate boolean value result.


<assert applicPropertyIdent="serialno"applicPropertyType="prodattr"applicPropertyValues="1B070640|1B070642~1B070720|1B070722|1B070730~1B070799"/>

<assign> annotation from PCT:

<assign applicPropertyIdent="serialno"applicPropertyType="prodattr" applicPropertyValue="1B070642"/>

Boolean value result: true false

Textual assert annotation

Indicate the values in the data module for a result of readable text: Road Conditions: Icy


<assert applicPropertyIdent=“_____________"applicPropertyType="prodattr" applicPropertyValues=“_______________"/>

product attribute declaration from ACT:

<productAttribute id=“conditions" valuePattern="."><name>Road Conditions</name><descr>Weather/road Conditions</descr><enumeration applicPropertyValues=“icy|dry"/></productAttribute>

The Publication Module


Publication Module (PM)

The publication module (PM) defines the content and the structure of a publication.

It contains one or more references to:

• the data modules• the illustration data modules• other publication modules• legacy technical publications

Publication Modules

Publication Model Concept

Final DeliverablePublication Module

<pmRef> - reference to a Publication Module, Pub A

<pmRef> - reference to a Publication Module, Pub B

<dmRef> - reference to a Data Module




<pmRef>

<dmRef> <dmRef> <dmRef> <dmRef> <dmRef> <dmRef>

<dmRef> <dmRef>

<dmRef>


Pub A Pub B Pub C

Publication Model Concept

Publication Modules


<pmRef> - reference to a Publication Module, Pub A<pmRef> - reference to a Publication Module, Pub B

<dmRef> - reference to a Data Module<dmRef> - reference to a Data Module<dmRef> - reference to a Data Module<dmRef> - reference to a Data Module

<pmRef>


<dmRef>

<dmRef> <dmRef>


Pub A Pub B Pub C


Legacy Data <externalPubRef>– legacy

data

In addition to the first publication deliverable, suppose a second that shares some of the data:

Publication Module Code

The Publication Module Code (PMC) is a standardized and structured identifier of a publication module or a final delivered publication. The PMC is part of the unique identifier of the publication module.

Publication Module Code

Use <pmref> to reference the PM.

The element <pmRef> contains details of the destination publication module that is referred from some other S1000D context, such as a data module, another publicationmodule etc. (refer to the example in your notes)


The Publication Module (PM) is similar to a Data Module in that it has:

• an identifier and status section <identAndStatusSection>• a content section <content>

The content section contains the references to data modules, legacy technical publications or other publication modules in the order and the structure the publication is to be delivered.

The element <pm> contains a definition of the content and structure of a publication.

Example:

<pm><identAndStatusSection><pmAddress>... </pmAddress><pmStatus>...</pmStatus></identAndStatusSection><content>...</content></pm>


There is an identAndStatusSection


Example:


Example:


<pmAddress> <pmIdent>

<identExtension> <pmCode> <language> <issueInfo>

</pmIdent><pmAddressItems>

<issueDate><pmTitle>

</pmAddressItems></pmAddress>

With a <pmAddress>

Example:


Example:



<pmStatus><security securityClassification= ... /><responsiblePartnerCompany><enterpriseName>...</enterpriseName></responsiblePartnerCompany><applic><displayText><simplePara>...</simplePara></displayText></applic><qualityAssurance><unverified/></qualityAssurance></pmStatus>

and a <pmStatus>

Example:


Example:


There is the <content> which contains reference(s) to the contents of the publication.


<content><pmEntry><dmRef>...</dmRef></pmEntry></content>

The references are to data modules, other publication modules, and/or external publications.

Example:



There is the <content> which contains reference(s) to the contents of the publication.

The references are to data modules, other publication modules, and/or external publications.

The dmRef contains the details of the data module

<content><pmEntry><dmRef>...</dmRef></pmEntry></content>

<content><pmEntry> <dmRef> <dmRefIdent>

<dmCode modelIdentCode="S1000DBIKE" systemDiffCode="AAA"systemCode="D00" subSystemCode=“0" subSubSystemCode="0"assyCode="00" disassyCode="00" disassyCodeVariant="AA"infoCode=“00P" infoCodeVariant="A" itemLocationCode="D" /><issueInfo issueNumber="004" inWork="00"/>

</dmRefIdent>...

<content><pmEntry> <dmRef> <dmRefIdent>

<dmCode modelIdentCode="S1000DBIKE" systemDiffCode="AAA"systemCode="D00" subSystemCode=“0" subSubSystemCode="0"assyCode="00" disassyCode="00" disassyCodeVariant="AA"infoCode=“00P" infoCodeVariant="A" itemLocationCode="D" /><issueInfo issueNumber="004" inWork="00"/>

</dmRefIdent>...


The <dmRef> below is a reference to:


<content><pmEntry><pmRef>...</pmRef></pmEntry></content>

In addition to the <dmRef>, the <content> may include a <pmRef> — for example:

contains details of the publication module


<content><pmEntry> <pmRef> <pmRefIdent> <pmCode modelIdentCode=“BICYCLEXXXAAA“ pmIssuer=“XYENT" pmNumber="00001" pmVolume="02"/> </pmRefIdent>...

<content><pmEntry> <pmRef> <pmRefIdent> <pmCode modelIdentCode=“BICYCLEXXXAAA“ pmIssuer=“XYENT" pmNumber="00001" pmVolume="02"/> </pmRefIdent>...

The <pmRef> below is a reference to:

PMC-BICYCLEXXXAAA-XYENT-00001-02


<content><pmEntry>

<externalPubRef><externalPubRefIdent><externalPubCode pubCodingScheme ... </externalPubCode><externalPubTitle>...</externalPubTitle></externalPubRefIdent>

</externalPubRef>...

In addition to referencing a data module, <dmRef> and/or another publication module, <pmRef>, the <content> may also include a reference a non-S10000D publication or document, <externalPubRef>.


Pub Updates and Version Control

• Updates of publications are due to updates in the data modules that the publication module(PM) references, or to the PM itself.

• The S1000D specification requires that the publication module be reissued if there are any updates to the publication.

• Updates can be either in the form of a change or a new issue.

Pub Updates and Version Control

• A consecutive three digit number is issued to indicate every issue of a PM. The initial issue of a publication must be numbered 001.

• An optional attribute can be used to number the drafts/revisions or changes to the PM issue or a DM that is referenced in the PM. The attribute is a two digit sequential number.

• A value of attribute type of the issueInfo, it describes the type of update for a new issue of the publication module. It is related only to the issue number.

Workshop Exercise

Publication Module

Defining the Publication Module Code

Create a PMC that meets the following requirements:

This is publication number 16, the second volume of a three volume documentation set for the Jeep Cherokee. The

issuing authority is Chrysler.

Publication Module (PM) <dmRef>

Complete the following XML to reference the data module:

DMC-S1000DLIGHTING-AAA-D00-00-00-00AA-056A-A_007-00_EN-US.xml<dmRef><dmRefIdent>

<dmCode modelIdentCode="________" systemDiffCode="_____" systemCode="____" subSystemCode="__" subSubSystemCode="__" assyCode=" ____" disassyCode=" ____" disassyCodeVariant=" ____" infoCode="______" infoCodeVariant="__" itemLocationCode="__" /> <issueInfo issueNumber="______" inWork="____"/>

</dmRefIdent>

<dmRefAddressItems>

<dmTitle><techName>____________</techName><infoName>________________________</infoName></dmTitle>

</dmRefAddressItems></dmRef>

The Data Dispatch Note


Data Interchange

S1000D provides standard ways to transfer data modules using an S1000D CSDB interchange (transfer) package.

The transfer package consists of one Data Dispatch Note (DDN), and at least one of the following data categories:

• one or more data modules, associated illustrations, multimedia and other data• one or more CSDB Status List (CSL)• one or more Data Module Requirement List (DMRL)• one or more COMment forms (COM) and associated attachments• one or more Publication Modules (PM)




Data Interchange

This is the actual data you want to send—the DM(s), ICN(s) and/or

other data




To ensure that all CSDB are built up without divergence, it

is recommended that each agency/company produces and exchanges a periodic reference listing of all data modules that it has issued for interchange.

Data Interchange




Data Interchange

The DMRL is used to identify the required data

modules for a project.

Data Interchange




Contains comments and reports on issues raised on data modules or publication modules during the

verification process and the in-service phase of the Product




Data Interchange

(I hope this one is obvious)

Data Dispatch Note

The DDN defines the sender, receiver and content of the dispatch.

A data delivery list (DDL) is optionally included in the DDN. This lists all file names of the dispatched data together with their control numbers and issue numbers as additional options.

Data Dispatch Note

MI-SSSSS-RRRRR-YYYY-NNNNN

Model Identifier

Sender NCAGE

Receiver NCAGE

Year

Sequential numberper year

The DDN defines the sender, receiver and content of the dispatch. The DDN is identified by a CONTROLNUMBER in the format:

Data Dispatch Note

For example:

MI-SSSSS-RRRRR-YYYY-NNNNN

Model Identifier

Sender NCAGE

Receiver NCAGE

Year

DDN-S1000DBIKE-U8025-I9005-2003-00002.XML

seqNumber Contains a sequence number of the comment, related to senderIdent and yearOfDateIssue

modelIdentCode Identifies the Product to which the data applies

senderIdent Contains the CAGE code of the sender of the comment

receiverIdent Contains the CAGE code of the receiver of the comment

yearOfDateIssue Contains the year (YYYY) when the issue was made public

Sequential numberper year

Workshop Exercise

Data Dispatch Note

Data Dispatch Note

<ddnCode senderIdent="______________" yearOfDataIssue="_____________"modelIdentCode="___________"receiverIdent="___________" seqNumber="_____________" />

DDN-S1000DBIKE-U8025-I9005-2003-00002.XML

Use the sample DDN for this exercise and fill in the blanks below.

Business Rules


Business Rules

The S1000D spec outlines requirements for business rules as a foundation for each project to maintain consistency across the departments and individuals who are part of the project.

Business rules are decisions that are made by a project or an organization on how to implement S1000D. Business rules cover all aspects of S1000D and are not limited to authoring or illustrating.

They can also address issues that are not defined in S1000D such as rules related to how S1000D interfaces with other standards, specifications and business processes that are related to its implementation.

Refer to Chap 2.5 in S1000D International specification for technical publications, Issue 4.0, 2008-08-01

Business Rules

Throughout the specification, in particular the authoring chapters, business rule decision points have, wherever possible, been identified.

However, in many cases, they have been marked as "None identified".

Projects and organizations must still decide for themselves whether certain business rules decisions must be made in these cases.

Refer to Chap 2.5 in S1000D International specification for technical publications, Issue 4.0, 2008-08-01

Ten different business rule categories have been identified.

These categories are defined to ensure that business rules developers consider all major business rules decisions within S1000D.

Business Rules

Refer to Chap 2.5, page 3 in S1000D International specification for technical publications, Issue 4.0, 2008-08-01

Business Rules



Business Rules


Business rule category 1: General serve as overall decisions (business rules) for the implementation of

S1000D


Business Rules


Business rule category 2: Product definition covers the data module coding strategy related to how the Product is broken down (eg physical or functional).


Business Rules


Business rule category 3: Maintenance philosophy and concepts of operation

cover the types of information that a project or an organization requires.


Business Rules


Business rule category 4: Securitycovers all security issues. They include

security classifications, copyrightmarkings, use or disclosure restrictions, destruction instructions and any other

data restrictions.


Business Rules


Business rule category 5: Business processcover how technical publications development is

coordinated with other disciplines within an organization or within the project level at that organization or the

project as a whole.


Business Rules


Business rule category 6: Data creationgives information about the creation of text, illustrations and multimedia objects. The data creation business rules

include rules for creating textual data and rules for creating graphics, 3D content and multimedia objects


Business Rules


Business rule category 7: Data exchangeCovers the rules for how data must be exchanged between partners and customers. This includes for

example the use of data dispatch notes and howdata module requirement lists as well as CSDB status

lists are used.


Business Rules


Ten different business rule categories have been identified. Business rule category 8: Data integrity and management

enforce the referential integrity within the CSDB.Closely coupled with the data exchange business rules, they

cover how data is managed by both the creator and the customer

Business Rules


Ten different business rule categories have been identified. Business rule category 9: Legacy data conversion, management and handling

include but are not limited to: − conversion rules (including mapping

between elements and attributes of source and target specifications)

− rules for inclusion of legacy information in a technical publication

Business Rules



Business rule category 10: Data outputspecify the output formats for S1000D data. These formats can include page-oriented (eg paper) formats, IETP formats, multimedia

formats and SCORM Formats.

Business Rules

The top level of the business rules (S1000D BR) are those developed and defined in the

S1000D spec.

The layers under, are in a hierarchy whereby “the

business rules in the lower ("children") layers must adopt or must be conformant to the business rules of the higher

(their "parent") layer.”

Refer to Chap 2.5.1 pgs 13 in S1000D International specification for technical publications, Issue 4.0, 2008-08-01

Business Rules

As a minimum requirement, the higher layers are

responsible for informing the lower layers on their business

rules.

For example, organizations must provide information to

projects, which organizational business rules must be

followed and which decision points are up to the projects.

Refer to Chap 2.5.1 pgs 12-14 in S1000D International specification for technical publications, Issue 4.0, 2008-08-01

Example Business Rules Conflicts

“Problems can occur in the project layers when the same Product is

used in different projects.

Consider an engine that is used in different airframes where one

airframe manufacturer imposes different rules than another.

Another example is when a given Product is used for both civil and military use, which can mean data

rewrites.”

Engine A

Airframe A

Airframe B

Airframe C


Business Rules AFM CUse 2.3 DTDDo not use <techstd>Titles in uppercase ...

Business Rules AFM BUse 1.9 DTD<techstd> is to contain.....Illustrate as CG4Use OxfordEnglish

Business Rules AFM AUse 1.8 DTDDo not use <techstd>Do not use step leve 4-5Illustrate as CGMUse Webster’s English

Engine A

Airframe AAirframe BAirframe C

“Before any authoring or implementation of S1000D begins on a project, all

stakeholders who have their own business rules must reach consensus on the

business rules to be deployed for that project.”





“When projects are presented with conflicting business rules from multiple customers or parent organizations, projects must resolve these conflicts. These conflicts must be resolved by:

• coordinating a change or waiver to the conflicting rules with one or more of the customers or parent organizations

• producing data modules to comply with each set of rules.”





Business Rules (BREX)

Business Rules EXchange mechanism (BREX) is a means to communicate the business rules that have been developed and agreed upon within a project.

To facilitate unambiguous description of the business rules, a BREX data module can be used and is stored in the CSDB.


A sample BREX from the USAF


snsCode for system is 05

Subsystem for:

general aircraft is 0standard practices, airframe is 1ground handling is 2safety and protectice devices is 3

References

Thank you!


SDL-S1000D Training

Documents

Transcript of SDL-S1000D Training