..
/
download
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
gopher://khzae.net/0/s1000d/spec/chap1/DMC-S1000D-A-01-03-0000-00A-040A-A_008-00_EN-US.txt