SDL-S1000D Training

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 Modules
Information Control Numbers
Data Module Requirements List
Publication Modules
Data 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)

S1000D Training Workshop
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
“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)

System Difference Code
The system difference code identifies alternative
versions of the system and subsystem/subsubsystem

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 where
the 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.

<dmIdent>
</dmIdent>
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.

<dmIdent>
</dmIdent>
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"/>
</dmIdent>

XML and the DMC
Specify the XML filename in which this data appears:
<dmIdent>
<dmCode modelIdentCode="S1000DLIGHTING"
subSystemCode="0" subSubSystemCode="0" assyCode="00"
disassyCode="00" disassyCodeVariant="AA" infoCode="056"
infoCodeVariant="A" itemLocationCode="A"/>
</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 Sub
system & 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 Sub
system & 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
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.
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
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"
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"
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.
storm”/>

storm”/>
<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 storm
Mk1 or Brook trekker Mk9)</simplePara></displayText>
<assert applicPropertyIdent="type" applicPropertyType="prodattr"
applicPropertyValues="Mountain bicycle"/>
<evaluate andOr="or">
<assert applicPropertyIdent="model"
applicPropertyType="prodattr" applicPropertyValues="Mountain
storm"/>
<assert applicPropertyIdent="version"
applicPropertyType="prodattr" applicPropertyValues="Mk1"/>
</evaluate>
applicPropertyType="prodattr" applicPropertyValues="Brook
trekker"/>
</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>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</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>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</applic>

<applic>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</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:
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:
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>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</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.

<applic>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</applic>

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>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</applic>
Add <referencedApplicGroup>
Add </referencedApplicGroup>
Add the id attribute
for example:
<applic id=“appl-001”>

<applic>
storm"/>
</evaluate>
trekker"/>
</evaluate>
</evaluate>
</evaluate>
</applic>
<referencedApplicGroup>
storm"/>
</evaluate>
trekker"/>
</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>
storm"/>
</evaluate>
trekker"/>
</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:
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.

assert annotations.
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>

assert annotations.
The human readable format is:
"Model: Brook trekker”
</productAttribute>
</productAttribute>

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"
applicPropertyValue="1B070642"/>
Boolean value result: true false

Applicability Exercise
Consider the following and indicate the appropriate boolean
value result.
<assert applicPropertyIdent="serialno"
applicPropertyValues="1B070640|1B070642~1B070720|
1B070722|1B070730~1B070799"/>
<assign> annotation from PCT:
<assign applicPropertyIdent="serialno"
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=“_____________"
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 Deliverable
Publication Module
<pmRef> - reference to a
Publication Module, Pub A
Publication Module, Pub B
<dmRef> - reference to a Data
Module
Module
Module
Module
<pmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
Pub A Pub B Pub C

Publication Model Concept
Publication Modules
Final Deliverable
Publication Module
Publication Module, Pub A
Publication Module, Pub B
<dmRef> - reference to a
Data Module
Data Module
Data Module
Data Module
<pmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef
>
<dmRef
>
<dmRef
>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
<dmRef>
Pub A Pub B Pub C
Final Deliverable
Publication Module
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 publication
module 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:
<pm>
</pm>
Example:
<pm>
</pm>
<pmAddress>
<pmIdent>
<identExtension>
<pmCode>
<language>
<issueInfo>
</pmIdent>
<pmAddressItems>
<issueDate>
<pmTitle>
</pmAddressItems>
</pmAddress>
With a <pmAddress>

Example:
<pm>
</pm>
Example:
<pm>
</pm>
<pmStatus>
<security securityClassification= ... />
<responsiblePartnerCompany>
<enterpriseName>...</enterpriseName
>
</responsiblePartnerCompany>
<applic>
<displayText>
<simplePara>...</simplePara>
</displayText>
</applic>
<qualityAssurance>
<unverified/>
</qualityAssurance>
</pmStatus>
and a <pmStatus>

Example:
<pm>
</pm>
Example:
<pm>
</pm>
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:
<pm>
</pm>
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>
systemCode="D00" subSystemCode=“0" subSubSystemCode="0"
infoCode=“00P" infoCodeVariant="A" itemLocationCode="D" />
</dmRefIdent>
...
<content>
<pmEntry>
<dmRef>
<dmRefIdent>
systemCode="D00" subSystemCode=“0" subSubSystemCode="0"
infoCode=“00P" infoCodeVariant="A" itemLocationCode="D" />
</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 number
per 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 number
per 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: Security
covers all security issues. They include
security classifications, copyright
markings, use or disclosure restrictions,
destruction instructions and any other
data restrictions.

Business Rules
Business rule category 5: Business process
cover 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 creation
gives 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 exchange
Covers the rules for how data must be exchanged
between partners and customers. This includes for
example the use of data dispatch notes and how
data module requirement lists as well as CSDB status
lists are used.

Business Rules
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
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 output
specify 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 C
Use 2.3 DTD
Do not use <techstd>
Titles in uppercase
...
Business Rules AFM B
Use 1.9 DTD
<techstd> is to contain.....
Illustrate as CG4
Use OxfordEnglish
Business Rules AFM A
Use 1.8 DTD
Do not use step leve 4-5
Illustrate as CGM
Use Webster’s English
Engine A
Airframe
A
Airframe
B
Airframe
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.”
Use 2.3 DTD
Titles in uppercase
...
Use 1.9 DTD
<techstd> is to
contain.....
Illustrate as CG4
Use OxfordEnglish
Use 1.8 DTD
Illustrate as CGM

“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.”
Use 2.3 DTD
Titles in uppercase
...
Use 1.9 DTD
<techstd> is to
contain.....
Illustrate as CG4
Use OxfordEnglish
Use 1.8 DTD
Illustrate as CGM

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 0
standard practices, airframe is 1
ground handling is 2
safety and protectice devices is 3

Thank you!

SDL-S1000D Training

More Related Content

What's hot

Viewers also liked

Similar to SDL-S1000D Training

SDL-S1000D Training

Editor's Notes