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

You are viewing proxied material from khzae.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.