Chapter 1.3 - How to use the specification
Aerospace and Defence Industries Association of Europe
2016-12-31



GENERAL


This chapter gives an overview of:

-   the structure and content of the specification

-   The basic production and delivery methods

-   the fundamental reading rules



FIELD OF APPLICATION


S1000D is an international specification, which is designed to cover
technical publication and learning information in support of any
platform, system or equipment project (air, sea, land vehicle, equipment
or facilities, civil or military).

The following aspects of technical publication and training information
are described:

-   information generation (authoring)

-   management within the CSDB

-   publication generation - page-oriented and IETP

-   exchange of data modules, publications and training content packages

-   commenting

The specification addresses two main delivery methods of technical
publications and training content packages:

-   Data exchange - S1000D objects (data modules and supporting objects)
    delivery for further processing

-   Publishing - Delivery of publications and training content
    packages - Information ready to use

Refer to Delivery methods for further details on the delivery methods.



BASIC DEFINITIONS


the Product

    Any platform, system or equipment (air, sea, land vehicle, equipment
    or facility, civil or military)

Project

    The task to develop, maintain and dispose of the Product.

technical publications

    Operational and maintenance documentation and data. Technical
    publications do not include design documentation (eg, design
    drawings or CAD models).

learing information

    Information used in the development of training activities that
    facilitate learning and the development of new and existing skills.

self-contained data module

    A data module which is ready to use without a need for any common
    information repository data modules. Refer to Self-contained vs
    CIR-dependent data modules.

CIR-dependent data modules

    A data module which needs access to one or more Common Information
    Repository (CIR) data modules. Refer to Self-contained vs
    CIR-dependent data modules.



SELF-CONTAINED VS CIR-DEPENDENT DATA MODULES


There are two basic methods of production (authoring) and delivery
(publishing) of data modules and publications:

-   Using self-contained data modules only. This is the basic method to
    deliver data modules.

-   Using common information repository data modules (eg, warnings,
    cautions, externalized applicability annotations) as a necessary
    part of the delivery. This method means that the "ordinary" data
    modules are delivered CIR-dependent.

The CIR provides the ability to further optimize and reuse data. It does
this by using:

-   CIR data modules. Refer to Chapter 4.13.1 - Optimizing and reuse -
    Common information repository concept.

-   Incremental updates of CIR data modules. Refer to Chapter 4.13.2 -
    Optimizing and reuse - Incremental update of CIR data modules.

-   Alternates. Refer to Chapter 4.13.3 - Optimizing and reuse -
    Alternates concept.

-   Container data modules. Refer to Chapter 4.13.4 - Optimizing and
    reuse - Container data module.

  NOTE

  The CIR concept can be implemented in the production process as
  "internal repositories" and thus not necessarily as CIR data modules.

The delivery from a production environment using CIR data modules can be
done in two ways:

-   Self contained data modules

    These data modules include all information needed to understand a
    description or fulfill the maintenance task. Data from the CIR data
    modules (eg, warnings, cautions, externalized applicability
    annotations), if used, are included (not linked) in the data modules
    to be delivered to the customer or end user.

    For example, if warnings, cautions and/or applicability CIR are used
    these must be included in the data modules to which they apply, if
    self-contained data modules are the deliverables.

      NOTE

      Only a limited set of data from the repository data modules can be
      included in the data modules.

      NOTE

      The CIR data modules can still be delivered together with the
      self-contained data modules as the repository data modules include
      useful additional/detailed information which cannot be
      accommodated in the data modules but used in an IETP.

-   CIR-dependent data modules

    These data modules are dependent on CIR data modules as pieces of
    information are "removed" or externalized into one or more CIR data
    modules prior to delivery to the customer or end user (or an IETP
    application). The customer, end user or the IETP application,
    resolves any links before use or during use of the IETP
    viewer/browser.

The authoring rules differ between the two methods which are explained
in the authoring chapters. Refer to Chap 3.9.5.2.1. When using CIR data
modules certain information does not require authoring but would require
referencing (linking) to the appropriate CIR data module. For example,
the name of the support equipment being referenced (linked) to a CIR
data module rather than being authored.

Refer to Chapter 4.13.1 - Optimizing and reuse - Common information
repository concept for details on the use of the CIR concept.

Refer to Chapter 4.13.4 - Optimizing and reuse - Container data module
for details on the use of the container concept.



DELIVERY METHODS


Data exchange

The delivery method based on data exchange of S1000D objects (refer to
Field of application) is used when the receiving organization has a CSDB
and is expected to process the data and even include changes (eg, due to
adaptation of the data modules to internal regulations and needs). The
receiver can then produce another interchange package or produce the
final ready-to-use publications or SCORM content package modules. Refer
to Main delivery methods.

Data exchange is done between two CDSB, a sender CSDB and a receiver
CSDB. The exchange could be between a subcontractor and a prime, or
between a contractor and a customer.

The data exchange packages consist primarily of data modules and their
associated illustrations and multimedia files. Publication modules,
SCORM content package modules, and supporting files such as data
dispatch notes and data management lists can also be exchanged.

The interchange of transfer packages is done as described in Chapter 4.8
- Information management - Interchange of data modules.


Delivery of ready-to-use publications or training content packages

This method is used when the CSDB owner, contactor or customer, delivers
a final ready-to-use product to the end user. It can be page-oriented
publications delivered as paper publications in binders or electronic
publications in PDF, the latter with some linking mechanisms. The
deliverable can also be an IETP generated as described in Chapter 7.4.1
- Generation of publications - IETP, or a training related product. The
latter could be used as SCORM, just-in-time training, instructor or
student guides.

[Main delivery methods]


Delivery with and without CIR

The exchange of data modules can be done based on self-contained or on
CIR-dependent data modules.

An interchange (transfer) package of CIR-dependent data modules must be
accompanied with the relevant CIR.

An interchange package of self-standing data modules does not
necessarily include any CIR. However it can be useful to exchange CIR
between partners (subcontractor and contractor) to have consistent data
for supplies, support equipment, warnings and cautions.

Delivery methods for technical publications - Detailed view shows the
interchange of data between different CSDB. It also briefly shows the
"data transfer" from a CSDB to an end user IETP via the neutral IETP-X
format described in Chapter 7.4.1 - Generation of publications - IETP.

[Delivery methods for technical publications - Detailed view]



READING CONVENTIONS


General

Throughout the S1000D specific conventions are used to aid common
understanding and to minimize duplication. These conventions are:

Available for projects

    SNS and attribute values that are available for projects or
    organizations to give their own specific definitions.

Not available for projects

    SNS, information codes and attribute values that are not available
    for projects or organizations to give their own specific
    definitions. Projects or organizations can apply for formal
    definitions by the normal CPF process.

M

    Mandatory

    The attribute affected must be given in the data module and the
    required entries in the construct must be populated.

    (M) is used in some chapters to, for example, explain the use or
    presentation of specific data.

O

    Optional

    The attribute affected can be omitted if a project or organization
    decides.

    (O) is used in some chapters to, for example, explain the use or
    presentation of specific data.

(D)

    Default value

    The affected markup value is the default value.

enterprise/company

    Enterprise is used as the generic term when a company and/or
    organization is referred to. Company is used as a synonym to
    enterprise when a business organization is referred to.

    The term manufacturer (Product manufacturer, equipment manufacturer,
    aircraft manufacturer) and supplier are used when needed in context
    only. These rules are being successively introduced in S1000D.

must

    Mandatory to follow the given rules.

name

    The name of a "thing" such as a part, a component, an assembly.
    Sometimes called description, nomenclature or designation. Name is
    used consistently throughout S1000D.

can, could

    Options to be followed by project or organization decision.


Permissible characters in codes and numbers

Throughout the S1000D the following definitions on permissible
characters (alphas and numbers) when used in codes (eg, data module
codes, publication module codes, learn codes, learn event codes, data
management lists) and numbers (eg, issue numbers) are given below.

Alpha characters

The code abbreviation is "A".

The permissible characters are:

-   "A" thru "Z" in uppercase. It is recommended that the use of "I" and
    "O" is avoided.

Numeric characters

The code abbreviation is "X".

The permissible characters are:

-   "0" thru "9"

  NOTE

  "NN" is frequently used to indicate a numerical sequence starting from
  "00" or "01". Details for the interpretation are given where used in
  the specification.

Alphanumeric

The code abbreviation is "Y".

The permissible characters are:

-   "0" thru "9"

-   "A" thru "Z" in uppercase. It is recommended that the use of "I" and
    "O" is avoided.

Specific alpha character values

When an alpha character is given in a data module code that is intended
to indicate a value, it is presented by underlining the character. For
example, _A_ means the value of "A" and not an alpha character. "A"
means an alpha character and not the value "A".

Use of the alpha characters "I" and "O"

_Business rule decision point BRDP-S1-00001 - USe of "I" and "O":_

-   Decide whether and when to use the alpha characters "I" and "O".



USE OF, AND APPLICATION FOR CAGE CODES


The specification uses CAGE (Commercial and Government Entity) codes to
uniquely identity enterprises and organizations. The values of some
elements and attributes mandate that a registered CAGE code is used, for
example, when using the identification extension in _DME_ and _PME_
(refer to Chap 4.12), when using the CAGE code based _ICN_ (refer to
Chap 4.4), when using _data management lists_ (refer to Chap 4.5) and
when commenting using the _Commenting Schema_ (refer to Chap 4.6). To
perform a _file based transfer_ (refer to Chap 7.5.1) you also need a
CAGE code.

As it is essential to uniquely identify parts in many cases, the
specification based the identification of those parts on the CAGE code.

_Business rule decision point BRDP-S1-00002 - List of permitted CAGE
codes and/or names to be used for the technical publication project:_

-   Create a list of permitted CAGE codes and/or names of the
    enterprises.

Enterprises and organizations that do not have a CAGE code, can apply
for a code at their National Codification Bureau (NCB) or at:

NSPA
S2000M Administrator
L-8325 CAPELLEN
G.-D. Luxembourg
Email: [email protected]



ACRONYMS


Throughout the S1000D common acronyms are used to aid understanding and
to minimize duplication. These acronyms are:

2D

    Two Dimensional