International procedure specification
for
Logistics Support Analysis
LSA

Issue 1 2010-04-01

S3000L-B6865-03000-00

Copyright and user agreement
1

Copyright
Copyright (C) 2010 AeroSpace and Defence Industries Association of Europe - ASD.
All rights reserved. No part of this document may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying and recording, or by any
information storage or retrieval system, except as may be expressly permitted by the Copyright
Act or in writing by the Publisher.
S3000L™ is a trade mark owned by ASD.
All correspondence and queries should be directed to:
ASD
Monsanto Building
270 Avenue de Tervuren
B-1150 Brussels
Belgium

2

Agreement for use of the specification S3000L™ suite of
information

2.1

Definitions
S3000L™ suite of information means, but is not limited to:−−−

the International procedure specification for Logistics Support Analysis LSA - S3000L
examples (eg XML instances, pdf files, style sheets) and schemas
any other software or information under the heading “S3000L™ suite of information”,
available for download from www.asd-stan.org

Copyright Holder means AeroSpace and Defence Industries Association of Europe (ASD).

2.2

Notice to user
By using all or any portion of S3000L™ suite of information you accept the terms andconditions of this User Agreement.
This User Agreement is enforceable against you and any legal entity that has obtained
S3000L™ suite of information or any portion thereof and on whose behalf it is used.

2.3

License to use
As long as you comply with the terms of this User Agreement, the Copyright Holders grant toyou a non-exclusive license to use S3000L™ suite of information.

2.4

Intellectual property rights
S3000L™ suite of information is the intellectual property of and is owned by the CopyrightHolder. Except as expressly stated herein, this User Agreement does not grant you any
intellectual property right in the S3000L™ suite of information and all rights not expressly
granted are reserved by the Copyright Holder.

2.5

No modifications
You must not modify, adapt or translate, in whole or in part, S3000L™ suite of information.
You may however add business rules.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-021A-A_001_00_EN-US.doc

S3000L-A-00-00-0000-00A-021A-A

2010-04-01 Page 1

S3000L-B6865-03000-00

2.6

No warranty
S3000L™ suite of information is being delivered to you "as is". The Copyright Holder does notwarrant the performance or result you may obtain by using S3000L™ suite of information.
The Copyright Holder makes no warranties, representations or indemnities, express or implied,
whether by statute, common law, custom, usage or otherwise as to any matter including without
limitation merchantability, integration, satisfactory quality, fitness for any particular purpose, or
non-infringement of third parties rights.

2.7

Limitation of liability
In no event will the Copyright Holder be liable to you for any damages, claims or costs
whatsoever or any consequential, indirect or incidental damages, or any lost profits or lostsavings or for any claim by a third party, even if the Copyright Holder has been advised of thepossibility of such damages, claims, costs, lost profits or lost savings.

2.8

Indemnity
You agree to defend, indemnify, and hold harmless the Copyright Holder and its parents andaffiliates and all of their employees, agents, directors, officers, proprietors, partners,
representatives, shareholders, servants, attorneys, predecessors, successors, assigns, andthose who have worked on the preparation, publication or distribution of the S3000L™ suite of
information from and against any and all claims, proceedings, damages, injuries, liabilities,
losses, costs, and expenses (including reasonable attorneys' fees and litigation expenses),relating to or arising from your use of the S3000L™ suite of information or any breach by youof this User Agreement.

2.9

Governing law and arbitration
This User Agreement will be governed by and construed in accordance with the laws of theKingdom of Belgium.
In the event of any dispute, controversy or claim arising out of or in connection with this User
Agreement, or the breach, termination or invalidity thereof, the parties agree to submit thematter to settlement proceedings under the ICC (International Chamber of Commerce) ADR
Rules. If the dispute has not been settled pursuant to the said Rules within 45 days following thefiling of a Request for ADR or within such other period as the parties may agree in writing, suchdispute shall be finally settled under the Rules of Arbitration of the International Chamber ofCommerce by three arbitrators appointed in accordance with the said Rules of Arbitration. All
related proceedings should be at the place of the ICC in Paris, France.
The language to be used in the arbitral proceedings shall be English.

S3000L-A-00-00-0000-00A-021A-A

Applicable to: All

End of data module
DMC-S3000L-A-00-00-0000-00A-021A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

Table of contents
The listed documents are included in Issue 1, dated 2010-04-01, of this publication.

Document title

Chapter

ApplicabletoIntroduction to the specification
PurposeScope
How to use the specification
Maintenance of the specification
General requirements
LSA Business process
Configuration management
Influence on design
Human factors analysis
LSA failure modes and effects analysis
Damage and special event analysis
Logistic related operations analysis
Scheduled maintenance analysis
Level of repair analysis
Maintenance task analysis
Software support analysis
Life cycle cost considerations
Obsolescence analysis
Inservice feedback
DisposalInterrelation to other ASD specifications
Data elements
Data exchange
Terms, abbreviations and acronyms
Terms, abbreviations and acronyms - Introduction
Terms, abbreviations and acronyms - Glossary of terms
Terms, abbreviations and acronyms - Abbreviations andacronyms
Data element list

Chap 1
Chap 1.1
Chap 1.2
Chap 1.3
Chap 1.4
Chap 2Chap 3Chap 4Chap 5Chap 6Chap 7Chap 8Chap 9Chap 10Chap 11
Chap 12Chap 13Chap 14Chap 15Chap 16Chap 17Chap 18
Chap 19
Chap 20
Chap 21Chap 21.1
Chap 21.2
Chap 21.3

All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All
All

Chap 22

All

Applicable to: All

S3000L-A-00-00-0000-00A-009A-A
End of data module

DMC-S3000L-A-00-00-0000-00A-009A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

Chapter 1
Introduction to the specification
Table of content
Chap 1
Chap 1.1
Chap 1.2
Chap 1.3
Chap 1.4

Document
Introduction to the specification .......................... S3000L-A-01-00-0000-00A-040A-A
Purpose .............................................................. S3000L-A-01-01-0000-00A-040A-A
Scope ................................................................ S3000L-A-01-02-0000-00A-040A-A
How to use the specification ............................. S3000L-A-01-03-0000-00A-040A-A
Maintenance of the specification ........................ S3000L-A-01-04-0000-00A-040A-A

S3000L-A-01-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-01-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 1
2010-04-01 Page 1

S3000L-B6865-03000-00

Chapter 1.1
PurposeTable of contents

Page

Purpose ......................................................................................................................................... 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 2
2
Purpose ........................................................................................................................... 2
3
Background...................................................................................................................... 2

List of tables
1

References ...................................................................................................................... 1

References
Table 1 References
Chap No./Document No.

Title

DEF-STAN-00-60

Integrated Logistic Support - UK MoD

DEX1AD

DEX1A&D - Aerospace and defense business DEX for
exchange of product breakdown for support

DEX3AD

DEX3A&D - Aerospace and defense business DEX for
exchange of a task specification

GEIA-STD-0007

Logistics Product Data

ISO 10303-239 PLCS

Product Life Cycle Support (PLCS)

MIL-HDBK-502

Department of defense handbook acquisition logistics

MIL-STD-1388-1A

Logistics support analysis - DoD

MIL-STD-1388-2B

DoD requirements for a logistic support analysis record

S1000DInternational specification for technical publications using acommon source database

S2000M

S2000M - International specification for materielmanagement

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

S5000F

Specification for operational and maintenance data
feedback

Applicable to: All

S3000L-A-01-01-0000-00A-040A-A
Chap 1.1

DMC-S3000L-A-01-01-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

1

GeneralThis chapter gives a basic overview of the S3000L purpose including the history of thedevelopment.

2

PurposeThe Logistic Support Analysis (LSA) is one of the most important processes of product support.
It is the principal tool to−−design the products relevant to maintainability, reliability, testability and to optimize life
cycle costdefine all required resources to support the product in its intended use, during in-service
operation

S3000L defines the processes, general requirements and related information exchange
governing the performance of LSA during the life cycle of aerospace and defense products. This
specification may also be used for complex technical products from other industrial domains.

3

BackgroundThe creation of this specification originated within the Aerospace and Defence Industries
Association of Europe (ASD) in 2005. At that time, MIL-STD 1388-1A had already beencancelled and DEF STAN 00-60 had become too unique to UK-MoD acquisitions to be
applicable as an international handbook for general purposes.
The lack of a common valid procedure resulted in the development of various program specific
LSA handbook versions and associate IT-solutions. For each new program (such asEurofighter, NH-90, Tiger, A400M and Gripen) these specific tasks had to be accomplished.
This caused considerable effort for both industry and its military customers.
This situation prompted an initiative by ASD and the Aerospace Industry Association of America(AIA) to consider the joint development of a new common international specification for LSA.
This initiative started with an "Inaugural meeting on S3000L" held in Brussels on January 18th,
2006. The attendees gave their expectations on the need for an international LSA specification
based on shortfalls in current standards, specifications and handbooks. It was agreed that there
is not a shortfall of standards, there are too many of them.
In a subsequent project definition phase meeting in Munich in March 2006, the following basic
requirements were identified:
The LSA specification shall−−generally be based on the processes of MIL-STD-1388-1A, MIL-HDBK-502 and
DEF-STAN-00-60 and the activity model given by ISO 10303-239 PLCS
be the handbook for creation and development of LSA data exchanged by•••

DEX1A&D - Aerospace and defense business DEX for exchange of productbreakdown for support
DEX3A&D - Aerospace and defense business DEX for exchange of a task
specification
another exchange mechanismwith the intention to address the relevant data from the MIL-STD-1388-2B.
−−−

use experience gained from the performance of LSA for the current programs such asEurofighter, NH-90, Tiger, A400M, Rafale, Gripen, JSF
include process application guidelines and rules for information exchange
be tailorable and include guidelines for tailoring

Applicable to: All

S3000L-A-01-01-0000-00A-040A-A
Chap 1.1

DMC-S3000L-A-01-01-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00−−

take into account current ISO/EN baseline documents
enable interfaces to the suite of the ASD specifications S1000D, S2000M, S4000M and theS5000F (the latter in preparation)

The development work was then allocated to an international team of experts working under thejoint chairmanship of AIA and ASD representatives. The following companies/organizations
contributed to the work:
−
−
−
−
−
−
−
−
−
−

AgustaWestland
Airbus Deutschland GmbH
BoeingDassault Aviation
EADS Casa
EADS Military Air Systems
Eurocopter
LOGSA
MBDA
Saab AB

UK
Germany
United States
FranceSpain
Germany
FranceUnited States
FranceSweden

S3000L-A-01-01-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-01-01-0000-00A-040A-A_001_00_EN-US.doc

Chap 1.1
2010-04-01 Page 3

S3000L-B6865-03000-00

Chapter 1.2
Scope
Table of contents

Page

Scope ......................................................................................................................................... 1
References ..................................................................................................................................... 1
1
Scope ............................................................................................................................... 1

List of tables
1

References ...................................................................................................................... 1

List of figures
1

The integrated logistics support functional elements ...................................................... 2

References
Table 1 References
Chap No./Document No.

Title

None

1

Scope
The specification S3000L is designed to cover all processes and requirements governing theperformance of LSA.
−
−
−
−
−

It provides rules for the usage of the product breakdown for logistic purposes and for theselection of LSA candidate items.
It describes type and methodology for performance of the specified analyses.
It gives guidelines on how to process the results of the analysis tasks and on how toachieve a cost-efficient support solution.
It covers the interface between LSA and the support engineering areas (eg reliability,
maintainability and testability).
It covers the interface between LSA and the ILS functional areas as shown in Fig 1 (egsupply support, technical data services, special tools/test equipment or training).

The specification in particular describes the interface between industry (contractor) and thecustomer, which, when based upon contractual agreements, will provide the typical deliverablesof LSA as given in this specification. Examples for typical deliverables of an LSA process are:−−−−reliable and maintainable products because of influence on design from a logistics
perspective
cost efficient support system
logistics product data
ILS support products

Applicable to: All

S3000L-A-01-02-0000-00A-040A-A
Chap 1.2

DMC-S3000L-A-01-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

Activities which are described in detail within other ASD specification like the preparation oftechnical documentation (covered by S1000D) or the establishment of a materiel management
process (covered by S2000M) are out of scope of S3000L. The same holds for prescribedmethodologies how to perform technical/logistic analysis activities (eg performance ofscheduled maintenance analysis corresponding to S4000M or detailed performance of level ofrepair analysis).

Design &Design &Development
Development

Maintainability
Maintainability
Testability
Testability

Reliability
Reliability

Logistic Support
Logistic Support
AnlysisAnlysisEnvironmental &Environmental &Operational
Operational
Requirements
Requirements

Customer
CustomerRequirements
Requirements
Support Concept
Support Concept

Supply Support
Supply Support

Technical Data
Technical Data
Services
Services

SupportSupportEquipment
Equipment

Training &Training &Training
Training
Equipment
Equipment

Infrastructure
Infrastructure

Personel
PersonelRequirements
Requirements

Maintenance
Maintenance
Plan
Plan

Integrated Logistic Support
ICN-B6865-S3000L0001-001-01
Fig 1 The integrated logistics support functional elements

S3000L-A-01-02-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-01-02-0000-00A-040A-A_001_00_EN-US.doc

Chap 1.2
2010-04-01 Page 2

S3000L-B6865-03000-00

Chapter 1.3
How to use the specification
Table of contents

Page

How to use the specification .......................................................................................................... 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 3
2
Application ....................................................................................................................... 3
2.1
S3000L Application policy ............................................................................................... 3
2.2
S3000L Application .......................................................................................................... 3
2.3
Tailoring of S3000L processes ........................................................................................ 3
3
Basic definitions ............................................................................................................... 3
4
Acronyms ......................................................................................................................... 3
5
Organization of the specification ..................................................................................... 4
5.1
Chapter 1 - Introduction to the specification .................................................................... 4
5.2
Chapter 2 - General requirements ................................................................................... 4
5.3
Chapter 3 - LSA Business process.................................................................................. 4
5.4
Chapter 4 - Configuration management .......................................................................... 5
5.5
Chapter 5 - Influence on design ...................................................................................... 5
5.6
Chapter 6 - Human factors analysis ................................................................................ 5
5.7
Chapter 7 - LSA failure modes and effects analysis ....................................................... 5
5.8
Chapter 8 - Damage and event analysis ......................................................................... 5
5.9
Chapter 9 - Logistic related operations analysis ............................................................. 5
5.10
Chapter 10 - Scheduled maintenance analysis ............................................................... 6
5.11
Chapter 11 - Level of repair analysis ............................................................................... 6
5.12
Chapter 12 - Maintenance task analysis ......................................................................... 6
5.13
Chapter 13 - Software support analysis .......................................................................... 6
5.14
Chapter 14 - Life cycle cost considerations ..................................................................... 6
5.15
Chapter 15 - Obsolescence analysis ............................................................................... 6
5.16
Chapter 16 - Inservice feedback...................................................................................... 7
5.17
Chapter 17 - Disposal ...................................................................................................... 7
5.18
Chapter 18 - Interrelation to other ASD specifications .................................................... 7
5.19
Chapter 19 - Data elements ............................................................................................ 7
5.20
Chapter 20 - Data exchange ........................................................................................... 7
5.21
Chapter 21 - Terms, abbreviations and acronyms .......................................................... 8
5.22
Chapter 22 - Data element list ......................................................................................... 86
Supporting publications ................................................................................................... 8

List of tables
1

References ...................................................................................................................... 1

References
Table 1 References
Chap No./Document No.

Title

Chap 1Introduction

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

Chap No./Document No.

Title

Chap 2

General requirements

Chap 3LSA Business process

Chap 4

Configuration management

Chap 5

Influence on design

Chap 6

Human factors analysis

Chap 7

LSA failure modes and effects analysis

Chap 8

Damage and event analysis

Chap 9Logistic related operations analysis

Chap 10

Scheduled maintenance analysis

Chap 11

Level of repair analysis

Chap 12Maintenance task analysis

Chap 13

Software support analysis

Chap 14

Life cycle cost considerations

Chap 15

Obsolescence analysis

Chap 16

Inservice feedback

Chap 17

Disposal

Chap 18

Interrelation to other ASD specifications

Chap 19

Data elements

Chap 20

Data exchange

Chap 21

Terms, abbreviations and acronyms

Chap 22

Data element list

DEX1AD

DEX1A&D - Aerospace and defense business DEX for
exchange of product breakdown for support

DEX3AD

DEX3A&D - Aerospace and defense business DEX for
exchange of a task specification

S1000DInternational specification for technical publications using
a common source database

S1003X

S1000D and S3000L interface specification

S2000M

International specification for materiel management

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

S5000F

International specification for operational and maintenancedata feedback

ISO 10303-239 PLCS

Product Life Cycle Support (PLCS)

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

1

GeneralThis chapter gives an overview of−−

how to apply S3000L to a project
organization of the specificationand the fundamental reading rules.

2

Application

2.1

S3000L Application policy
It is intended that S3000L shall be the common LSA specification to be used by customers andcontractors, eg governments, procurement authorities, support agencies, and industry. By
agreement between customer and contractor, S3000L can be supplemented by additional
international or national requirements for specific projects. The use of the specification and any
supplemental processes should always be a subject of the contractual agreement between thecustomer and contractor. It is also the intention of industry that the specification shall be used,whenever possible, in projects involving other customers throughout the world.

2.2

S3000L Application
At the start of any project in which the S3000L procedures are to be used, it is necessary for thecustomer and contractor to agree how S3000L should be utilized and to jointly define thevariables and options which S3000L provides. These agreements are recorded in the document
commonly known as the project’s Guidance Conference Document (GCD). The process usedby the customer and contractor to establish the information to go into the GCD is known as the"LSA Guidance Conference", which is described in detail in Chap 3.
In addition, in order to supplement the GCD, the project should also define an interchange
specification (data and other deliverables). Depending upon the complexity of the project, thismay be a stand-alone specification, or integrated within the GCD.

2.3

Tailoring of S3000L processes
In order to ensure efficient application, S3000L has been designed to allow users to selectfunctionality that is appropriate to their specific projects.
Individual chapters may be included or excluded. Tailoring can also be applied in regard to
number and range of LSA candidate items, in regards to the number of analyses per candidate
item and in regard to data to be used during an analysis.

34Basic definitions
the ProductAny platform, system or equipment (air, sea, land vehicle,
equipment or facility, civil or military)

project

The task to develop, maintain and dispose of the ProductAcronyms
Throughout the S3000L a set of common acronyms are used to aid understanding and tominimize duplication. These acronyms are only explained in this chapter.The same abbreviation
is used for all tenses, the possessive case and singular and plural forms of a given word. A
complete list of abbreviations, acronyms and definitions is given in Chap 21.
The common acronyms are:
AIA

Aerospace Industries Association of America

ASD

European Aerospace and Defense Industries

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

5

ATA

Air Transport Association

CAGE

Commercial And Government Entity

CSN

Catalog Sequence Number

FMEA

Failure Mode and Effects Analysis

FMECA

Failure Mode, Effects and Criticality Analysis

ILS

Integrated Logistics Support

LORA

Level of Repair Analysis

LRU

Line Replaceable Unit

LSA GCLSA Guidance Conference

PLCS

Product Life Cycle Support

RCM

Reliability Centered Maintenance

SE

Systems Engineering

SRU

Shop Replaceable Unit

Organization of the specification
S3000L is organized into chapters. When subjects are common to more than one chapter, they
have been assigned to an appendix which must be read in conjunction with the related chapter.
The nature of the project using S3000L will determine the range of deliverables that are
required and hence the depth to which the S3000L procedures need to be employed (tailoring).
Details are given in the specification.

5.1

Chapter 1 - Introduction to the specification
Chap 1 provides a summarized view on purpose, background, scope and application of
S3000L. It also explains the rules regarding the maintenance of S3000L and how to access the
specification.

5.2

Chapter 2 - General requirements
Chap 2 provides general information regarding the set-up and administration of an LSA programas part of an overall development/ILS program. It describes the interfaces, dependencies andtime constraints in regard to the other ILS disciplines within a model scenario.

5.3

Chapter 3 - LSA Business process
Chap 3 is designed to provide a full, in-depth description of the complete LSA process. It starts
with the establishment of product usage data by the customer and LSA significant productdesign and performance data by the contractor. These are joint inputs for the LSA Guidance
conference. The LSA Guidance conference establishes an agreement on rules regarding typeand depth of breakdown and on methodology of LSA candidate item selection and identification.
Chap 3 further defines the type, methodology and acceptance of the potential analysis tasks. It
covers the customer involvement in the LSA business process and the performance of the LSA
Review conference. This is the final step in accepting the LSA results and defining the support
concept. It also starts the production of ILS elements to support operation.

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

5.4

Chapter 4 - Configuration management
Configuration management is the discipline that ensures the proper identification and version of
the configuration. It controls changes, and records the change implementation status of thephysical and functional characteristics of the structure, system/subsystem, and equipment.
Configuration management therefore is the means through which integrity and continuity of thedesign, systems engineering and supportability are recorded, communicated, and controlled.
Configuration management efforts result in complete audit traceability of decisions and designmodifications.
This chapter defines the details and methodology of how the principles of configuration
management are applied to the LSA process. Refer to Chap 4.

5.5

Chapter 5 - Influence on design
Influence on design is the goal of an industrial activity generally known as supportability
engineering. Supportability engineering influences those product characteristics which are vitalfor enabling the operation of the product according to performance and design requirements
and to minimize Life Cycle Cost (LCC).
The product characteristics to be influenced are primarily Reliability, Maintainability andTestability. The tools for supportability engineering are early Reliability, Maintainability andTestability activities/programs and the performance of Logistic Support Analysis.
Supportability engineering acts as the enabler between Design and Development andIntegrated Logistics Support (ILS).
This chapter describes how the methods of supportability engineering are applied and how theresults will be linked to the LSA process. Refer to Chap 5.

5.6

Chapter 6 - Human factors analysis
Chap 6 describes the relationship and integration between human factors engineering and the
support analysis process. Like all other supportability engineering functions, human factors
provide source data that is used by the support analysis team to determine maintenance crew
and support equipment requirements. This relationship begins in the design review process andcontinues through the development of the maintenance task analysis.

5.7

Chapter 7 - LSA failure modes and effects analysis
Chap 7 covers the methodology and decision logic that will be applied for the identification ofcorrective maintenance tasks to be applied to the product in case of a failure occurrence during
normal use.

5.8

Chapter 8 - Damage and event analysis
Chap 8 covers the methodology for identifying and justifying those maintenance tasks which areappropriate in case of special events or damage found on the product during general or detailed
inspections.

5.9

Chapter 9 - Logistic related operations analysis
Chap 9 covers the methodology for identifying and justifying logistic related operations tasks.
These are tasks which can neither be assigned directly to the area of direct usage of a productsystem (eg documented in a user's guide) nor to the area of maintenance (eg documented in a
maintenance handbook). However, they are accomplished in operations and maintenancefacilities in support of the day to day operations (eg packaging, handling, storage, mooring)
These tasks can be very important for the proper usage of any product. There are many
operational aspects (ease of operation, usability, flexibility of usage, mobility, etc) that are
restricted by logistics related operations tasks.

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

5.10

Chapter 10 - Scheduled maintenance analysis
The identification of required scheduled or preventive maintenance is of vital importance for theoperation of a complex Product. Technical, commercial, operational and environmental factors
must be carefully considered. The preventive or scheduled maintenance, along with thecorrective maintenance gives a complete view of what must be expected in terms of the effort
for overall maintenance activities. Refer to Chap 10.

5.11

Chapter 11 - Level of repair analysis
Chap 11 describes the actions to be taken when performing a Level of Repair Analysis (LORA)
as part of any acquisition program. The requirement for a LORA is usually located in logistic
support plans or similar documents.
LORA is a stand-alone activity that establishes an optimised maintenance or support concept
using technical, commercial, operational and environmental data. The LORA should be
performed on each LSA candidate item to determine the most cost-effective method to restore
each item to its full serviceable condition.

5.12

Chapter 12 - Maintenance task analysis
Chap 12 covers the methodology of how to analyse an identified maintenance task concerning
its logistic requirements including spare parts and consumables, support equipment, personnel,
facilities and task duration information. Additional information such as task criticality, training
needs, pre- and post-conditions, safety and environmental requirements should also be
considered.

5.13

Chapter 13 - Software support analysis
Chap 13 provides the logistic analyst with a guideline on how to handle the specificrequirements concerning software in the environment of maintenance and operation of technicalsystems. Additionally, the interrelation between software and hardware will be defined clearly
and an explanation will be given on how to integrate software aspects in the overall LSA
process.
In modern technical Products, software aspects are of increasing significance. More and more
Product functions are performed by complex software packages. For hardware components,
concepts and processes are established to guarantee a proper supportability of the system
during its entire life cycle. These concepts and processes are documented in the LSA process.
Software has the same requirement. Software and hardware are of equal importance for theproper function of a product. For this reason, an analysis methodology should be applied todevelop an adequate software support concept, called Software Support Analysis (SSA).

5.14

Chapter 14 - Life cycle cost considerations
Chap 14 covers the actions to be taken by the LSA analyst with regard to life cycle cost. LCC is
the total cost of ownership of a product including all the direct and indirect costs.
The objective of LCC is to choose the most cost effective approach from a series of alternatives
to achieve the optimum cost of ownership for the life cycle of the product. LCC is an economic
model over the life cycle, including the cost of operation, maintenance and disposal (Recurring
Costs). These normally exceed all the other costs such as development (Non-Recurring Costs).
LCC is a very useful tool in the determination of design configuration alternatives, andoperational and support concepts.

5.15

Chapter 15 - Obsolescence analysis
Chap 15 describes the relationship between obsolescence analysis and the support analysis
process.

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

In the development process it is the goal of LSA to avoid/control the use of components andmateriel that are likely to result in obsolescence in the early operational phase.
During the inservice phase, LSA will be involved in the analysis of obsolescence events and willcontribute to the definition of economic alternatives with regard to the maintenance and support
concept.
The results of the obsolescence analysis effort will be stored in the LSA data repository.

5.16

Chapter 16 - Inservice feedback
Chap 16 covers the methodology of how to feed inservice data back into the LSA businessprocess. This feedback is required to compare the actual product performance with thepredicted performance values established during the LSA process. Amongst others, thiscomparison will enable industry to manage performance based contracts.
This subject will also be covered by a new ASD specification, ASD S5000F - Specification for
operational and maintenance data feedback, which is under preparation.

5.17

Chapter 17 - Disposal
Chap 17 deals with the disposal of products and product components, eg their disposal from
active and/or passive operation. Although disposal of products normally occurs during the lastphase of the life cycle, disposal has to be considered in the very early phases of every program
planning to acquire a product.
Adequate disposal activities may include:−−−

destruction/neutralization of toxic substances
enabling a sustainable development, by recycling materials
demilitarization of defense systems, to avoid weapons proliferation

Disposal activities of the life cycle phases are outlined in this chapter. Appropriate data will be
generated and be used during the LSA process.

5.18

Chapter 18 - Interrelation to other ASD specifications
Chap 18 addresses the benefits of using the ASD suite of ILS Specifications in conjunction withthis specification. The LSA relationships to the following specifications are addressed:−

S1000D - International specification for technical publications using a common source
database.
Note
Issue 1 of S3000L is synchronized to S1000D at Issue 4.0.

−−

S2000M - International specification for materiel management
S4000M - International procedure handbook for the development of scheduled
maintenance programs for military aircrafts
S5000F - International specification for operational and maintenance data feedback

−

5.19

Chapter 19 - Data elements
Chap 19 defines a coherent data model supporting the S3000L LSA process and its interaction
with the related business processes. These processes can either be dependent upon data
coming out from LSA or be business processes that provide input to the LSA process.
Additionally, the chapter defines all data elements that are used in the S3000L data model. A
matrix gives for each data element the related chapter in the specification and it describes thedata group (class) to which the data element belongs.

5.20

Chapter 20 - Data exchange
Chap 20 deals with the interaction between the LSA process and its related business processes
can be realized using computer based data exchange. Chap 20 defines a set of Data Exchange

Applicable to: All

S3000L-A-01-03-0000-00A-040A-A
Chap 1.3

DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

Specifications (DEX) which supports the events when data is to be exchanged between various
engineering disciplines, such as design engineering, maintainability engineering, reliability
engineering and technical publications development.
A DEX is a standardized message, based on ISO 10303-239 Product Life Cycle Support(PLCS).
The PLCS compliant data exchange specifications that supports subsets of the S3000L data
model are the aerospace and defense DEX1A&D - Aerospace and defense business DEX for
exchange of product breakdown for support and the DEX3A&D - Aerospace and defense
business DEX for exchange of a task specification. These DEX can be used to exchange task
data between an S3000L application and an S1000D Common Source Data Base.
For more information on how DEX1A&D and DEX3A&D can be used to support the exchange oftask data between S3000L and S1000D refer to S1003X - S1000D and S3000L interface
specification. Refer to Para 6.

5.21

Chapter 21 - Terms, abbreviations and acronyms
Chap 21 provides a glossary of terms, abbreviations and acronyms used within S3000L.

5.22

Chapter 22 - Data element list
Chap 22 defines all the data elements that are used as attributes in the S3000L data model andin the S3000L data exchange specifications.
A data element list is organized alphabetically by the data element name, and contains:−−−−

Data element name
Data element data
Data element definition, contains a textual definition and a list of valid values
Class name, identifies Classes in the S3000L data model where the data element is used
as an attribute
Unit of Functionality, identifies in which section of Chap 19 where the Class is defined
S3000L chapter references, indicating which business process in S3000L that creates (C),reads (R), or updates (U) the respective data element.

−−

An attribute list defines all the data elements that are used to define the S3000L data types

6

Supporting publications
For implementation and data exchange the following specifications/files have been developed insync with S3000L:−

DEX1A&D - Aerospace and defense business DEX for exchange of product breakdown for
1
support2
DEX3A&D - Aerospace and defense business DEX for exchange of a task specification
3
S1003X - S1000D and S3000L interface specification−−

1

Available as an extractable zip-file including a set of html files

2

Available as an extractable zip-file including a set of html files

3

Available as a pdf file

S3000L-A-01-03-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-01-03-0000-00A-040A-A_001_00_EN-US.doc

Chap 1.3
2010-04-01 Page 8

S3000L-B6865-03000-00

Chapter 1.4
Maintenance of the specification
Table of contents

Page

Maintenance of the specification.................................................................................................... 1
References ..................................................................................................................................... 1
1
Maintenance of the specification ..................................................................................... 1

List of tables
Table 1 References ....................................................................................................................... 1

References
Table 1 References
Chap No./Document No.

Title

None

1

Maintenance of the specification
The S3000L suite of information will be maintained and further enhanced by a S3000L Steering
Committee which will comprise representatives from member nations of ASD and AIA.
Any proposals relating to changes to the specification are to be managed by change proposals.
The suite consists of the following four specifications/files:−−−−

S3000L - International procedure specification for Logistics Support Analysis
DEX1A&D - Aerospace and defense business DEX for exchange of product breakdown forsupport
DEX3A&D - Aerospace and defense business DEX for exchange of a task specification
S1003X - S1000D and S3000L interface specification

S3000L-A-01-04-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-01-04-0000-00A-040A-A_001_00_EN-US.doc

Chap 1.4
2010-04-01 Page 1

S3000L-B6568-03000-00

Chapter 2
General requirements
Table of contents

Page

General requirements .................................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Integrated logistic support program ................................................................................. 3
2.1
Integrated logistic support program implementation ....................................................... 3
2.2
Integrated logistic support program supplier participation ............................................... 4
2.3
Progress, status and management reporting .................................................................. 4
2.4
Integrated logistic support in the system engineering process ....................................... 4
2.5
ILS management ............................................................................................................. 4
2.5.1
ILS manager responsibilities ........................................................................................... 4
2.5.2
ILS management ............................................................................................................. 52.5.3
Master ILS program milestone schedule ......................................................................... 5
2.5.4
ILS organization ............................................................................................................... 5
3
Logistics support analysis program ................................................................................. 6
3.1
LSA implementation ........................................................................................................ 6
3.1.1
LSA activities and performance ....................................................................................... 6
3.1.2
Develop an early LSA strategy ........................................................................................ 7
3.1.3
LSA program plan requirements...................................................................................... 8
3.2
Program management principles ..................................................................................... 9
3.2.1
Integrated logistics support management ....................................................................... 9
3.2.2
Operating logistics organizational structures ................................................................... 9
3.2.3
Formal logistics organizations ......................................................................................... 9
3.3
Logistics management objectives and policies ............................................................. 10
3.3.1
Logistics management objectives.................................................................................. 10
3.3.2
Logistics management policies...................................................................................... 10
3.4
LSA program organization ............................................................................................. 10
3.5
LSA management responsibilities ................................................................................. 11
3.5.1
The LSA manager.......................................................................................................... 11
3.5.2
Program LSA managers/leads ...................................................................................... 12
3.5.3
Program technical staff (logistics engineers/analysts) .................................................. 12
3.5.4
Supportability analysis integrated product team ............................................................ 12
3.6
Elements of a LSA program plan................................................................................... 12
3.6.1
General requirements .................................................................................................... 12
3.6.2
Functional requirements identification ........................................................................... 13
3.6.3
Unique functional requirements ..................................................................................... 14
4
Product development organization ................................................................................ 14
4.1
Integrated product teams ............................................................................................... 14
4.2
Multidiscipline teams ..................................................................................................... 15
4.3
Single point accountability ............................................................................................. 15
4.4
Empowerment................................................................................................................ 15
4.5Management plans ........................................................................................................ 15
4.6
Clear product definition and interfaces .......................................................................... 16
4.7
Disciplined processes .................................................................................................... 16
4.8
Effective communications .............................................................................................. 16
4.9
Performance metrics ..................................................................................................... 16
Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

List of tables
1

References ...................................................................................................................... 2

List of figures
1
2

Example for a simple ILS/LSA management structure.................................................... 6
Simplified LSA process .................................................................................................... 7

References
Table 1 References
Chap No./Document No.

Title

Chap 3

1

General1.1

Introduction
The Logistic Support Analysis (LSA) program is considered to be a subset of Integrated Logistic
Support (ILS). ILS has overall responsibility for the development of technical information and the
support environment that will be used to support a product throughout its intended life cycle.
The different disciplines in the context of supportability (eg technical documentation, spareparts, support equipment, personnel and training) need to be harmonized. The main disciplines
are:
−
−
−
−
−
−
−
−
−
−

Design interface
Supply support and provisioning
Support and test equipment
Technical data/technical documentation
Personnel and manpower
IT/Software support
Facilities
Scheduled maintenance/maintenance planning
Packaging, Handling, Storage and Transportation (PHST)
Training and training devices

The LSA program is the principal source of technical data for ILS planning and resource
decision. LSA will be used:−−−

To link system design and ILS requirements to system readiness thresholds and to define
detailed support element requirements.
Throughout the acquisition cycle to assess and alter system design and to establish andupdate support element requirements.
As an important source of design related data for determining and integrating all logistics
support requirements, for analyzing alternative design, operational, and support concepts,
and for conducting tradeoffs among design and the various elements of logistics support oftechnical data for ILS planning and resource decisions.

The logistic analysis activities results and support resource data will be stored in the LSA
database to give all program elements access to a common data source for evaluating the
supportability of design alternatives and objectives. The integrated product teams' practices will
Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

ensure the timely interaction of the LSA activities and data for all elements of the design
process.

1.2

ObjectiveILS supported by an embedded LSA process ensures there is an open exchange of information
to and between the logistic disciplines and to the design. It pursues two thrusts simultaneously:−

Design for support
A focus on designs that minimize operation, maintenance, training, support tasks, and lifecycle costs while optimizing operational readiness.

−

Design of support
The design, development, funding, test, and acquisition of all support resources needed toassure optimum performance and readiness of the system in its intended operational
environment and mission profiles.

1.3

Scope
This chapter is directed to ILS managers and LSA managers for both the customer and thecontractor. The understanding of how a LSA program needs to be integrated into the superordinate ILS program is of crucial importance. The approach for implementing a LSA program
varies across organizations and sometimes across projects within an organization. Regardlessof the organization or project, there should be policies in place to establish the functional
responsibilities and expectations of the LSA program.

2

Integrated logistic support program

2.1

Integrated logistic support program implementation
The LSA program is the central element of the contractor's logistics program and provides theframework for monitoring and controlling the orderly and systematic development and executionof the ILS program, including identification of necessary corrective activities, communications,and follow-up procedures. LSA provides the data required to define and develop logistic
elements support resource requirements. Data generated by performance of LSA activities are
documented in data records directly related to the logistic elements.
Through the integrated product development system engineering process, the LSA program has
been established as the analytical tool for determination of supportability requirements for thelogistic elements. Since design and supportability requirements are fed into the LSA database,a direct relationship has been established between logistic-related design parameters such as,reliability, maintainability, and availability to readiness resource requirements.
Evaluation of LSA output reports, coupled with design process feedback, assists the contractor
in defining supportability drivers and requirements. Additionally, due to the iterative nature of
LSA, an audit trail is formed which documents the process used to make supportability
decisions.
LSA input data from the engineering specialties and supportability tasks are fed into the LSA
database. Reports are provided to the logistic members of the integrated product organizationand feedback occurs within the integrated product organization. Logistics elements are directly
related to each other through the LSA process and their impact on other elements is readily
available through output reports using the common LSA database. Using these outputs, thecontractor can determine, for example, what effect selection of a particular item of support
equipment will have on maintenance planning, training requirements, technical data, and supply
support. This information permits logistic element resource planners to make timely andintelligent inputs into the design process, which in turn permits optimization of support at thelowest logistic Life Cycle Cost (LCC).

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

2.2

Integrated logistic support program supplier participation
Suppliers are an integral part of the logistics organization, especially main suppliers within the
program need to be integrated in the ILS process. The contractor will impose as much of the
ILS program on suppliers as is practical, consistent with the suppliers' capability andexperience. The contractor conducts ILS procurement reviews to evaluate candidate suppliers
based on their logistics and supportability program capability. This effort, similar to a source
selection evaluation, surveys suppliers to verify that each supplier is capable of providing thelogistic support necessary to satisfy program requirements.

2.3

Progress, status and management reporting
ILS planning and control regularly reporting will provide ILS progress, status and management
report needs. Such a management report can include among other things:−−−

Master ILS program milestone schedule
Baseline schedule for each logistic element
Current status of each logistic element compared to the Statement of Work (SOW)The required reporting system is dependent on the project itself. Standardized solutions forsuch reporting requirements are often not available or not applicable to specific project needs.

2.4

Integrated logistic support in the system engineering process
Contractor objectives for integration of logistics and supportability into the systems engineering
process is to ensure that the traditional design process disciplines, and reliability andmaintainability engineering are employed in the design-to-support parameters for the programsupport system. This objective is part of the overall program management objective to:−−−−Achieve operational availability and readiness thresholds
Achieve reliability and maintainability thresholds necessary to meet these objectives
Assign appropriate priorities to logistics and supportability element requirements in systemdesign tradeoffs
Identify support and manpower drivers

Systems engineering is the application of scientific and engineering resources to:−−−Transform the operational need into a system configuration which meets effectivenessstandards
Integrate related technical parameters and assure compatibility in a manner which
optimizes the system and the system's design
Integrate the efforts of all engineering disciplines and specialties into the integrated productdevelopment systems engineering process

Logistics and supportability:
−
−
−
−
−
−

Flows down system requirements
Develop logistic support requirements
Develop the support system
Interacts with and makes direct inputs to the integrated product organisation during tradestudies
Participates in design analyses
Responds to customer requirements and expectations

2.5

ILS management

2.5.1

ILS manager responsibilities
The ILS manager with the direction, control and authority to:−−Plan, coordinate, develop, produce and deliver quality products on schedule and within cost
Assure the development of each logistic element is driven by and results from the LSA

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

−
−

2.5.2

Plan, coordinate, and schedule the resources necessary to test and evaluate the system,
support and test equipment, training equipment, containers, associated logistics data andplanned logistics resources
Ensure supportability and supportability-related features are incorporated into the system,
support system, and training system design

ILS management
The ILS management functions to monitor and control the execution of ILS planning, coordinate
efforts, monitor schedules, assess performance, and ensure timeliness and accuracy of inputs.
ILS management also evaluates compliance with applicable specifications, requirements, andguidelines. Program status should be maintained for individual areas of responsibility.
ILS management meetings will be scheduled to be held in conjunction with other major program
meetings, eg design reviews. Regular logistics technical interchange meetings will be held in
direct support of the ILS management.

2.5.3

Master ILS program milestone schedule
The ILS Planning and Control process provides the planning, scheduling and reporting system
necessary for effective ILS management of the program. Generation, implementation andupdating of the master ILS program milestone schedule can be established as a four step
process.
−
−

−

−

2.5.4

Initiate specified and expected contract requirements. These documents provide key
system development, testing and operational dates, locations and hardware requirements.
Major ILS milestones are identified and updated for use in ILS plans, schedules and status
reports. This step requires a master ILS program milestone schedule for the purpose of
integrating the overall ILS program, determining the relationship among logistic elementtasks, and merging the ILS program into a master program schedule.
Logistic element plans and schedules provide the logistic elements leader with a planningand control system. Baseline logistic element schedules are linked to the master ILS
program milestone schedule and are provided in an ILS program progress, status andmanagement report (or reports).
Provides detailed logistic resource scheduling and status reporting for items such as,
spares and repair parts, technical data, training equipment.

ILS organization
The ILS organization has to be established carefully. All responsibilities must be clear andtransparent for all participants within the ILS and LSA processes (especially in programs where
cooperation between several companies has to be established). The top level ILS manager is
responsible for the proper establishment of such an organization. ILS managers at the several
cooperation partners can support the overall ILS manager. The same holds for the LSA
organization. It is recommended to establish a top level LSA manager who supports the ILS
manager. LSA managers at the participating partner companies within a cooperation project
have to report to the top level LSA manager. It must be pointed out that a proper ILS/LSA
organization has to be established on both sides, customer and contractor. The example given
in Fig 1 shows a simple schema of an ILS/LSA management structure.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

Programmanagement

ILS manager(lead)„local“ ILS manager(eg at one company within acooperative program)

LSA manager(lead)„local“ LSA manager(eg at one company within acooperative program)

ILS discipline
ILS discipline
managers
ILS discipline
managers
ILS discipline
managers
ILS discipline
managers
ILS discipline
managers
ILS discipline
managers
managers

ICN-B6865-S3000L0096-001-01
Fig 1 Example for a simple ILS/LSA management structure

3

Logistics support analysis program
LSA is a systematic iterative process that integrates system design and support system
requirements and evaluates supportability requirements relative to achieving the specified
system/component sustainability and availability requirements. The analyses documentation
process is optimized by employing an electronic database. The logistics relevant informationconsists of the identification, optimization, and traceability of ILS resources (eg spares,
manpower; personnel; training; support and test equipment, training and training equipment,
facilities, PHST and technical documentation).

3.1

LSA implementation
Design reviews and technical information meetings should be conducted throughout the
program. Host design reviews and conduct in-house design reviews to ensure that Design
Program goals and objectives are being achieved. The cognizant LSA analysts and integrated
product personnel will be aware of supportability and supportability related design issues
through direct participation in design reviews and/or by receiving all design review meeting
minutes. Supportability concerns involving equipment design that arises during meetings, or
throughout the overall and continuous design process, will be brought to the attention of thecognizant integrated product engineers. All design related supportability issues will be
documented, including status, as necessary to ensure that a timely and appropriate resolution is
obtained. LSA reviews will be conducted in conjunction with scheduled design/quarterly
reviews.

3.1.1

LSA activities and performance
The LSA process includes the application of selected quantitative methods (refer to Fig 2) to aid
in the:−−−Initial determination and establishment of logistic criteria as an input to system design
Evaluation of various design alternatives
Identification and provisioning of logistic support elements

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00−

Final assessment of the system support capability during use
Staff target/ andoperational
requirements

Supportconcept

DesignEvent analysis(incl. LSA
FMEA)Corrective
maintenance

Scheduledmaintenanceanalysis

Operational
tasks

Scheduled/
preventive
maintenanceSupportresource
requirements
Level of repair
analysis (LORA)

Maintenance
Task Analysis

ICN-B6865-S3000L0095-002-01
Fig 2 Simplified LSA process
The LSA program is based on an integrated product definition concept and can be based on thefollowing major elements:
−
−
−
−
3.1.2

A LSA program plan that identifies all the required LSA activities that must be performed inorder to influence design for supportability and determines the appropriate logistic
resources
Scheduling that identifies the timing of the LSA requirements. The LSA schedules may bebased on program phased needs and established to be mutually beneficial and supportiveof other program requirements
Assignment of responsibilities for performance of LSA activities to the design,
supportability, and ILS personnel skilled and qualified for the activity
Effective management of a wide range of design, supportability, and ILS disciplines

Develop an early LSA strategy
Develop a proposed LSA program strategy to be performed early in the acquisition program.
This strategy will identify the scope of the proposed supportability objectives for thesystem/equipment, and the qualitative analysis that will be performed to provide the best costbenefit for the acquisition program. The LSA requirements will be analyzed in order to establish
a comprehensive LSA program, including quantitative, qualitative and test LSA requirements forthe systems, subsystems, and components comprising the overall system. The resultant LSA
program shall be a tailored cost effective program that accomplishes each customer requested
procedure and provides a system that meets or exceeds each customer LSA requirement.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

3.1.3

LSA program plan requirements
The LSA Program Plan (LSA PP) describes the strategy for developing the LSA activities during
the engineering and manufacturing development phase of the complete program. It identifies
and integrates the LSA activities, identifies management responsibilities and activities, andestablishes the approach for accomplishing the analysis activities. This plan provides aroadmap of what LSA will be performed and how it will be accomplished. Furthermore, this plan
provides an approach to LSA and a basis to measure progress throughout the various phasesof the program. The LSA process is iterative and dynamic in nature; therefore this plan will be
updated to reflect current program status and planned changes.
This LSA PP describes the LSA process and the management structure established to execute
this process. It contains details as to how the LSA process will be accomplished to satisfy theintended requirements. LSA is an iterative process that usually continues for as long as the item
under analysis is in continuous use. Once the item has been retired, the LSA data may be usedas baseline comparison data for future supported items.
The LSA PP describes the management, organizations, and procedures required to accomplish
program requirements. It shall include the following:
−
−
−
−
−
−
−
−

Description, interrelationships, and schedule of procedures to be accomplished by eachorganizational element concerned in support of the LSA program
Statement of requirements for LSA program participants (eg subcontractors, suppliers,
partner companies, agencies)
Identification of LSA program monitoring points
Dissemination of LSA requirements to design and description of techniques to be employed
to ensure that desired LSA is inherent in the product design
Description of the planned approach to LSA activities, and specific methods and sources tobe employed to satisfy qualitative supportability analysis and resolve design issues
Description of the LSA database, Work Breakdown Structure (WBS), Breakdown element
identification numbering system, and handling government furnished information
Description of how problems will be identified, controlled, and reported
Description of provisions for updating the plan

Planning and coordination of LSA is the responsibility of logistics engineering management.
LSA managers provide technical guidance in conducting LSA and have special analytical skills
required to accomplish LSA-peculiar activities. Procedures must ensure supportability
requirements are identified as an integral part of systems engineering and design. Supportability
design baselines identify:−

Quantified reliability and maintainability comparative analysis requirements, like:
•
•
•

−

The maintenance concept including:
•
•

−
−
−
−

Maintenance man-hours per operating hour
Mean Time Between Failure (MTBF)
Mean Time to Repair (MTTR)

On equipment activities
Off equipment activities

Field/fleet supportability improvements and status
Lessons learned and status
Support drivers
New technology requirements

In general the LSA PP can be a part of an overall ILS management plan or ILS PP. For more
complex projects it is recommended to have a separate document. Many aspects to be covered
are also harmonized and agreed between customer and contractor within a LSA Guidance
Conference (GC). In Chap 3 a proposal is given how to organize the huge amount of
information with the help of two different documents:
Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

−
−

3.2

LSA Program Plan (LSA PP)
Guidance Conference Document (GCD)

Program management principles
The logistics team is responsible for development of the support system. This team is a subsetof the integrated product team responsible for the design, development, manufacture,operations, and support of a specific product.

3.2.1

Integrated logistics support management
The maintenance of an interface with the LSA program manager (LSA manager) to provide
continuity between program management direction and the development of the LSA results is of
crucial importance. A smooth execution of the LSA program by maintaining proper interface
between the LSA program manager/lead and other functional management should be ensured.
The ILS manager is responsible for providing logistics and supportability expertise andresources to the program teams. In the product development process, each integrated productteam leader controls the budget and is held accountable for development of that team's
products. Consequently, most logistics and supportability personnel are assigned to, and workwith, the integrated product teams. Logistics and supportability resources should be provided tothe integrated product teams to:
−
−
−
−

3.2.2

Incorporate supportability into the design of the system and support system by providing
reliability, maintainability, testability, human engineering, integrated diagnostics, andenvironmental suitability resources.
Develop the support system and training system, and plan logistics resources by providing
supply support, support equipment, technical data, facilities, PHST, manpower andpersonnel, and training and training equipment personnel.
Accomplish logistics engineering in the product development systems engineering anddesign process.
Provide for LSA, standardization, interchangeability and interoperability, and environmental
assurance.

Operating logistics organizational structures
The operating organizational structure for a support program may be aligned with the WBS. The
hierarchical characteristics of the WBS may be used to establish lines of responsibility,
authority, accountability and reporting chains from the lowest level member to the program
manager. Integration of logistics into the depicted organization is designed to:−−Reflect each logistics and supportability element identified by the WBS and system
specification.
Provide effective interfaces for logistics-related design functions most important todeveloping the support system, and achieving readiness goals.

Each ILS manager is vested with total responsibility for all aspects of that team's products.
Product team leaders at each organizational level combine the responsibilities of all subordinate
product teams. This responsibility and reporting chain continues to the point that the program
manager, as leader of the system team, has responsibility for all products. A significant featureof this organization is every product has a single point of responsibility, authority andaccountability in the organization.
3.2.3

Formal logistics organizations
Functional leaders such as product support, production, and engineering department heads are
members of the product team and provide support to the program manager. In that capacity,
these leaders bring functional expertise and resources to assist in program execution andensure uniform, timely assignment of needed skills to the product teams to assist in program
execution and ensure uniform, timely assignment of added skill to the integrated product teams.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6568-03000-00

3.3

Logistics management objectives and policies

3.3.1

Logistics management objectives
Integration of logistics and supportability into the integrated product development programorganization ensures:
−
−
−
−
−
−
−

Design reflects test data assessment, supportability alternatives and tradeoff evaluations
Detailed specification requirements
Logistic resource planning is adjusted as necessary
Operational availability and readiness thresholds are met
The item is supportable in the expected operational environment
The operational environments is/are accurately assessed
The Support System achieves expected performance

An underlying logistic program objective is to identify and resolve supportability technical risk
issues early, prior to beginning production and deployment of the product.
3.3.2

Logistics management policies
To achieve logistics management objectives, a proper organization should be established fordesign-for-supportability through the integration of design and the development of the support
system and training system. This will be achieved by:−−−

Structuring an integrated product development organization which provides for active
logistics participation and influence on design
Structuring the ILS process to be continuously interactive, on a working level, with design
engineering through the system engineering process
Planning to work closely with customers and suppliers to develop the system

Additionally, established a LSA process which:−−−

Provides the logistic analysis procedures for integrating supportability requirements into thebaseline design
Requires the support system configuration match the system design configuration
Provides the detailed maintenance planning and bottoms-up identification of total logistics
resource requirements

As a mean of controlling, establish an ILS program progress, status and management reporting
system which will document that program design, development, test and evaluation, andtransition accomplishments meet or exceed logistics priorities and developing supportability
requirements.

3.4

LSA program organization
The program manager is the final authority for effecting implementation of the LSA program
integrated product development organization. LSA is part of the system engineering integration.
LSA is an integral element in the integrated product team’s commitment of providing the highest
quality products and services at the lowest possible cost.
The system engineering integration organization is responsible for defining the requirements
analysis for the LSA program.
−−−

Performing the functional analysis and allocation and providing them to the integrated
product teams
Providing product and process solutions which satisfies the supportability requirements
Providing system analysis and control activities through the system engineering process

The integrated product team leader is responsible for completing the LSA program on his
product.
The ILS manager is responsible for monitoring the LSA activities on all teams, ensuringcommonalty across the program and for delivery of LSA data submittals (if required). The
Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6568-03000-00

program manager has final authority for all program functions. Supportability is an active
member of the integrated product teams. The objective of these teams is to develop guidance insystem design that meets performance, produceability and supportability requirements andachieves low LCC.

3.5

LSA management responsibilities
The following list should give an overview of the potential responsibilities of the different players
in the LSA process.

3.5.1

The LSA manager
The typical responsibilities of a LSA manager can be, but not limited to the following:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Implement established company operating policies and procedures concerning LSA.
Accomplishes quality reviews of LSA data through in process reviews and formal reviews
prior to data submittal.
Addresses questions and coordinate required corrective actions pertaining to thedevelopment, implementation, and modification of integrated maintenance concepts andlogistics resources and related problems/status.
Assesses subsystem design and support concepts for supportability influence/impact for
their assigned subsystems.
Assists in resolution of problems pursuant to acquisition of supplier/customer-furnished LSA
data necessary to support the assigned subsystems.
Assists in the development and implementation of formal LSA review activities to ensure
integration of maintenance concepts and compatibility with contractor and customer
requirements for their respective system.
Conducts LSA reviews with the customer and incorporate the results into the LSA
database.
Coordinates evaluation of design changes for LSA impacts and ensure impacts arehighlighted to decision makers when design changes will have an adverse impact on easeand cost of support.
Coordinates with appropriate Program and Functional management to ensure problems areresolved for their assigned subsystems.
Documents LSA task analyses and coordinate LSA task scheduling and planning.
Maintains technical liaison with design/supportability engineering and logistics groups.
Manages the technical aspects of the LSA process and the documentation of design
considerations and logistic resource identification.
Monitors/coordinates the technical aspects of LSA relative to established program
objectives, schedules, and directives.
Participates in customer and supplier design and program reviews and ensures LSA is anagenda topic as appropriate.
Participates in technical coordination meetings and design reviews with suppliers and/or thecustomer. Each review shall include formal review and assessment of supportability andrelated design requirements.
Provides assistance and information to Program and Functional management in achieving
contractor and customer objectives.
Schedules LSA in accordance with engineering documentation release dates/support
milestones, and accomplish LSA database management and configuration.
Tracks LSA task accomplishment and participate in problem resolution.
Establish company LSA operating policies and procedures.
Help establish program statement of work and approve man-hour estimates for all LSA
activity.
Help assign personnel to programs and projects as required satisfying the LSA statementof work.
Monitor and assist LSA program managers/leads in the performance of program
statements of work.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6568-03000-00

−
3.5.2

Establish training requirements for LSA personnel and LSA related tasks.

Program LSA managers/leads
The typical responsibilities of an overall program LSA manager (eg required within international
projects with several participating companies) can be, but not limited to the following:
−
−
−
−
−
−

Ensure LSA program requirements are being met
Implement established company operating policies and procedures
Control program cost and maintain program schedule
Maintain a functional interface with team members, subcontractors and/or vendors
Maintain a program interface with program management and the customer
Be technically responsible for the accuracy of the LS

3.5.3

Program technical staff (logistics engineers/analysts)− Responsible for the performance of the data analysis− Operate data collection software and generate reports− Manage supplier and customer interfaces for data collection− Have working relationships with engineering, all ILS elements, suppliers, and customer

3.5.4

Supportability analysis integrated product teamParticipate in the development of an early LSA strategy
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Develop the LSA PP
Participate in program and design reviews
Coordinate the operational requirements
Coordinate the requirements of mission hardware, software, and support systemstandardization
Participate in developing the requirements for comparative analysis
Coordinate the requirements for technological opportunities
Coordinate the requirements of supportability and supportability related design factors
Perform scheduled maintenance analysis
Participate in the development of support system alternatives
Participate in evaluation of alternatives and trade-off analyses
Coordinate inputs from maintainability and packaging, and develop maintenance task
analysis
Coordinate the requirements for early fielding analysis
Coordinate the requirements for post production support analysis
Coordinate the requirements for supportability test, evaluation, and verification

3.6

Elements of a LSA program plan

3.6.1

General requirements
The LSA PP shall include the following elements of information, but not limited to, also refer toadditional information concerning LSA PP and GCD in Chap 3), with the range and depth of
information for each element tailored to the project phases:−−−−

A description of how the LSA program will be conducted to meet the system and logistic
requirements defined in the applicable project documents.
A description of the management structure and authorities applicable to LSA. This includes
the interrelationship between line, service, staff, and policy organizations.
Identification of each LSA task that will be accomplished and how each will be performed
A schedule with estimated start and completion points for each LSA program activity or
task. Schedule relationships with other ILS program requirements and associated systemengineering activities shall be identified.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6568-03000-00−

A description of how LSA activities and data will interface with other ILS and systemoriented tasks and data. This description will include analysis and data interfaces with thefollowing programs, as applicable:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

−

−
−
−
−
−
−
−
−
−

3.6.2

Equipment design
Equipment maintainability
Equipment reliability
Equipment testability
Facilities/infrastructure
Human factors integration
Initial provisioning
PHST
Parts control
Standardization
Support and test equipment
Survivability
System safety
Technical documentation
Test and evaluation
Training and training equipment

Breakdown structure identification of items upon which LSA will be performed anddocumented, including software items. Identification of a LSA Candidate Item List (CIL),
and LSA candidate item selection criteria. The list shall include all items recommended foranalysis, items not recommended and the appropriate rationale for selection or nonselection.
Explanation of the breakdown element numbering system to be used.
The method by which supportability and supportability related design requirements are
disseminated to designers and associated personnel.
The method by which supportability and supportability related design requirements are
disseminated to subcontractors and the controls levied under such circumstances.
Government data to be furnished to the contractor.
Procedures for updating and validating of LSA data to include configuration control
procedures for LSA data.
LSA requirements on Government Furnished Equipment/Materiel and subcontractor/vendor
furnished materiel including end items of support equipment.
The procedures to evaluate the status and control of each task and identification of theorganizational unit with the authority and responsibility for executing each task.
The procedures, methods and controls for identifying and recording design problems or
deficiencies affecting supportability, corrective actions required, and the status of actions
taken to resolve the problems.
Description of the data collection system to be used by the contractor to document,
disseminate and control LSA and related design data.

Functional requirements identification
This activity identifies the required operations and support functions for the product. The primary
inputs are the results of the supportability and supportability-related design factors, and resultsof the reliability and maintainability programs and analyses. The results of this task form thebasis for the support system alternatives. Through coordination and interaction with design
engineering, maintainability, human engineering and technical manuals, LSA personnel willrevise as applicable functional block diagrams identifying subsystem component changes andtheir functional interface within the subsystem and with associated subsystem components. LSA
personnel will then evaluate and identify operations and maintenance functions that are
required to implement the maintenance and operational concept for LSA candidates.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6568-03000-00

The functional requirements inherent in maintenance and operation of the product include
requirements such as:
−
−
−
−
−
−
3.6.3

Inspections
Servicing
Testing
OperatingRepairing
Configuring for specific usage

Unique functional requirements
The same process used to identify operations and maintenance functions will identify any
unique functional requirements. These unique functional requirements are normally associatedwith new technologies and equipment incorporated in the system or its support system.
Hazardous materials, hazardous wastes, and environmental pollutants will also be considered.
Although the same analysis techniques are utilized to identify and evaluate these uniquefunctions, special attention will be given to them because they have a tendency to exhibit higher
risks. The LSA organization will ensure that configuration changes are tracked and their impact
on identified unique functional requirements are identified and evaluated.

4

Product development organization
The product oriented organization integrates the unique capabilities of each engineering
discipline through the product development process. This process is a systematic approach tothe integrated, concurrent design of products and their related processes, including production
and support. Use of this approach is intended to cause the developer, from the outset, toconsider all elements of the product life cycle from conception through disposal, including cost,schedule, performance, supportability, quality and user requirements.
Integrating product development during design will help achieve first time quality and improved
compliance with requirements will:−−−

Support completing the program within target cost
Meet affordability requirements through design for produceability and concurrent
manufacturing process improvements
Reduce operational and support costs through design-to-supportability with emphasis on
reliability, maintainability and life cycle cost

Fundamental characteristics of an effective integrated product development organization are:
−
−
−
−
−
−
−
−

4.1

Integrated product teams
Clear product definition and interfaces
Multidiscipline teams (integrated teams)
Disciplined processes
Single point accountability
Effective communications
Empowerment
Performance metrics

Integrated product teams
Each of the product items in the entire system, including supplier and customer furnished items,
is owned by a product team. Resource allocation and integration normally occur through a WBS
hierarchy of product teams starting with the system team. The flow down is from team to team,down to the detailed subassembly or component. These teams represent significant, identifiable
subsystems, subassemblies and components of the system, operation planning and logistics
segments.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6568-03000-00

Each level in the organization is fully accountable for the aggregate of its subordinate teams, aswell as for the integration and overall performance of its end product. Team leaders at all levels
embody the full responsibility, authority and accountability of their teams. A single unbroken line
of authority flows through the team leaders from the program manager to the subassembly orcomponent team leaders. Team leaders allocate roles and responsibilities based on specific,
tangible products. Each team member has a clear charter that focuses on the development orcreation of a product.

4.2

Multidiscipline teams
Early consideration of the product life cycle results in the identification of design conflicts. Thisfeature is made possible with multidiscipline teams where there is diversity of perspective to acommon mission. Each individual, whether they are skilled in
−
−
−
−
−
−
−
−
−
−
−

DesignQuality assurance
Manufacturing
Reliability, testability and maintainability
Technical data and technical documentation
Support equipment
Supply support
Facilities
Technical services
PHST
Personnel and training

are forged into a single effort. The objective of an integrated team is to identify and resolve as
much design conflict as possible in the shortest period of time with the understanding that eachperspective is of equal value. Each team member brings their unique perspective to the creationof a single, concurrently engineered design. Without this integration of perspectives there is no
integrated product development or concurrently engineered design.

4.3

Single point accountability
The integrated product team leader is held accountable for the development of all products.
This feature provides the benefits of:−

avoiding redundant efforts

and−defining clarity of purpose.

This individual brings together the right resources (manpower, skills, budget and facilities) toachieve the mission.

4.4

Empowerment
Empowerment enables integrated product team members to achieve their mission and provides
them with the ability to influence and to the maximum extent possible, control their disciplines
destiny. Individuals are empowered to the extent necessary to fulfill their individual roles andresponsibilities but their ultimate destiny is controlled by the performance of their teammates. By
definition, every individual within a team is dependent upon the other team members.
Empowerment is the principle of enabling team members, with sufficient and adequate
resources, to achieve their specified roles and responsibilities.

4.5

Management plans
Corrective actions for resource problems consist of procurement actions (early orders for longlead-time items or schedule, cost, and budget changes), support system/concept changes, ordesign changes. These resource challenges will be brought to management's attention throughApplicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6568-03000-00

technical analysis reviews and schedules. Problems that are identified will be worked throughthe responsible functional management. The responsible subsystem logistics manager will
ensure that appropriate action is assigned and that proposed changes are implemented.

4.6

Clear product definition and interfaces
Mission success is dependent upon understanding clearly and completely what the product isthat the team is accountable for providing. The product description includes not only therequirements like performance, supportability, and produceability but also how that productmust relate or interface with other products.

4.7

Disciplined processes
The processes for designing, developing, testing, producing and supporting system and support
system products are founded upon accepted standardized principles. The focus of integrated
product development is rigorous and consistent application of standardized processes for thedevelopment of all products along with a continuous search for methods to improve the process.
As the processes are documented, the team is committed to management by process rather
than management of the product.

4.8

Effective communications
Communications in the integrated product development process simply means that a free andopen exchange of data, information and opinions is the fuel that keeps the process working.
Effective communications begins with establishing the roles and responsibilities of the teams,
defining the team's products, establishing team goals and objectives, and providing the ability toidentify and resolve design conflict. Instrumental to effective communications are collocation ofteam members, regularly scheduled integrated product team meetings, all-hands meetings,
functional and program staff meetings, effective use of memos, use of electronic
communications (eg E-mail, video conferences), and knowledgeable interchange of data andinformation.

4.9

Performance metrics
It is important to know how well each integrated product team is progressing toward
development of their products. Measuring is achieved by identifying those critical parameters in
the product development process and establishing an associated metric. The parameters
selected by an individual or team must characterize:−−−−

Product quality
Schedule
Cost
Risk assessment

S3000L-A-02-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-02-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 2
2010-04-01 Page 16

S3000L-B6865-03000-00

Chapter 3
LSA Business process
Table of contents

Page

LSA Business process ................................................................................................................... 1
References ..................................................................................................................................... 6
1
General ............................................................................................................................ 6
1.1
Introduction ...................................................................................................................... 6
1.2
Objective .......................................................................................................................... 7
1.3
Scope ............................................................................................................................... 7
2
Establishment of product usage data .............................................................................. 7
2.1
General usage aspects .................................................................................................... 7
2.2
Operational requirements document ............................................................................... 9
2.2.1
General usage scenario (overview) ................................................................................. 9
2.2.2
Geographical position of locations and special conditions of each location ................... 9
2.2.3
Systems (products) supported and systems (products) deployment ............................ 10
2.2.4
Usage overview ............................................................................................................. 10
2.3
Detailed checklist for the creation of an operational requirements document .............. 10
2.4
Customer requirements document ................................................................................ 10
2.4.1
Supply concept .............................................................................................................. 10
2.4.2
Support equipment concept ........................................................................................... 10
2.4.3
Personnel integration and staff training ......................................................................... 11
2.4.4
Facilities ......................................................................................................................... 11
2.4.5
IT and communication resources .................................................................................. 11
2.4.6
New organizational structures ....................................................................................... 11
2.4.7
Schedule considerations ............................................................................................... 11
2.4.8
Additional aspects.......................................................................................................... 11
2.5
Detailed checklist for the creation of a customer requirements document.................... 12
2.6Time schedule for document creation ........................................................................... 12
2.7
Site surveys ................................................................................................................... 12
2.8
Qualification requirements ............................................................................................. 12
2.9
Certification requirements .............................................................................................. 123
Establishment of product design and performance data ............................................... 13
3.1
Selection criteria concerning LSA relevant data and information .................................. 13
3.1.1
Selection of LSA data and information derived from contractual documents................ 13
3.1.2
Selection of LSA data and information derived from product usage data ..................... 13
3.1.3
Selection of LSA data and information derived from design and performance
specifications ................................................................................................................. 14
3.1.4
Selection of LSA data and information relevant for product certification and verification
contained in other product documents .......................................................................... 14
3.2
Influence of overall LSA strategies and principles on LSA data selection .................... 14
3.2.1
Procedures and principles influencing selection of LSA data ....................................... 14
3.3
Acceptance rules concerning the verification of values................................................. 15
3.3.1
Category of measurement values.................................................................................. 15
3.3.2
Identifying tolerances ..................................................................................................... 15
3.3.3
Establishment of acceptance criteria ............................................................................. 16
3.3.4
Establishment of special rules ....................................................................................... 16
3.4
Criteria and procedural aspects for verification of projected values .............................. 16
3.4.1
Determination of measurable target values ................................................................... 16
3.4.2
Verification of the individual projected values ............................................................... 16
3.4.3
Verification method ........................................................................................................ 16
3.4.4
Verification for special purposes.................................................................................... 16
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

3.4.5
3.5
3.5.1
3.5.2
4
4.1
4.2
4.3
4.3.1
4.3.2
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.4.8
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.6
4.7
5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.3
5.3.1
5.3.2
5.3.3
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.5

Update of status codes .................................................................................................. 17
Customer involvement ................................................................................................... 17
Checklist for the LSA guidance conference .................................................................. 17
Documentation of the results of the LSA GC ................................................................ 17
LSA guidance conference ............................................................................................. 17
The transition from a request for proposal to the LSA guidance conference ................ 18
LSA business process at a glance ................................................................................ 19
Documents and Information for LSA guidance conference ........................................... 20
Checklist of documents for the LSA guidance conference ............................................ 21
Checklist of documents and information from the LSA guidance conference ............... 22
LSA program plan .......................................................................................................... 22
Purpose of LSA and logistic analysis activities ............................................................. 23
Hierarchical product breakdown methodology .............................................................. 23
Breakdown depth for the item under analysis ............................................................... 24
LSA candidate selection criteria .................................................................................... 24
Candidate item list ......................................................................................................... 24
Potential analysis activities for candidate items ............................................................ 24
Performance measurement and verification of LSA activities ....................................... 24
IT aspects ...................................................................................................................... 25
Guidance conference document.................................................................................... 25
Data element list and input instructions ......................................................................... 26
List of selected software packages................................................................................ 26
Reports examples .......................................................................................................... 26
Mathematical appendix .................................................................................................. 26
Candidate item list ......................................................................................................... 27
Contractual documents .................................................................................................. 27
Establishment of breakdown according to agreed rules ............................................... 27
Definitions of general terms ........................................................................................... 28
Product/end item............................................................................................................ 28
Product variant identifier ................................................................................................ 28
Product breakdown ........................................................................................................ 28
Breakdown element and breakdown element identifier................................................. 28
Breakdown element revision ......................................................................................... 28
Replaceability aspects ................................................................................................... 28
Parts .............................................................................................................................. 29
Product related applicability – Management of product variants and configurations .... 29
Types of product breakdown ......................................................................................... 29
Functional breakdown ................................................................................................... 30
Physical breakdown ....................................................................................................... 30
Zonal breakdown aspects .............................................................................................. 30
Installation location of equipments/components and multiple installation ..................... 31
Mixture of functional and physical breakdown methodology ......................................... 31
Parallel usage of functional and physical breakdown methodology .............................. 32
Family concepts in physical breakdown methodology .................................................. 32
Background for different approaches to establish a product breakdown ...................... 33
Traditional LSA product breakdown .............................................................................. 34
PDM-oriented product breakdown ................................................................................. 35
Combining the two product breakdown approaches in S3000L .................................... 35
Purpose of breakdown element identifier ...................................................................... 36
Breakdown element identifier structure ......................................................................... 36
Alternative breakdown element ..................................................................................... 37
Documentation of peripheral items ................................................................................ 37
Identification of item families ......................................................................................... 37
Integration requirements ................................................................................................ 38
Establishment of an exchange system for data and documents ................................... 38
Breakdown element identifier logic ................................................................................ 38

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

5.5.1
5.5.2
5.6
5.6.1
5.6.2
5.6.3
5.6.4
5.7
5.8
5.8.1
5.8.2
6
6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.4
6.5
6.6
6.7
7
7.1
7.2
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
7.2.6
7.2.7
7.2.8
7.2.9
7.2.107.2.11
7.2.127.2.137.2.14
7.3
7.4
7.5
7.5.1
7.5.2
7.6
7.6.1
7.6.2
7.6.3
8
8.1
8.1.1

Breakdown without homogeneous BEI logic ................................................................. 39
Basic syntax of breakdown element identifier – Establishment of breakdown levels ... 40
Breakdown element identifier and related codes .......................................................... 41
Purpose of breakdown element revision ....................................................................... 41
Applicability .................................................................................................................... 42
Breakdown element type ............................................................................................... 44
Equipment type .............................................................................................................. 44
Breakdown element identifier requirements concerning software ................................. 45
Breakdown element identifier aspects for LSA guidance conference ........................... 45
General aspects for customer involvement ................................................................... 45
Standardized numbering system ................................................................................... 45
Candidate item selection and identification ................................................................... 46
Definitions and general terms ........................................................................................ 46
Candidate and non-candidate ....................................................................................... 46
Maintenance relevant items and maintenance significant items ................................... 46
Structural items, structure significant items and structural details ................................ 47
Non-hardware items ...................................................................................................... 47
Classification of LSA candidates ................................................................................... 47
Selection process and criteria list .................................................................................. 48
Preconditions for the selection process - Product breakdown ...................................... 48
Preconditions for the selection process – Existing analysis results .............................. 48
Preconditions for the selection process - Candidate selection rules ............................. 49
Preconditions for the selection process - Candidate classification selection rules ....... 49
Influencing factors.......................................................................................................... 51
Recommendations for LSA candidate selection............................................................ 51
Candidate item list (draft) .............................................................................................. 53
Candidate item list as an output of LSA guidance conference ...................................... 53
Logistic analysis activities .............................................................................................. 53
Principles for analysis activity selection ........................................................................ 54
Potential analysis activities ............................................................................................ 54
Analysis for identification of general LSA needs ........................................................... 55
Comparative analysis .................................................................................................... 55
Human factor analysis ................................................................................................... 55
Configuration assessment ............................................................................................. 56
Assessment of reliability analysis .................................................................................. 56
Maintainability analysis .................................................................................................. 56
Testability analysis......................................................................................................... 57
Analysis activities concerning event driven maintenance ............................................. 58
Level of repair analysis .................................................................................................. 59
Maintenance task analysis ............................................................................................ 60
Software support analysis ............................................................................................. 60
Operations analysis ....................................................................................................... 60
Simulation of operational scenarios............................................................................... 60
Training needs analysis ................................................................................................. 61
Analysis relations and general overview ....................................................................... 61
Analysis activities selection criteria ............................................................................... 62
Checklist for analysis activity recommendation ............................................................. 64
Recommendation and decision sheet ........................................................................... 64
Selection matrix example and rating values .................................................................. 64
Analysis workflow processes ......................................................................................... 65
Early phase analysis activities ....................................................................................... 66
Design freeze analysis activities .................................................................................... 67
Inservice phase analysis activities................................................................................. 67
Customer involvement ................................................................................................... 67
Customer assessment of candidate items and recommended analysis activities ........ 67
Establishing LSA assessment rules .............................................................................. 68

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

8.1.2
8.1.3
8.2
8.2.1
8.2.2
8.3
8.4
8.5
8.5.1
8.5.2
8.5.3
8.5.4
8.5.5
8.5.6
9
9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.3.4
9.4
9.5
9.6
9.7
10
10.1
10.1.110.1.210.1.310.1.4
10.2
10.3
11
11.1
11.2
11.3
11.3.1
11.3.211.3.311.3.411.3.511.3.611.3.711.4
11.4.1
11.4.2

Initial assessment and re-assessments ........................................................................ 68
Establishing an assessment procedure ......................................................................... 69
Information exchange between customer and contractor ............................................. 69
Commenting process ..................................................................................................... 69
Informing the contractor by the customer ...................................................................... 70
Final clarification on open issues................................................................................... 71
Customer decision (status influencing) ......................................................................... 71
Exchange of analysis data with the customer ............................................................... 72
Establishment of appropriate rules for data and document exchange with the customer....................................................................................................................................... 72
LSA data and document collection by the contractor .................................................... 72
Delivery of LSA data/documents by the contractor ....................................................... 72
Customer assessment and distribution of assessment results ..................................... 72
Distribution of customer response by the contractor ..................................................... 72
Distribution of the contractor response concerning disagreed comments .................... 72
LSA review conference .................................................................................................. 72
LSA review process overview........................................................................................ 72
Subject to be reviewed .................................................................................................. 73
Examples for review structuring .................................................................................... 74
LSA review step - CIL and maintenance analysis allocation ......................................... 74
LSA review step - LORA results and maintenance concept information....................... 74
LSA review step - LSA FMEA and SMA results ............................................................ 74
LSA review step - Maintenance Task Analysis (MTA) .................................................. 74
Status code examples ................................................................................................... 75
Depth of status code allocation ..................................................................................... 75
Functions of the status code.......................................................................................... 75
Status code definition at the LSA guidance conference ................................................ 75
Starting point and management of the creation of the logistic products ....................... 76
Starting point recommendations .................................................................................... 76
Technical documentation ............................................................................................... 76
Materiel support ............................................................................................................. 78
Common and special support/test equipment ............................................................... 79
Training .......................................................................................................................... 80
Management of the creation of the logistic products ..................................................... 81
Influence of modifications on logistic products .............................................................. 81
Checklists ...................................................................................................................... 82
Detailed checklist for the creation of an ORD ............................................................... 82
Detailed checklist for the creation of an CRD ................................................................ 86
Breakdown element identifier - structure examples ...................................................... 88
Functional breakdown ................................................................................................... 89
Mixture of functional and physical breakdown ............................................................... 90
Separation of physical and functional breakdown with cross referencing (hardware
only) ............................................................................................................................... 91
Physical breakdown with explicit parent-child relationship ............................................ 93
Integration of software as part of a single physical hardware item ............................... 94
Integration of software as part of more than one physical hardware items ................... 94
Integration of software in a functional breakdown ......................................................... 95
LSA candidate selection flowchart examples ................................................................ 97
Non structural items ....................................................................................................... 97
Structural items .............................................................................................................. 98

List of tables
1
2

References ...................................................................................................................... 6
Required input documents for LSA GC ......................................................................... 21

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

List of output documents of the LSA GC ....................................................................... 22
Basic categories of breakdown elements ...................................................................... 28
Basic table for explicit breakdown documentation ........................................................ 39
BEI readability aspects .................................................................................................. 40
Product variant applicability from Fig 18 ....................................................................... 43
Aspect of replaceability .................................................................................................. 44
Aspects of repairability .................................................................................................. 44
Definitions of MSI and MRI ............................................................................................ 46
Definitions of Structural Item, Structure Significant Item and Structural Detail ............. 47
LSA candidate categories .............................................................................................. 47
Classification criteria for full LSA candidates ................................................................ 50
Classification criteria for partial LSA candidates ........................................................... 50
Classification criteria for LSA candidate family ............................................................. 51
Recommendations for LSA candidate selection............................................................ 52
Depth of maintainability analysis depending of item type ............................................. 57
Classification of different depths of LORA ..................................................................... 59
Analysis activities selection criteria ............................................................................... 63
Explanation of time schedule of the commenting process ............................................ 70
Examples for status codes ............................................................................................ 75
List of different spare part types identified by LSA ........................................................ 78
Checklist of detailed questions to support the ORD creation ........................................ 82
Checklist of detailed questions to support the CRD creation ........................................ 86
Listing of functional breakdown from Fig 28 .................................................................. 89
Listing of functional breakdown from Fig 29 .................................................................. 90
Listing of mixed breakdown extract from Fig 30. ........................................................... 91
Listing parent-child breakdown extract from Fig 33....................................................... 93

List of figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Schedule for the creation of the basic documents ........................................................ 12
LSA tasks in conjunction with the preparation of an offer/contract ............................... 18
Flowchart of LSA business process at a glance (Sheet 1 of 2) ..................................... 19
Flowchart of LSA business process at a glance (sheet 2 of 2) ..................................... 20
LSA GC, inputs and outputs .......................................................................................... 21
Example of content of a LSA Program Plan .................................................................. 23
Example of content of a Guidance conference document ............................................ 25
Simple functional breakdown......................................................................................... 30
Simple physical breakdown ........................................................................................... 30
Breakdown methodology - Simple parent-child philosophy .......................................... 31
Breakdown methodology - Extended parent-child philosophy ...................................... 31
Breakdown methodology - Mixture of functional and physical methodology................. 32
Example for a spare part grouping concept .................................................................. 33
Product breakdown - Traditional LSA approach versus PDM approach ....................... 34
Product breakdown derived from Table 5 ..................................................................... 40
Example for simple BEI syntax (reduced to numbering system)................................... 41
Example for extended BEI syntax ................................................................................. 41
Usage of BEI and applicability ....................................................................................... 43
Analysis activities relations and overview ..................................................................... 62

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

Example of a simple analysis activity recommendation sheet ...................................... 65
Position of LSA in the overall project schedule ............................................................. 66
Process of information exchange between customer and contractor (example) .......... 70
Correlation between LSA and technical documentation ............................................... 77
Correlation between LSA and materiel support ............................................................. 79
Correlation between LSA and support/test equipment .................................................. 80
Correlation between LSA and training ........................................................................... 81
Influence of design modifications on logistic disciplines in general............................... 82
Functional breakdown, simple syntax with separators .................................................. 89
Functional breakdown, extended syntax with separators ............................................. 90
Mixed breakdown, extended syntax with separators..................................................... 91
Parallel usage of functional and physical breakdown.................................................... 92
Cross referencing between functional and physical breakdown ................................... 92
Breakdown with parent-child methodology.................................................................... 93
Assigning of software BEI in a physical breakdown ...................................................... 94
Distributed software in a physical breakdown ............................................................... 95
Functional BEI structure concerning SW ....................................................................... 96
Full LSA candidate selection flowchart .......................................................................... 97
Partial LSA candidate selection flowchart ..................................................................... 98
LSA candidate selection flowchart for structural items .................................................. 99

References
Table 1 References
Chap No./Document No.

Title

Chap 5

Influence on design

Chap 9Logistic related operations analysis

Chap 10

Scheduled maintenance analysis

Chap 12Maintenance task analysis

Chap 13

Software support analysis

DEF-STAN-00-60

Integrated Logistic Support - UK MoD

MIL-STD 1388-2B

DoD requirements for a Logistic Support Analysis Record

S1000DInternational specification for technical publications using
a common source database

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

1

General1.1

Introduction
With the introduction of a new product, all logistic requirements must be made available in atimely manner. This requires programs to establish a process to ensure consideration of logistic
requirements during the design of the product. This process includes a number of analysis
activities concerning a wide range of logistic considerations. Activities to achieve proper

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

supportability must be carefully agreed to between the contractor and the customer. Early
consideration of logistic aspects is increasingly important with regard to both operational andeconomic considerations. A product that cannot be operated and maintained properly and costeffectively is not acceptable to the end user.
It should be noted that modern products normally contain software elements. The overall
Logistic Support Analysis (LSA) process for software and hardware is very similar. For thisreason, this chapter is valid for the supportability of software, as well as hardware. However,some specific aspects of software must not be ignored and will be covered by Chap 13,
Software Support Analysis (SSA). This chapter is referenced as appropriate.
Logistic considerations are significant in terms of costs. Over the life cycle of a complex
technical product, support costs are much higher than acquisition costs. Because of this,programs are tending to consider logistic aspects as important as performance aspects.

1.2

Objective
This chapter is a guideline for the establishment of an effective LSA process. It considers eachlife cycle phase of a technical product and emphasizes the importance of the logistic
requirements. Additionally, the interaction between the contractor and the customer during thedifferent phases of the product's life cycle is described in detail. The LSA process has two main
purposes: 1) with the help of different analysis methods, the design should be influenced toallow appropriate supportability, and 2) the creation of logistic end products should bemanaged. The requirements for spare parts, consumables, technical documentation, support
equipment, personnel, training, facilities and software support are identified and the creation of
the logistic end products should be supported. All together, this is an extensive task, which has
to be carried out carefully. A properly established LSA process that is embraced and used by
the customer and the contractor is an example of an efficient plan for a successful introductionof new complex technical equipment.

1.3

Scope
This chapter is directed to Integrated Logistic Support (ILS) managers and LSA managers forboth the customer and the contractor. LSA offers a powerful methodology to build the coreneeds for the realization of ILS. Additionally, monitoring and control functions can be achievedby using relevant LSA information. The quality and commonality of the logistic products can bepositively influenced by the application of a LSA process. With the incorporation of various
analysis results, it can be assured that customer's needs for operability, supportability andreadiness can be achieved.

2

Establishment of product usage data
To identify the pertinent supportability aspects of a new product, all relevant information related
to the intended use must be collected and documented carefully. This chapter describes how
information can be structured and documented in a set of obligatory documents. It should bepointed out that in an early stage of a project sometimes complete relevant information is notalways available. In this case, iterative steps may be necessary for a complete definition of thecustomer's usage of the product to be analyzed. In any case, changes to the usage scenario
are of crucial importance for logistic purposes and must be taken into consideration by thelogistic analysts accordingly.

2.1

General usage aspects
To establish an initial overview to identify pertinent supportability aspects, some very generaldecisions are necessary. These first decisions must consider the overall preconditions for theusage of the new product to be introduced and also consider some strategic aspects comingfrom the product design and performance data, which are described in Para 3. These generaldecisions should be documented in a general project document describing the overall support
strategy. This strategy should be a basic guideline for the further execution of any logistic

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

analysis and for creation of the Operational Requirements Document (ORD) and the Customer
Requirements Document (CRD).
The general questions, which should be answered before or at least in parallel to the creation of
the ORD and the CRD, are the following:−

What kind of product should be used?
A short description of the product should be given including key features, key requirements
and basic technical data needs.

−

Will contractor logistics support be required? If yes, at which maintenance levels?
This is a very central question that can only be answered by a deeper examination of some
additional aspects described in the following questions.

−

Where will the product be operated and maintained?
•••

In which operational environment will the product be operated and maintained (from afixed/industrial/benign environment to a mobile/austere/hostile one)?
Will the environment influence the item’s characteristics (eg reliability, maintainability)?
Will the environment significantly change the manner in which the item must be
repaired? If so, contractor support might not be the best approach.

−

How long will the product be used (predicted service life)?
If the product will only be in the inventory for a few years, then contractor support might bepreferable to a lengthy and costly gearing-up of an organic logistics support structure.

−

How many maintenance levels are planned for the product support?
The repair strategy must be clearly envisioned before the ORD is written.

−

What are the features and/or typical actions within each maintenance level?
For example in a classical 2-level maintenance concept, the exchange of "black boxes" andthe re-sending to the contractor or to the original manufacturer will be typical.

−

Are there existing maintenance capabilities that can be adapted to the support concept for
the new product?

−

Is the usage of existing maintenance capabilities from former products or other similar
products at or nearby the operating locations possible and effective?

−

Should the customer be involved in any repair activity of the product or should thecorrective maintenance be limited to simple "black box" exchange (replace only)? The
involvement of the customer is dependent on the abilities which can be provided by thecustomer itself.

−

Which frequency and duration of preventive or scheduled maintenance actions (expressedin measurable terms) is acceptable?

−

Are there limitations for preventive maintenance eg because of special preconditions
concerning available personnel or facilities?

−

How much of the software is mature? How much is customer unique?
Software, never delivered 100% bug-free, may take several years to mature. The logistics
support structure should also address software maintenance of potential user required
upgrades.

−Is there any software/data loading and/or unloading which should be performed by thecustomer?
Which concept should be established to guarantee proper function of the product after theloading of software/data at an acceptable level (eg simulated integrity test based on a
hardware-software compliance matrix in a test bench, General Purpose Test Equipment
concept for software, required software device and encrypting system for loading and/or
unloading).

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00−

What is the expected need for product replacement or upgrade due to changes intechnology? These questions concern how a support structure can keep up with changes in
the product and modify the support strategy. If it is difficult or impossible, contractor
logistics support should be preferred.

All general questions should be answered as completely and carefully as possible. Additionalquestions to those listed above may occur. This depends on the project and on thecorresponding products to be used. Best information available should be the basic principle.
Create a basic document with all general and programmatic information and harmonize thisdocument between the contractor and the customer. Ideally this should be done before thecreation of the ORD and the CRD.

2.2

Operational requirements document
Operational requirements must be defined in a quantitative and qualitative way. Previously
conducted analyses concerning area of operation and product usage, that identified relations
between hardware, usage and supportability, should be considered. A further definition of theidentified operational requirement must be performed by measurable details. Supportability
requirements are developed directly from the operational requirements. Each supportability
requirement should be based on an operational requirement, and that relationship should beclearly identified. If the basis for the supportability requirement is not clear, that requirement
should be regarded with suspicion. The main goal is to identify and document the pertinent
operational requirements related to the intended use of the new product. The writers of the ORD
are required to identify key performance indicators. Any parameter not identified as a key
parameter, should be a candidate for revision when supportability attributes are negatively
impacted. The ORD requires the product developer to make difficult choices between “musthave” and “nice to have” at an early stage of the program. This information is of vital importanceto the logisticians so they can understand what they must support, regardless of costs, andwhat they can trade off.
Operational requirements to be considered within the ORD are described in the following
paragraphs.

2.2.1

General usage scenario (overview)
In the general usage scenario, all information should be collected to describe the environmental
aspects of the usage of the product.
−
−
−
−
−
−

2.2.2

General description of overall usage areas and/or mission areas
Possible operation scenarios and requirements for each scenario must be documented.
Influence on the environment by the usage of the product and resulting actions to avoid or
reduce negative influence
Supportability problems that have arisen over the life of the currently used productInteraction and dependability with existing products
Mobility requirements

Geographical position of locations and special conditions of each location
In this paragraph, details of each location should be collected to describe the special aspects ofeach location in which the product will be operated.
−
−
−
−
−
−

Number and geographical position of the operating locations.
Type of each operating location.
Special conditions at each operating location.
Is the location in a peacetime or wartime region?
Threat situations require a special emergency maintenance concept limited to minimum
intervention.
Is sufficient infrastructure available to access each operating location?
Special infrastructural requirements for reaching a location.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00

−
−

2.2.3

Systems (products) supported and systems (products) deployment
In this paragraph, the deployment of the products and the interactions coming from thedeployment should be collected. The location at which the products will be based affects thedecision to use either organic or contractor support.
−
−
−

2.2.4

Number of systems supported per location
Deployment of products per location
Interactions between the different locations concerning usage

Usage overview
Depending on the customer, define the planned usage of the product as a basic input to logistic
analysis. The frequency and the duration of the usage, in combination with the reliability of the
product, provide the initial basis for determining the range and quantity of support resourcesthat will be required.
−
−
−
−
−
−
−
−
−

2.3

Capabilities (existing and planned) of each location (eg equipment, infrastructure,
personnel, facilities, supply depot, repair station).
Interactions between different locations concerning, as an example maintenance support,
from one location for another location.

Key usage/key missions per location
Performance parameters and constraints. The product performance parameters, such asrange, accuracy, payload or speed, are to be identified in measurable quantifiable terms.
General terms or those whose interpretation is potentially ambiguous must be avoided.
Predicted operational availability and usage success rates
Operation per unit of time
Operation profile per operating day, week, month or year
Usage of the product as training equipment as a portion of operating time
Permanent operational conditions/possible maintenance windows
Average duration of each unique usage event
Key measurement base of usage per unit of time

Detailed checklist for the creation of an operational requirements
document
For a detailed checklist on how to create an ORD, please refer to Para 11.1.

2.4

Customer requirements document
To ensure the proper usage of the system, the customer has to consider all the logistic
requirements. The logistician can most efficiently influence the supportability and design of a
new system during its early stages of development. One method to convey these needs is to
document them in a CRD. The logistics elements of the CRD are described in the following
paragraphs.

2.4.1

Supply concept
The supply concept is of crucial importance for the logisticians. A general decision on how toorganize the provision of spare parts and consumables can have high impact on themaintenance scenario itself. It must be decided whether or not facilities must be planned
because of the need for supply storage areas and who will manage the supply chain whenoutsourcing the Supply Chain Management. Costs (especially facility construction) andobsolescence are important considerations.

2.4.2

Support equipment concept
Common support equipment, instead of special support equipment, should be acquired whenpossible and cost effective. To reduce costs, it is important to evaluate whether or not existingsupport equipment can be used or can be adapted for use.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6865-03000-00

2.4.3

Personnel integration and staff training
Manpower issues are crucial to the supportability of many systems. It is necessary to plan for
the timely training of all support personnel. Acceptable risk levels, training level needs, andmanpower ratios must be addressed as supportability concerns. The training needs consist of
two distinctive components: initial and on-going. Both are important in order to ensure adequate
operator skill levels. Given the high level of turnover in personnel, maintaining a current
operator’s skill is often a crucial issue. Repair and maintenance personnel can also turn overrapidly. Support planning must deal with these issues.

2.4.4

Facilities
Early planning considerations must be given to facilities because of the long lead times
associated with site acquisition and allocation. Facilities that address maintenance actions must
be planned with care to ensure process needs and activity work flow are supported.

2.4.5

IT and communication resources
This is another area where logisticians need proper preparation. What constraints arenecessary in order to provide interfaces with other services? What is the trade-off when X
architecture provides a desirable improvement in operational availability but denies access to Y
communications network used by another service? Which IT architecture must exist or must be
additionally established? It must be clear that IT resources include all aspects such as computer
hardware, computer network components, network wiring, communication protocols, software
packages, data security aspects and standards.
This paragraph also requires an understanding of future capabilities. Designing a system tointerface with those “forecasted to exist at the time the system will be fielded” requires theengineer and logistician to be aware of the status of other related programs. How can thisproduct interface with planned future communications architecture? The logistician must assess
the impact of IT-system changes to be expected and determine necessary adjustments to thelogistics structure.

2.4.6

New organizational structures
New organizational structure considerations have two aspects:−−

Any changes to the established organizational structure at a location of the customer thatmust be made to support and operate the system.
Changes in the organizational structure (eg reduction in personnel) that can be madebecause the system replaces old existing systems or because the new product is easier tomaintain.

Organizational structure changes have impacts on available logistics support infrastructure thatmust be accounted for in the development of a new product.
2.4.7

Schedule considerations
The logistician is obviously concerned with scheduling decisions. Logistic support is a vital andintegral part of any product that is fielded. Only when logistics is an afterthought would it causedelays and inefficient use of resources. If logistic considerations are interwoven with eachprogram in each of its phases, then the supportability schedule will have been efficiently
synchronized and integrated with other system schedules.

2.4.8

Additional aspects
Special aspects concerning areas such as packaging, storage, handling or transportationconsiderations can be addressed here. Unique data requirements are defined here. Logisticiansmust know how and when they will use the data they request, and they must be able todistinguish between “nice to have to cover possible contingencies” data and essential data.
Packaging, handling, transportation, disposal and environmental impact considerations are far
from the forefront for system designers, developers, and users, but they are important andpotentially expensive considerations. Logisticians must understand the potential impact of these

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6865-03000-00

issues on the product from its inception, and must raise these issues whenever they have an
impact on program planning.

2.5

Detailed checklist for the creation of a customer requirements document
For a detailed checklist how to create a CRD, please refer to Para 11.2.

2.6

Time schedule for document creation
To ensure that all required information is available for each of the 3 basic documents which
identify product usage data, a sequence or work flow for the creation of these documents
should be identified.

GeneralGeneralUsage
Usage
Aspects
Aspects

ORD
ORD

CRD
CRD

Time

ICN-B6865-S3000L0002-001-01
Fig 1 Schedule for the creation of the basic documents

2.7

Site surveys
Site surveys of operational units and maintenance/repair workshops can provide a significant
input into the operational and customer requirements in terms of identifying existing capabilities,
resources, and potential problems. Site surveys can be useful once the operational environment
for the new equipment is identified in sufficient detail to determine existing operational units andrepair facilities that would most likely be involved in the operations and support of the new
equipment. The results of site surveys should be documented carefully and should become partof the ORD eg as an additional appendix.

2.8

Qualification requirements
When the customer requires a qualification process, it must be clear between customer and thecontractor, at an early stage, which aspects of maintenance activities must be taken into
account to achieve a qualification of the product by customer authorities. The requirements forthe qualification must be defined by the customer and should be transmitted to the contractor
together with the ORD.

2.9

Certification requirements
When a required certification process is necessary for the operation of the product in thepredicted environment, special attention should be given to the collection and documentation of
the maintenance activities that are a part of the certification. These activities are necessary,
regardless of the costs. All aspects of maintenance activities that influence certification musthave first priority. The project, in its early stages, must clarify which efforts must be considered
in order to fulfill the requirements of the certifying authority. The requirements for thecertification are defined by the certifying authority and must be well known to both the customer
and the contractor.
The customer and the contractor must ensure that the differences between the qualification
process and the certification process are evident and well known to each responsible person.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6865-03000-00

3

Establishment of product design and performance data
This chapter deals with the identification and documentation of product design and performancedata/information relevant for LSA purposes.

3.1

Selection criteria concerning LSA relevant data and information
In this context, the data and information that should be considered as relevant are those thatare subject to verification and control within the intended LSA process. Related criteria must be
established in detail depending on the individual product that is subjected to LSA, the related
contract and specifications, as well as the established ILS philosophy. Relevant information may
be documented within the LSA database as requirements in order to set a goal to be verified
within the established LSA process. As a general approach, the selection criteria described in
the following paragraphs should be considered.

3.1.1

Selection of LSA data and information derived from contractual documents
Contractual documents should be considered carefully for LSA relevant product design andperformance features that could be verified by information documented within the LSA
database. Usually, overall product requirements or so-called Key Performance Indicators ofimportance are covered within these documents to establish mandatory goals and/or thresholds
that are potentially related to contract incentives.
Examples of Key Performance Indicators:
−
−
−
−
−

−

3.1.2

Specified Maximum Maintenance Man Hours per Operating Hour.
This value may serve as a benchmark concerning successful maintenance design.
Specified Maximum Mean Time to Repair paired with Specified Maximum Mean Time to
Repair Percentile. These values may serve as an indication for successful design as it isrelated to repair within established time constraints.
Specified Maximum Failures per Operating Hour. This value is an indication of the desired
reliability of the product and inversely the maintenance workload.
Specified figures concerning minimum availabilities.
These values may serve as a indication for successful design with respect to readiness for
operation.
Testability characteristics.
These values indicate the ability of the design for monitoring vital functions, detection andlocalization of potential malfunctions by internal means like Built in Test Equipment (BITE)
and overall test architecture.
Minimum operational lifetime.
This value indicates a minimum lifetime requirement. This should indicate any risk of falling
below the established threshold.

Selection of LSA data and information derived from product usage data
In this context, refer to Para 2. Relevant information may be documented within the LSA
database as a baseline reference.
Examples:
−
−
−
−
−

Annual Operating Requirements (AOR) with its measurement base
Number of operating locations to be considered
Number of systems to be operated at each location
Maintenance levels to be established at each location
Maintenance personnel available at each location (number of persons by trade and skill)

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6865-03000-00

3.1.3

Selection of LSA data and information derived from design and performance
specifications
In this context, refer to Chap 5. LSA relevant parameters influencing the design andperformance of the product may be documented within the LSA database for verification and/or
control purposes.
Examples:
−
−
−
−
−

3.1.4

Specified Mean Time Between Failures (MTBF) together with the related measurementbase indicating the minimum value
Reliability growth
Specified testability features concerning BITE
Specified maximum allowable time for replacement
Specified Maximum Mean Time to Repair paired with Specified Maximum Mean Time to
Repair Percentile. These values may serve as an indication for successful design related to
repair within established time constraints.

Selection of LSA data and information relevant for product certification and verification
contained in other product documents
LSA relevant information may also be derived from other documents originated by the design
department, Configuration Management (CM), safety, stress department or from the customer's
documents.
Examples:
−
−
−
−
−
−
−

3.2

Special operation and/or repair limitations (eg temperature ranges, anti-static protection
requirements, clean air repair conditions)
Delivery plans
Validity information (eg version applicability)
Hazardous classification of failures
Storage limitations and/or requirements
Criticality classification of specific parts
Scheduled requirements (eg established time limits, overhaul requirements)

Influence of overall LSA strategies and principles on LSA data selection
Prior to the determination of relevant product design and performance data, an overall LSA
strategy should be established as part of the tailoring of the LSA program. The tailoringprocesses are dependent on the project’s complexity, value to business units (contractor), andknown risk factors. These constraints and performance requirements are then balanced
between the required analysis efforts, time, schedule, and allocated budget with a cost/benefit
that is best for the program. These requirements, issues, and constraints are then reviewed andevaluated at the Guidance Conference (GC) to achieve a consensus between all participants.
These findings, analyses and resulting agreements are documented in the Guidance
Conference Document (GCD).
This tailoring activity is an iterative process and should be repeated in each program phase.
Results and lessons learned from each prior phase should be a part of and included in the
tailoring analysis for each of the following phases.

3.2.1

Procedures and principles influencing selection of LSA data
The overall LSA strategies and principles may influence the selection of product design andperformance data in relation to the LSA process. Examples for supportability needs to beconsidered in this area are as follows:−

Pre-determined two level maintenance concept
Maintenance is mainly limited to only two maintenance levels, one for the replacement of
an item and the other for its repair. This will help avoid requiring duplicate inventory at

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6865-03000-00

many repair facilities. The two level maintenance concept is normally preferred because of
overall cost considerations if the equipments (LRU) to be removed and replaced at theoperational site have a low failure rate and a high built-in-test detectability rate, and a
responsive supply chain between the operational sites and suppliers is configured
With this concept, LSA data are limited to pre-determined Maintenance Levels (ML).
−

Repair concentrated on one certain ML’s
Repair is mainly limited to user sites in order to achieve maximum autonomy, independentof cost-effectiveness.
With this concept, repair option data are limited to the pre-determined ML.

−

Limited Repair at ML 1 and/or 2
The corrective maintenance action may be limited to an item exchange (no in situ repair) inorder to shorten any operational downtime.
With this concept, maintenance task are limited to pre-determined criteria.

−

Single source principle
When major repair is necessary, the supplier of the item should be most-favored since eg
related experience, personnel and equipment are available and ready.
With this concept, repair data are limited to the supplier information.

−

Interim support concept
In order to acquire experience and reduce risks prior to final Maintenance Concept (MC)decisions, an interim support phase may be established.
With this concept, MC data are limited to preliminary information.

−

Commercial off-the-shelf (COTS) concept
When equipment already available on the market is used, related conditions must be
accepted.
With this concept, data have to reflect related supplier information/conditions.

3.3

Acceptance rules concerning the verification of values
Clearly defined acceptance rules should be established in order to avoid uncertainty during theverification process. These rules will allow accurate acceptance or rejection of the results for
LSA relevant product design and performance data.

3.3.1

Category of measurement values
The type of requirement should be stated regarding the importance of the related values such
as:
−
−
−

3.3.2

Mandatory values
Objectives
Thresholds (minimum or maximum values)

Identifying tolerances
For each identified value, the associated tolerances should be expressed.
−

Tolerances for the dedicated value expressed by the requirement for one single value

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6865-03000-00

−

3.3.3

Tolerances concerning a group of similar values, for example, possible compensating of
failure rates within a given area of items under analysis in order to meet the failure rateof the group instead of the single items, eg by following additional constraints

Establishment of acceptance criteria
Measurable acceptance rules should be established for each specified value along with its
related requirement. These rules should identify the basic conditions (eg fulfillment of minimum
required values based on sufficient statistic confidence levels) that lead to the acceptance orrejection of the values documented within the LSA database.
In addition, the consequences of the established status information should be stated clearly:
−
−
−

3.3.4

Establishment of special rules
When special rules are established, the related conditions and related values have to be welldefined in order to avoid uncertainty:
−
−

3.4

Status of the Item under Analysis (IUA) indicating the acceptance of the documented value
Status of the IUA indicating the rejection of the documented value (with related
justification).
Status of the IUA indicating the conditional acceptance of the documented figure (eg "ingeneral acceptable but requiring minor rework")

Establishment of penalty regulations concerning failed specified LSA significant data
Establishment of rewards in case of exceeding specified LSA significant data

Criteria and procedural aspects for verification of projected values
Finally, the criteria for verification of data and/or other information being subject to verification
should be established as follows:

3.4.1

Determination of measurable target values
For data elements under consideration the related projected value range should be establishedand documented within the LSA database as a requirement by considering the original target
along with its established tolerances and relevant acceptance rules, if any. The projected value
range may be allocated to a single item and/or a group of dependent items covered by relevant
acceptance rules in order to establish the related acceptable values that fulfill the requirements.

3.4.2

Verification of the individual projected values
The relevant data and other information documented in the LSA database derived from theanalysis process should be compared to the associated acceptable values. The result should bereported to the analyst and/or involved management indicating whether or not the actual LSA
values consistent with the projected values.

3.4.3

Verification method
Projected values and their method of verification should be agreed upon:
−
−
−
−
−
−

3.4.4

Verification by furnishing analytical proof (documented within the LSA database)Verification using an analytical method based on appropriate tests (eg at a test rig)
Verification by demonstration (on a prototype or serial versions of the product)
Verification under the rules of certification and/or demonstration programs
Verification by trial sessions (eg performed by customer's staff)
Verification during long term exercises (eg during a defined "maturity phase")

Verification for special purposes
When verification for special purposes are necessary (eg in order to gain certifications,
qualifications, licenses), particular rules may be established and required.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6865-03000-00

3.4.5

Update of status codes
Depending on the verification results, the related status information should be linked to theverification result by following the rules established for status allocation.

3.5

Customer involvement
The selection of product design and performance data subject to verification and control within
the intended LSA process should be agreed upon by the customer during the LSA GC anddocumented in the GCD. This also applies to the agreement of related rules and projectedvalues.

3.5.1

Checklist for the LSA guidance conference
The checklist should contain all relevant proposals for design and supportability requirements,eg:
Have LSA relevant product design and performance data been identified?
−
−
−
−
−

List of selected LSA data and information derived from contractual documents
List of selected LSA data and information derived from product usage data
List of selected LSA data and information derived from design and performance
specifications
List of selected LSA data and information contained in other product documents
Have selected LSA data and information subject to certification and verification or otherspecial requirement (eg for license purposes) been noted accordingly?

Have acceptance rules concerning the verification of relevant values been identified?
−
−
−
−
−
−
−

Have measurable target values been identified for the selected data/information?
Have the category of measurement figures been stated against the selected
data/information (eg mandatory values, goal values, thresholds)
Have tolerances been defined for the selected data/information?
If applicable, have compensating rules been established?
Are projected values acceptable/agreed to by the customer?
Are the consequences of acceptance/agreement concerning status information identified?
If applicable, have penalties and/or rewards regulations been established?

Are overall LSA strategies and principles established that influence these?
−
−
−
−
−
−
−

Identify the preferred maintenance concept (eg is two level maintenance mandatory?)
Identify the supply chain management support concept
Have the repairs focused on one maintenance level (which level)?
Is repair at Maintenance Level1 and/or 2 limited?
Is single source principle determined?
Is an interim support concept applicable?
Is COTS concept to be considered?

3.5.2

Documentation of the results of the LSA GC
The details of the LSA CG checklist must be documented as part of the GCD.

4

LSA guidance conference
The LSA GC should be the central event with participation of management staff and specialists
on both sides, customer and contractor. At this conference, the binding agreements for the
performance of the LSA process must be established. To ensure best performance of thisconference, it is necessary to have prepared inputs and to have a clear expectation of theresults and final agreements. It is strongly recommended to have checklists for the LSA GC
preparations and expectations.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6865-03000-00

Note
Never accept "to be determined" (TBD) as an input for any subject to be discussed in the
LSA GC. Discussions should always be based on concrete proposals prepared by
specialists, on how to realize the required task. Evaluate the advantages anddisadvantages (cost/benefit) of the alternatives under consideration. Provide documentationof all alternative analysis and decisions.

4.1

The transition from a request for proposal to the LSA guidance
conference
It should be pointed out clearly that the majority of essential decisions influencing the LSA effort
have to be negotiated before the LSA GC. Usually, the LSA process begins while creating anoffer and will be similar to the final version contained in the corresponding contract. This applies
to any LSA significant aspect within the contract (eg related Statement of Work) as well as forcontractual details such as eg deliverable items, indispensable specified values or major
milestones. This implies a series of investigations to be done prior to the contractual offer (egidentification of LSA activities considered as mandatory, recommended or voluntary, dependingon early strategy judgment and/or the kind of systems and equipments to be assessed).

• Customer‘s needs• General usage
information• Global strategy• LSA relevant
conditions

RfP
document(s)Systemhardware,softwareetc…

Offer by thebidderPreliminary LSA strategy and planning
Prepared by LSA as contribution to offer:- Proposed global LSA strategy- Preliminary operational requirements data for LSA- Preliminary LSA analysis tasks (mandatory / optional)- Alternatives and trade-off analysis- Statement of Work (SoW) concerning LSA- Assessment of related effort to proposed LSA
LSA contribution to the offer under preparation
If necessary, additional LSA activities will be
undertaken in order to adapt to the contract.
LSA activities as defined in the contract(in a consolidated form)
The LSA results for contribution to the offer and contract
may be reused as part of preparation for the LSA GC.
LSA GC
defines details i.a.w. contract together withrules to a further extend

ICN-B6865-S3000L0003-002-01
Fig 2 LSA tasks in conjunction with the preparation of an offer/contract
The LSA GC serves as a vehicle to communicate to the customer the work that will be done indetail, along with the associated rules and time schedules, based on the contractual
requirements and further agreements as noted above. The LSA GC also clarifies any questions
the customer might have regarding the effort. Nevertheless, changes to the LSA work effort, toa certain extent, must be allowed during the LSA GC without the need of contract changes andchanges in the cost of the effort. Considering the iterative nature of LSA activities, customization(tuning) must be possible in order to be flexible.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6865-03000-00

4.2

LSA business process at a glance
CUSTOMER ACTIVITIESCONTRACTOR ACTIVITIESBasis / Starting Point:

Contract or MoU / Top Level Requirement Specification

Establishment of
Product Usage Data

Establishment of
Product Design &Performance Data

Preparation of LSA
Guidance Conference

General usage
aspects

Candidate Item List
- DRAFT -General Product
Design Aspects

Operational
Requirements

Data Element List
- DRAFT -General Performance
Data

CustomerRequirements

Programme Plan
- DRAFT GC Document (GCD)- DRAFT -LSA Guidance Conference

Candidate Item List

Data Element List

Programme Plan

GC Document (GCD)

Establishment ofbreakdown according to agreed rules
Delivery of
CIL to thecustomer

Assessment of Candidate Item selection
and identification

Agreed ?

Clarification of nonagreement and/or
modification of
Candidate Item List
Delivery ofrecommended
analysis
activities per CI

Assessment of CIs and theirrecommended analysis tasksnoAgreement
to CILyesno

Agreed ?

Candidate Item
(CI) selection and identificationaccording to agreed rules

yes

Recommendation of analysis tasks per
Candidate Item

Agreement torecommended
analysis
activities

Clarification concerning
non-agreement and/or
identification of solution
how to proceedA
ICN-B6865-S3000L0004-002-01
Fig 3 Flowchart of LSA business process at a glance (Sheet 1 of 2)

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6865-03000-00

A
Subprocess General Analysis• Analysis for identification of general LSA
needs• Comparative Analysis• Configuration Aspects• Human Factor Analysis

•
•
•
•
•
•
•
•

Delivery ofanalysis task
results (draft /master)

Subprocess Task Identifying Analysis
Maintenance Task Definition
Software Support Analysis
Reliability / Maintainability / Testability
Technical FME(C)A  LSA FME(C)A
Scheduled Maintenance Analysis
Damage / Special Event Analysis
Operations Analysis
Software Support Analysis

Subprocess Task Resource Analysis• Maintenance Task Analysis• Level of Repair Analysis• Training Needs Analysis• Simulation scenarios

Performance of any analysis tasks

Assessments / Observation
Agreement /rejection

LSA Pre-/Master Assessment Conference

Start with production of ILS products

ICN-B6865-S3000L0004-002-01
Fig 4 Flowchart of LSA business process at a glance (Sheet 2 of 2)
The flowchart gives an overview of complete LSA process, from the collection of operationaland customer requirements to the creation of the logistic products.

4.3

Documents and Information for LSA guidance conference
In the following paragraph you will find a list of applicable documents relevant for the LSA GC.
This list should give you a guideline for which information should be documented in which way.
The particular project may add additional aspects or skip some information. The following figure
should give a summarized overview of the LSA GC concerning the required documents:
Note
It should be kept in mind that the majority of essential decisions influencing the LSA effort
should be negotiated before the LSA GC and documented in the contract. This applies to
any LSA relevant aspect within the statement of work and the corresponding parts of thecommercial offer, as well as for contractual details such as deliverable items, indispensable
specified values and major milestones. This mandates a series of investigations to be done
prior to the contractual offer (eg identification of LSA-analysis activities considered as
mandatory/recommended/voluntary - depending on early strategy judgment and/or the kindof systems/equipments to be assessed).

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6865-03000-00

GeneralGeneralUsage
Usage
Aspects
Aspects

ORD
ORD
Operational
Operational
RequireRequirements
ments
Document
Document

CRD
CRD
Customer
CustomerRequireRequirements
ments
Document
Document

Candidate
Candidate
Item List
Item List
(CIL)
(CIL)

Data
Data
Element
Element
List (DEL)
List (DEL)

Programme
Programme
Plan (PP)Plan (PP)GC
GC
Document
Document
(GCD)
(GCD)

DRAFT
DRAFT

DRAFT
DRAFT

DRAFT
DRAFT

DRAFT
DRAFT

INPUT

Contractual
ContractualDocuments
Documents

INPUT

LSA GC

already valid
already valid
before LSA GC
before LSA GC

OUTPUT

Candidate
Candidate
Item List
Item List
(CIL)
(CIL)

LSA
LSA
Programme
Programme
Plan (PP)Plan (PP)Preliminary
Preliminary

Guidance
Guidance
Conference
Conference
Document
Document
(GCD)
(GCD)

Data
Data
Element List
Element List
(DEL)
(DEL)

ICN-B6865-S3000L0005-001-01
Fig 5 LSA GC, inputs and outputs
4.3.1

Checklist of documents for the LSA guidance conference
In the following table an overview of required information is given to prepare for a LSA GC.
Table 2 Required input documents for LSA GC
Type of document

Content

Responsible
for creation

General usage
aspects

Strategic aspects of the product design andperformance data, which are described in Para 3.

Customer

Contractual
documents

Contractual decisions, which can influence the LSA
Customerprocess, must be available at the LSA GC and must be andconsidered.
contractor

Operational
Requirements
Document (ORD)

Details about the usage of the systems in the planned
scenario at all operational locations. These details aredescribed in Para 2.

Customer

CustomerRequirements
Document (CRD)

Details of customer requirements regarding theoperational scenario described in the ORD. These
details are described in Para 2.

Customer

Candidate Item List
(CIL)-DRAFT

A list of Breakdown Elements (BE) to be considered as Contractor
potential candidates for a LSA and for the performanceof any logistic analysis activities

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6865-03000-00

Type of document

Content

Responsible
for creation

Data element list
(DEL)-DRAFT

A list of proposed data elements required to document
the performance of all potential logistic analysis
activities. This list should be an appendix to thepreliminary GCD.

Contractor

LSA Program Plan
(PP)-DRAFTManagement plan for the LSA project

Customer
andcontractor

Guidance Conference Implementation rules for the LSA project
Document(GCD)-DRAFT

4.3.2

Customer
andcontractor

Checklist of documents and information from the LSA guidance conference
The result of the LSA GC must be an integrated consensus of measurable rules for guiding the
LSA process. These rules, checklists and documents provide a clear road map of needs andexpectations between the contractor and the customer. This collection of official documents
must be agreed to and signed by the customer and the contractor. These documents should
contain the following (as a minimum):Table 3 List of output documents of the LSA GC
Type of document

4.4

Content

Responsible
for creation

Preliminary Candidate List of LSA candidates containing all BEs that havebeen selected for logistic analysis activities, including
Item List (CIL)
the analysis activities to be performed for each BE.

Customer
andcontractor

LSA Program Plan
(PP)

Initial release of the preliminary LSA Program Plan
(PP). LSA GC consensus of attending members.

Customer
andcontractor

LSA GC Document(GCD)

Initial release of the LSA GCD. LSA GC consensus ofattending members.

Customer
andcontractor

LSA program plan
The LSA PP is a crucial output document of the LSA GC. It should be organized with general
sections and descriptive subsections. These are followed by the appendices. In the general
section, the following aspects should be covered:
−
−
−
−
−
−
−

Management structure of the program for both the contractor and customer
Time schedule of the program and meeting calendar
Definition of milestones
Responsibilities and reporting levels
Change process (categories and levels of authority)
Risk management
Work share agreements

The following figure shows an example of the structure of a LSA PP:

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6865-03000-00

Project XXXLSA Program Plan

Date

CONTENT
1

General

2

Scope

3

General program definitions
3.1
3.2
3.3
3.4
3.5
3.6

Management structure of the program on customer side
Management structure of the program on contractor side
Time schedule of the program
Definition of milestones
Meeting calendar
Responsibilities and reporting levels

APPENDICIESAppendix A

Purpose of LSA and of logistic analysis tasks

Appendix B

System breakdown methodology

Appendix C

Breakdown depth

Appendix D

Rules for LSA candidate selection

Appendix E

Candidate Item List

Appendix F

Rules for analysis tasks selection

Appendix G

Rules for performance measuring and verification

Appendix H

IT aspects

ICN-B6865-S3000L0006-001-01
Fig 6 Example of content of a LSA Program Plan
The appendices will provide additional clarity and specific needs which supports the content in
the subsections.
4.4.1

Purpose of LSA and logistic analysis activities
As a basic result of the LSA GC, the contractor and customer must agree to the principles of
how to use the data coming from the logistic analysis activities. The documentation of data
within a logistic database must define the purpose of collecting the data. Therefore, it is strongly
recommended to carefully select which data elements will be documented in a logistic database
and then link the data with its corresponding purpose. This also applies to the logistic analysis
activities. The selection must consider technical and economical aspects, especially for very
extensive analysis. Examples can be the following:
−
−
−

4.4.2

Detailed or simplified Level of Repair Analysis (LORA)
Optimization methods, such as via simulation runs
Detailed Scheduled Maintenance Analysis (SMA)

Hierarchical product breakdown methodology
In this appendix to the LSA PP, all the results of the procedure described in Para 5 for theestablishment of a product breakdown methodology must be documented. It must be clarified
between the customer and the contractor, how the Breakdown Elements (BE) are to be
identified, eg using system hardware identification according to S1000D, Logistic Control
Number (LCN) in accordance with MIL-STD 1388-2B, or any other identification systempreferred by the customer.
If it is necessary to use different breakdown methodology (physical and functional) within aprogram in parallel, it must be clarified whether and how to interconnect these different
breakdowns. Additionally, the purpose of its use must be documented (eg a functional
breakdown).

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6865-03000-00

Note
It is recommended that detailed examples in the appendix should be included, covering all
possible cases (eg it must be clarified how software will be incorporated within thehierarchical breakdown, it must be clarified how to cover different end item variants).
4.4.3

Breakdown depth for the item under analysis
In addition to the decisions required for the types of breakdown, the breakdown depth is a
crucial attribute of the breakdown itself. The following aspects must be considered for a final
decision:−−−−

Is a full breakdown of the item required to identify all relevant spare parts and is thisbreakdown type effective and applicable?
Is a breakdown that only contains LRUs applicable and effective?
What depth of breakdown is required to identify all spare parts for a repair concept at theauthorized level?
For what purpose shall a functional breakdown be established (eg for SMA) and how is thefunctional breakdown linked to the physical breakdown?

4.4.4

LSA candidate selection criteria
The criteria for LSA candidate selection as described in Para 6 must be documented in an
appendix of the LSA PP. A decision flowchart should also be part of the appendix.

4.4.5

Candidate item list
As an input to the LSA GC, a draft of the CIL must be prepared as an input document by thecontractor. During the GC, this draft must be discussed between the contractor and thecustomer, resulting in an agreed upon CIL. The CIL will be an official output document of the
LSA GC.

4.4.6

Potential analysis activities for candidate items
The CIL does not only contain the selection of the LSA candidates from the product breakdown,
it should also contain the analysis activities to be performed for each LSA candidate. In addition
to the analysis activities selection, the depth of the analysis should be clarified. For example, in
the area of the Maintenance Task Analysis (MTA), a decision must be made about how deep
the description of the maintenance task should be documented or whether it is necessary forthe project to identify personnel requirements. Finally, the CIL should serve as a LSA program
overview, in which the complete effort is summarized. Additionally, the CIL can be used as ahelpful management tool, documenting the progress of the LSA program.
Note
As a final output from the LSA GC, a CIL must be generated. It is recommended that thislist is designated as a reference table and part of the projects master data which is sharedand synchronized across the project’s master data management system. It can be used asa monitoring tool to supervise the progress of the project. This will avoid duplicating data,such as breakdown information, in external lists which are not synchronized to cleansed
master data.

4.4.7

Performance measurement and verification of LSA activities
The performance of LSA activities should be continuously evaluated and documented eg bystatus information within the logistic database. The criteria, when an analysis activity is fulfilled
or when a LSA candidate is completely documented within the logistic database, must be clear
and documented in a list of acceptance criteria that are a part of an appendix within the GCD.
The process and the rules of performance measurement and verification must be clear. For
each delivery of any analysis result, these rules must be obeyed by both the customer and thecontractor.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6865-03000-00

4.4.8

IT aspects
As a general recommendation, using different software packages for the same analysis
activities at different locations should be avoided. Integration and harmonization processes canbe extensive and are a potential risk factor. However, many projects currently use different
software packages because of existing licenses, contractual constraints or IT environment
necessities. In this case, for any task to be performed, suitable software packages compatible
between all partners should be found.
The decisions about software packages must be documented at the LSA GC. Changes ofsoftware releases during a program must be harmonized and agreed to between all impacted
partners.

4.5

Guidance conference document
The GCD is another crucial output document of the LSA GC. It contains the implementation
rules of the LSA process on reporting, data element definitions, data exchange procedures andselection of software packages to perform analysis activities.
In the following figure, an example for a possible structure of this document is given.
Project XXXLSA Guidance Conference Document

Date

CONTENT
1

General

2

Scope

3

Implementation rules
3.1
3.2
3.3
3.4

Simple data element list (DEL)
Reporting process
Definition of required reports
Data exchange processes

APPENDICIESAppendix A

Detailed data element list (DEL & input instructions)

Appendix B

List of selected software packages per analysis task

Appendix C

Report examples

Appendix D

Mathematical appendix

ICN-B6865-S3000L0007-001-01
Fig 7 Example of content of a Guidance conference document
The GCD should be organized with a general section and a number of appendices, which aredescribed in the following paragraphs. In the general section, the definition of theimplementation rules should be covered:−

Data Element List (DEL):
List of all the required data that should be recorded in a logistic database.

−

Reporting process and definition of required reports:
All report content and format must be defined clearly. Any data elements required for thereports must be available and accessible. All contracting parties will agree on content,
format and derived calculations. Any business rules necessary to calculate and/or selectsource data will be identified and documented.

−

Data exchange process:Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6865-03000-00

For a proper exchange of information, a data exchange process must be established andharmonized between the customer and the contractor. Especially in programs with several
partners on both sides, customer and contractor, a clear process for data integration andharmonization is required. A time schedule should be agreed to during the LSA GC and it
must be clarified the consequences of missing the time schedule.
Note
A detailed description of the recommended data exchange format by the usage of ASD
DEXs is given in Chap 20.
4.5.1

Data element list and input instructions
The detailed DEL describes the context and description of the data being captured in a LSA
database. This includes syntax (if required) and allowed codification. Also, any calculation
methods of numeric values should be described in a mathematical appendix.
To support the initial selection of data elements, it is recommended to create a simple draft DEL
as an input to the LSA GC. The justification for the project's LSA DEL selection is based on thefollowing questions:
−
−
−
−
−
−
−

Is the data element required for the proof of any specification values?
Is the data element required for the calculation of any logistic parameters?
Is the data element required for the following disciplines such as technical documentation,materiel support, identification of special support equipment, and identification of facilities ortraining requirements?
Is the data element required for the performance proof of the LSA itself?
Is the data element required to document the results of the logistic analysis activities?
Is the data element required for any report, necessary for the customer and/or thecontractor?
Is the data element a special interest for the customer/contractor (eg internal usage ofcontractor)?

Note
It is strongly recommended to select the data elements based on a logical, traceable projectrequirements need. Listing of any data elements that do not link to a requirement or thedevelopment (calculation) of a requirement should be a candidate for elimination.
The DEL must be agreed to during the LSA GC and will be a part of the official GCD.
Nevertheless, it is to be considered as a living document. The DEL should be updated, when
additional needs arise during program maturation (eg matured project design as indicated bycontractor and customer).
4.5.2

List of selected software packages
In the GC, the decision should be made (or at least prepared), on which software packages will
be used by the contractor and the customer to support the required analysis activities. The
selection of software packages should be contractual. An upgrade or a complete change ofsoftware packages within the project must be investigated carefully, including all participants
involved with such changes in the IT environment.

4.5.3

Reports examples
To guarantee a common understanding of reporting, examples should be part of the GCD.
These examples should convey to the conference members: formatting, sorting, filling andcalculations.

4.5.4

Mathematical appendix
To complete the implementation rules, each method of calculation should be documented. The
calculation of values should be evaluated by both, contractor and customer, and should be

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 26

S3000L-B6865-03000-00

available for review by those who have a need. For this reason, the mathematical appendix
should cover two basic aspects:
−
−

4.6

Mathematical equations and their explanations (with list of mathematical abbreviations andsymbols)
Sources and business rule logic from which the data is obtained for calculation

Candidate item list
The creation of the CIL including the associated business rules is described in detail in Para 5
and Para 6.

4.7

Contractual documents
Contractual conditions are the basis for a project. All contractual decisions that were made prior
to the LSA GC must be carefully considered. If these decisions impact the ILS process itself, theselection of the logistic analysis activities will be crucially influenced.
Another contractual consideration is the significance of the output documents of the LSA GC.
The supporting LSA GC documentation should support contractual requirements and needs forboth the contractor and the customer.

5

Establishment of breakdown according to agreed rules
A systematic breakdown of a product is essential to the LSA process and provides the following:
−

−
−
−

−
−
−

A clear understanding of how the product is structured with respect to systems,
subsystems, functions, hardware and software components. This also applies to peripheral
equipment that may be included in the LSA process, for example complex training
equipment and support equipment.
A clear relationship between the included hardware elements and their possible realizationsin terms of manufactured hardware parts.
A clear relationship between the included software elements and their possible realizationsin terms of actual software releases.
Enable the allocation of unique or unified identifiers. This enables the establishment ofinterfaces between design departments including configuration sources, LSA and thelogistics disciplines such as technical documentation, materiel support, training and support
equipment.
Enable an appropriate level of detail for the selection of LSA candidates.
Identification of product variants and product configurations.
Enable CM with respect to how a specific revision of the product breakdown relates to thecorrect revisions of its corresponding ILS end products. It also enables the CM of source
data on which the product breakdown and its ILS products is based, including documents,
design information and product usage data.

Different breakdowns of the product can be defined for different purposes. In many projects it iscommon to have a design breakdown of the product being defined in some kind of Product DataManagement (PDM) system. The same product often also has a LSA breakdown, as well as aseparate breakdown for the recording of operational and maintenance data feedback. Different
breakdowns for different purposes often results in mismatches in between the different
breakdowns, and complicates to communicate product related data in between the different
disciplines.
This chapter describes both, the situation where there is need to define a separate breakdownof the product from a LSA point of view, as well as the situation where the LSA process canreuse the breakdown as defined by design.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 27

S3000L-B6865-03000-00

5.1

Definitions of general terms

5.1.1

Product/end item
The product (or end item) is a final combination of systems, subsystems, component
parts/materials and software (eg ship, vehicle, machines, aircraft or other complex technicalsystems). The product represents the top level (root) of any hierarchical product breakdown.

5.1.2

Product variant identifier
The product variant identifier is a code, which uniquely identifies the product variant. It is
recommended to use the product variant identifier in conjunction with other identifiers within theentire ILS process.

5.1.3

Product breakdown
A product breakdown consists of the product itself, and the hierarchical listing of, for example
assemblies, subassemblies, and components that can be disassembled, reassembled or be
replaced. Depending on the breakdown philosophy, a product breakdown can also consist of
systems, subsystems, functions and zones. Examples of types of product breakdown are
described in Para 5.2.
It should be pointed out that the required depth of a product breakdown in a LSA databasenormally will be different from, for example, the one being required for materiel support or
production. Nevertheless, breakdown rules concerning breakdown syntax should be consistent
within a project.

5.1.4

Breakdown element and breakdown element identifier
The BEI identifies the individual BEs that is defined within a product breakdown. It is strongly
recommended that the establishment of the BEs and their BEIs is co-ordinated with the otherlogistic disciplines and with the design department. The BEI should help to uniquely identify any
item that is a part of any logistic analysis activity. Para 5.2, describes the different types ofsystematic product breakdowns. Depending on the type, different rules for the establishment of
the BEI should be addressed.

5.1.5

Breakdown element revision
A BER defines a new release of a BE. BER captures the development progress (often referred
to as design iterations). The use of BER supports CM and especially the synchronization
between changes that are being introduced from product design, and its consequences in the
LSA results.
Note
The BER must not be mixed up with methods to document alternative components within a
product breakdown as, for example, by Alternate Logistic Control Number (ALC) in MILSTD 1388- 2B. The situation, that an equipment which has to be installed at a certain
position within the product breakdown has two different realizations (eg two different
equipments of different manufacturers which have different maintenance concepts) iscovered in S3000L by the means of related realizations in terms of parts (hardware orsoftware). These parts also can be LSA candidates against which the results of thetechnical/logistic analysis activities can be documented.

5.1.6

Replaceability aspects
Some common terminology has been established in the area of logistics concerning the
replacement of equipment/components. These are given in the following table:
Table 4 Basic categories of breakdown elements
Term

Full name

Description

LRU

Line Replaceable Unit

Directly replaceable on product level

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 28

S3000L-B6865-03000-00

SRU

Shop Replaceable Unit

Replace on LRU or SRU level, but not directly
replaceable on product level under normal
circumstances. This means, the superior
component (LRU or SRU) may need to be removed
before the concerned SRU can be replaced.

ASSY

Assembly

Artificial level to structure the breakdown

Note
In Para 5.6.4, the table above will be detailed. In addition to item replacement, repairability
aspects are considered.
5.1.7

Parts
Parts are the actual realization of BEs defined in a product breakdown, and can be either
hardware items or software packages.

5.1.8

Product related applicability – Management of product variants and configurations
Product related applicability (often also referred to as effectivity) is used to reflect theconfiguration information of a BE with respect to its allowed use in different product variants. It
covers the need to limit the applicability of any item in a product breakdown to special productvariants. An example for the usage of BE and applicability is given in Para 5.6.2.
Note
It is strongly recommended that the CM aspects between the customer and the contractor,
and the meaning of CM must be clarified by both the customer and the contractor. In
general applicability should be used for management of product variants. In this context,
different product variants should be designated via applicability to the BEs.
It is recommended that the LSA database is not used as a CM tool for the as-built situation(eg to enter the configuration of each end item delivered to the customer, into the LSA
database).

5.2

Types of product breakdown
A breakdown of a product can contain both functional and physical aspects. These two
approaches are illustrated by the examples in Fig 8 and Fig 9. Any LSA database should be
able to document both methods and combinations thereof (so called hybrid breakdowns).
The interrelationship of an item with other items at the same indenture level and the next higher
indenture, as well as its breakdown items (eg attaching parts), can be reflected by the BEI and
BE realizations or via explicit parent child relationships, respectively. To reflect the structure of a
product the following methods are recommended, depending on the requirements of the project.
−−−−

A pure functional breakdown
A pure physical breakdown
A mixed breakdown, functional and physical in one breakdown tree (often referred to as
hybrid breakdown)
A pure functional and pure physical breakdown parallel, with cross-mapping

Special attention should be given to software. In modern state-of-the-art systems, software use
is increasing. This should be considered in any logistic analysis. It should be possible tointegrate loadable software packages into the breakdown, if the installation/de-installation ofsoftware is maintenance relevant. The assignment of software to hardware should be clear
within the breakdown. Configuration changes due to software modification are another aspect of
the breakdown. If hardware will not be modified, but software integrated in the hardware willchange, this situation has to be documented in a product breakdown.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 29

S3000L-B6865-03000-00

5.2.1

Functional breakdown
A simple functional breakdown should start on top level of the product as the root of the
breakdown tree. The different functions of the product should be documented from the mainfunctions down to the sub-functions to the required depth. Within the pure functional breakdown,no hardware elements should be found.

Fuel system
Fuelstorage

Fuel
distribution

Tankinterconnection

Fuelinjection

Fuel transport toengineControl &indication

Refueling

Pressure
refueling

Gravityrefueling

ICN-B6865-S3000L0008-001-01
Fig 8 Simple functional breakdown
5.2.2

Physical breakdown
A simple physical breakdown should also start on top level of the product as the root of the
breakdown tree. As a general principle, in each physical breakdown it should be possible tostructure the breakdown by the usage of assemblies. As shown in Fig 9, this is realized on thesecond indenture level by introducing two different tank assemblies.
Product / end item

Tank 01
front left

Tank 02
front rightRubbertank

Tank 03rear left

Cover
tank

Tank 04
auxiliary

Drain
valve

Tank 05
auxiliary

Blanking
plug

ICN-B6865-S3000L0009-001-01
Fig 9 Simple physical breakdown
Below the product itself, the actual hardware elements are documented. Within a pure physicalbreakdown, no function should be found.
5.2.3

Zonal breakdown aspects
A zonal breakdown can be accomplished by sequencing all the zones defined for the product. It
should be pointed out that the required depth and structure of a zonal breakdown established ina LSA database may be different from, for example, the one being defined for product design.
Nevertheless, breakdown rules concerning breakdown syntax should be consistent within aproject.
Zones as BEs are typically required for the documentation of maintenance activities which are
related to the physical area represented by a zonal BE (eg scheduled zonal inspection). To
describe the content of a zone, it should be possible to establish relationships between zonalBEs and physical BEs within a LSA database.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 30

S3000L-B6865-03000-00

5.2.4

Installation location of equipments/components and multiple installation
In general, the installation location is the primary information within the physical breakdown.
Multiple installations of equipment/components can be considered in two different ways:−

One BE with quantity information (eg quantity per system)
Fuel system
Tank
Quantity: 3

Rubber
tank

Cover
tank

Drain
valve

Blanking
plug

ICN-B6865-S3000L0010-001-01
Fig 10 Breakdown methodology - Simple parent-child philosophy
In the example Fig 10, the same type of fuel tank is installed three times within the system. The
deeper breakdown of the fuel tank is always the same. In some cases, it can be sufficient tohave only one BE for the three tanks within the breakdown with the additional information of thequantity per system.
−

Several breakdown elements
Fuel system

Fuel tanks

Tank 01
front left

Tank 02
front rightRubber
tank

Cover
tank

Tank 03rear left

Drain
valve

Blanking
plug

ICN-B6865-S3000L0011-001-01
Fig 11 Breakdown methodology - Extended parent-child philosophy
In this example Fig 11, each fuel tank is considered as a separate BE. This method should be
used for typical LSA purposes. The installation location is decisive (eg the installation or theremoval can be totally different depending on the installation location).
5.2.5

Mixture of functional and physical breakdown methodology
An established product breakdown approach is a mixture of functional and physical aspects
within one breakdown tree, as shown in Fig 12. Typically systems and subsystems are offunctional character, equipment and components are physical breakdown elements.
Nevertheless, a system need not be one concrete function but more a collection of componentsthat have a set of common characteristics eg an electrical system. In this case, a system is built
from a set of functions/components, but there is still a system BE which is neither a concrete
function nor a physical item.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 31

S3000L-B6865-03000-00

Fuel system

Fuel distribution

Fuel storage

Internal storage
tanks

Tank 01
front left

Tank 02
front rightRubbertank

Fuel injection

Functional
breakdownelements

Auxiliary storagetanks

Physicalbreakdownelements

Tank 03rear left

Cover
tank

Electronic control& indication

Drain
valve

Blanking
plug

ICN-B6865-S3000L0012-001-01
Fig 12 Breakdown methodology - Mixture of functional and physical methodology
If a mixture of functional and physical breakdown methodology is used, it can be useful to first
generate a functional structure of the product dividing it into several basic systems andsubsystems (eg engine system, electrics, structure, hydraulic system, fuel system). Dependingon the magnitude of a system, the indenture level where the documentation of real hardware
BEs begin is not always the same. The typical breakdown path, system  subsystem equipment  component is not always fixed, so the indenture level at which LSA candidates arelocated can be different from system to system.
5.2.6

Parallel usage of functional and physical breakdown methodology
If it is required to establish both functional and physical breakdowns in parallel for different
analysis purposes, each breakdown tree should be established as separate breakdown
structures. The decisive factor is the generation of an effective connection between these two
breakdown trees. Physical BEs must be linked to functional BEs.
This methodology can be a good basis for troubleshooting analysis. Based on a functional
breakdown, troubleshooting should be able to identify the reasons that certain functions are notavailable. For this reason, the analyst must know which hardware elements could be
responsible for the missing function. The parallel usage of functional and physical breakdowns
also allows assigning hardware to functions. For example, the function "fuel distribution" fromFig 12 does not only contain typical elements such as fuel pipes, but also electric power supply
elements. However, electric power supply is documented in another area, but it must be
assigned to the function “fuel distribution”.
The cross functional interconnection between different breakdown methodologies should beconsidered in a logistic database structure also.

5.2.7

Family concepts in physical breakdown methodology
To reduce efforts in the establishment of a physical breakdown, family concepts should be usedwhenever possible. The following aspects can be considered when deciding whether or not to
use a family concept:−−

Similar items with common maintenance concepts can be grouped by family BEI concepts(eg harnesses of the same type, pipes of the same type, and structural items of the sametype).
Standard spare parts can be grouped by one BEI family

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 32

S3000L-B6865-03000-00

Tank 02
front right

to: family/grouping concept

Rubber
tank

Cover
tank

Drain
valve

Blanking
plug

Seal 09

Seal 08

Seal 07

Seal 06

Seal 05

Blanking
plug

Seal 04

Drain
valve

Seal 03

Cover
tank

Seal 02

Rubbertank

Seal 01

Tank 02
front rightfrom: full breakdown concept

Grouping of similar items
into one breakdown element

Seals
Seal 01
Seal 02
Seal 03……

ICN-B6865-S3000L0013-001-01
Fig 13 Example for a spare part grouping concept
However, the grouping of items under one BEI needs a possibility to document the single groupelements in a certain place within the LSA database. The required logistic information should becollected within the group BEI.

5.3

Background for different approaches to establish a product breakdown
As mentioned in Para 5.2, a product breakdown can be defined for different purposes. The
respective breakdown is traditionally often defined and used by a specific discipline. However,the correlation between these breakdowns is often non-existent, which means that there is aproblem to exchange data and share experience in between different disciplines. Examples are:•BE that represents a position in a product are often identified in different ways withindifferent breakdowns.

•

The breakdown philosophy (methodology) is often different from each other, whichmakes it hard to identify similarities and differences in between the different
breakdowns.

Product breakdown approaches are driven by different requirements. The working area ofdesign and development needs another kind of product breakdown than eg support engineering
for technical/logistic analysis activities. For that reason there are specific views on how to
structure a product breakdown. The intention of S3000L concerning this subject is to be as clear
as possible but also be flexible when required. For that reason the integration of the following
two main approaches to product breakdown into one data model which supports bothalternative solutions is a main goal of S3000L.
•

Approach 1:
Traditional LSA product breakdown by means of structured BEI (eg similar to LCN/ALC
structures as described in MIL-STD 1388-2B or DEF-STAN 0060). Functional andphysical areas are integrated into one common product breakdown. Indenture levels
are defined in an implicit way by the syntax of the specific identifier (BEI).

•

Approach 2:
Design oriented or PDM based product breakdown by means of explicit parent-childrelationships. These breakdowns are driven by relations of hardware components. The
identifiers of the components are not structured by syntax to document indenture levels
as in approach 1

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 33

S3000L-B6865-03000-00

The following figure gives a graphical overview of the main differences of the two basic productbreakdown approaches described above:
Classical LSA Product breakdown

Design or PDM-based Product breakdown

Product

Product

BEI

BEI

MT

1

MT

A01U
Usage

BEI

BEI

11

12

MT

BEI

BEI

XD4

H07

MT

Usage

BEI

BEI

11-1

11-2

MT

BEI

BEI

JK-02

H-L01

MT
Realization

BEI

BEI

11-2-1

11-2-2

MT

PI
P04X

PI
P321

MT
Assembly (BOM)

Explicit parent child realtionship
Implicit parent child relationship
LSA candidate

PI
P04A

PI
P04B

MT

Non LSA candidate
Maintenance tasks (related to LSA candidates)

ICN-B6865-S3000L0082-001-01
Fig 14 Product breakdown - Traditional LSA approach versus PDM approach
5.3.1

Traditional LSA product breakdown
A traditional LSA related product breakdown uses an implicit breakdown approach. An implicit
breakdown approach defines the position of the BE by the syntax of its BEI. This methodology
can be established by using existing standards like MIL-STD 1388-2B or DEF-STAN 0060
respectively. In these basic standards the breakdown elements are represented by a BEI known
as the LCN. Another approach can be the usage of S1000D Standard Numbering System(SNS). Central for both approaches is that the position for the respective BE within the overall
breakdown is determined by its BEI syntax.
The consequence for LSA process is that the design breakdown needs to be quite stable before
the LSA work can start. One reason for this is that once the LSA product breakdown has been
established, it’s been nearly impossible to introduce intermediate levels into the breakdown.
Another consequence using BEIs as the way to organize breakdown hierarchies is that a BE
cannot be reused in between different products in a simple way.
Since these kind of breakdowns do not distinguish between the function being performed andthe part that realizes the function, there is a need to introduce so called alternative breakdown
elements (ALC in MIL-STD 1388-2B and Disassembly Code Variants in S1000D). An alternative
BE is just another BE, where its BEI indicates that it is alternative equipment or component toan existing BE. The BEI therefore indicates that the BE can occupy the same installation
position in the breakdown as an existing BE. This means that such an alternative BE will haveits own unique BEI and its unique BER.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 34

S3000L-B6865-03000-00

Alternative BEs can be result of, for example, different manufactures that are selected for a
special item at a special installation place, where the respective manufactured item requires
different logistic considerations (in form, fit and function, they are the same).
It’s also a fact that incorporating breakdowns from subcontractors enforces the subcontractor to
adopt the primary contractors BEI philosophy, and implement the BEI philosophy into its
process and documentation. This increases the cost for updating and maintaining productbreakdowns that already exists.
Note
In traditional product breakdown concepts there is no mechanism to document revisions ofa BE based on design progress. For that reason it is hard to synchronize changes comingfrom design since there is no way to track the revision of a BE based on development
status.
5.3.2

PDM-oriented product breakdown
Product breakdowns as defined in, for example, today's PDM systems, defines explicit parentchild relationships between its constituent breakdown elements. This means, that a breakdown
can be established without having a structured methods for the identification of the respective
breakdown element. Using explicit parent-child relationships requires that each breakdown
element documents:−−

Relationships to its child BEs
Each parent-child relationship can include information about the quantity of child elements
and installation location

Note:
The unique BEI for BEs as defined by design are often generated by the PDM system as arandom code.
BEs are often defined as being a specifications for a system, subsystem, hardware or software
etc. Therefore, the breakdown stops at a level where a BE can be realized by an assembly(hardware part) or a software package (software part). Assemblies and software packages canin turn have a defined Bill of Material or a defined assembly structure.
The advantage of using explicit breakdown structures is that all BEs and parts can be reused inmany installation locations and in multiple breakdowns (eg for different products) without having
to define new elements, and one can introduce new intermediate levels at any time during the
project, without causing a lot of extra work.
Another advantage is that there is no need to define alternative BEs, since alternatives are justdifferent part realizations for a BE.
The incorporation of breakdowns and parts from subcontractors is also simpler, because there
is only a need to define a parent-child relationship between the main contractor’s leaf element
and the subcontractors root element. This is much more cost effective than enforcing acomplete identification system which the subcontractor needs to maintain.
5.3.3

Combining the two product breakdown approaches in S3000L
Even though the S3000L data model supports both approaches as such, a "combination" of thetwo approaches is the recommended way forward.
1

During the early phases of LSA:••

Use the product breakdown, breakdown elements and their identification (BEI) as
defined by design (including the identification of revisions in order to be able to identify
and track design changes).
If there is a need to introduce BEs required by LSA, then:−Firstly, try to influence the breakdown structure as defined by design

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 35

S3000L-B6865-03000-00

−

•
•
2

Secondly, if there is possibility to add this to the design, then create a separate
branch in the breakdown. Do not enter intermediate BEs, since that will make it
hard to manage updates of the breakdown coming from design

If there is a need to add BEs to the design breakdown, incorporate productbreakdowns from subcontractors using the subcontractor BEIs, if possible
Let assemblies, subassemblies and components be identified by part numbers and notby its position(s) in a breakdown

At delivery of the LSA results••

Apply a systematic identification system to the BEs from the product itself down to a
sufficient breakdown level (refer to Para 5.3.1). Proposal is to stop at the level where abreakdown element (specification) can be realized by a hardware or software part.
Do not enforce BEI to parts, i.e. to actual realizations.

This approach will support both the flexibility required during the LSA process, and provide across-discipline solution.

5.4

Purpose of breakdown element identifier
The BEI should give a structured view of the product in relation to the defined breakdown. The
following paragraphs provide a general overview of how these different breakdown
methodologies can be documented.
The interrelationship of an item with other items at the same indenture level and the next higher
indenture, as well as its breakdown items (eg attaching parts), will be reflected by the syntax of
the BEI (traditional approach) or by parent-child relationship (PDM approach). To reflect thestructure of an IUA assignment of hardware and software (SW), the following methods arerecommended, depending on the requirements of the project.
−−−−

Pure functional breakdown
Pure physical breakdown
Mixed breakdown, functional and physical in one breakdown tree
Pure functional and pure physical breakdown parallel, with cross-mapping

Special attention should be given to SW. In modern state-of-the-art systems, SW use isincreasing. This should be considered in any logistic analysis. It should be possible to integrateloadable SW packages into the breakdown, if the installation/de-installation of SW is
maintenance relevant. The assignment of SW to hardware should be clear within the
breakdown. Configuration changes due to SW modification are another aspect of the
breakdown. If hardware will not be modified, but SW integrated in the hardware will change,
how can this situation be documented in a product breakdown.
5.4.1

Breakdown element identifier structure
For a traditional product breakdown approach, the BEI structure defines the relationshipbetween the different breakdown indenture levels. The number and the type of charactersassigned to each indenture level of the product breakdown are defined here. The BEI structure
should be developed as early as possible and great care should be taken to define itappropriately to the project. However, BEIs should not be assigned to the BEs until the firstdelivery of LSA results (refer to Para 5.3.3). Avoid using more characters than required for eachindenture level. Ensure that the BEI structure is capable, consistent, and broad enough toaddress the entire project structure. Know the limitations of your LSA application as it relates to
BEI length and syntax. It is recommended to plan and allocate resources to address any system
structure limitations.
Note
Projects using the traditional LSA product breakdown approach will notice that any changes
to the BEI structure would cause rework for the different IT systems of the LSA andassociated ILS disciplines. For these projects it is better to use an additional digit for an

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 36

S3000L-B6865-03000-00

indenture level precautionary than to encounter BEI structure problems at later stage of the
project.
For a PDM product breakdown approach it is not required to define a specific BEI structure. In
this case, the parent-child relations of the breakdown elements are realized by explicit
relationship.
5.4.2

Alternative breakdown element
Projects using the traditional LSA product breakdown will meet the requirement to be able todefine alternative BEs similar to the former usage of ALC from MIL-STD 1388-2B orDisassembly Code Variant in S1000D for example.
The requirement for alternative BEs can be the result of, for example, different manufacturersthat are selected for an item at a specific installation place, but the respective manufactured
item requires different logistic considerations (in form, fit ,function and interface, they are thesame). In S3000L, the usage of different BEI to document this situation is not mandatory.
Alternate items to be installed at the same installation place within a product breakdown can bedifferent realizations by different hardware (or even software) at the same installation place. The
representation of these alternate realizations can be done in two different ways within S3000L:−−

Introduction of additional BEs with own BEIs (and even possibly different revisions, BER) to
document different development stages). Relation to different product variants can berealized by using product related applicability
Introduction of different realizations of a BE by different realizations (eg from different
manufacturers). These parts can become LSA candidates for the documentation of different
logistic considerations, if required.

Note
For the documentation of alternative parts to be possibly installed at one and the same
installation place, which are exactly the same in form, fit, function, interface and logistic
considerations it is sufficient to document the alternate realization against thecorresponding BEI without making the alternate part a LSA candidate.
Alternative BE is just another BE, and not a revision of an existing BE. Its BEI can indicate that
it is alternative equipment or component to an existing BE, and the BEI therefore indicates thatthe BE can occupy the same installation position in the breakdown as an existing BE. Thismeans that such an alternative BE will have its own unique BEI and its unique BER.
5.4.3

Documentation of peripheral items
Besides the product/system that is subjected to a LSA (prime LSA item), analysis of peripheral
items may also be required. Those peripheral items (which include special tasks) have to beaddressed by unique BEI and have their own product breakdown composed of eg BEs andparts. However it is necessary for the BEI to follow the BEI logic that is defined for the prime
LSA item.
Examples of peripheral items (enabling products) are:
−
−

5.4.4

LSA for complex support equipment (eg test equipment, working platforms)
LSA for complex training equipment (eg simulators, training rigs)

Identification of item families
Similar items can be grouped together for analysis purposes. This family concept can minimize
the efforts and can avoid the repetition of similar analysis activities. The following examples
should help to find appropriate criteria for the use of a family BE represented by acorresponding BEI.
−

Wiring of the same type (eg standard copper, coaxial, fiber-optical) within harnesses can begrouped together into families. Within these families, standardized tasks for cablemaintenance can be identified

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 37

S3000L-B6865-03000-00

−
−

5.4.5

Structural parts of the same type can be grouped together. Within these families, standard
structure repair procedures can be defined.
Grouping by manufacturer. All parts of a similar type coming from one manufacturer, can begrouped, because the maintenance of these parts is covered by a maintenance concept
supported by the manufacturer itself (eg with corresponding repair kits).

Integration requirements
Integration is an important aspect within the logistics area. It should be ensured that each BE
can be identified uniquely by each logistic discipline by both the customer and the contractor. It
is recommended to consider the following aspects:−

Harmonization of terminology
The item names (eg derived from early design documents) should be used unchanged andwithin the associated logistic disciplines in order to avoid confusion by the usage of different
names for the same item.

−

Harmonization of key addresses between the logistic disciplines
The key addresses should be kept as common as possible in order to ease any
communication or interaction in between different disciplines. For that reason, a common
identification of BEs and parts shall be performed to a maximum extent within all logistic
disciplines as well as the design department and CM. It is recommended to harmonize thenumbering systems of LSA and other technical/logistic disciplines.

−

Breakdown element and part identification adopted to a standardized numbering system
The BEI should correspond to a SNS as used, for example, by the design group or by CM.
It is recommended that the numbering systems of LSA and the design department and the
CM should be harmonized.

5.4.6

Establishment of an exchange system for data and documents
By using the BEI and part numbers as a common key, the following requirements can besupported:
−
−
−
−
−
−
−
−
−
−

5.5

Related ILS elements can be registered and exchanged internally and between partnercompanies
Interfaces between the logistics disciplines, design and configuration can be established inorder to establish an information network
To ease the comparison of data between logistic disciplines in order to guarantee
commonality and data quality
To identify functional and/or physical positions of all LSA candidate items
To ease trouble-shooting
To address reports derived from or received by the LSA database (eg for logistic
disciplines, management)
To address data exchange with the customer, partner companies or suppliers
To address LSA status information to breakdown elements
To structure documents that are relevant for LSA and/or other disciplines (eg technicalspecifications, handbooks, general documents, drawings and document numberingsystems)
To enable structuring of other LSA documents such as the CIL

Breakdown element identifier logic
Within BEI logic, some special aspects of information can be incorporated. The main purpose of
the BEI is the structuring of a product into hierarchical levels from the top level down to therequired breakdown depth, in order to document the relevant equipment and components. The
establishment of rules for the syntax of the BEI is important. These rules are agreed to at the
LSA GC.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 38

S3000L-B6865-03000-00

5.5.1

Breakdown without homogeneous BEI logic
For a complete documentation of breakdown methodology, the explicit parent-child principle
should also be described. This means, that a breakdown can be established without having a
structured BEI logic. Each BE only needs to identify its children. Each association with therespective child BE can contain information about the quantity of child elements (always
defaulted to one) and possible description of installation location.
Note
Quantity and installation location is data being associated with the relationship between theparent and child BEs.
Table 5 Basic table for explicit breakdown documentation
Item name

BEI

Part
numberItem type

Next higher
item

Quantity

Product / end item--

Product--

Fuel tank

TF001

-

Equipment

Product

3

Auxiliary tank

TF004

-

Equipment

Product

2

Rubber tank

TRT001-

Component

TF001

1

Tank cover

TC001

-

Component

TF001

2

Blanking plug

TBP001-

Component

TF001

1

Drain valve

TV001

-

Component

TF001

1

Valve1-45-90F

Component

TV001

1

Valve2-45-90H

Alternatecomponent

TV001

1

Filter1-

27-12

Component

45-90F

1

Body

-

45-BB

Component

45-90F45-90H1

Filter2-

27-27

Component

45-90H

1

…

...

…

…

…

The breakdown structure example from Table 5 is visualized in Fig 15.
Note
Normally, any functional information is missing in this type of explicit breakdown
methodology.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 39

S3000L-B6865-03000-00

Product / end item

Fuel tank
TF001
1

Fuel tank
TF001
1

Rubber tank
TRT001
1

Fuel tank
TF001
1

Auxiliary
TF004
1

Drain valve
TV001
1

Tank cover
TC001
2

Auxiliary
TF004
1

Blanking plug
TBP001
1

Realization

TF001
45-90F

Valve245-90H

Valve145-90F

BEI
Part number

Assembly (BOM)

Filter1
27-12

Body
45-BB

Filter2
27-27

ICN-B6865-S3000L0014-002-01
Fig 15 Product breakdown derived from Table 5
5.5.2

Basic syntax of breakdown element identifier – Establishment of breakdown levels
The implementation of a BEI syntax must consider the definition of the different indenture levels
and how to make the BEI easily comprehensible. Both the number of digits per indenture level
and the proper usage of letters, numbers and special characters must be defined carefully foreach project. Each aspect concerning the required depth and range, readability and possible
future requirements must be considered. Readability can be improved by taking into account thefollowing aspects:−−

The usage of separators between different levels is recommended
A decision made on whether to always use the full range of digits in the breakdown syntax
or to allow a BEI termination at the relevant indenture level.
Table 6 BEI readability aspects

BEI

BEI (for better clarity)

28000000000AAA

better readable by usageof a separating character

28-000-000-000-A-AA

28000000A

better readable by usageof a separating blank

28 000 000 A28
28-00128-001-001
28-001-001-002
28-001-001-002-001

28-000-000-000-000
28-001-000-000-000
28-001-001-000-000
28-001-001-002-000
28-001-001-002-001

better readable bytermination after the last
relevant breakdown level

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 40

S3000L-B6865-03000-00

In Fig 16 a typical example for a simple BEI syntax is given:
28 01 01 001 001

BEI, 5th indenture level, 3 digits, numeric
BEI, 4th indenture level, 3 digits, numeric
BEI, 3rd indenture level, 2 digits, numeric
BEI, 2nd indenture level, 2 digits, numeric
BEI, 1st indenture level, 2 digits, numeric

ICN-B6865-S3000L0015-001-01
Fig 16 Example for simple BEI syntax (reduced to numbering system)
In addition to readability aspects, other information can be incorporated within the BEI.
Examples are:−−BE variant coding
Coding of the project/product, eg a product identifier

JX 28 01 01 001 001 A
BEI suffix, eg part of coding to document BE variants
BEI, 5th indenture level, 3 digits, alphanumericpart of BEI, which
BEI, 4th indenture level, 3 digits, numericrepresents the
BEI, 3rd indenture level, 2 digits, numericnumbering systemof the project
BEI, 2nd indenture level, 2 digits, numeric
BEI, 1st indenture level, 2 digits, numeric
BEI prefix, eg product/project identifier
ICN-B6865-S3000L0016-001-01
Fig 17 Example for extended BEI syntax
Note
The definition of the syntax of a BEI as a code is not restricted. The BEI can be used as asimple representation of the numbering system as shown in Fig 16. To incorporate
additional information, the BEI can be extended eg by a prefix or a suffix as shown in
Fig 17. In this way the documentation of different BE variants can be realized. JX-28-01-01001-001-A and JX-28-01-01-001-001-B would be two different variants of breakdown
elements being installed at the same installation place. The installation place isdocumented by the part of the BEI representing the numbering system of the productbreakdown, the variant is identified by the suffix.

5.6

Breakdown element identifier and related codes
Along with the coding of the functional/physical breakdown element with the help of a BEI,
additional information is important for the unique identification of any product component. The
usage of this information described in the following paragraphs along with the BEI will provide acomplete idea of the structure and assembly of the analyzed product.

5.6.1

Purpose of breakdown element revision
The Breakdown Element Revision (BER) documents different stages of development.
Especially in the design and development phase it can be necessary to document different
development step concerning influence on design and principal changes which have significant
influence on technical/logistic analysis results and/or on the support solutions. Revisions of BE

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 41

S3000L-B6865-03000-00

have not been considered in traditional product breakdown methodologies, but is being
introduced in S3000L in order to enable a better integration with product design or logistic
disciplines.
Note
The BER is not designated to be the code to distinguish between for example, alternate
hardware components (eg from different manufacturers) which can be installed at the same
installation place (also refer to Para 5.4.2).
5.6.2

Applicability
Often different equipments (eg from different manufacturers) or equipment variants (eg from thesame manufacturer, but different releases) can be installed at the same installation position
within a product. The usage of applicability for different BEs and BE realizations (eg parts)
enables for the distinction between variants of equipments/components documented by BEI or
part identifier which can be installed within different variants of products (documented byapplicability). Concerning variants of components or parts respectively it is possible todistinguish between 2 different situations:−

Situation 1:
Simple alternative components (equal in form, fit, function, interface and logistics
considerations, eg interchangeable components from different manufacturers).

−

Situation 2:
Modified alternative components (equal in form, fit, function and interface, but not equal
concerning logistics, eg equipment/parts of the same type from different manufacturers,
which have different maintenance concepts).

In general, situation 2 has to be documented carefully by the introduction of different elements
within the product breakdown. These elements can be different BEs represented by different
BEI (traditional product breakdown approach) or, alternative, different realizations by eg
different parts (PDM breakdown approach) of one and the same BE. In both cases it is possible
to document the different logistic information against the LSA candidate, which is represented in
the first case by the BEI and in the second case by the BE realization (installation of different
parts at the same installation place, eg identified by part number).
Additional to the requirement to be able to distinguish between variants of components or parts
respectively, the product as the superior item can also be realized by different product variants(eg for different customers). A proper applicability method must be able to allocate eachcomponent or part variant to the corresponding product variant.
In the following S3000L product breakdown example the principle of assigning applicability isvisualized. The breakdown is represented by PDM-orientated explicit parent-child relationships
and applicability is realized by relationship to the product variant applicability object within the
product breakdown. The same principle can be used when a traditional product breakdown
approach is realized.
Note
In comparison to the traditional approach by MIL-STD 1388-2B the function of the data
elements ALC and UOC is now realized by applicability and hardware or software
realization.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 42

S3000L-B6865-03000-00

BEI

Advanced
truck
project

Contract

Fuel truck

DAAB0001

Product

LegendPart No

Breakdown = Physical

Truck model A

Product variant

Truck model B

A00

Product variant
applicability

A01

Truck
R01

A200

A100

Gas engine

A20200

Block

A201

Transmission
BY02

A20300

R01

Pump2
RN8

DE001

A20101

Electricalsystem

R01

Pump1
RN7

Diesel engine

TT01

A20400Fuel pumpCarburetor
R01

R02

A300

Body

GE001

A20100Truck

Fuel pump

Block

R01

Pump3
RN9

A20301

R01

Hardware element
realization

R01

Pump
RNA

ICN-B6865-S3000L0017-002-01
Fig 18 Usage of BEI and applicability
As shown in Fig 18, two different variants of the product, in this case a fuel truck, arecontracted. The main difference is the installation of two different engines. For the truck variant
represented by the BEI A00, a gas engine is installed, for the truck variant represented by the
BEI A01, a diesel engine is installed. The breakdown elements Body and Transmission are
applicable for both truck variants. The usage of applicability represented by Fig 18 easily
enables a complete representation of each product variant.
For the representation of different variants of component/part, which can be installed on an
equipment (represented by one BE), applicability is realized by hardware (or software) element
realization. The three different fuel pumps which can be installed into the gas engine arevariants of the fuel pump (represented by the BE fuel pump) with the BEI A20300.
Table 7 Product variant applicability from Fig 18
BEI

PNR

Name

Applicability

A00

R01

Truck (truck model A)

applicability object

A01

R02

Truck (truck model B)

applicability object

A100

BY02

Body

to A00, A01

A200

GE001

Gas engine

to A00

A201

DE001

Diesel engine

to A01

A300

TT01Transmission

to A00, A01

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 43

S3000L-B6865-03000-00

It is strongly recommended that the identification of variants (both, product/end item and its
components/parts) and the usage of applicability between contractor and customer is clarified at
the LSA GC.
5.6.3

Breakdown element typeBEs can be of both functional and physical character within product breakdowns. To distinguishfunctional and physical BEs a type information can be used, especially if a mixed methodology
will be applied. The classification of BEs, representing a product variant or an assembly, canalso be covered in this way. The type information can be introduced as an attribute of the BE
itself within the LSA database.

5.6.4

Equipment type
Other important information concerning equipment which can be assigned to the BE relate to
the installation and repair of the item. This includes discard information as well as accessibility
information. In the following tables, a number of general terms are introduced. This table should
be a guide to how corresponding terminology can be used within a project. However, it isrecommended that a common understanding of typical logistic terms eg within a glossary, isagreed at the LSA GC.
Table 8 Aspect of replaceability
Terminology

Description

Direct replaceable

Item that is directly replaceable on the product level (a LRU
as already described in Para 5.1.6 is a typical direct
replaceable item)

Not direct
replaceable

Item that is not directly replaceable on the product level(installed in a superior item). The superior item must be
removed before replacement, eg the compressor of anengine can only be replaced after engine removal (a SRU as
described in Para 5.1.6 is a typical “not direct replaceable”
item)

Non replaceable

Item that is intrinsically tied to another and cannot be
replaced separately.

Additional to the replaceability it is necessary to know whether an equipment
or a component can be repaired or not. This aspect is summarized in thefollowing table.
Table 9 Aspects of repairability
Terminology

Description

Full repairable

Item that is fully repairable

Partial repairable

Item that is partial repairable (depends on failure)

Non repairable(discard part)

Item that is not repairable.

Normally, the repairability information is related to a component/part and will be documented
against a realization (eg part). In some cases it can be an attribute of a BE, when the installation
situation prevents a repair of the installed component.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 44

S3000L-B6865-03000-00

The combination of replaceability and repairability fully describe the equipment within thecontext of the decision on whether an item will be replaced, but this decision can also be
influenced by economical considerations.

5.7

Breakdown element identifier requirements concerning software
Software as a part of the breakdown has some special requirements. In general, it should bepossible to include SW items within the overall product breakdown. Refer to Para 11.3 forexamples concerning SW elements in physical and functional breakdowns.

5.8

Breakdown element identifier aspects for LSA guidance conference
To summarize the most important aspects, the following list supports the creation of rules forthe establishment of a product breakdown methodology.

5.8.1

General aspects for customer involvement
The following aspects concerning breakdown depth must be considered:−−Have overall support and repair strategies with influence on breakdown requirements
already been decided? (eg two level maintenance concept, overall test/BITE architecture,single source principle concerning major repair)
What aspects must be observed concerning the depth of detailed breakdown?
••−

Have rules been established to differentiate between breakdown requirements concerning:
•
•
•

−

−
−

Pre definition or definition phase
Early development phase (eg breakdown for comparison purposes)

Information to be addressed by the BE (eg required within CIL):
•
•
•
•
•
•

5.8.2

Equipment with embedded SW (breakdown concerning SW design aspects)
Equipment with user loadable SW and data (SW- up/down loading, transportation)

Is a dedicated breakdown concerning SW items predicted (rules to be followed)?
Are peripheral items (eg complex support equipment, simulators, and maintenance trainers)
to be included in the breakdown?
Are contractual requirements identified that need to be verified against a BE?
For what program phases are LSA to be performed (especially starting stage)?
••−

Newly developed or major modified equipment
Moderate modified equipment
Commercial Off-The-Shelf (COTS) items

Have rules been established for SW items concerning:
•
•

−
−

Potential depth of repair at authorized level (eg at depot level)
Potential level for traceable usage data collection

Marker indicating each selected LSA candidate
Marker indicating (potentially) cost-/readiness-/maintenance drivers
Marker for LRUs
Marker for SRUs
MTBF values allocated to each BE or part
Estimated unit price (or price categories) for high cost articles – as available

Standardized numbering system
A numbering system to be used for the product breakdown has to be identified, eg SNS from
S1000D to be used for BEI structure.
Have rules been established concerning the breakdowns type to be defined/used?
−

Physical breakdown

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 45

S3000L-B6865-03000-00−−−

Functional breakdown
Mixture of functional and physical breakdown
Both types in parallel linked by cross-mapping

Use of the product breakdown for standardization purposes:−−

6

Is the selected BEI to be used as central identifier for assigned LSA candidates within a CIL
Is the selected BEI to be used for item terminology (common for all logistic disciplines)

Candidate item selection and identification
The LSA process should be seen as considerably cost intensive. For that reason, the selectionof the LSA candidates and the associated analysis activities should be done with adequate carein order to keep a good balance between the effort for LSA and the benefits acquired from the
LSA process. The candidates can be of different quality, which requires the type of analysis
processes and the depth of the analysis to be dependent on the particular LSA candidate.

6.1

Definitions and general terms
First, some definitions of general terms used in the logistics environment concerning
systems/items impacted by logistic support analysis will be introduced.

6.1.1

Candidate and non-candidate
The LSA candidate is the driver for all LSA activities. A potential LSA candidate, in general, canbe an item on system, subsystem, equipment, module or sub module level, which is repairable
or which requires maintenance support, scheduled or unscheduled. The decision on whether an
IUA will be part of the CIL is dependent upon the criteria above, plus some additional criteria
which must be defined individually by the project.
In addition to this hardware related definition, special activities or descriptions can be part of a
product breakdown. For example, the description of standard practices for the repair ofstructural components can be documented within a special chapter of the product breakdown.
In this case, these specific non-hardware breakdown elements also can be LSA candidates,
because, for example, special events or maintenance tasks are addressed to them.
For non-candidate items, a detailed logistic analysis is not required. These items do not need toappear in a physical breakdown under a unique BEI. If a deep breakdown is established, allitems that do not fit into any of the selecting criteria given in the LSA candidate selection
checklist are potential non-candidates. Breakdown items that are only subject to standard tasks
for which no special logistic resource is required, are also potential non-candidates. Typicalexamples for non-candidates are consumables and bulk items, such as screws, bolts, nuts or
washers. Nevertheless, even though an item may be identified as a non-candidate during the
LSA candidate selection process, the result needs to be documented in the CIL.

6.1.2

Maintenance relevant items and maintenance significant items
For a clear definition of existing and new terms, a separation between the established term
Maintenance Significant Item (MSI) and the definition of the LSA candidate must be established.
Any IUA that is impacted by any maintenance action must be regarded as relevant for logistic
analysis. The type of maintenance tasks is divided into two general categories: the scheduled or
preventive maintenance and the unscheduled maintenance (failure or damage correcting). For
this reason, the terms will be defined as follows:
Table 10 Definitions of MSI and MRI
Item typeDefinition

MaintenanceRelevant Item

A Maintenance Relevant Item is an item that can be repaired or replaced incase of a failure or damage. Normally this item is automatically a potential
LSA candidate, but not automatically an MSI.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 46

S3000L-B6865-03000-00

6.1.3

Item typeDefinition

MaintenanceSignificant Item

A Maintenance Significant Item is an item that was identified by any
selection process as the result of a SMA procedure such as S4000M, MSG3 or Reliability Centered Maintenance (RCM). For this item, a SMA will be
performed (eg a system and power plant analysis as described in S4000M).
A MSI can become a LSA candidate if the SMA identifies a scheduled task.
This task will be documented in the LSA database.

Structural items, structure significant items and structural details
The structure of a system (like the bodywork of a car) is also part of the product breakdown.
Structural items can be typical LSA candidates and also candidates for a SMA.
Table 11 Definitions of Structural Item, Structure Significant Item and Structural Detail
Item typeDefinition

Structural Item

A Structural Item is a part of the system's bodywork. It can be a LSA
candidate as well as a Structure Significant Item.

Structure
Significant Item

A Structure Significant Item is an item which was identified by any selection
process from a SMA procedure such as MSG-3 or S4000M. For this item, a
SMA will be performed (eg Structure Analysis as described in S4000M).

Structural Detail A Structural Detail is a specific area of an SSI which was identified by any
selection process from a SMA procedure such as MSG-3 or S4000M. For
this detail, a SMA will be performed. In the breakdown, a structural detail canbe identified by an additional artificial BEI below the super ordinate structuralcomponent.

Note
A detailed classification of structural items (with impact on a product breakdown) and adefinition of zones are given in S4000M for the application of the SMA.
6.1.4

Non-hardware items
Within a hierarchical hardware breakdown, only hardware is normally documented. If it isnecessary to describe any general tasks which cannot be assigned to a specific hardware or
which are standard procedures for a group of items (eg repair procedures for electrical wiring),
non-hardware items must exist within the product breakdown. These non-hardware items canbecome LSA candidates, too.

6.2

Classification of LSA candidates
It is recommended to establish categories of LSA candidates. This enables the differentiation
between the needs and to reduce the effort to an adequate level for each category of LSA
candidate. The LSA candidates can be classified according to the table below. For all candidate
types, the exact meaning of every classification must be defined carefully and harmonized withthe customer, especially for the partial candidates, as it may be necessary to define more than
one partial type within a certain project.
Table 12 LSA candidate categories
Candidatecategory

Description

Full candidate

Provide full scale of selected LSA information applicable to the related item.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 47

S3000L-B6865-03000-00

Candidatecategory

Description

Partialcandidate

Provide a partial scale of selected LSA information applicable to the related
item, (eg only remove and install information because of the need to gain
access to other items, but no repair information required because the item isa discard item).

CandidatefamilyProvide LSA information focused on specific requirements, (eg for a family of
items such as non-specific wirings, harnesses, pipes, lines, minor items of
the same type such as clamps, harnesses, connectors) Those items mayneed only a summary analysis for each group.

Standard
procedures
candidate

Provide a partial scale of LSA information because relevant information forthis item is already covered by the LSA information of other non-hardware
BEI (eg tasks concerning standard repair procedures of structure orelectrical wiring).

For every LSA candidate type, a list of criteria must be established. Together with these criteria
lists, a flowchart for the decision process should be developed to support the logisticians.

6.3

Selection process and criteria list
For LSA candidate selection, each breakdown item must be assessed concerning its
significance for LSA purposes. If the agreed upon section matrix indicates that an item is acandidate according to the rules for selection, the relevant item will be noted as a LSA
candidate.
The LSA candidate selection process should be adapted to each project. In the following
paragraphs, examples for typical selection criteria are given. Additionally, LSA candidate
selection flowcharts are given in Para 11.4. Depending on the project, some questions in the
flowcharts can be modified or additional questions can appear in the process.
To perform the LSA candidate selection process, some preconditions concerning productbreakdown and the establishment of rules must be fulfilled.

6.3.1

Preconditions for the selection process - Product breakdown
LSA candidates will be derived from a hierarchical hardware breakdown of the System under
Analysis (SUA) from the product level to sub-module level. For this reason, the most importantprecondition to be able to perform a LSA candidate selection is the availability of a productbreakdown. It has to be ensured, that the existing breakdown is applicable for this task by
examination of the following criteria:
−
−
−

6.3.2

Is the product breakdown available in a sufficient depth and extent (refer to Para 5)?
Is the product breakdown a preliminary issue (eg for responding to a request by a potential
customer or for pre-contractual agreements with a potential customer)?
Is the existing product breakdown already agreed by the customer?

Preconditions for the selection process – Existing analysis results
Each existing analysis result (eg from analysis activities in advance or directly from the
manufacturer) should be used for candidate selection. Examples are the following:−−−

Existing experience for equipments already used in other products/systems
Existing maintainability or reliability data
Existing Failure Mode and Effects Analysis (FMEA) or Failure Mode and Effects Criticality
Analysis (FMECA) results

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 48

S3000L-B6865-03000-00

6.3.3

Preconditions for the selection process - Candidate selection rules
The establishment of the rules for LSA candidate selection and the extent of analysis must be
agreed to by the contractor and the customer as a part of the LSA GC. This means that the final
CIL cannot be presented at the beginning of a LSA GC (only a preliminary CIL can be
published). In the following list, some criteria are listed that can be used as a basic guideline forpotentially relevant aspects for a LSA candidate selection.
The following items should be considered as potential LSA candidates that need to be assessed
for inherent reasons and/or due to their installation area:
−
−
−
−
−
−
−
−

The item is maintenance significant concerning the related failure/defect frequency or the
awaited workload.
The item needs special logistic requirements such as personnel, training, material or
support equipment.
The item is subject to scheduled or preventive maintenance (eg preventive change of lifelimited items).
The item is subject to special procedures, eg after special events like lightning-, bird-, hailstrikes, contact with obstacles.
The item is subject to diagnostic and/or functional test tasks (eg complete system tests
linked to a high level BEI).
The item is potentially endangered by damages due to the installation area and/or thedesign of an item.
The item is subject to the use of new technology
The item contains user loadable software (including data)

The following items should be considered as a potential LSA candidate that needs to beassessed for a global point of view (for special interests):
−
−
−
−
−

The item is a potential readiness driver
The item is a potential cost driver (eg expensive support equipment required)
The item is a potential maintenance driver (eg high workload expected)
The item is subject to emphatically customer interest
The item is subject to LSA related contractual fulfillment

The following items should be considered as potential LSA candidates that need to be assessed
only or mainly for standardization reasons:−−−

The items require only removal and installation in order to gain and undo access to a LSA
candidate. No true LSA activities are required concerning these items, but the involved
logistic requirements should be standardized and documented.
Documentation of general tasks within the LSA database. Those tasks need to beincorporated in the LSA database mainly for registration and documentation of theassociated logistic requirements. Often, the general tasks are linked to non-hardware BEI.
Groups of items that may require a summarized logistic analysis (eg a family of non-specificwirings, harnesses, pipes, lines, minor items of the same type like clamps)

All the criteria above must be detailed using measurable threshold values. For example thecriteria indicating whether an item is maintenance significant concerning the related
failure/defect frequency, must be specified with a clear threshold value such as the MTBF. The
criteria above fit for all types of candidates. The possible criteria for the differentiation of thecandidate types will be described in the following paragraph.
6.3.4

Preconditions for the selection process - Candidate classification selection rules
In the following tables, examples for criteria for the different candidate types are given to
support this important task of the LSA candidate selection process. Flowcharts for candidate
item selection are given in Para 11.4.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 49

S3000L-B6865-03000-00

Table 13 Classification criteria for full LSA candidates
Candidate
Classification criteria
classification

RequiredanswerFull candidate Is the item a newly developed or a major modified item
(functional equipments, not valid for structure)?

Yes

Is the item a Line Replaceable Unit (LRU)?

Yes

Is the item a repairable item?

Yes

Is the item of low reliability (must be defined in measurable way)? Yes
Is the item maintenance relevant? In other words, are there any
dedicated maintenance tasks planned such as repair, servicing,
lubrication or calibration (no general tasks such as simple
cleaning or a simple replacement).

Yes

Are dedicated maintenance tasks complex, very time consuming
or personnel intensive?

Yes

Is the required support equipment for dedicated maintenancetasks a non-standard or a non-existent item?

Yes

Does the item need specific scheduled or preventive
maintenance identified in a Scheduled Maintenance Analysis(SMA)?

Yes

If all of the questions from Table 13 are answered with "No", the IUA will not be a full candidate.
If any question is answered with "Yes", then this item is a potential full candidate and can beclassified as such in the CIL.
Table 14 Classification criteria for partial LSA candidates
Candidate
Classification criteria
classification

RequiredanswerPartialcandidate

Must the item be removed to gain access?

Yes

Is a removal for access frequent for the IUA?

Yes

Is the item a system or a subsystem that has not been previously Yes
defined as a full candidate, for which a fault location and/or a test
procedure or other general maintenance procedures will be
described?
Is the item a non-hardware item, for which general activities (egcleaning, storing, parking, mooring, general inspections) will be
described?

Yes

If all of the questions from Table 14 are answered with "No", the IUA will not be a partial
candidate. If any question is answered with "Yes", then this item is a potential partial candidate
and can be classified as such in the CIL.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 50

S3000L-B6865-03000-00

Table 15 Classification criteria for LSA candidate family
Candidate
Classification criteria
classification

RequiredanswerCandidatefamilyIs the IUA installed within the system many times in the same orsimilar way?

Yes

Is it possible to combine all equal or similar items to one familywith common maintenance activities?

Yes

The LSA candidate family concept should be used when a large number of equal or similar
items are installed within the SUA. For example, all electrical wiring with the same properties
and the same or similar connectors can be summarized under one LSA candidate family. For
this family, all maintenance relevant information (eg a connector repair concept) is valid for all
single cables of the whole family, and can be documented for a family BEI.

6.4

Influencing factors
The following factors should be taken into account for candidate item selection and/or
establishing related rules:
−
−
−
−

−
−

Program phase to which the LSA program belongs
Complexity of the product/system to be analyzed
Price of the product/system to be analyzed
Budget available for the overall logistic support and budget specifically planned for the LSA
process. The limitation of budget will always have an influence on the number of LSA
candidates that can be analyzed. In these cases, a reduction in the real maintenance andcost drivers is required.
Importance of the LSA results for the internal logistic disciplines and the information
required by the customer and the industry management required to make decisions and tofulfillment the contractual requirements of the LSA related items.
Items already in use under comparable conditions
•
•
•
•

−
−
−
−
−
−

6.5

Items already in use, but under not comparable conditions
COTS items usable with or without major modification
Items already available but requiring major modification
Newly developed items

Information expected from the LSA process (to be harmonized with/agreed by the customer
during the LSA GC)
Identification of possible alternatives (for hardware, software, support concepts) and relatedconsequences (eg MC, logistic support requirements)
Proposal of recommended MC
Identification of tasks associated with the intended MC
Identification of related logistic support requirements
Estimation of related logistic support costs (part of LCC)

Recommendations for LSA candidate selection
To give an overview to the analyst on how to handle LSA candidate selection criteria in detail, alist of recommendations concerning what is unquestionably required and what is nice to have.
The following table provides assistance in the selection process. From this table, the analyst
can find recommendations on how to determine whether it is mandatory, recommended, orvoluntary for an IUA to be a LSA candidate.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 51

S3000L-B6865-03000-00

Table 16 Recommendations for LSA candidate selection
Aspects

Description of criteria

Risk andcriticality

Must LSA candidates be integrated from separate LSA
Mandatory
programs? LSA information to be integrated into one LSA
program (developed outside) without any change (eg LSA
data for an engine derived from a separate contractor) or
external LSA information to be integrated with adoption to a
LSA program that requires changes to be harmonized withthe original contractor.

Item type

Generalattributes

Considerationas potential
candidate item?

The IUA is subject to a SMA (S4000M, MSG-3, RCM) andscheduled or preventive tasks are identified.

Mandatory

The structural IUA is subject to a SMA (S4000M, MSG-3,
RCM) and scheduled or preventive tasks are identified.

Mandatory

The IUA is subject to life limits.

Mandatory

The IUA is subject to preventive maintenance, other thanscheduled, or to special procedures (eg after special
events like lightning-, bird-, hail- strikes, contact withobstacles).

Voluntary

The IUA is subject to the use of new technologies.

Mandatory

The IUA is a potential cost driver (high value items, costlimits must be defined with the customer).

Mandatory

The IUA is a potential readiness driver because of longrepair times.

Mandatory

The IUA is a potential maintenance driver (high workload)

Mandatory

The IUA is of special customer interest (information values
must be defined with the customer)

Mandatory

The IUA is subject to LSA related contractual fulfillment

Mandatory

Item already in use under comparable conditions

Recommended

Item already in use under non-comparable conditions

Mandatory

Item already in use but requiring major modification

Recommended

Item newly developed

Mandatory

COTS items

Recommended

Part of an maintenance significant "item family"

Voluntary

Item containing user loadable SW and/or data

Mandatory

Item is line replaceable

Mandatory

Item is shop replaceable

Recommended

Item is line repairable

Recommended

Item is shop repairable

Recommended

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 52

S3000L-B6865-03000-00

Aspects

MaintenancesignificanceDescription of criteria

Considerationas potential
candidate item?

Item is repairable at customer depot or at industry level

Voluntary

A FMEA/FMECA is available concerning the related item

Mandatory

Item is potentially subject to LSA relevant servicing

Voluntary

Item is potentially subject to (diagnostic/functional) test

Recommended

Item is potentially endangered by damages

Voluntary

Item is potentially subject to general tasks

Voluntary

Item is potentially subject to summary analyses

Recommended

Item is potentially subject to standard procedures

Voluntary

Item is subject only to gain/undo access to LSA candidates Voluntary

6.6

Candidate item list (draft)
For LSA candidate selection purposes, a matrix may be used in order to structure anddocument the selection results. A first draft should be included in a recommendation list,
prepared by the contractor, which reflects the proposed selection criteria. The draft of the CIL
should be prepared by the contractor for the LSA GC. After harmonizing the proposed selection
rules between the contractor and the customer, this draft can be reworked and published as thepreliminary CIL.

6.7

Candidate item list as an output of LSA guidance conference
The CIL should be included in an obligatory list, reflecting the decisions that were made by thecustomer. This CIL must be a living document in order to document changes during the life
cycles of the program. During the LSA GC (refer to Para 4) the Draft CIL will be discussed andharmonized between the customer and the contractor. This must be recognized as one of themost important steps regarding contractual terms. In the CIL, a collection of all LSA candidates
and the corresponding workload from the selected analysis activities will be managed. To
support the LSA process management, the progress of the LSA and documentation work
should be documented by status codes, which reflect the status for all the different contractual
relevant analysis activities to be covered within the LSA process.
To increase effectiveness, it is recommended to integrate the CIL as a central management tool
into the logistic database application so that it will be possible to hold all relevant information of
the CIL in the breakdown of the system. An overview of the project can easily be given by thecorresponding reports.
All changes in the CIL for whatever reasons (eg technical, budgetary, redesign) must be
discussed and harmonized between the customer and the contractor and documented carefully.
For the LSA managers and the ILS managers for both the customer and the contractor, the CIL
is the valid document for control of the whole LSA process. The customer and the contractor
must understand, at every stage of the project, who is the holder of the contractually valid issueof the CIL.

7

Logistic analysis activities
In the early life cycle, LSA shall support cost relevant decisions by performance of adequate
front end analysis (eg LORA). LSA must influence design concerning logistic aspects from the
beginning of the definition phase and this task has to be continued during the lifetime of the

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 53

S3000L-B6865-03000-00

product. The inputs for the design come from different analysis sources such as reliability,
maintainability, testability or SMA. The performance of analysis activities for LSA candidates
can be a cost concern if no threshold is established to reduce the effort to a suitable level. In
order to balance between analysis-related efforts and acquired knowledge which is mandatory
to identify adequate logistic requirements (that satisfies the user's needs and logistic support
cost constraints), a series of assessments is required. Related allocation criteria and rules mustbe identified by the contractor and proposed to the customer as general guidelines tailored tomeet the specific requirements of a given program.
Note
This has a large cost influence on both the effort to be spent for the LSA program itself andon the generation of future support costs during the overall life cycle of the items underanalysis. Based on experience acquired within a broad range of LSA applications, it isstrongly recommended to perform this task on a preliminary basis as an initial assessment
early in a program and to harmonize the derived strategy with the customer before signinga contract.

7.1

Principles for analysis activity selection
Only those analysis activities should be selected for a LSA candidate that are considered to
improve the investigation result such a way that the expected benefit is greater than the effort tobe spent for the intended analysis activity itself. Prior to the allocation of potential analysis
activities to LSA candidates, they should be grouped into categories in order to identify the realneed for analysis activities to reduce the effort to an adequate level (refer to Para 5).
Knowledge acquired by "lessons learned" should be taken into account on customer andcontractor side. This holds for both, positive and negative experience. Based on thatknowledge, LSA relevant decisions may be predetermined without further analysis activities.
New available analysis methods should be taken into account where feasible. For example, asimulation result is much more comprehensive than a traditional ("more static") analysis.
Note
Based on the experience of Industry, powerful simulation software packages are available
and are expected to become important for LSA purposes.

7.2

Potential analysis activities
The following LSA activities are a list of potential analysis which can be performed anddocumented in different ways depending on the kind of project. The LSA database must
document the LSA activities and their results.
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Analysis for identification of general LSA Needs
Comparative analysis
Human factor analysis
Configuration assessment
Reliability analysis assessment
Maintainability analysis
Testability analysis
LSA FMEA - Logistic FMEA
Damage analysis
Special event analysis
SMA (S4000M, MSG-3, RCM)
LORA
MTA
SSA
Operations analysis
Simulation operational scenarios

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 54

S3000L-B6865-03000-00−

Training Needs Analysis (TNA)For each LSA activity, the contractor and the customer must agree whether, and how, theresults of each analysis activity will be documented, delivered, commented and assessed. It is
recommended that most of the results of the analysis activities be documented in a LSA
database, but it is possible to document as a special analysis report or an official document. It
must be clarified before the beginning of the analysis, the required results and the benefits fromthe collected data, and how the data will be evaluated and used for later logistic purposes.
7.2.1

Analysis for identification of general LSA needs
This starting point for any LSA activity is the basic precondition for applying any of the following
tasks. Here you have to determine why the analysis must be performed. Do not spend valuable
resources for analysis work without a clearly defined objective. The identification of general LSA
needs is mainly related to contractual, customer and user interests. The following aspects must
be considered and harmonized between the contractor and the customer very carefully to avoid
any misunderstandings in a later stage of the project.
−−−−

Consider the results of the establishment of product usage data (ORD and CRD), intended
support strategy and principles and alternative solutions. Clarify which scenarios must be
analyzed, how and in what depth.
Consider which contractual information must be demonstrated/validated by LSA results,
how and in what depth.
Consider the definition of required reports concerning areas of special interest (egmanagement reports, status overviews, performance measuring reports, verification
reports).
Also consider trade off analysis results in order to guarantee the best return of investment.
This means, for example, customer demands may be discussed to achieve the goal bysome other method. The alternative solution might have significantly less effort, but it must
lead to a comparative result which meets the requirements of the customer in a similar andacceptable level.

The result of these first considerations must be an agreement between the contractor and thecustomer about the purpose, goal, depth of analysis, and documentation method for eachanalysis type so each has a common view on the performance of LSA. The result of thisanalysis should be documented in the LSA program plan at the LSA GC.
7.2.2

Comparative analysis
This analysis will be performed upon special request only. As a precondition, comparative
information of equipment, a system or an end item must be available and effective for decision
making (limited to the initial LSA activities). If a comparative system can be defined, appropriate
analyses must be performed in order to derive applicable comparative data. For the
documentation of the results, special summary reports concerning comparative factors and data
and/or support alternatives addressed to comparable LSA candidates must be identified.

7.2.3

Human factor analysis
This analysis may have influence on those LSA candidates for which a MTA is performed.
Human factors can be a reason for special limitations (eg concerning the applicability of amaintenance task which requires special abilities). Ergonomic aspects must be considered
here, as well as the definition of rules for an appropriate man machine interface. For example,
some aspects that can have limiting consequences to LSA activities (eg MTA):−−−−

Ability to lift and carry heavy loads
Ability to move for a long time in special conditions
Handling of dangerous materials
Limitations of personnel employment by law (security restrictions)Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 55

S3000L-B6865-03000-00

7.2.4

Configuration assessment
In the case of significant deviating design configurations of any LSA candidate, configurationassessments are mandatory. Potential change of validity, engineering changes, deviations or
waivers must be examined. Configuration assessments must be performed as general
assessments of the need of deviating maintenance concepts and/or logistic support
requirements (personnel, material) in order to re-assess the need for analysis activities on LSA
candidates.
The customer and the contractor must clarify how configuration deviations of LSA candidates
should be documented within a logistic database. For that purpose, the usage of alternate BEI
concepts is described in Para 5.

7.2.5

Assessment of reliability analysis
Reliability predictions (eg Mean Time between Failures, MTBF) related to the intended usage
scenario of the LSA candidates must be assessed regarding their use for LSA purposes. The
determination of reliability values is a design and development related task, but the
documentation of certain results of this analysis is of crucial importance for LSA purposes.
Normally, a reliability analysis is mandatory for each hardware LSA candidate. Additionally, it isrecommended to extend reliability predictions to all essential items of a LSA breakdown and toensure consistency of these values over all breakdown cascades.
Note
The reliability values are directly linked to the values of a LSA FMEA concerning ratios ofdifferent failures of a LSA candidate. These two areas in a logistic database must be
consistent. Any LSA software package should be able to check this correlation between
these two analysis areas automatically, otherwise the overview of reliability dataconsistency with FMECA data will be easily lost. Every LSA software package must be able
to automatically check the consistency of reliability values over all breakdown cascades.

7.2.6

Maintainability analysis
For each LSA candidate, a maintainability analysis is strongly recommended in order to decide,from a technical point of view, whether an item is supportable or not (rules for related conditions
and time frames should be established). Alternative repair solutions must be investigated, if
applicable. Where applicable, a maintainability analysis must be applied that addresses thefollowing aspects:−−−

Assessment of maintainability features reflecting customer requirements
Identification of maintenance tasks at different levels in order to support the maintenanceconcept for each applicable LSA candidate
Investigation of supportability aspects such as modular design of end item, goodaccessibility, installation concept in special zones (the item with the worst MTBF must not
be installed behind others)

In general, the maintainability analysis can be performed by following applications with different
level of detail and effort:
−
−

−
−

Best Engineering Judgment in the case of lowest level of available information
Assessment with or without transformation of equipment supplier information. In the case of
demanding information from suppliers, apply data sheet templates to ensure that every
supplier will be able to deliver the required information correctly and completely. Harmonize
these templates with the customer and the contractor (and contractor suppliers).
Take into account supporting analyses such as LORA for comparison of alternatives and/or
SMA methods, such as S4000M, MSG-3, RCM, to build the maintenance concept for the
IUA.
Use simulation tools for those products performing missions according to operational
profiles, focusing on maintenance and support while evaluating potential consequence
from, for example, limited maintenance resources or changed operational profiles.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 56

S3000L-B6865-03000-00

Depending on the different types of items, the following should be applied as a minimum
analysis:Table 17 Depth of maintainability analysis depending of item type
Item

Maintainability analysis depth

Items currently used undercomparable conditions

Moderate information and data transformation, a more detailed
maintainability analysis is voluntary

Items currently in use, but notunder comparable conditions

Careful data transformation is mandatory, a more detailed
maintainability analysis under new conditions is recommended

COTS items without major
modification

Non-compliances of logistic features and/or requirements
should to be documented and agreed by the customer.

Items currently available
requiring minor modification

Moderate information and data transformation, a more detailed
maintainability analysis is voluntary

Items currently available
requiring major modification

Careful data transformation is mandatory, a more detailed
maintainability analysis under new conditions is strongly
recommended

Newly developed items based Detailed maintainability analysis is strongly recommended
on well known technology
Newly developed items based Detailed maintainability analysis is mandatory
on new technology

The results of the maintainability analysis must be carefully documented, therefore,
maintainability reports should be defined and harmonized between the contractor and thecustomer. In addition to these reports, some results of the maintainability analysis will be
documented within a logistic database within the maintenance concept reflected by theidentified maintenance tasks.
7.2.7

Testability analysis
Main aspects for a testability analysis, which must be taken into consideration, are the following:
−
−
−
−
−
−
−

Identification of maintainability strategy aspects, which must be observed
Identification of overall test architecture and test principles
Identification and verification of contractual testability requirements
Evaluation of FMECA/FMEA documents concerning testability information
Description of failure verification methods at equipment-, system- and end item level
Description of functional check requirements at all involved levels
Identification of related logistic resource requirements (personnel, loadable software, test
software)

The testability analysis is closely connected to the maintainability analysis. Results fromtestability directly influence the maintainability analysis. Any corrective maintenance concerning
test capable items is dependent of the detectability of the failure to be corrected. If a failure
cannot be verified by any test procedure, the corresponding repair task cannot be performed. In
addition to these aspects, it is necessary to be able to perform a functionality test of an item
after repair. The depth of failure detectability/verification is one of the most important influencing
factors on an applicable maintenance concept.
Since it is nearly impossible to establish testability features after the design of an item has been
finalized, testability requirements must be described and documented carefully for eachapplicable item during the design and development phase. These requirements must be
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 57

S3000L-B6865-03000-00

harmonized with the customer during the LSA GC, however, testability capability should only beplanned to the depth on which repair is intended.
For all items containing full Built in Test (BIT) capability, a testability analysis is considered
mandatory. Related testability features must be identified and documented. A testability analysis
report, as a summary of the analysis itself, is required. For equipment with reduced BIT
capability items (eg off the shelf equipment) that are somehow monitored within the overall testarchitecture, a testability analysis is recommended. Related testability features must be
identified and documented, also.
The types of data concerning testability features must be documented in a logistic database orin special testability reports and must be established and harmonized with the customer. Rules
for manufacturers on how to implement testability features must be carefully established andverified (eg by testability demonstrations/validations together with the contactor and/or thecustomer).
7.2.8

Analysis activities concerning event driven maintenance
The following paragraphs describe the events that can be the justifications for maintenanceactivities. An overview of the event driven maintenance is given in Chap 12 in figure 1.

7.2.8.1

LSA FMEA (Logistic FMEA)
Each LSA candidate with an existing technical FMECA (eg MIL-STD-1629) must be considered
as a potential full LSA candidate. The FMEA/FMECA results should be grouped as much as
feasible in order to keep the required effort to a sensibly low level. This grouping will lead to a
LSA FMEA or logistic FMEA. Criteria for grouping and the methods for documentation shouldbe established and agreed to within the LSA GC. Grouping should be performed for every
failure or defect that leads to the same maintenance action or chain of maintenance actions thathave to be:
−
−
−
−
−

7.2.8.2

performed on the same itemat the same maintenance levelby the same personnel (trade, skill level, number of persons)requiring the same material (special support equipment, spares)
requiring the same user loadable software or data

Damage analysis
Items susceptible to damage should be considered as at least partial LSA candidates. In
general, damages are special events, for which a prediction of criticality or extent cannot begiven for every case. Nevertheless, it is useful to identify classes of damages, which can be
maintained in the same way or which can be detected in the same way. Analyses that at least
address initial diagnostic tasks and simple repair procedures (eg simple repair of damages suchas scratches) are strongly recommended. The result of these analyses should be documented
within general chapters in a logistic database, eg the standard test and repair procedures forstructural items or for electrical wiring is collected within a non hardware chapter of the productbreakdown.
Because reliability values concerning damages are not normally available, general quantitative
statements are generally not possible. Only with the help of statistical evaluations is it possible
to get a prediction of the required effort resulting from damages. It is recommended to use suchpredictions with caution.

7.2.8.3

Special event analysis
In additional to the occurrence of damages, which are a type of special event, other events canhave an impact on the maintenance concept for an IUA or on the product. It is strongly
recommended to identify and to document probable special events that require special
maintenance tasks in order to guarantee the proper functionality for the further usage. Also, theApplicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 58

S3000L-B6865-03000-00

required maintenance tasks must be described and documented (including information
concerning required resources like personnel, material or software) within a logistic database.
Some examples of special events that require maintenance tasks include:
−
−
−
−
−
−
−
−
7.2.8.4

Exceeding temperature limitations
Exceeding mechanical load limits (eg over torque)
Exceeding maximum allowed speed
Operation in salt-laden atmosphere
Operation in sand-laden atmosphereLightning strike
Hard landing of an aircraft
Collision with external objects (eg bird strike)

Scheduled maintenance analysis
A SMA is performed to ensure that safety relevant, highly economic or ecological failures arestrictly avoided. This analysis is mandatory for safety relevant aspects and strongly
recommended if significant economic or ecological disadvantages are to be expected. The SMA
itself is an extensive analysis and the results have direct impact on the maintenance concept.
Scheduled maintenance tasks, which are identified by the SMA from S4000M, MSG-3 or RCM
processes, must be documented in a logistic database. It is recommended to establish rules on
how to harmonize SMA results with the logistic database documentation method.
Each item for which scheduled or preventive maintenance tasks are identified via a SMA
process should become a full LSA candidate.
For more detailed information on SMA, refer to Chap 10.

7.2.9

Level of repair analysis
Depending of the general support strategy, it may be necessary to decide for each item, thelevel at which maintenance and/or repair of the item will take place. To support this decision, a
LORA can be performed by applying one of several methods, depending on the type of LSA
candidate to be analyzed, the effort required and/or the information available. Depending on
LSA GC agreements, different categories of LORA could be assigned, as shown in theexamples in Table 18.
Table 18 Classification of different depths of LORA
LORA
classification

Description

Simplified LORA

May be derived on the basis of Best Engineering Judgment by simply
taking into account best information available. The results of thisanalysis must be documented and harmonized with the customer
through, for example, a "Simplified LORA report".

Full LORA

A front end analysis using software packages available based onmathematical models of different complexity and accuracy. All required
data concerning the item itself and the context of its use (eg operational
scenario, spare part provision, costs) must exist in order to perform suchan intensive analysis.

Analysis via
simulation

A simulation that considers very detailed information about the IUA and
its deployment and operational scenario may produce the best LORA
results. This requires a complete set of information/data in the required
format for the simulation software package to be used. The preparationof this data can cause a lot of additional effort.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 59

S3000L-B6865-03000-00

In any case, where applicable, a LORA analysis must be considered to be a mandatory analysis
activity. This holds for LSA candidates with alternative repair and/or support solutions
concerning personnel, material and/or user loadable software or data as well as for scheduled
maintenance tasks derived from an SMA or equivalent and/or servicing tasks, if contracted.
7.2.10

Maintenance task analysis
The MTA is one of the central analysis activities within the LSA process. Here, the identified
maintenance tasks (both scheduled and unscheduled) are detailed with all required information
available. The following list gives a limited overview, for more detailed information refer toChap12.
−
−
−
−
−
−
−

7.2.11Documentation of general task information such as preconditions for task performance,
training requirements or criticality information.
Assignment of maintenance tasks to the identified events (eg failures, damages, special
events, time limitations)
Rough task description (sequence of subtask)
Identification of related logistic resource requirements (eg personnel, support equipment,
spares, facilities, software)Time estimations
Calculation of task frequencies
Consideration of required pre- and post- tasks (eg test, fault location, gaining access)Software support analysis
Each item containing user loadable data/software must be analyzed with regards to loading, deloading, transportation and documentation of existing SW releases. This covers maintenanceand servicing tasks applicable for:−−−

Maintenance of hardware containing user loadable data/software
Data and/or operational software required for usage preparation
Software support in order to update items with new user loadable software releases

If a SSA program will manage SW changes, SW releases, and the maintenance of SW in caseof SW failures (bug fixing), a process analogue to the LSA process for hardware should beestablished.
For more detailed information, refer to Chap 13.
7.2.12

Operations analysis
Operational requirements must be analyzed to identify tasks that are important for the general
handling of the SUA. These tasks should also be documented in a logistic database. For logistic
purposes, it is necessary to analyze such tasks to identify the requirements concerning
personnel, support equipment or material.
For more detailed information, refer to Chap 9.

7.2.13

Simulation of operational scenarios
This analysis will be performed by special request only. Simulation represents a very powerfulability to evaluate operational scenarios in combination with logistic scenarios. Today,
simulation SW packages offer the opportunity to analyze and optimize the planned usage of asystem under particular logistic conditions. Only the combination of these two aspects, planned
usage scenario and planned logistic scenario, makes it possible to generate meaningful
analysis results. The better the scenario can be described, the better the results will be.
It must be clear that simulation analysis needs a lot of input data with a certain depth. This
causes additional effort, which must be considered. If simulation is selected as a required
analysis activity, it is strongly recommended to start early with the examination of the dataneeds of the simulation SW package. The decision to perform simulation can influence theApplicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 60

S3000L-B6865-03000-00

depth and the requirements for the quality of any logistic data (eg the detailed description of alogistic scenario can cause additional effort within a MTA). Also, the creation of an operational
scenario can cause additional effort for the customer.
7.2.14Training needs analysis
Within this analysis, it must be decided whether a task requires special training or not. If training
is required, it must be determined how the training can be applied most effectively. This process
can be supported with the help of the content of the LSA database concerning the identified
tasks.
The criteria for a training requirement should be discussed and harmonized between thecustomer and the contractor during the LSA GC. It is recommended to establish an IT
supported process for the TNA. The criteria should be "translated" to the LSA database systemand each task should be examined against these criteria. The result can be a preliminary TNA
decision based on existing data concerning tasks within a LSA database.

7.3

Analysis relations and general overview
All the analysis types described in the previous paragraph are interconnected and influenceeach other. Some analysis types are a basic precondition for other ongoing analysis processes.
Some analysis types are of a general significance for all other analysis procedures. Fig 19
shows a graphical depiction of the relations between the different logistic analyses.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 61

S3000L-B6865-03000-00

Analysis for identification of general LSA needs
Comparative analysis

Technical
FME(C)A

Human
factoranalysis

Reliability
analysis

influences

influences

Specialevent
analysisidentifies
M-tasks

identifies
M-tasks

Operations
analysis

SoftwareSupportAnalysisidentifies
M-tasks

Damageanalysisidentifies
M-tasks

Maintainability
and Testabilty
analysis
influenceon M-tasks

identifies
M-tasks

LSA
FME(C)A

identifies
M-tasks

Scheduled
MaintenanceAnalysis(SMA)

Configuration aspects

Maintenance Task Definition

Maintenance Task Analysis (MTA) Identification of task requirements

Level Of Repair Analysis (LORA) Maintenance concept

Training Needs Analysis (TNA) Identification of training needs

Simulation scenarios

ICN-B6865-S3000L0018-001-01
Fig 19 Analysis activities relations and overview

7.4

Analysis activities selection criteria
The following aspects must be considered in order to select and allocate LSA relevant analysis
activities to LSA candidates that are applicable and effective depending on the type of items,
candidates and required information.
The selection criteria and aspects must be tailored to each program by taking into account any
specific circumstances and they must be harmonized between the contractor/industry partnercompanies and the customer within the LSA GC.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 62

S3000L-B6865-03000-00

Table 19 Analysis activities selection criteria
Criteria group

Criteria

Recommendation

Items with existing
experience

Items already in use undercomparable conditions

Moderate transformation of existing
analysis data

Items already in use but under
non-comparable conditions

Careful transformation of existing
analysis data

COTS items usable withoutmajor modification

Moderate transformation of existing
analysis data

Items currently available thatwould require (minor/major)
modification

Careful transformation of existing
analysis data or performance of new
analysis

Newly developed items basedon well known technology

Performance of analysis activities inrequired depth strongly recommended

Newly developed items basedon new technology

Performance of analysis activities inrequired depth mandatory

Potential readiness drivers
and/or cost drivers

Criteria for these items must be
detailed within the LSA GC

Subject to emphatic customer
interest

Items must be detailed within the LSA
GC

Subject to LSA related
contractual fulfillment

Items must be detailed within the LSA
GC

Item is maintenance significant
concerning the related
failure/defect frequency,
workload, special logistic
requirements (personnel and/or
material)

Criteria for these items must be
detailed within the LSA GC

Item is subject to scheduled
maintenance or to life limits

Criteria for SMA must be detailed
within the LSA GC

Item is subject to preventive
maintenance resulting from
special events

Criteria for special event analysis
must be detailed within the LSA GC

Item is potentially susceptible todamages due to its installationarea

Criteria for damage analysis must be
detailed within the LSA GC

Full candidate

Subject to applicable analysis, results
documented within LSA

Partial candidate

Rudimentary information to be
documented in LSA

Candidate families

A group of items considered as one
LSA candidate, subject to applicableanalysis, results documented within
LSA

Items that need to
be assessed for
global point of viewor for special
interests

Items that need to
be assessed for
inherent reasons or
due to theinstallation area

Type of LSA
candidates

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 63

S3000L-B6865-03000-00

Criteria group

Subject to request
for information by
the customer

Criteria

Recommendation

Items subject to standard
procedures

Rudimentary information to be
documented in LSAInformation expected from the
LSA process

To be harmonized with and agreed toby the customer during the LSA GC

Proposal of recommended
logistic support principles

To be harmonized with and agreed toby the customer during the LSA GC

Identification of possible
alternatives (for hardware,
software, support concepts) andrelated consequences (eg MC,
logistic support requirements)

To be harmonized with and agreed toby the customer during the LSA GC

Proposal of recommended
maintenance concepts including
corresponding tasks

To be harmonized with and agreed toby the customer during the LSA GC

Estimation of related logistic
support costs

Identification of related logistic
support requirements
Estimation of related logistic support
costs
Information for early system/program
decisions (significant costs influence)

7.5

Checklist for analysis activity recommendation

7.5.1

Recommendation and decision sheet
For analysis activities selection purposes, a selection matrix should be used in order to structureand document the selection and decision results.
Analysis activities recommendation sheet:This matrix should be prepared by the contractor for the LSA GC, identifying the LSA
candidates, the task selection criteria and the derived results (recommendations). For all
general tasks not driven by the LSA candidates, recommendations must be documented
carefully eg in independent documents. This applies to the following analysis activities:−−−−

Analysis for identification of general LSA needs
Configuration assessment/aspects
Availability of a technical FMEA/FMECA and influence on LSA FMEA and SMA
Human factor analysis

Analysis activities decision sheet:This matrix will be harmonized and finalized at the LSA GC and reflects the decisions made by
the customer. This contractually relevant document should be established as a living document
in order to reflect changes, to incorporate "lessons learned" results and enable traceability
during the life cycles of the program. As a recommendation, a preliminary list could become partof a commercial proposal in order to introduce a general guideline for LSA task allocation to thecustomer for risk reduction purposes.
7.5.2

Selection matrix example and rating values
In order to identify the relative importance of the allocated analysis activities, "ratings" should be
agreed to concerning both the importance of the selected LSA candidate itself as well as theimportance of the potential analysis activity. The result can rank LSA candidates and analysis

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 64

S3000L-B6865-03000-00

activities from mandatory down to voluntary. This ranking could be used to refine the selectionof candidates/analysis activities in case of eg limitations of budget or time constraints. The
results of this selection procedure would be the initial issue of the LSA CIL as well as the rangeof LSA activities considered as relevant and effective for the LSA candidates. Appropriate rules
must be identified and harmonized within the industry partner companies and agreed to by thecustomer during the LSA GC.

ICN-6865-S3000L0019-002-01
Fig 20 Example of a simple analysis activity recommendation sheet
Fig 20 shows a simplified example of a recommendation matrix for the selection of analysis
activities. For an actual project, it may be necessary to go into further detail, for example, theperformance of a LORA can be divided up in more categories such as simplified LORA or full
LORA with the help of a special software package. Additionally, the rating values can be moredetailed.
The creation of the rating method should only be done by very experienced personnel in orderto ensure that the result of the recommendation sheet for analysis activities selection is reliable
and sensible.

7.6

Analysis workflow processes
In the different project phases, different sets of information are available for the execution of thelogistic analysis activities. Some of the tasks described in the paragraph above can typically be
addressed during an early phase of the project. Some of the tasks can be executed at a stage
in which detailed and final information concerning the design are available (eg an extensive

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 65

S3000L-B6865-03000-00

SMA can be done during a late stage of design, because a lot of detailed information is required
for this type of analysis).

Early phases
Conception
phase

Design & development
phase

Risk reduction
phase

Production
andintroduction
phase

In-service phase

Waste
disposal
phase

TIME
Final
logistic
analysis
tasks

First
logistic
analysistasks
Analysis for
identification ofgeneral LSA
needs

Disposal
analysis

Iterative
LSA / ILS
process

Comparative
analysis
Human factor
analysis
Operations
analysis
Configurationassessment

Detailed logistic analysis tasks- Configuration assessment- Reliability analysis assessment- Maintainability analysis- Testability analysis- LSA FMEA (Logistic FMEA)- Damage analysis- Special event analysis- Scheduled Maintenance Analysis (SMA)- Level of Repair Analysis (LORA)- Maintenance Task Analysis (MTA)- Software Support Analysis (SSA)- Operations analysis- Training Needs Analysis (TNA)ICN-B6865-S3000L0020-002-01
Fig 21 Position of LSA in the overall project schedule
Logistic analysis requirements do not end at the end of a design & development phase. Within
the next phase (production and introduction), logistic analysis can be required multiple times,
depending on the modifications being made to the product.
This is especially relevant for the inservice phase, which is normally the longest phase. There
will be extensive modifications during the inservice phase and, depending on the modification,
logistic analysis will be necessary again in corresponding depth. Therefore, the iterative
LSA/ILS process will reappear repeatedly. For this reason, it is recommended that the
documentation of logistic data and logistic decisions is continued throughout the entire project,ending with the disposal phase. Even for this final phase, logistic aspects must be considered.
The next paragraphs give a general impression on how the different analysis activities can be
typically assigned to the project phases.
7.6.1

Early phase analysis activities
In the early phase of a project, the logistic analysis activities can be limited to the ones that only
require a rather low level of information. Before the LSA GC, information about the operationaland customer requirements is normally available and drafts for basic rules of the LSA process
are prepared.
Detailed information of the SUA or the IUA is not normally available. Only basic conditions andrules for the application of the process should be available in the early stages, nevertheless,some analysis activities can, or even should, start in the early stages of the LSA process:−Analysis for identification of general LSA needs

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 66

S3000L-B6865-03000-00

−
−
−
−
7.6.2

Comparative analysis
Human factor analysis
Operations analysis
Configuration assessment

Design freeze analysis activities
During the Design & Development phase, the LSA process should accompany the design
process. This fits for almost all LSA activities with the exception of those activities that shouldbe performed in a very early phase or after a design freeze. The following activities should
accompany the design & development phase:
−
−
−
−
−
−
−
−
−
−
−
−
−

Configuration assessment
Reliability analysis assessment
Maintainability analysis
Testability analysis
LSA FMEA (logistic FMEA)
Damage analysis
Special event analysis
SMA - Scheduled Maintenance Analysis (S4000M, MSG-3, RCM)
LORA - Level of Repair Analysis
MTA - Maintenance Task Analysis
Software and data uploading/downloading/transportation analysis
SSA - Software Support Analysis (software design and software maintenance)
Operations analysis

After design freeze, the collection of logistic relevant data should be mostly complete. For thisreason, analysis activities that need a lot of detailed data should be performed at a late stage ofthe design process in order to guarantee a fixed design and to reduce the risk of repeating
costly analysis activities. This applies for:−−

Simulation operational scenarios
TNA

7.6.3

Inservice phase analysis activities
During the inservice phase, the logistic analysis activities will repeat, but to a lesser extent. If
the product has technical upgrades or design changes, a new analysis concerning logistic
requirements should be performed. The depth and extent of this analysis will depend on thetype of system and the scale of change.

8

Customer involvement
In order to avoid negative consequences of misunderstandings between the contractor and thecustomer, the customer shall be involved in the industry interpretations and approaches in an
appropriate depth during the whole LSA program. The customer involvement with regards to theselection of LSA candidates, relevant analysis activities and resulting analysis data shall becovered as well as the principles of information exchange, documentation of results and related
management aspects.

8.1

Customer assessment of candidate items and recommended analysis
activities
The selection of LSA candidates in conjunction with the allocation of appropriate analysis
activities must be considered as the most cost influencing for a LSA process. For that reason,these selections must be done and assessed with great care in an early program stage. In orderto reduce risk, an initial selection should be done prior to the signing of the contract
In general, the contractor must select the LSA candidates and related LSA relevant analysis
activities based on a product breakdown as detailed in Para 5 for establishing of breakdown,

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 67

S3000L-B6865-03000-00

Para 6 for LSA candidate selection, and Para 7 for recommended analysis activities. The resultmust be released to the customer for assessment.
Note
Since a list that only reflects the proposed LSA candidate items (CIL) would not provide aclear picture of what it is really intended, it is strongly recommended to assess both theproposed Candidate Items (CI) and the related analysis activities in order to find a wellbalanced decision.
8.1.1

Establishing LSA assessment rules
The assessment of proposals must be done under the customer's responsibility, and some
general rules concerning principles for assessment should be established, as a minimum, but
not limited to:
−
−
−
−
−
−
−
−
−
−
−

8.1.2
8.1.2.1

Only aspects that concern rules agreed to in the LSA GC or rules that may be agreed to
between the customer and the contractor within the subsequent LSA process (eg in LSA
reviews), must be considered as assessment relevant.
If an assessment has been performed and has reached a successful final clarification, it
must not be reassessed unless new assessment relevant aspects occur.
Only rules that have been established within the area of the LSA community must be
considered as assessment relevant.
Other communities (eg technical documentation, materiel support, and training) are notallowed to establish or define subjects with relevance for the LSA assessment.
A change in the customer's staff is not to be considered as assessment relevant and mustnot be accepted by the contractor as a reason for any reassessment.
Rules concerning time limits between the release of LSA deliveries and an adequate
response should be established and agreed upon, along with the consequences of nonfulfillment.
Both the invitation for assessment of details within the contractor's LSA deliverables as wellas the assessment result should be indicated using applicable codes within a "status code".
The structure, details of information and individual codes to be used are the responsibility of
the contractor but must be coordinated with the customer.
The LSA review structure should be organized in line with the information grouprepresented by the status code.
An appropriate data element within the logistic database should be established for “statuscode”.
The status code concerning each LSA candidate must be kept updated as applicable in thelogistic database.

Initial assessment and re-assessments
Initial assessment
During the initial assessment, primarily the principles have to be considered such as:
−
−
−
−
−

Is the product breakdown considered to be in line with the rules established during the LSA
GC, eg especially concerning its structure, content and depth?
Are rules for selection of LSA candidates and for non selection or non recommendation
available and sufficient?
Is the selection of LSA candidates and relevant analysis activities selection in line with rules
established within the LSA GC?
Assessment results must be documented and passed to the contractor according to theestablished assessment procedure and followed until a final clarification status is reached.
Once assessed and commented upon and final clarification is reached between thecustomer and the contractor, those principles must not re-assessed or re-discussed forlater assessments.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 68

S3000L-B6865-03000-00

8.1.2.2

Re-assessments
Assessments subsequent to the initial assessment must concentrate on aspects such as:
−
−
−
−
−

Items released by the contractor designated for assessment
Assessment of contractor deliveries concerning general questions or comments (newaspects)
Assessment of contractor deliveries concerning detailed questions or comments(observations)
Assessment of contractor deliveries concerning details such as like discrepancies with prioragreements
Assessment results must be documented and passed to the contractor according to theestablished detailed assessment procedure and followed until a final clarification status isreached.

8.1.3

Establishing an assessment procedure
A detailed assessment procedure (including an appropriate commenting process) shall beestablished that is tailored to the specific requirements of the individual LSA program andcomprises the above elements. This procedure should be harmonized between the customer
and contractor.

8.2

Information exchange between customer and contractor
The customer should inform the contractor about the individual assessment results that are
relevant in order to proceed with the LSA process, mainly on agreements/disagreements
together with the reasons for any disagreement. In addition, general comments covering global
aspects and/or general questions may occur. Those comments and questions should be kept
separate from the other comments as they usually need a special response such as a dedicatedexplanation or request for special training.
The content of this paragraph is not limited to LSA candidates and related analysis activities,
but it also applies to detailed results of the analysis and to a response on any official LSA
report.

8.2.1

Commenting process
A structured commenting process should be established in order to ease the management ofcomments and to enable traceability.
−−−

Any LSA delivery from the contractor to the customer released for assessment shall be
registered and officially commented upon.
Any customer agreement must be documented carefully.
Any customer disagreement must be documented along with the related reasons. Affected
items must be monitored until final clarification has been reached and the clarification is
documented.

In order to cover these subjects, the commenting process shall be detailed as follows.
8.2.1.1

Registration of LSA deliverables
Any LSA delivery that needs assessment shall be registered according to rules and files thathave been agreed to and established as part of the LSA/ILS management structure.

8.2.1.2

Registration of comments
For each LSA delivery released for assessment, the customer response must be documented.
For that reason, a status must be registered for each applicable BE depending on theconsequences of the customer response.

8.2.1.3

Registration of the LSA status
The LSA status code should be structured in order to belong to different information
requirements per released BE (refer to Para 9.4)

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 69

S3000L-B6865-03000-00

8.2.2

Informing the contractor by the customer
The customer informs the contractor as agreed in the established commenting process about:−Agreements concerning released LSA deliverables: This will be documented by thecontractor according to established management rules. In the case of a consortium, allcompanies involved in the contractor network must be informed according to related rules.
Disagreements concerning released LSA deliverables: In these cases, the response will be
investigated by the contractor (or the involved company) in order to identify an adequate
response (eg further explanation, proposed rework by industry). The contractor's response
will be forwarded to the customer in order to reach an agreement in an iterative manner.
When issues remain open and cannot be resolved by iterative commenting, an adequate
solution must be identified in order to reach a final clarification.

−−

CONTRACTOR

Remainingcustomer´scomments to be
discussed in LSA
Review(First) answers ofcontractor forclarification

limited numberof iterations

Customer´scommentation
process

LSA REVIEW- final decisions for status updating

Delivery of
Customer´scomments inestablished format- final clarification of open issues (if possible)

Delivery of LSA
Data, Analysis
Reports, CIL, etc.

Preparation for
final clarification ofopen issues
during LSA
Review

Evaluation ofcustomer´scomments by thecontractor(s)Preparation of
LSA delivery tocustomer(integration andharmonization ofdata, if required)

Evaluation of (first) answers ofcontractor by the customer

CUSTOMER

To

T1

T2

T3

T4

TReview(time)

ICN-B6865-S3000L0021-002-01
Fig 22 Process of information exchange between customer and contractor (example)
Table 20 Explanation of time schedule of the commenting process
Time

ActionsTo

The start of the preparation of the LSA delivery items by the contractor. Thispreparation can include the integration and harmonization of data between morethan one contractor in case of a contractor consortium.

T1

Delivery of the contractual LSA delivery items to the customer in the agreed
format.

T2

Between T2 and T1 the commenting of the customer on the delivered items (egLSA data, LSA reports) will take place. At the agreed point of time T2 the deliveryof the comments to the contractor will take place.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 70

S3000L-B6865-03000-00

Time

Actions

T3

To reduce the effort of the LSA review, any type of comments that can be
answered easily by the contractor should be handled before the LSA review, if
possible. Nevertheless, any decision concerning the customer's comments must
be documented carefully.
During this time, more than one question-answer loop can clarify special
questions in detail, however, the number of loops should be limited since more
extensive questions must be clarified (eg at the LSA review or by a longer
clarification process between the contractor and customer).

8.3

T4

Taking into account the clarification loops between the customer and thecontractor in the time between T2 and T4, the remaining customer comments will
be delivered to the contractor. These comments will be the basis for any
discussions and clarifications in the LSA review.

TReview

Time of LSA review. It must be ensured that every decision in the LSA review isdocumented in an update of corresponding status information.

Final clarification on open issues
For any remaining open issues, an adequate solution must be identified. If this is not possible
during a regular review session, a meeting of dedicated specialists could be required to reach asatisfactory solution.

8.4

Customer decision (status influencing)
Normally, it is required to distribute a LSA delivery for assessment to different places (egdifferent authorities in different nations and, since LSA is to be understood as inter-disciplinary,to all involved logistics communities). Subsequently, individual comments must be collected and(in case of deviating responses) be harmonized in order to provide one official customer
response.
Note
It is important for the contractor to receive only one official customer response in order toproceed with the LSA process in a manageable way. It is recommended to receive thecustomer's decisions as a status code change (following the rules established for status
code allocation).
The status code allocated by the customer remains unchanged in the related customer release.
Any related explanation (eg reason for disagreement) also must be documented as part of thecontractor response and remain untouched for traceability reasons.
For LSA program traceability reasons, both, the LSA delivered as proposed for assessment, as
well as the customer's response (if applicable including final clarification results), may be
documented as:−−

LSA recommendation document delivered by the contractor, andLSA decision document responded to by the customer

Especially in the case of essential documents such as LORA or SMA results, the resulting
recommendation/decision documents may ease some clarification requirements.
Within the contractor's LSA database, corresponding status codes concerning the involved
breakdown elements must be updated accordingly. However, contractor's information may
supersede the status code as allocated by the customer (eg on-going work status, requireddeletions).

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 71

S3000L-B6865-03000-00

8.5

Exchange of analysis data with the customer
In general, the following steps must be applied:

8.5.1

Establishment of appropriate rules for data and document exchange with the customer
Appropriate agreements and rules must be documented and agreed to, by the customer and thecontractor in the LSA GC and the subsequent LSA agreements, for example:
−
−
−
−
−

Software to be used
Data and report formats (eg DEX-format)
Periodicity
Other reasons for delivery
Distribution partners and sequences to be obliged

8.5.2

LSA data and document collection by the contractor− Establishment of an appropriate data/document exchange and file network within industry− Collection of data/documents for intended delivery between associated companies and LSA
related disciplines− Performance of industry internal quality checks, harmonization and agreement for delivery

8.5.3

Delivery of LSA data/documents by the contractor− Distribution of the LSA deliverable (directly or via a designated management unit) by taking
into account the agreed distribution rules (as well as the due date, if applicable)− Contractor internal documentation and distribution of the official LSA delivery.

8.5.4

Customer assessment and distribution of assessment results− Distribution of the contractor's LSA delivery, as required− Harmonization of the individual responses to the official customer response− Distribution of the customer response to the contractor

8.5.5

Distribution of customer response by the contractor− Registration of the official customer response− Industry internal distribution− Identify, distribute and harmonize the contractor investigation results− Update of the LSA database according to the customer response details (as much as
possible)− Preparation of harmonized contractor response to general comments and disagreements

8.5.6

Distribution of the contractor response concerning disagreed comments
Steps concerning iterated analysis data from the contractor as described in Para 8.5.3.

9

LSA review conference
A LSA Review Conference (LSA RC) should be planned with the participation of contractor andcustomer personnel in order to:
−
−
−
−
−

9.1

reach final clarification of open issues
reach customer acceptance on open issues
monitor the status of LSA candidate items, eg concerning completion and quality
assess logistic support aspects related to each phase of the processreach additional agreements between the customer and the contractor concerning LSA
aspects in order to improve the LSA process, as required

LSA review process overview
The LSA RC shall be conducted at LSA candidate level. Prior to the conference, the contractor
shall inform the customer about the LSA candidates to be discussed.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 72

S3000L-B6865-03000-00

During the LSA RC, the related LSA deliveries and the relevant data elements shall beassessed and decided upon by taking into account established acceptance criteria. Any
decisions must be documented.
Complex LSA candidate items may require a sequence of analysis activities, which may be
distributed over a long period of time, depending on the type of information that is available
within different program stages. On the other hand, some decisions must be made in a very
early program stage based on limited information (eg establishment of an preliminary
maintenance concept) while other decisions require a stable design that is not typically available
until a very late stage (eg identification of scheduled maintenance tasks based on time
consuming, excessive analysis like MSG-3). For this reason, different review steps must be
established in order to enable sequenced decisions in line with the structured analysis process.
Therefore, the overall review process must be divided into different review steps, eachcomprising coherent information. These review steps shall be identified by review step
indicators (refer to Para 9.3). It should be defined which data elements must be available for ormust be assessed during the individual review steps. Each LSA RC should cover any steps thatbelong to the individual LSA candidates being requested for assessment which will be indicatedby according status codes.
Due to the iterative nature of any LSA process, any approval given during a review conference
must be considered as a temporary assessment but it must allow the contractor to continue with
the LSA process. As a consequence of the iterative nature of LSA, the data may be reexamined due to changes in the design, the updating of technical data and/or the support oroperational environment.
The final results to be documented in the LSA documents and/or within the LSA database, eg at
the end of each program phase, must be considered as frozen. Related acceptance criteria
must be agreed to in the LSA GC.
The LSA RC should be held in accordance with the evolving design and the progress of theintended analysis activities and they should take place regularly within an agreed period in timeor depending on the amount of information to be assessed. Minutes of each LSA RC must be
prepared to show the results and to give evidence of the necessary actions for the customer
and the contractor. The updating of related LSA documents and/or the LSA database inaccordance with the results of a LSA RC must be considered a permanent action.

9.2

Subject to be reviewed
In general, any contractual item agreed to during a LSA GC, or by subsequent agreements
between the customer and the contractor must be reviewed within a LSA RC. In addition, any
aspect that can be identified as essential for the LSA process or that may influence otherlogistic processes with interfaces to the established LSA program may be discussed within a
LSA RC in order to agree on modified or additional LSA tasks. Highly unlikely occurrences
within the LSA process that require common assessment in order to correct any essential
problem should be coordinated between the customer and the contractor.
Introductions into procedures and/or principles of LSA relevant analysis required should bepresented by the contractor to the customer in order to reach a common understanding
concerning the goal of analysis activities, related restrictions and essential LSA results. This
includes the introduction into global analysis work flowcharts.
Progress reports and data quality assessment summaries should also be provided by thecontractor, as well as summary reports reflecting items of special interest for the customer.
Some examples include:−−

Maintainability values such as mean man-hours per operating hour
Logistic performance parameter such as Mean Elapsed Time (MET) for maintenance tasks
that occurred within specified limits, along with the related percentage

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 73

S3000L-B6865-03000-00

9.3

Examples for review structuring
The following examples provide an idea of how a typical review process may be structured.
Different aspects and/or types of information at different stages of the overall analysis process
will be covered in this way. The following steps can be arranged as required by a project torealize LSA data release and acceptance within the LSA review process.

9.3.1

LSA review step - CIL and maintenance analysis allocation
This step forms the basis for all subsequent LSA tasks documented within the LSA databaseand consists of:−−

BEI and LSA candidate selection (including grouping of candidates, where applicable)
Identification of the type of candidate and related attributes, such as:
•
•
•
•

−
−
−

9.3.2

Identification of LRUs
Potential cost drivers
Potential maintenance drivers
Potential readiness drivers

Allocation of LSA relevant analysis activities to be performed for each selected candidate
Status code reflecting details
Any updates regarding changes in the design configuration at the candidate item level must
be managed in the LSA database

LSA review step - LORA results and maintenance concept information
In this step the (preliminary) maintenance concept will be prepared by allocating maintenancetasks to their related maintenance levels and performance sites. This task typically includes:−−

Maintenance concept recommendation proposed by the contractor.
Identification of maintenance tasks relevant for equipment integration into the product, such
as:
•
•
•

−
−

Gain and undo accessRemove and install equipment
Performance of functional tests at equipment and system level, as required

Substantiation concerning the proposed maintenance concept as required (eg LORA
results, applied method or procedure, main influencing aspects to be considered, otheranalysis being applied or assessed for LORA constitution).
Customer decision on the maintenance concept (rejection or alternative solution)

9.3.3

LSA review step - LSA FMEA and SMA results
In this step, the maintenance concept shall be finalized by taking into account the LSA FMEA(eg constituted from technical FMECA by the grouping of failures focused on the intended
maintenance tasks) for the identification of unscheduled maintenance tasks. Results from SMA
will identify scheduled maintenance tasks.

9.3.4

LSA review step - Maintenance Task Analysis (MTA)
In this step, the identified maintenance tasks will be analyzed concerning its requirements andits execution:−−−

Description of the required maintenance tasks in applicable detail and depth
Duration of each task step
Identification of related logistic resources required to support the maintenance activities (egpersonnel, support equipment, spare parts, consumables, facilities, data and software)

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 74

S3000L-B6865-03000-00

9.4

Status code examples
In order to reflect the status of each LSA candidate in detail concerning the identified review
steps, a status code should be used, which may consist of sub codes reflecting the following
information:−−−−

Responsibility of involved companies. For each task group, the responsible company
should be identified. This also reflects the agreed work share details concerning thissubject.
Type of LSA candidate (eg full, partial)
Important aspects (eg contains user loadable SW and/or data)
Review step indicator
Here, the analysis status of the addressed LSA candidates must be indicated concerning
the content of each review step (eg as described in Para 9.3).

The following table gives examples for potential codes and the corresponding meaning (foreach LSA candidate review step indicator):
Table 21 Examples for status codes

9.5

Code

Description

X

Review step content is in "working condition", assessment not requested

N

Review step is "not applicable" for the related LSA candidate

R

Review step content is requested for assessment and decision in the next LSA RC

A

Review step content is (temporarily) agreed to by the customer

B

Review step content was assessed and in principle (temporarily) agreed to by thecustomer. However, minor rework is expected prior to final acceptance. In terms ofcontractual status, a "B" can be treated like an "A".

O

Review step content was not agreed to by the customer and remains an open
issue

Depth of status code allocation
As a minimum requirement for each LSA candidate, relevant status codes should be allocated.
In addition, the subject of assessment may be addressed in more detail (eg the specific task of
the LSA candidate that was established/modified and needs to be assessed). This decisionmust be made during the LSA GC.

9.6

Functions of the status code
The status code shall reflect the review process structure and address all contractual issues
that have to be documented within the LSA database. It can be used for overall status summary
reports concerning the content of the LSA database, eg after each LSA RC to reflect the
progress in the area of LSA.
A LSA candidate list filtered by status code may be used to focus the customer's attention tothis specific subject.
The status code may also be used internally by the contractor in order to indicate to logistic
disciplines the "stop" or "go", respectively to indicate any risk when creating ILS products.

9.7

Status code definition at the LSA guidance conference
The intended review steps, as well as the related status code structure and applicable status
codes, must be proposed by the contractor and harmonized with the customer within the LSA
GC along with the depth (level of detail) of status code allocation.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 75

S3000L-B6865-03000-00

10

Starting point and management of the creation of the logistic
products

10.1

Starting point recommendations
The start point for the creation of the logistic products is dependent on several factors, including
technical documentation and illustrated parts data availability. Changes of design or
maintenance concepts can have also extensive influence on these products. In this context, ILS
products to be considered include:
−
−
−
−
−

10.1.1

Technical documentation
Materiel support (illustrated parts data)
General and special support equipment
Training
The facility construction is not considered a typical ILS product since the decisions forfacilities are made in an early phase of a project, because of the long qualifying time.

Technical documentation
In general, technical documentation consists of two main parts:−−

Handbooks for system repair and maintenanceHandbooks for system operation (user documentation)

During a design and development process, the supporting logistic analysis activities are
performed. Depending on the progress of these analysis activities, it becomes clearer which
maintenance concept will be the basis, which personnel, support equipment and spares are
required and how the task will be executed (task description). For this reason, technicaldocumentation concerning system repair and maintenance should start at a later point. The
better the information from the logistic analysis activities is, the less the risk for the creation of
the technical documentation remains.
Nevertheless, experience has shown, that creation of technical documentation must start earlybecause of time limitations and contractual preconditions. The basis for the creation of technicaldocumentation concerning system repair and maintenance is the maintenance task, which is
documented in the LSA database. It is recommended to find a proper solution to trigger thetechnical documentation to begin the creation of real products. This process must be
harmonized between the contractor’s support engineering and the technical documentation
departments. A good solution is to use status information for LSA candidates, or even formaintenance tasks, within the LSA database.
The general, the correlation between LSA and technical documentation can be seen in Fig 23.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 76

S3000L-B6865-03000-00

LSA database
Repair andmaintenance tasks

Operational tasks

Start of creation oftechnical
documentation
triggered by LSA(e.g. by status of
BEI / task)

Handbooksforsystem repair
andmaintenanceStart of creation oftechnical
documentation
triggered by LSA(e.g. by status of
BEI / task)

Operational
analysis

Handbooksforsystem operation

ICN-B6865-S3000L0022-002-01
Fig 23 Correlation between LSA and technical documentation
Generally, the creation of the handbooks for product operation is independent from the LSA
process. It must be guaranteed by the technical documentation department that this part of
documentation is available early enough to operate, for example, a prototype of a technicalsystem safely for testing and qualification needs. A special aspect is the consideration of
information from the operational analysis activities. The tasks described and documented in the
LSA database in this area can be part of both the handbooks for product repair andmaintenance, and the handbooks for product operation. In this case, the recommendations forthe repair and maintenance documentation are also valid for the results of operational analysis.
It must be clear that each repair or maintenance task identified and documented in the LSA
database must have its corresponding part of technical documentation in the handbooks for
product repair and maintenance.
Nevertheless, the handbooks for system repair and maintenance can contain information
beyond the documented LSA tasks, because in general it is not possible to include each single
maintenance action within the LSA database (eg because of budgetary reasons). Not every
piece part will be a LSA candidate. The purpose of LSA should be to analyze, in depth, the true
maintenance and cost drivers. The remaining equipment or piece parts that require technicaldocumentation must also be considered. The depth and the extent of this additional technicaldocumentation should be clarified between the contractor and the customer within the Guidance
Conference technical documentation.
To guarantee a meaningful information flow between LSA and technical documentation, it isrecommended to establish a process to forward the status of work of LSA to the technicaldocumentation department on a regular basis. In this way, technical documentation can find all
relevant information needed to start production. The following aspects should be covered:−−Is the relevant maintenance task ready for technical documentation?
If the status of the LSA task indicates: "Not ready for technical documentation", what risk
could be taken to start the production of technical documentation anyway?

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 77

S3000L-B6865-03000-00−−

10.1.2Is there a blocking status in LSA, which permits the start the production of technicaldocumentation?
Which additional activities must be documented within technical documentation, which are
not a part of the LSA database (no trigger from LSA for those aspects)?

Materiel support
The identification of relevant spare parts is a main task within the LSA process. The depth of the
breakdown and the extent of analysis activities will be reflected in the identification of spareparts. Depending on the maintenance concept, identification of spare parts can differ drastically.
For example, in a simple 2-level maintenance scenario, complete components will be replaced
and no repair activities will be performed by the operator of the system. In this case, only asmall number of spare parts will be identified. However, additional spare parts such as standard
parts, could be identified that are additionally required by the identified complete components.
The decisive question is the depth of the breakdown within the LSA. Theoretically, a breakdown
down to the last piece part is possible, but the effort would be irresponsible. Therefore, inpractice, the identification of spare parts within the LSA process will stop at a certain level.
Typically, the maintenance drivers and the cost drivers should be identified within the LSA
process. This information is documented within the requirements of maintenance tasks in the
LSA database. A similar process as described for technical documentation should also beestablished for materiel support. Depending on the progress of the logistic analysis activities,
the start of the creation of the logistic products concerning materiel support should be triggeredby LSA relevant maintenance drivers and cost drivers.
Similar to technical documentation, it should be clear that not all required spare parts will beidentified by LSA. However, all spare parts identified by a LSA task must be considered withinmateriel support. The following table gives an overview of the different types of spares and theirconsideration in the identification process.
Table 22 List of different spare part types identified by LSA
Spare parttype

Description

Correlation between LSA andmateriel support

Completepiece ofequipment- Maintenance driver- Cost driver

Identification of the equipment asa required spare part should beapproved by a maintenance task
defined within the LSA.

Required spare parts for replace tasks(scheduled or unscheduled) at operatorsite (replacement of complete equipment
without any repair at operator site)

Dedicatedspare parts

Required spare parts for equipment repair
or maintenance tasks at operator site
(repair of the equipment will be performedat operator site)

Identification of this component asa required spare part should beapproved by a maintenance task
defined within the LSA.

Standard
parts

Required standard parts (eg attachingparts or seals) for repair or maintenancetasks at operator site (repair of theequipment will be performed at operator
site)

Identification of this component asa required spare part should beapproved by materiel support
because of missing depth ofbreakdown within the LSA.

Consumables Required consumables such as liquids,
grease, special chemical products, source
material, glue.

Applicable to: All

Identification of this component asa required spare part can beapproved by materiel support orby LSA.

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 78

S3000L-B6865-03000-00

The process to begin the preparation of illustrated parts data within materiel support is shown in
Fig 24:Illustrated parts data

LSA database
Repair andmaintenance tasks

Operational tasks

Start of creation ofmaterial support
products triggeredby LSA(e.g. by status of
BEI / task)

Start of creation ofmaterial support
products triggeredby LSA(e.g. by status of
BEI / task)• Spare parts andconsumables identified
by LSA• Additional spare parts• Additional consumables• Other additional
information like support
equipment andcorresponding spareparts

Operational
analysis

ICN-B6865-S3000L0023-002-01
Fig 24 Correlation between LSA and materiel support
10.1.3

Common and special support/test equipment
The identification of relevant support and test equipment is a main task within the LSA process.
The timely provisioning with required support/test equipment is of crucial importance and it
should be distinguished between common and special support/test equipment. Especiallyrequirements for special support/test equipment should be identified by the LSA process. Afterthe identification, a development or procuring process should begin.
Each item of support and test equipment that was identified by the LSA as a requirement must
be a part of a development or a procurement process. The responsible department for support
and test equipment should be triggered by status information from the LSA. Nevertheless,requirements for support/test equipment can also be derived from sources other than the
documented LSA tasks (especially for common tools, eg a simple screwdriver need not be
identified by a special LSA task).

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 79

S3000L-B6865-03000-00

LSA database
Repair andmaintenance tasks

Operational tasks

Start ofdevelopment /procurement
triggered by LSA(e.g. by status of
BEI / task)

Start ofdevelopment /procurement
triggered by LSA(e.g. by status of
BEI / task)

Common and special
support/test
equipment• Support and test
equipment database• Support and test
equipment development
process• Support and test
equipment procurement
process

Operational
analysis

ICN-B6865-S3000L0024-001-01
Fig 25 Correlation between LSA and support/test equipment
10.1.4Training
The training area must be specially considered. Training needs concerning maintenanceactivities cannot be identified until complete information concerning the required maintenancetasks is available (eg details of performance, required support equipment, difficulty andcriticality, duration, number of working steps, required personnel). The first step in identifying
training requirements should be a Training Needs Analysis (TNA). This can be based on themaintenance tasks identified by the LSA. To help identify the best starting point for training
activities, status information should be introduced. Additional information should be taken fromthe technical documentation in order to support the identification of training needs that are notdocumented in LSA, and to support the creation of training documents in general.
The process to identify and create training should be harmonized with the customer through anagreement concerning LSA and/or technical documentation that is available. The creation oftraining equipment can be very cost intensive (eg production of training videos, training rigs,
training simulators). For this reason, decisions concerning training should be based on
information that is reliable.
For the best possible support, it is recommended to document training information that is within
the LSA database. The LSA database can contain simple markers such as "training required",skill levels for personnel or more detailed information, if available. In addition to these data
elements, all possible IT support is recommended to be used to translate training requirements
into corresponding queries within the LSA database system.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 80

S3000L-B6865-03000-00

LSA database
Repair andmaintenance tasks

Operational tasks

Training
products

Start of training
activities triggeredby LSA(e.g. by status of
BEI / task)

Training
Needs
Analysis• Training documents• Training rigs
• Training simulators

Operational
analysis

ICN-B6865-S3000L0025-001-01
Fig 26 Correlation between LSA and training

10.2

Management of the creation of the logistic products
One central challenge within the development or introduction of a new product is thecoordination of the product support activities. Especially in case of a new development, thecreation of the ILS products is complex. For this reason, it must be ensured that the
management of this creation process works properly. It is recommended for ILS managers to
use LSA information and the LSA database as a central management tool for the entire ILS
process. The following aspects must be considered by the contractor:−−

Timely creation of the ILS products must be supported by LSA status information.
Triggering the logistic disciplines should be carried out by the support engineering
department to ensure a proper start.
Creating unnecessary effort in any logistic discipline must be avoided, such as:••••

Creation of technical documentation for maintenance actions that are never performedat the customer operational site.
Documentation or provisioning of spare parts or consumables that are never requiredat the customer operational site.
Beginning the development or procurement of support/test equipment that are neverrequired at the customer operational site.
Planning training for maintenance tasks which are never performed at customer
operational site.

A permanent quality check of the content of the logistic disciplines against the content of the
LSA database is recommended to avoid effects described in the list above.

10.3

Influence of modifications on logistic products
Design modifications that are relevant for any logistic analysis activity and are relevant for the
ILS disciplines must be considered carefully. Logistic disciplines must be triggered in case ofchanges in the LSA database and, of course must be triggered in case of design changes withno connected information within the LSA database. The ILS process, as a common process

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 81

S3000L-B6865-03000-00

from the design to the logistic products, must be carefully managed. It is recommended toestablish a strategy for every project phase, on how to manage modifications. Experience
shows that even in the design & development phase, many of modifications will have an effecton the entire project. Also, in later phases of the project, modification management for thelogistic support products is of vital importance for both the customer and the contractor.

Influence ofdesignmodifications
on logistic
analysis tasks

DESIGN

modification

INFLUENCE

causes:TRIGGER

Logistic disciplines

Change ofmaintenanceconcept
modification• Technicaldocumentation

Change ofcontent of LSA
database• Materiel support• General and special
support equipment• Training

modification

TRIGGER

modification

Influence of design modifications on
logisitic disciplines without
documentation within LSA database…………..
ICN-B6865-S3000L0026-001-01
Fig 27 Influence of design modifications on logistic disciplines in general

11

Checklists

11.1

Detailed checklist for the creation of an ORD
To support logisticians in creating a complete ORD, the following checklist with a number ofdetailed questions should be used. Nevertheless, it must be clear that special project aspects
should be taken into consideration in addition to this list.
Table 23 Checklist of detailed questions to support the ORD creation

Detailed ORD questions

Answer/Action

General usage scenario
Which usage areas or which mission areas are expected?

Describe usage areas

Is the normal usage of the product the only scenario?

Yes/No?

Are there special usage scenarios, which must be taken into
consideration?

Yes/No?
If yes, describe special usage
scenarios in detail

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 82

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

Is a permanent usage expected?

Yes/No?
If yes, describe in detailIs an out of area usage under rough conditions expected?

Yes/No?
If yes, describe in detailIs there any influence on the environment expected from noise from theusage or the maintenance of the product?

Yes/No?
If yes, describe in detailIs there any influence on the environment expected by pollution from theusage or the maintenance of the product?

Yes/No?
If yes, describe in detailIs there any other influence on the environment expected from the usageor the maintenance of the product?

Yes/No?
If yes, describe in detail

Are there any actions necessary to avoid negative influence on theenvironment such as noise or pollution?

Yes/No?
If yes, describe in detail

Are there any problems with the currently used product concerning
performance?

Yes/No?
If yes, describe problems

Are there any problems with the currently used product concerning
maintenance?

Yes/No?
If yes, describe problems

Are there any problems with the currently used product concerning
supportability?

Yes/No?
If yes, describe problems

Is the system used in combination with other existing products (generally
or only sometimes)?

Yes/No?
If yes, describe interaction

Is the usage of the product dependent on other existing products?

Yes/No?
If yes, describe dependence

Is the product itself transportable?

Yes/No?

How long does it take to prepare the system for transportation?

Duration

Does transportation require a special conservation and packaging?

Yes/No?
If yes, describe in detail

Define transportability requirements (mode, type, quantity, distance,
duration of transport)

Define details

Which requirements concerning support equipment and personnel exist
for the preparation of the product for transport?

Define details

What is the maximum time to reset the product to full capability after
transportation?

Define duration

Which requirements concerning support equipment and personnel exist
for the rest of the product to full capability after transportation?

Define details

What else must be transported (eg support equipment, spares,
personnel) for the proper operation of the system at the destination andwhat are the requirements for these additional transportation actions.

Define details

Deployment of locations and special conditions of every location
How many operating locations exist?

Applicable to: All

Number

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 83

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

Is there an international or even an intercontinental distribution of theoperational locations?

Yes/No?

What are the distances between the operating locations?

Map, distances

What are the distances between the operating locations and the required
industry and/or contractor facilities?

Map, distances

Define the type of each location:

Define details

Is the location land based?
Is the location ship based or sea based?
Is the location based in a mountain region?
Is the location a depot with maintenance abilities?
Is the location a home base or an offshore location for the system?
Is the location a training base equipped with training facilities?
Define the special conditions at each location:

Define details

Are there extreme sandy or dusty conditions?
Is there a salty atmosphere because of location?
Are there extreme hot or cold weather conditions?
Are there other extreme stress conditions at special locations?
Are there limitations due to special regulations/laws at special
locations?
Are there special storage requirements due to extreme weather
conditions at special locations?
In a wartime scenario, are there special locations that would preclude
contractor maintenance? (maintenance and repairs in wartime
environment cannot easily be performed by contractors)

Yes/No?

Are there special threat situations that might require a special emergency Yes/No?
maintenance concept limited to a minimum of intervention?
Is there sufficient infrastructure available to reach all locations (eg toguarantee proper supply of spare parts or consumables)

Define details

Quality and existence of roads
Airport (local or international) nearby
Connection to railway stations
Connection to inland or sea ports
Are there special infrastructural requirements for reaching a location?

Yes/No?
If yes, define details

What are the existing capabilities of each location concerning support
equipment?

Define details

What are the existing capabilities of each location concerning
infrastructure and facilities?

Define details

What are the existing capabilities of each location concerning personnel?

Define details

What are the planned capabilities of each location concerning support
equipment?

Define details

What are the planned capabilities of each location concerning
infrastructure and facilities?

Define details

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 84

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

What are the planned capabilities of each location concerning personnel? Define details
Is it planned to establish a repair station at special locations?

Yes/No?

Is it planned to establish a supply depot at special locations?

Yes/No?

Is it planned to share abilities between different locations (exchange of
support equipment or personnel)

Yes/No?

Products (systems) supported and product (system) deployment
How many supported products are planned per location?

Define details

Deployment of products (end items) per location

Define details

Is it planned to share products (end items) between different locations?

Define details

Detailed usage overview
What will be the normal usage of the product at every location (keyusage)?

Define details

What is the planned availability of the product at each operating location? Define details
When the product is used in missions, what are the planned mission
success rates for each operating location?

Define details

Are there any periods of special usage of the products at a special
location?

Define details

low payload period
temporary peak loads
temporary storage of the productout of area usage under special or rough conditions
wartime usage
In the case of permanent operational conditions, what are the possible
down times for maintenance (maintenance windows)?

Define time periods formaintenanceDefine additional system performance parameters in measurable
quantifiable terms such as:

Define detailed values

range of usage
required accuracy
payload values
required temperatures
required speed
required distances
What is the key measurement base of usage per unit of time? Examples
can be the following:

Define detailed values

Operational hours for general products
Flight hours for airborne products (aircrafts, helicopters)
Kilometers or miles for land based vehicles
Rounds or cycles for periodic processes in a productTons for transportation systems

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 85

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

What operational profile is expected at each location?

Define a operational profile asdetailed as possible

How many operating hours or missions are planned per day?
Are there different typical usage days, define the operating profile foreach "day type".
What are the typical operational profiles for longer ranges such as weeks,months or entire years?
How many operating days/operating hours are expected for a year or for
any other basic time period?

Define detailed values

What is the average duration of each different usage (eg operation,
mission, trip, flight, dive)Define detailed values

11.2

Detailed checklist for the creation of an CRD
To support logisticians to create a complete CRD, the following checklist with a number ofdetailed questions should be used. Nevertheless, it must be clear that special project aspects
should be taken into consideration in addition to this list.
Table 24 Checklist of detailed questions to support the CRD creation

Detailed CRD questions

Answer/Action

Supply concept
Are central depots expected, and how is the deployment planned?

Define details

Are depots planned directly at the operational locations?

Yes/No?

Is a material exchange between different locations expected?

Yes/No?

Is a selection process for suppliers defined and how is it planned tointegrate suppliers into the expected supply concept?

Define details

Is it possible for a production line to provide spare part support (especially Yes/No?
at early stages)?
Is an outsourcing concept via a support agency expected?

Yes/No?

What are the limitations for spare part availability and lead times?

Define details

What distribution systems and IT-system shall be used for spare part
supply?

Define details

Which concept shall be used for initial provisioning?
Is it expected to use an optimization or a simulation tool?
Is the deployment schedule properly supported by the initial sparesdelivery?

Define details

Will spare part delivery impact the production schedule?

Yes/No?

Will the industrial base be obligated to provide spares support in the outyears for items that remain in the inventory?

Yes/No?

Support equipment concept
How can it be ensured that all support equipment is available in time?

Applicable to: All

Define details

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 86

S3000L-B6865-03000-00

Detailed CRD questions

Answer/Action

What is the identification and realization process for standard and special Define details
support equipment?
How effectively is automated test equipment being utilized to support the
product?

Define details

What is planned for maintenance and support of the support equipment
itself?

Define details

Repair and overhaul of support equipment
Calibration of support equipment
Personnel integration
What are the general requirements and provisions for manpower andpersonnel?

Define details

Are the products operated by the staff of the customer or by staff of thecontractor?

Define details

Should cooperative models be considered?

Yes/No?

How can it be ensured that the required operator training is verified ontime?

Define details

How can it be ensured that the required maintenance training is verified
on time?

Define details

What training processes should be developed to ensure adequate
operational and maintenance support at all levels during the entire life of
the system? The possible rapid turn-over of personnel should especiallybe considered.

Define details

Facilities
Which services must be available at the required facility (eg electrical
power, hydraulic power, compressed air, special working environment)

Define details

Are existing facilities at operational locations appropriate to therequirements of a new product (operational and maintenance facilities)?

Yes/No?

Can existing facilities at operational locations be adapted to therequirements of a new product (operational and maintenance facilities)?

Yes/No?

Is there a realistic time schedule available for the building of required new Yes/No?
facilities?
Define details
Is there a plan to identify and reduce risks caused by the delay of thebuilding of facilities?

Define details

IT and communication resources
Which IT architectures exists at every operational location concerning the Define details
following aspects:
Network capabilities
Data storage capabilities
Computer capabilities
Communication resources

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 87

S3000L-B6865-03000-00

Detailed CRD questions

Answer/Action

Are the existing IT and communication capabilities appropriate for the
new products to be introduced?

Yes/No?
Define details

Are there risks in connection with future changes in IT or communicationarchitecture concerning the operation of the new products?

Define details

Are there concepts for an initial provision with data for required IT
systems?

Define details

Who is the holder of the required data?
Are there contractual aspects to be considered?
Are there any problems concerning data security requirements?
Are there plans for a first installation of required new IT systems and forthe appropriate service of IT systems during the life of the product to besupported?

Yes/No?

Are there service contracts for hardware and software (planned andexisting)?

Yes/No?

Fast reaction to downtime must be ensured.
Upgrade of hardware and software in case of technical progress should
be included in the agreements of a service contract.
Are different IT systems at different operational locations compatible?

Yes/No?

Is there a plan to ensure the existence of all required interfaces to otherIT systems?

Yes/No?

New organizational structures
Will any organizational structures be changed at operational locations
and what are the risks of these changes?

Define details

What structure changing opportunities exist with the introduction of a new Define details
product (eg reduction of personnel)
Schedule consideration
What are the plans for an appropriate participation of logistic disciplines in Define details
all phases of the program?
Are the logisticians involved in the program in a very early phase of the
program so they can influence basic decisions concerning design?

Yes/No?

Additional aspects
What additional aspects specific to the project are of high significance forthe logisticians?

11.3

Define details

Breakdown element identifier - structure examples
The following examples show how an effective product breakdown could be established. For
this purpose, examples from Para 5.2 are used and filled with the missing BEIs for eachbreakdown level and for each breakdown element. Additionally, examples of how to integrate
software items are part of this paragraph.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 88

S3000L-B6865-03000-00

11.3.1

Functional breakdown
The first example (Fig 28) shows a functional breakdown following a simple BEI syntax
structure. The top level item (root) can be a product containing a fuel system.
Fuel system
28

Fuel storage

Fuel distribution

Fuel injection

Control & indication

28-01

28-04

28-05

28-06

Tank
interconnection

Fuel transport toengineRefueling

28-04-01

28-04-02

28-04-03

Pressure
refueling

Gravityrefueling

28-04-03-01

28-04-03-02

ICN-B6865-S3000L0027-001-01
Fig 28 Functional breakdown, simple syntax with separators
Table 25 Listing of functional breakdown from Fig 28
BEI

Item nameItem type

28
28-01
28-04
28-04-01
28-04-02
28-04-03
28-04-03-01
28-04-03-02
28-05
28-06

Fuel system
Fuel storage
Fuel distribution
Tank interconnection
Fuel transport to engine
Refueling
Pressure refueling
Gravity refueling
Fuel injection
Control & indication

Main system
Function
Function
Subfunction
Subfunction
Subfunction
Sub subfunction
Sub subfunction
Function
Function

The second example (Fig 29) shows a functional breakdown with an extended BEI syntax
structure. The top level item (root) can be any vehicle or product containing a fuel system; thefirst function/system is the fuel system itself. The BEI includes information about the end item
itself (V125) and about the BEI type (F=functional). In this case, the fuel system is the first levelof the breakdown tree.
Note
For a common understanding, it should be noted that the end item within a tree should beconsidered as level zero, or in other words, as the level "root". The next level down from theroot should be the first breakdown level.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 89

S3000L-B6865-03000-00

Vehicle V1
V1

Fuel system
V1-F-28

Fuel storage

Fuel distribution

Fuel injection

Control & indication

V1-F-28-01

V1-F-28-04

V1-F-28-05

V1-F-28-06

Tank
interconnection

Fuel transport toengineRefueling

V1-F-28-04-01

V1-F-28-04-02

V1-F-28-04-03

Pressure
refueling

Gravityrefueling

V1-F-28-04-03-01

V1-F-28-04-03-02

ICN-B6865-S3000L0028-001-01
Fig 29 Functional breakdown, extended syntax with separators
Table 26 Listing of functional breakdown from Fig 29

11.3.2BEI

Item nameItem type

V1
V1-F-28
V1-F-28-01
V1-F-28-04
V1-F-28-04-01
V1-F-28-04-02
V1-F-28-04-03
V1-F-28-04-03-01
V1-F-28-04-03-02
V1-F-28-05
V1-F-28-06

Vehicle V1
Fuel system
Fuel storage
Fuel distribution
Tank interconnection
Fuel transport to engine
Refueling
Pressure refueling
Gravity refueling
Fuel injection
Control & indication

Product
Main system
Function
Function
Subfunction
Subfunction
Subfunction
Sub subfunction
Sub subfunction
Function
Function

Mixture of functional and physical breakdown
The next example (Fig 30) shows a typical mixture of a functional and a physical breakdown.
Within this breakdown, starting from the root level, the first breakdown levels are used forfunctional/system information. From a certain depth of breakdown downwards you will find real
physical equipment and parts. The functional information will be fixed inside the breakdown.
This means that a functional system can be identified by the first breakdown level of the BEI, afunctional subsystem can be identified by the second breakdown level and so on. Withincomplex products, systems can be of different size. For that reason normally an indenture level
where functional breakdown ends and physical breakdown starts cannot be fixed. It is
recommended to use existing SNS (eg chapters of the S1000D) for an adequate structuring of
the product under analysis.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 90

S3000L-B6865-03000-00

Physicalbreakdownelements

Product

Functional
breakdownelements

Fuel system
A1-28

Fuel distribution
A1-28-01

Fuel storage
A1-28-04

Internal storagetanks
A1-28-04-01

Fuel injection
A1-28-05

Control & indication
A1-28-06

Auxiliary storagetanks
A1-28-04-02

Tank 01, front left
A1-28-04-01-01

Tank 02, front rightA1-28-04-01-02

Tank 03, rear
A1-28-04-01-03

Rubber tank
A1-28-04-01-03-01

Cover tank
A1-28-04-01-03-02

Drain valve
A1-28-04-01-03-03

Blanking plug
A1-28-04-01-03-04

ICN-B6865-S3000L0029-002-01
Fig 30 Mixed breakdown, extended syntax with separators
Table 27 Listing of mixed breakdown extract from Fig 30.
BEI

Item nameItem type

A1
A1-28
A1-28-01
A1-28-04
A1-28-04-01……..
A1-28-04-01-03
A1-28-04-01-03-01
A1-28-04-01-03-02
A1-28-04-01-03-03
A1-28-04-01-03-04…….
A1-28-04-02
A1-28-05
A1-28-06

Aircraft A1
Fuel system
Fuel distribution
Fuel storage
Internal storage tanks

Product
Main system
Function/subsystem
Function/subsystem
Subfunction/assembly

Tank 03 rear
Rubber tank
Cover tank
Drain valve
Blanking plug

Equipment
Component/partComponent /partComponent /partComponent /part

Auxiliary storage tanks
Fuel injection
Control & indication

Subfunction/assembly
Function/subsystem
Function/subsystem

As shown in Fig 30, sometimes the border between a functional BEI and a physical BEI is fluid.
For example the BEI representing the internal storage tanks in Fig 30 could be a functional BEI,
covering the function internal fuel storage, or could be an assembly of physical components, inthis case, the four internal tanks.
11.3.3

Separation of physical and functional breakdown with cross referencing (hardware only)This example (Fig 31) shows the usage of totally separate breakdown trees for both functional
and physical breakdowns. The problem of finding an effective connection between these twoareas should be solved within a LSA database by the means of appropriate cross referencetables.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 91

S3000L-B6865-03000-00

functional breakdown

physical breakdown

Cross reference
betweenfunctional
and physicalbreakdown

Product
Fuel system
A1-F-28

Product

Fuel storage

Tank 01

Auxiliary 01

A1-F-28-04

FT002-791

FT102-591-A

Internal
storage

Auxiliarystorage

A1-F-28-04-01

A1-F-28-04-02

Tank 02

Auxiliary 02

FT002-791

FT102-591-A

Tank 03
FT002-791

Rubber tank
AFT-009-G-21

Cover tank
G0135991

Blanking plug
G05H32110

Drain valve
VG7-1206

ICN-B6865-S3000L0030-002-01
Fig 31 Parallel usage of functional and physical breakdown
The cross referencing between separate breakdowns should be realized in a m:n relationshipstructure. On the one hand, one special function can be connected to many (m) hardware
components, on the other hand one special hardware component can be connected to morethan one (n) function. In this context, this kind of connection is called a m:n relationship between
the functional and the physical breakdowns.
functional breakdown
A1
Product

A1-F-28
Fuel system

A1-F-28-04
Fuel storage

cross reference

physical breakdown
A1

A1-F-28-04-01

FT002-791

A1-F-28-04-01

AFT-009-G-21

A1-F-28-04-01

G0135991

A1-F-28-04-01

G05H32110

A1-F-28-04-01

VG7-1206

Rubber tank

Product

FT002-791
Tank 01

AFT-009-G-21

A1-F-28-04-01

A1-F-28-04-01

FT002-791

G0135991

Internal storage

A1-F-28-04-01… ……

Cover tankA1-F-28-04-02

A1-F-28-04-01

FT002-791

G05H32110

A1-F-28-04-01… ……

A1-F-28-04-02

FT102-591-A

Auxiliary storage…….

Blanking plug

VG7-1206
Drain valve

A1-F-28-04-02… ……

FT002-791

A1-F-28-04-02

FT102-591-A

Tank 02

A1-F-28-04-02

… ……

……….

FT002-791
Tank 03

Which function isrealized by which
hardware……….

FT102-591-A
Auxiliary 01……….

FT102-591-A
Auxiliary 01……….

ICN-B6865-S3000L0031-002-01
Fig 32 Cross referencing between functional and physical breakdown

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 92

S3000L-B6865-03000-00

11.3.4

Physical breakdown with explicit parent-child relationship
Another philosophy of breakdown is the usage of a parent-child methodology. In this case, thehardware is organized in a hierarchical way concerning the installation of the equipments orcomponents in the corresponding parent breakdown element. This type of breakdown is used,
for example, in PDM systems. Additional information in form of a BEI can also be given. The
functional entity (as given in the examples before by using the "28" from a SNS for fuel system)
is not automatically given in this type of breakdown methodology.
Product

Fuel tank

Fuel tank

Fuel tank

Auxiliary tank

Auxiliary tank

FT002-791

FT002-791

FT002-791

FT102-591-A

FT102-591-A

Rubber tank

Cover tank

Drain valve

Blanking plugATF-009-G-21

G0135991

VG7-1206

G05H32110

Filter
H63433-A

O-RingO-Ring12056641205667

ICN-B6865-S3000L0032-001-01
Fig 33 Breakdown with parent-child methodology
In this type of breakdown, as shown in Fig 33, the key information given by, for example a partnumber of the BE, does not contain any information concerning the functional entity. Theinterrelation between the BE’s not given by the key data element part number. Using this type of
breakdown methodology requires the information about the next higher BEI to be able to create
the tree structure of the complete breakdown. The information given in the following table must
be documented in a corresponding LSA database system when using the parent-childmethodology.
Table 28 Listing parent-child breakdown extract from Fig 33.
Item number

Item nameItem type

Next higher item

Quantity

V1

Vehicle V1

Product--

FT002-791

Fuel tank

Assembly

V1

3

FT102-591-A

Auxiliary tank

Assembly

V1

2

ATF-009-G-21

Rubber tankComponent

FT002-791

1

G0135991

Cover tankComponent

FT002-791

1

VG7-1206

Drain valve

Component

FT002-791

1

G05H32110

Blanking plug

Component

FT002-791

1

H63433-A

FilterComponent

VG7-120611205664

O-RingComponent

H63433-A

11205667

O-RingComponent

H63433-A

1

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 93

S3000L-B6865-03000-00

Within an explicit breakdown, it is also possible to document multiple installations ofcomponents. In the case that there is a need to be explicit about each installation location, each
installation location has to be documented as a separate BE with quantity 1.
11.3.5Integration of software as part of a single physical hardware item
The first case to be examined is the ability to assign a SW package directly to one piece ofhardware equipment. The assignment of a BEI for the SW can be done at the level below the
hardware according to the established breakdown coding rules.
The coding rules can include special digits to identify the BEI as a hardware BEI or a SW BEI.
In breakdown example 1 of Fig 34, the BEI of the Navigation radar and of the Navigation SW
package embedded in the Navigation radar cannot be separated based on whether it is a
hardware or a SW BEI. But it is clear that the SW package can be assigned uniquely to the
Navigation radar as the carrier of the SW.
Breakdown example 1

Breakdown example 2 (with software BEI)

Product

Product

Navigation system

Navigation system

V1-43

V1-43

Radar

Radar

V1-43-01

V1-43-01

Weather radar

Navigation radar

Weather radar

Navigation radar

V1-43-01-01

V1-43-01-02

V1-43-01-01

V1-43-01-02

Embedded
software

Navigation SW
V1-43-01-02-91

Embedded
software

Navigation SW
V1SW-43-01-02-91

ICN-B6865-S3000L0033-002-01
Fig 34 Assigning of software BEI in a physical breakdown
In breakdown example 2 of Fig 34, the same breakdown is shown, but with a "software BEI". It
is marked as a SW BEI using the two digits "SW" within the BEI. The other breakdown levels
are not affected, and the assignment of the SW package as a part of the Navigation radar is
unique.
11.3.6Integration of software as part of more than one physical hardware items
This situation is more difficult concerning the assignment of hardware. If the installation or
loading of SW distributes a software package to more than one physical device in the hardware
breakdown, a unique assignment of SW to hardware is not possible. An alternative method toassign the SW is to shift the SW component to a higher breakdown level. This is shown in Fig
35.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 94

S3000L-B6865-03000-00

Breakdown with software BEI next higher level

Product

Product

Navigation system

Navigation system

V1-43

V1-43

Radar

Radar

V1-43-01

V1-43-01

Weather radar

Navigation radar

Weather radar

V1-43-01-01

V1-43-01-02

V1-43-01-01

Navigationradar
V1-43-01-02

Navigation SW (loadable software)
V1-43-01-02-92

Navigation SW
V1-43-01-92

Cross referencing to the real „software carrier“

ICN-B6865-S3000L0034-002-01
Fig 35 Distributed software in a physical breakdown
The loadable radar SW in Fig 35 can be loaded in one procedure to two different pieces ofequipment. The SW cannot be divided up physically into two parts, because it is delivered andinstalled as one single object. The dividing is done by the loading procedure; a uniqueassignment is not possible.
In this case, it is possible to address the SW component one level higher to the BEI of thecomplete radar system. In order to have the correct cross referencing to the appropriate
hardware components, it may be necessary to establish a cross reference assigning the BEI of
the SW package to both the Navigation radar and to the Weather radar. This would be
important if the radar system contains further hardware equipment that are not loading devices
for the SW package.
11.3.7

Integration of software in a functional breakdown
In a functional structure, SW items should be shown as children of the functional system or
breakdown element within which they operate. In allocating a BEI, it is necessary to consider
the supportability characteristics of the SW items. Items with particular support requirements
should be allocated to their own BEI. For example, the BEI scheme should distinguish between
SW that is loadable and SW that is embedded. It may also be necessary to distinguish between
SW that has been provided by the prime contractor or SW items that are safety or security
significant. During the early stages of a project these supportability issues might not have been
fully considered. The development of a functional BEI allocation scheme should be seen as an
iterative process.
In order to develop a functional BEI structure in which SW items are logically grouped at an
appropriate level of indenture, and in which the differing support requirements of all software
items are exposed, items will often be included at levels of indenture against which only limited
amounts of information needs to be stored. For instance, in the example below (Fig 36), little
LSA data will be stored in respect to items Fourier and Signature. The full range of LSA
database information will be recorded against the items at the lowest indenture level. In such acase, SW is represented by the entities on which the software modification activity is carriedout.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 95

S3000L-B6865-03000-00

Product

Defensive system
V1-06

Identification
V1-06-01

Signiture
Package 01
V1-06-01-01-A

Signiture

Alert

Fourier

V1-06-01-01

V1-06-01-02

V1-06-01-03

Signiture
Package 02
V1-06-01-01-B

Signiture
Package 03
V1-06-01-01-C

Fourier 01

Fourier 02

V1-06-01-03-A

V1-06-01-03-B

ICN-B6865-S3000L0035-001-01
Fig 36 Functional BEI structure concerning SW
It is necessary to maintain both functional and physical views of SW items throughout the life of
the parent product. It can be important to establish links between software items in thefunctional domain and the associated executable SW package in the physical domain. This may
be achieved by the same method of cross mapping the physical hardware items to functional
product breakdown.
The requirements concerning the assignment of SW BEI in a pure functional breakdown are thesame as in physical breakdowns. If there are functions that are realized by exactly one definite
SW package, the unique assignment would be possible. If more than one function is realized by
the loading of a SW package, the need for a higher level assignment is the same as for thephysical breakdown methodology.
An additional question concerning SW is when to use a functional breakdown and when to use
a physical breakdown. In many cases, SW can be assigned within a physical breakdown on asubsystem or system level (this can be an additional argument to use a mixed breakdown
methodology, physical and functional). However, for SW modification purposes, a functional
breakdown is preferred within a separated SSA database. Normally, a mixed breakdown
structure including the higher breakdown hierarchies on system/subsystem level as a kind offunctional framework is not sufficient for a real functional breakdown. On the other hand, acomplete mixture of functional and physical breakdown aspects within one breakdown is not
feasible.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 96

S3000L-B6865-03000-00

11.4

LSA candidate selection flowchart examples

11.4.1

Non structural items
START

yes

yes

Is the itema new developed
or major modified
item ?

Has the item a low
reliability ?

Is theitem arepairable, MaintenanceRelevant Item
(MRI)?

yes

Full candidate selection (CS01)

no

Remarks forjustification(if required)noRemarks forjustification(if required)Are
dedicatedmaintenance tasks complex,
very time consuming and personnel
intensive or is non-standard
support equipment
required?

Does
the item needa specific scheduled or
preventive
maintenance?

to partial
candidateselection

Remarks forjustification(if required)

no

no

no

Remarks forjustification(if required)to partial
candidateselection

Remarks forjustification(if required)yes

Potential
full candidate
in CIL

ICN-B6865-S3000L0036-001-01
Fig 37 Full LSA candidate selection flowchart
The selection flowchart from Fig 37 shows a typical process for the determination of full LSA
candidates from an existing breakdown. The flowchart must be applied to each breakdown
element. If the selection flowchart for full LSA candidates leads to the IUA not being a full LSA
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 97

S3000L-B6865-03000-00

candidate, the second LSA selection flowchart for partial candidates must be applied to each of
those BE’s.

from full candidate selection

yes

yes

yes

Must theitem be removed
to gain access and is
the removal of highfrequency?

Is the item a systemor a sub-system, which is notpreviously defined as a full candidate
against which a fault location and/or a test
procedure or other generalmaintenance procedures
will be described?

Is the item a
non-hardware item,
against which general activities(like cleaning, storing, parking,mooring, general inspections)will be described ?

Potential
partial candidate
in CIL

Partial candidate selection (CS02)

Remarks forjustification(if required)nonoRemarks forjustification(if required)noRemarks forjustification(if required)

Potential
non-candidate
in CIL

ICN-B6865-S3000L0037-001-01
Fig 38 Partial LSA candidate selection flowchart
Depending on the project, the selection criteria must be adapted since additional criteria may berequired. In general, the analyst must have a guideline for the LSA candidate selection. The
examples here are simple and clear. Any required change of flowchart logic within a special
project must be harmonized between the contractor and the customer and accepted by thecustomer during the LSA GC.
11.4.2

Structural items
In the case of structural components, the selection of LSA candidates differs from the selection
process for non structural items.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 98

S3000L-B6865-03000-00

START

Is the designprinciple ofstructural item
save life?

Candidate selection (CS03)
for structural items

yes

no

yes

Does thestructural item
require specific inspection
and/or scheduledor preventive
tasks?

Results of Scheduled
Maintenance Analysis(S4000M, MSG-3, RCM)

no

yes

Is thestructural item
replaceable (in-service)as a re-occuring event or isitem removed
for accessregulary?

Is theitem repairable
in situ and in an installed
condition?

no

Remarks forjustification(if required)

no

yes

no

Can repairsof the structural itembe achieved with standard
or general repair
procedures?

yes

Potential
full candidate
in CIL

LSA candidate
family (standard
procedures)

Potential
non-candidate
in CIL

ICN-B6865-S3000L0038-001-01
Fig 39 LSA candidate selection flowchart for structural items

S3000L-A-03-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-03-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 3
2010-04-01 Page 99

S3000L-B6865-03000-00

Chapter 4
Configuration management
Table of contents

Page

Configuration management............................................................................................................ 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Introduction ...................................................................................................................... 3
1.2
Objective .......................................................................................................................... 4
1.3
Scope ............................................................................................................................... 42
Configuration management in the LSA process .............................................................. 4
2.1
Configuration management planning............................................................................... 4
2.1.1
Milestone plan.................................................................................................................. 5
2.1.2
Milestone input criterion (trigger) ..................................................................................... 5
2.1.3
Milestone output criterion (trigger) ................................................................................... 5
2.2
Configuration identification .............................................................................................. 5
2.2.1
General aspects............................................................................................................... 5
2.2.2
Configuration identification rules (steps) ......................................................................... 5
2.3
Configuration control ....................................................................................................... 6
2.4
Configuration accounting ................................................................................................. 7
2.5
Configuration verification and audit ................................................................................. 7
2.5.1
Functional configuration audit.......................................................................................... 7
2.5.2
Physical configuration audit ............................................................................................. 7
2.5.3
Configuration audit requirements .................................................................................... 83
Sources/drivers for configuration changes ...................................................................... 8
3.1
Customer requirements for change ................................................................................. 8
3.2
Design change proposals ................................................................................................ 9
3.3
Manufacturing deviation from design (concessions) ..................................................... 10
3.4
Supplier changes ........................................................................................................... 10
3.5
Inservice changes (service bulletins) ............................................................................ 10
4
The impact of configuration changes in LSA ................................................................. 10
4.1
Evaluation of the impact of configuration changes ........................................................ 10
4.2
Traceability between the source of changes and consequential LSA changes ............ 11
5
Processing of configuration changes during the LSA process ...................................... 11
5.1
General aspects............................................................................................................. 11
5.2
Coordinating role of LSA ............................................................................................... 11
5.3
Task assignment by discipline ....................................................................................... 12
5.4
Task status and control ................................................................................................. 12
6
Implementation of configuration management .............................................................. 13
6.1
Change compilation and traceability.............................................................................. 13
6.2
LSA configuration items identification ........................................................................... 13
6.3
Support system and other ILS configuration items definitions ...................................... 13
6.3.1
Technical documents configuration items ..................................................................... 14
6.3.2
Illustrated parts list and illustrated parts catalogue configuration items ........................ 14
6.3.3
Support equipment configuration items ......................................................................... 14
6.4
LSA compilation by change ........................................................................................... 15
6.4.1
General .......................................................................................................................... 15
6.4.2
Operational system configuration compilation ............................................................... 16
6.4.3
Functions and descriptions configuration ...................................................................... 17
6.4.4
Failure modes and effects analysis configuration ......................................................... 17
6.4.5
Task analysis configuration ........................................................................................... 18
6.4.6
Scheduled Maintenance Analysis configuration management ...................................... 19
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

6.4.7
6.5
6.5.1
6.5.2
6.5.3
6.5.4
6.5.5
6.5.6
6.6
6.6.1
6.6.2
6.6.3
6.6.4
6.6.5

Support equipment change compilation ........................................................................ 19
Applicability management .............................................................................................. 20
General .......................................................................................................................... 20
Manufactured serial number and fleet serial number concepts .................................... 20
Effectivity of change/criterion......................................................................................... 22
MSN versus FSN applicability management ................................................................. 23
Product variant management ........................................................................................ 23
Serialized item management ......................................................................................... 24
Production and releases management .......................................................................... 24
General .......................................................................................................................... 24
End product identification .............................................................................................. 25
Change traceability of releases ..................................................................................... 25
Release management ................................................................................................... 26
Customization of a release ............................................................................................ 27

List of tables
1
2
3

References ...................................................................................................................... 2
List of configuration identification rules (steps) ............................................................... 6
Types of affectation ....................................................................................................... 15

List of figures
1
2
3
4
5
6
7
8
9
10

Configuration management process................................................................................ 3
Configuration traceability from design configuration to ILS/LSA configuration ............. 13
LSA compilation by change ........................................................................................... 16
Applicability calculation based in the criteria applicability ............................................. 20
MSN usage example ..................................................................................................... 21
Fleet example ................................................................................................................ 21
FSN (fleet) versus MSN ................................................................................................. 22
Applicability calculation .................................................................................................. 23
Example for applicability to Product versions ................................................................ 24
Release management ................................................................................................... 27

References
Table 1 References
Chap No./Document No.

Title

Chap 3LSA Business process

S1000DInternational specification for technical publications using
a common source database

S2000M

S2000M - International specification for material
management

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

1

General1.1

Introduction
Configuration Management (CM) is a discipline that ensures the correct identification of theconfiguration, controls changes, and records the change implementation status of the physicaland functional characteristics of the structure, system/subsystem and equipment.
CM is to be performed at the lowest level of the breakdown of a product. It identifies what isrequired, designed, produced, supported and evaluates changes, including effects on technicaland operational performance and Integrated Logistic Support (ILS) activities. It also provides
visibility of the configuration.
The elements of configuration management include:
−
−
−
−
−

Configuration management planning
Configuration identification
Configuration control
Configuration accounting
Configuration verification and audit

CM is therefore the means through which integrity and continuity of the design, systems
engineering and supportability are recorded, communicated, and controlled. CM efforts result in
the complete audit traceability of decisions and design modifications. Suitably qualified
contractor and customer personnel, who will certify the components and inform CM of theoutcome, will perform these efforts. The following figure shows a schematic of how the entire
process of CM works.

Configuration management plan
Establish general rules, make planning and control based on milestones in accordance with the overall
project milestones

8

Customer
COC

Sources of change

DesignTechSpec

Manufacturing

Supplies

GSE

Drivers andsourcesmanagement(including
alerts ofchange anddatacollection)

Based on criteria, ensures the status of the criteria in all LSA
activities

Applicability
management

2

Criteria
1

Connect all CM
processes

Analyse any
externalchange todetermine
impact in LSA

4Providesapplicability to
any item of the
breakdown(operational
system + support
system)6

3
4

LSA activities to implement criteria
Suppliers
info

5

Provides authorization for LSA changes + traceability of changes

7

Production and release management

Design
CI/DS

Provide means to guarantee quality of deliveries and capability tofilter by effectivity

Detailed configuration planning and control
management

ICN-B6865-S3000L0076-002-01
Fig 1 Configuration management process
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

Explanation of the process steps in Fig 1:

1.2

1

Any external change when impact becomes criteria for change in LSA.

2

As a consequence of a criterion, a set of activities need to be performed so planning andcontrol for them is required.

3

Criteria are used to authorize change in the LSA products and also guarantee thetraceability of changes internally and externally to the sources.

4

The applicability of criteria + impact/authorization of criteria over the LSA configuration
items is used in the applicability management to provide the applicability of the LSA
configuration Items.

5

Provides the status of the criteria included in the set that defines a delivery.

6

Provide applicability to all components of the LSA products.

7

Provides contents for the LSA products and the criteria traceability to the LSA products.

8

Provides milestones for deliveries or releases of the LSA products.

Objective
The goal of this chapter is to present all processes involved in the CM for LSA guidelines andexamples are given in this chapter to allow efficient CM of the operational system as well as the
support system. This chapter covers all aspects of CM whether or not they are used for a
specific project. Users of this chapter must tailor the process to their needs.

1.3

Scope
This chapter is focused on the LSA CM, but since LSA is a core ILS process, it has many
relationships with other CM in other ILS disciplines. Most of the guidelines and rules given inthis chapter can be applied to other ILS disciplines and this chapter strongly relates to other
ASD specifications.
This chapter is oriented toward all LSA and ILS managers and it is recommended that thischapter is also read by other ILS discipline managers.

2

Configuration management in the LSA process

2.1

Configuration management planningCM planning in the LSA process shall start at the beginning of the program and continue
through all phases of the Product’s life cycle. CM planning results in an LSA CM Program(LCMP). The LCMP must account for the customer requirements regarding CM. The LCMP
shall identify a series of milestones/meetings, which are documented in a milestone plan.
An LCMP shall comply with the following:
−
−
−
−
−
−
−

Outline and define the organizational structure for developing the project (Service).
Define policies and methods used to establish and control the baselines and configuration
items identified.
Describe the plans for the application of configuration index, matrix and change statusaccounting records and procedures.
Describe methods for meeting CM requirements for continuous acquisition and life cycle
support.
Define the proposed methods for control and monitoring of any subcontractors andvendors.
Establish the major milestones for implementation of configuration management.
Describe integration of CM activities with other program/management activities.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00−

Describe the plans for conducting/supporting the functional and physical configuration
audits at any product management level (system/subsystem, equipment/module level).

2.1.1

Milestone plan
The milestone plan must generally follow the program/design milestones. However, it isimportant to establish a buffer between the design milestone and the relevant LSA milestone inorder to leave enough time to allow ILS personnel to incorporate the design changes. This
milestone plan requires an appropriate number of meetings between the customer and thecontractor for approval of the milestone accomplishment.

2.1.2

Milestone input criterion (trigger)
Every milestone will have an input criterion. This is the necessary documentation to bedelivered by the contractor/customer to properly conduct the milestone meetings. This input
criterion (trigger) must be delivered with enough time prior to the meeting to allow proper
analysis and ensure an efficient meeting. Non-compliance of any of this criterion may result in acancellation of the meeting.

2.1.3

Milestone output criterion (trigger)
These are the results of the milestone meeting and provide the action plan for the next phase
until the next milestone meeting.

2.2

Configuration identification

2.2.1

General aspects
Configuration identification consists of setting and maintaining baselines that define the systemor subsystem and their development at any point in the life cycle. From the ILS point of view,
the system to be considered comprises the mission system (eg aircraft) and the support system.
This means that ILS focuses not only on production, but also on servicing the product (mission
system).
−−

The mission system is traditionally considered to be the product. It is the system, along withall of the functions necessary to comply with the established mission, to be operated by thecustomer.
The support system includes all elements necessary to support the mission system and toallow it to comply with the mission in the most effective way. All the elements of ILS can beconsidered as the support system:
•
•
•
•
•

Support equipment. This includes any tool and support and test equipment necessary
to operate/support the mission system.
Technical documentation
Manpower
Training and training equipment
Facilities and any other item required in the operation and support of the mission
systemEffective configuration identification is a pre-requisite for all other CM activities. If configuration
identification and their associated configuration documentation are not properly identified, it is
impossible to control the changes to the item’s configuration, to establish accurate records andreports, or to validate the configuration through audits.
Inaccurate or incomplete configuration documentation may result in defective products,
schedule delays, and higher maintenance costs after delivery.
2.2.2

Configuration identification rules (steps)
Configuration identification must follow specific rules (steps) that are outlined below.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

Table 2 List of configuration identification rules (steps)
Rule

Description

Identification ofconfiguration items(Functional and physical)

The identification of the item must follow the design configuration
and be compatible with other ASD specifications like S1000D or
S2000M. For example, the Standard Numbering System (SNS)from S1000D could be followed for the functional configuration.

Relationship between
Functional and physicalconfiguration

Functional and physical configurations are two different points ofview of the same item. Any item in the functional configurationmust be identified in the physical configuration and vice versa,
therefore, requirements for the management and link between
these configurations must be establish in the LCMP.

Relationship between
design and LSA
identification

Rules to guarantee the traceability between design configurationand LSA configuration must be included in the LCMP

Zoning and access panel
identification

Structuring the product by zones to include identification of accesspanels is another approach to the configuration of a product

Functional Identification
Number /Reference
designator identification

Identifying an item for schematic purposes (eg electrical) can beaccomplished through the Functional Identification Number orReference designator (according to S2000M). Rules for Functional
identification number / Reference designator assignment can be
included in the LCMP.

Variants/Alternate item
identification

The use of variant must be defined at the beginning of the projectand included in the LCMP. This coding is used for identifying
different technical solutions for the same function. The relation toother specifications is also useful, for example, the relation
between an alternate breakdown element identifier and an Item
sequence number. Chap 3 provides additional information on
documenting product variants and alternate items.

Top level configuration
identification

At the beginning of the project, the type of top level configuration
management must be established. Top level configuration
management serves to identify the products or any other kind ofgrouping of products. For example, it is necessary to define theuse of different top level management:

Required documentation
for proper configuration
identification

2.3−

By manufactured serial number−

By fleet number or customer versions−

By system difference codes−

By applicability. This defines a way of managing theconfiguration by the part number. It is used for items for which
serial number management is not suitable

The documentation necessary to properly identify the configuration(eg ASD breakdown document, Illustrated Parts Data (IPD)) must
be defined at the beginning of a project.

Configuration control
Configuration control includes the evaluation of all change requests, change proposals, andtheir subsequent approval or disapproval.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

This shall ensure that no change will be implemented without due consideration of its effect on
the baselines, including logistics impact, costs, schedules, performance, or interface with any
associate companies, etc.
The authority required to make a decision on a change varies with the magnitude and nature of
the change concerned. It involves the appropriate levels within the organization of the customer
and the developer for the project. The decision making process is an integral part of the overallmanagement of the "project management system".
To enable the process to operate correctly, it is necessary to establish specific procedures for
dealing with changes, for example:
−
−
−

2.4

Providing the relevant information for best decisions on changes
Implementing decisions
Reviewing and controlling changes in accordance with established rules

Configuration accounting
The LCMP shall establish necessary procedures/requirements that ensure the correct
monitoring of changes and their effect on configuration. These are as follows:−−

Up-to-date accounting of the exact configuration of each product
List of changes status
•
•
•

−
−
−

2.5

Design changes
Waivers
Deviations

Procedure for change status control
Requirements for version versus changes incorporated
Discrepancies from audits management requirements

Configuration verification and audit
Functional and physical configuration audits will be performed in accordance with the generaland detailed requirements and processes. The main purpose of the Functional Configuration
Audit (FCA) and Physical Configuration Audit (PCA) is to establish a product baseline and toestablish a system or production baseline. This defines the configuration of the product for
manufacture and provides assurance for the support of the product during operational use.

2.5.1

Functional configuration audit
The FCA will be an examination of the configuration identification documents to ensure that thetechnical documentation accurately reflects the actual functional characteristics of aconfiguration item and conforms to the necessary interface characteristics.
Test and evaluation data will be examined to verify the configuration item has achieved theperformance specified in the relevant configuration identification documentation, ie, functional
and allocated baselines. The FCA will be performed on the first item that is representative of theconfiguration which is to be used as a deliverable item. Any difference will be identified between
the physical configuration of the selected configuration item and other development
configuration items used for the FCA, and will certify or demonstrate that these differences do
not degrade the functional characteristics of the selected configuration item.

2.5.2

Physical configuration audit
The PCA will be an audit of the configuration identification documentation, planning andmanufacturing data, released engineering drawings, and the quality evaluation records toensure that the configuration baseline engineering documents have been adhered to and thatthe "as-built" or "as-coded" condition is in accordance with them. The PCA will be performed on
the first item used for qualification and compliance verification. A system PCA may be

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

necessary for large and complex systems to ensure that the physical baseline build standard is
acceptable for production release.
2.5.3

Configuration audit requirements
Both the functional and physical audit should meet following requirements:
−
−
−
−
−
−

Accuracy and acceptability of the functional and product baselines and assure that theConfiguration is, in fact, built to these baselines
Contract requirements
Audit plan
Audit procedure
Items subject to audit
Audit scheduling and milestones••−

Input key
Output key

Audit responsibilities
Responsibility for the physical and functional configuration audits is with the CM technicalauthority and shall be performed by the acquirer or his nominated representative withsupport from the following:
•
•

−

3

System/subsystem design manager
Quality representative

Corrective action and risk management requirements

Sources/drivers for configuration changes
LSA CM is required because there are changes to the baseline configuration of a project. Thesechanges may be internal changes (eg improvement of the support analysis) or external changes(eg design changes, supplier changes).
Potential Drivers/Sources for configuration changes may be:
−
−
−
−
−

Requirements from the customer.
Changes from the design office
Manufacturing deviation from design (Concessions)
Supplier changes
Customer orders for change

Since specific drivers are linked to specific sources, the management of the relevant sources isrequired for CM. Specific changes normally will follow defined processes and will require
specific activities. The most important business cases are outlined below.

3.1

Customer requirements for change
In some cases, the customer requires changes to the end product. The process that needs tobe created when the customer requires a change is as follows:−−

Reception of Customer Originated Change (COC) proposal
COC management••

Analysis of impact with cost implications. The request for change from the customer
must be analyzed to determine the impact of the change proposal and the cost to
implement the change.
Change committee actions. The change can be submitted to the modificationcommittee for approval or rejection.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00•−

COC design validation
•
•
•

−

Decision and Resolution notification. The decision on the change proposal should becommunicated to the customer.

Requirement for design office to make an analysis. The change proposal is taken to
the design office for analysis.
Design change proposal associated. When the design office decides to create a designmodification, a link between the customer change proposal and the design changemust be established and recorded for traceability purposes.
Design office documentation collection. The design office prepares the documentationthat needs to be collected in order to make the final change proposal derivates fromthe customer requirement.

Change applicability assignment

Finally, a range of Manufacturer Serial Fleet or versions must be assigned to the final change
proposal. This may apply only to the customer that originated the change, or a decision can bemade to implement the change to other customers/fleets or to products identified by their
Manufacturer Serial Number (MSN).

3.2

Design change proposals
The design office may propose changes to the configuration for several reasons. Depending on
their origin, changes can be justified in three groups:−−−

Mandatory changes (safety): This type of change is unavoidable because the safety of the
product is involved. The consequences of not implementing these changes may lead tocatastrophic situations in the operation of the product.
Improvement changes: Change proposal that improves the functionality or supportability ofthe product.
Version definition changes. A change introduced to create new customer versions, inaccordance with the customer contractual requirements.

In order to maintain the traceability of changes, it is necessary to consider certain aspects
related to these changes and the subsequent actions that are required, such as:−−

Change applicability. Provides the applicability of the change in terms of the product.
Design configuration concepts. In general terms the design office uses the concept ofconfiguration item for a functional item. A functional item is a requirement to comply with a
specific function of the product. Since there is not just one way of doing this, it is possible tohave different Design Solutions (DS) for the same function. Therefore, there are several
DSs associated to one configuration item. A DS can be equipment, a set of equipment, oran assembly of different items that together provide functionality.
The design changes:
•
•

−
−

Create configuration items
Modify configuration items, creating, modifying or deleting new DSs associated to theconfiguration item

Drawing and mock-up changes. In some cases, the change does not introduce a new
CI/DS, but changes the position of the items (mock-up changes). These changes may also
affect the support items (such as maintenance task).
Changes to design specification and systems descriptions. The functional description of the
Product is included in design specifications. Therefore, changes to the configuration of the
Product imply change to its functionality, so the design specifications are affected by thedesign changes. Because design specifications are used in LSA for systems, LSA is
impacted by these changes.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00−

3.3

Design change status. In order to authorize/implement a design change, an approval
process is to be followed. It is important from the LSA point of view to know this status andto act accordingly. As LSA is an integral part of the entire process, the global status of thechange must take into account the LSA status. Therefore, the LSA provides feedback to theprogram change management.

Manufacturing deviation from design (concessions)
Where current approved configuration documentation is correct and manufacturing errors occur,
a form for "Deviations and waivers" is completed by manufacturing, either to enable the item tobe accepted, or for some kind of repair to be made in order to make the item conform to thedrawing or standards, rather than be rejected. Deviations and waivers should not be used to
avoid processes required by the life cycle. If non-applicable documents and evaluations are
required, these must be tailored and agreed upon prior to contract award.
−

Requirements for deviation
Prior to the manufacture of an item, if it is considered necessary to temporarily depart frommandatory requirements of a specification or drawings, for a specific number of units or a
specified period of time, the customer may authorize a request from the contractor. Items
shall not be delivered incorporating a known departure from documentation unless arequest for deviation has been approved.

−

Requirements for waiver
Supplies or services, which do not conform in all respects to the contractual requirements,
shall normally be rejected. An item, which through error during manufacture does notconform to the specified configuration documentation, shall not be delivered to thecustomer unless a waiver has been processed and granted.

3.4

Supplier changes
Any change in the equipment provided by any supplier may affect the configuration of the
product. The supplier change may affect the equipment or the support items applicable to the
supplier equipment.

3.5

Inservice changes (service bulletins)
When a modification to the product is to be incorporated once the mission system is operating
normally, it has to be introduced through a Service Bulletin (SB).
A SB is a technical document that describes the modification and how it is to be implemented in
the product. It has an associated applicability, and once the SB is approved, it can be treated asa design modification.
The difference between a design modification and a SB is that the contractor does not always
have information about the implementation of the SB by the customer. Therefore, theapplicability of the SB cannot be considered as a true applicability.

4

The impact of configuration changes in LSA

4.1

Evaluation of the impact of configuration changes
For proper CM, it is necessary to correctly evaluate all of the impacts that the changes may
introduce into ILS. The changes can have an impact on configuration items, on the
documentation, or on the support system. In order to control the impact of changes on operating
and support issues, the following will be taken into account:−−−

The effect of the change on the ILS disciplines.
The consequential effects of the change on support elements, (eg spares, test equipment).
Interchangeability/compatibility of all post- and pre-change items.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6865-03000-00−

If the change has applicability, this will be indicated in the change documentation and a
supplementary evaluation sheet will be attached giving details of the assessment.

The following areas must be analyzed for impact:
−
−
−
−
−
−
−
−
−
−
−

4.2

Reliability
Maintainability
Testability
Training
Software
System development environment
Standards, plans and procedures
SparesLife cycle costs
Support & Test equipment
Technical data/Technical Publication

Traceability between the source of changes and consequential LSAchanges
The traceability between sources changes and LSA changes is achieved by:−

Change proposal criterion traceability
The change traceability is guaranteed by using as a criterion (trigger) for Change the samecode that comes from the design office, or another source, as a change proposal. If this is
not the case, it is necessary to maintain a record to relate the criterion used to authorize thechanges to LSA/ILS with the original changes.

−

Design configuration items versus LSA configuration Items
Since the design office may use different codes for design configuration than the ones usedin LSA configuration, it is necessary to establish a link between the two ways of identifying
an item of the configuration. It is recommended to record the correspondence between
design configuration items and LSA configuration items. This helps to identify potential
impacts in LSA configuration items due to the modification in design configuration.

5

Processing of configuration changes during the LSA process

5.1

General aspects
Once it is decided that a change proposal has an effect on ILS and becomes a criterion(trigger), it is necessary to initiate consequential activities in order to ensure that:
−
−
−
−
−
−

5.2

The impact in the different disciplines is properly identified.
The different jobs to implement the necessary changes are identified and assigned to every
ILS discipline affected by the criterion (trigger).
These jobs are planned in time and the necessary resources to implement the change are
identified.
The status of the jobs performed by every ILS discipline affected can be known.
Feedback to the entire configuration management process at the program level about thestatus of the change implementation is guaranteed.
Any change proposal identified as non-affecting to ILS needs to be recorded with attachedjustification. This is required to ensure that the entire change proposal has been analyzed,
which guarantees the traceability of changes.

Coordinating role of LSA
Because LSA integrates the different ILS disciplines, a coordinator with the following
responsibilities is required:

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6865-03000-00

−
−
−
−
−
−

5.3

To analyze changes that can affect the ILS
To determine/assign disciplines affected by the trigger
To be the focal point of ILS at the program modification committee
To follow up the status of the trigger in every discipline
To obtain and provide the necessary documentation from the originator of the change
To coordinate the jobs between different disciplines and resolve planning problems

Task assignment by discipline
The coordinator identifies the different disciplines affected. It is necessary to maintain a recordof the affected disciplines and the expected jobs to be performed. This is necessary to ensurethat any approved change is reflected in ILS. Also, it is useful to ensure that any change in ILS
information has a justification.
Once the coordinator assigns the jobs to the disciplines, every discipline needs to analyze andverify that it is really affected by the trigger.
−
−
−

5.4

In the case that the ILS discipline considers that it is not affected, it must inform thecoordinator who records this decision, in order to update the impact and eliminate it fromthe records.
When the discipline confirms it is affected, the discipline responsible can plan the jobs to be
performed, identifying the forecast date for completely implementing the changes.
In cases where an ILS discipline is affected but requires input from other ILS disciplines,
the requirements will be documented and the coordinator will establish coordination
between the interrelated disciplines.

Task status and control
Para 5.3 was about planning and this paragraph is about control. Planning and Control together
implement change management. Correct implementation can be tracked by assigning a status
to every task discipline or ILS item.
The different codes to be used must be agreed upon at the beginning of the Program anddeclared in the LCMP document. It is recommended that a minimum set of status codes be
used. Following are examples of status codes:−−−

Open: when a task is identified but it has not already been required to start.
Pending: when it is required for the ILS discipline to perform the task.
Close or finish: When all the jobs associated with the task have been correctly completed.

There are different levels at which the criterion status can be managed:−−−

Criterion (trigger) level. It is the highest level of control. This level is mandatory for proper
configuration management at the Program level. It provides the feedback of change
management to the customer. A criterion can only be considered as complete when all
disciplines declare it as complete at the discipline level.
ILS discipline level. This provides visibility of implementation in the ILS disciplines. The
depth of management level in the organization is optional.
ILS item level. This level is optional and provides the visibility at the ILS item level.
Examples of ILS Item parameters are:
•
•
•
•
•
•

Breakdown Element Identifier (BEI)
Task
ASD system or chapter
Data module for technical publications
Scheduled maintenance analysis for a system or structural significant item
Description of a system

This level provides visibility of the change implementation of an ILS item. Normally, this issufficient regarding the traceability of a change. This is indirectly obtained from the ILS status.
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6865-03000-00

In most cases, an ILS item is managed by only one ILS discipline, but as an exception, one
configuration item may be managed by more than one discipline.

6

Implementation of configuration management

6.1

Change compilation and traceability
This paragraph explains how to implement the changes (criterion) and enables the mainprocess to guarantee the traceability of the change. This also identifies the ILS elements being
impacted and exactly what has been changed. In addition, it must be possible to determine who
has or provides the authority to change any part of the ILS elements.
The criterion can impact on the operational system and/or in the support system. It is essential
to have a clear process for identification of the operational system configuration and ILS
elements or support system configuration. The following figure illustrates how from the source,changes are compiled by the different ILS disciplines, thereby maintaining the traceability of thechange/configuration.

Change in design

Aircraft
SystemSubsystem
Sub-Subsystem
LRU
LRU
…………

A
A32
A321
A3211
A321101
A321102

End item / ProductLanding gear
Main gear and doors
Main gear
Leg
Shock absorberLSA

ASD S3000L

Technical
documentation
ASD S1000D

Illustrated parts
List/catalogue(IPL/IPC)ASD S2000M

ICN-B6865-S3000L0084-001-01
Fig 2 Configuration traceability from design configuration to ILS/LSA configuration

6.2

LSA configuration items identification
It is necessary to clearly identify any item or component of the analyzed technical system for
ILS purposes. The first important subject to highlight is that not every configuration item fromthe design point of view is considered an item relevant for LSA activities (LSA candidate). For
example many structural items are not LSA Candidate Items (CI) because they are notconsidered for support. The rules for identifying LSA CI are already documented in Chap 3.

6.3

Support system and other ILS configuration items definitions
In a traditional logistic approach, configuration refers only to the operational system. However,ILS and LSA consider that the complete project comprises of the operational system and the
support system. So the support system must also be considered in the configuration
management.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6865-03000-00

Support equipment also contains components and itself needs other support equipment tomaintain it. Where is the limit to consider the CM? The limit is at the maximum level of support
required. This means that the level of support analysis influences the CM. This level of support
analysis decides if an item is going to be repaired by the operator or not (because it is sent for
repair to the contractor/supplier facilities, or it is considered discard). If there are no
requirements to repair an item it is not necessary to know its component breakdown. This is thelimit for CM. When more than one customer is involved in the business, the limit is establishedby the customer who requires support at lowest level.
In the case of the support system, it should be considered as an extension of the operational
system. If support equipment is not going to be repaired at the operator’s facilities, there will be
no need to consider its components for CM. There are other elements of configuration in the
support system to be considered for CM such as the technical publication.
According to their nature, training elements can be considered as belonging to support
equipment or to technical documentation, as follows:−

Training aids:
Where there is equipment or systems, such as a simulator or computer based training,training equipments, these can be considered as support equipment−

Courses and training manuals can be considered as special technical documentation

Consumables can be considered as special spares.
Facilities can be regarded as a special category of support equipment. In this case, facilities andsupport equipment should be linked in a way that there is some support equipment included in
the facilities. From the functional point of view, support equipment does not belong to thefacilities, but from the physical point of view, they can be considered as components of the
facilities. However, it should be pointed out that the requirement of big facilities is a very special
aspect. This aspect has to be considered at a very early stage of any project, because normallythe construction of facilities and the required infrastructure is associated with high investment.
6.3.1

Technical documents configuration items
The S1000D states that technical documentation is managed with the help of a Common
Source Database (CSDB). These DMs are identified by a Data Module Code (DMC). A
prepared set of DMs is a technical manual. This provides a capability to create customized
technical manuals.
The DM that contains basic information belongs to the functional configuration of the support
system (technical data). The physical configuration of the support system for technical data is
the DMC, corresponding to the technical manuals and its components are normal DMs.

6.3.2

Illustrated parts list and illustrated parts catalogue configuration items
The S2000M states that the Illustrated Parts Data (IPD) is managed by using specific key data
elements to manage the configuration. These also are specific codes.
−−

CSN - (Catalogue Sequence Number)
ISN - (Item Sequence Number)

The configuration here is clearly oriented to illustrate how the spares can be disassembled fromthe product or from equipment in case of equipments with its own Illustrated Part presentation,eg items that traditionally have its own Component Maintenance Publication.
6.3.3

Support equipment configuration items
The term support equipment covers a wide range of items. This ranges from small tools tocomplex equipment used for testing purposes or training like a simulator. There is no specific
ASD specification which covers the subject of support equipment. However, the identification

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6865-03000-00

possibilities previously described are applicable to support equipment also. S1000D can beused for the creation of technical documentation for support equipment in the same way as forthe operational system. S2000M can be used to document the support equipment itself and theconfiguration of the support equipment, if required.
From the system breakdown point of view it is recommended that the support system isseparated from the operational system. In an existing SNS for a project it should be determined,
how to address and code support equipment. The following aspects should be considered:−−

The relationship of the support equipment to a specific project should be visible
The system where the support equipment is frequently used should be identified within thecode

Support equipment, in this way, can be treated like a LRU because it is independent from the
support point of view. It can be repairable at first level and can also be treated as having its own
IPD representation to illustrate its components. This is a coherent way to assign configuration
items with the way used for the operational system. In any case the structure of the breakdown
coding for support equipment must be defined and agreed between contractor and customer atthe beginning of a project.
From the physical point of view, support equipment can also be included in the facilities
configuration. To do that it is helpful to show the capabilities of the facilities in terms of the
support equipment available in each facility. One piece of support equipment can be in morethan one facility. Likewise one facility may have multiple items of support equipment. In this way
it is useful to identify the required facilities for a task according to the support equipment
required to perform it. Indirectly it provides the facilities where it is possible to conduct the task.

6.4

LSA compilation by change

6.4.1

GeneralCompilation by change means that any data compiled has to be done in accordance with achange code that authorizes it and also that change is considered as the driver for thecompilation. This is the reason to call the change used to compile criterion (criterion or reason
used to change information). There are some basic reasons to compile by change:−−−

To ensure the traceability of changes produced in design, manufacturing engineering,
supplier, or change requirements from the customer. This identifies the real impact of theapproved changes.
To have the authority of any piece of support system changed. This allows the justificationof any change.
To identify the applicability of the items (to be discussed if the part dedicated to an
applicability).

The basic way to do it is to identify the impact of any criterion in any item of the operational
and/or support systems. Identification of the item affected by the criterion and the type ofaffectation is recorded for quality assurance purposes. The type of affectation can be:
Table 3 Types of affectation
Type ofaffectation

Description

New item

The criterion creates a new item or extends the applicability of one existing
item. The item is new for the range of operational system products indicated by
the applicability of the criterion. The range of operational system products isindicated by a Manufacturer Serial Number (MSN) range. This information isvery important for achieving final applicability of the Items.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6865-03000-00

Type ofaffectation

Description

Deleted item

Most of the time it is not a real deletion, it is only a way to say that the existing
item is not any more applicable to the products covered in the range indicatedby the criterion applicability. This information is very important for getting theconfiguration item applicability.

Modified item

Used when only traceability function is required for the change, and nonapplicability impact is declared. For example a task is changed by a criterion
but the task is still applicable to the same range of MSN that was previously tothe application of the criterion. What is affected and has different applicability
are the components of the task (spares, step description, etc)

The following Fig 3 illustrates the explanation above.

LSAtasktask
LSA

Component(spares, steps, support
equipment …)

LSA task criteria
post / preCriteria-component
post / preCompilation
Criterion
Criterion

ICN-B6865-S3000L0085-001-01
Fig 3 LSA compilation by change
6.4.2

Operational system configuration compilation
The LSA operational system configuration is linked to the design configuration of the operational
system.
−−Through approved design modifications that have impact in ILS/LSA and for that reason
they become criterion. This modification must be recorded and associated to thebreakdown revision identifier, specifying whether to create a new breakdown element,
deleting existing ones (eg in the way of restricting applicability of the breakdown element)or just extending the range of applicability.
By linking the breakdown revision identifier, the hardware element realization and productvariant realization applicability and the design configuration items, there are different ways
to identify a configuration item in design. The following are examples of how to identify an
item.
•

Configuration item number
It is a number to identify a function or assembly position. It is equivalent to the BEI.

•

Design solution
Corresponds to the different alternatives of design that can be analyzed or mounted for
different MSN. It is equivalent to the hardware element realization. In some cases

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6865-03000-00

these do not correspond to a single equipment and it is an assembly of items. When
this happens it is necessary to have extra information, like the next element ofidentification.
•

Parent-child relation
Identify one single position in the assembly. The parent corresponds to the Part
Number (P/N) of the assembly and the child corresponds to the P/N of the component.
In some cases like mock-up applications the child position corresponds to a single
element. In other words if one P/N is mounted twice in an assembly there are twoparent child relations with the same P/N child. In these cases the breakdown element
structure is used to relate one or more parent-child relations but having the same P/Nchild.

Maintaining the relation between the breakdown element revision, hardware element realizationand product variant realization applicability and the original design configuration identification
provides the means to guarantee the traceability of the LSA configuration. It also provides help
to identify BEIs potential affected by new design changes.
6.4.3

Functions and descriptions configuration
Functions and descriptions of systems, subsystems and equipments are subject to changes
resulting from design, manufacturing or suppliers changes. To translate this change to the LSA
description and functions requires maintaining a traceability of the changes. So the criterion is
also used to determine the impact upon the element used to describe or define the functions of
the operational system items.
−−

Descriptions are basically a set of paragraphs. So to configure a description it is necessary
to have a paragraph identifier. It is recommended to manage configuration only at first levelof paragraph and not to subparagraph level.
Functions also need to have identifiers. It is possible to have functions and sub functions.
The complexity of managing both function and sub function is excessive, therefore it isrecommended to manage only the configuration of function.

The way to manage the configuration is the same as Breakdown Element Revision (BER), andproduct variant realization applicability. However, in place of BER, a paragraph or function
identifier is used and in place of product variant realization applicability, paragraph variant orfunction variant must be used.
In any case the depth of CM (function, sub function) must be decided at the beginning of the
project.
6.4.4

Failure modes and effects analysis configuration
The failures analysis is affected by the configuration changes, so it is necessary to know how
the failure analysis is affected by the criterion for change. There are three parts of the failure
analysis that can be affected, and need to have configuration management:−

Failures configuration
Refers to the change in the failure modes that can be changed due, primarily to the designchanges. These changes may occur due to:•••Different equipment can produce different failures
Different equipment can produce the same failure but with different failure rate
Different equipment provides different Built In Test Equipment (BITE) capabilities ordifferent detectability

So it is necessary to identify the failures and also variant of failures. It is important as well toassign the criterion, which authorize the new failure or variant, and the criterion that makenon-effective an existing failure.
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6865-03000-00−

Causes configuration
The cause of a failure is an LRU/equipment when the analysis is performed at the systemlevel or one SRU/component when the analysis is done at equipment level. As the causes
are items of the operational system configuration, the cause is affected by the samechanges that influence the operational system configuration. The causes are identified by
BER and hardware element realization. In this case the criterion does not need to be
associated to the cause because it can be obtained indirectly from the affected BER andhardware element realization.

−

Warning and error messages configuration
Related to the capabilities of BITE appears some information that is provided by the central
maintenance system (error messages) and the indicating system (warnings presented in
the warning display). These messages can be different from one operational systemproduct to another. These differences are due to the design changes or supplier change
introduced to the equipment with BITE. Criterion must be associated to the new or modified
messages/warnings like in the other cases.

6.4.5

Task analysis configuration
Task analysis is also subject to CM. Different products imply different applicable tasks. A
criterion can create a new task, restrict the applicability of the task or modify its components.
Components of a task are considered the following items:−

SparesSpares are items of the operational system configuration, so they can have a BEI or a
hardware element. Changes in design can affect the applicability of the spares thereby
effecting the identification of the spares used in a task. For this reason, it is recommended
that a criterion for spares be established.

−

Consumables
These are not necessarily components of the operational system because they are
consumed during the task. In other cases the item used in the task remains as part of theoperational system. In this case it is recommended that the criterion used to change thesupplies or consumables used in the task are identified (the term supplies is used in
S1000D while the term consumable is used in S2000M).

−

Support equipment
Due to changes in the configuration, the required support equipment can be different evenwhen the configuration item where the task is applicable has not changed. In this case,what can occur is that the environment around the item has changed, so that a different tool
will be needed. Therefore, criterion must be associated to the changed support equipment
applicable to the task.

−

Zones and access panels
One configuration item can be located in a different area zone of the operational system orjust the area around it has changed. In these cases the task (eg replacement of a LRU) canrequire different panels to be opened or the task is performed in a different zone of theaircraft. So it is necessary to associate the criterion to the access panel’s changes or zonechanges.

−

Personnel configuration

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6865-03000-00

Required persons can be different because there are changes in other components of thetask or the time required to perform the task is different. In this cases the changes includedin the task need to be authorized by a criterion.
−

Subtasks configuration
In the subtasks description the detailed instruction of how to perform the task is given. It is
recommended that the configuration is managed at the level of subtasks, otherwise it
becomes unclear how to manage the changes. When a subtask within a maintenanceprocedure needs to be changed a new variant of the subtask and/or task needs to becreated. Then it is important to have a variant identifier when a criterion substitutes one
existing subtask by another one. The criterion identifies the existing one as "out" or "old"and the new one as "new" or "in".

6.4.6

Scheduled Maintenance analysis configuration management
The Scheduled Maintenance Analysis (SMA) process is also affected by the CM, in the analysis
and also in the results of it. SMA uses the failure modes as source for the analysis and theresult of it is the scheduled maintenance task.
−

SMA logic configuration
The logic is oriented to the failures mode/effects. Since failures modes are configured, thelogic of the SMA is also configured and traceability of this analysis is required identifying
the effect of criterion implementation.

−

SMA disposition configuration
Disposition is linked to the causes, so different causes introduced by a criterion canderivate in a different disposition.

−

Other SMA configuration aspects
The results of the SMA are the scheduled tasks. These tasks can be different as aconsequence of a change (criterion).

6.4.7

Support equipment change compilation
Support equipment is part of the support system. They belong to the configuration of the
support system but also they have configuration because they have components.
−

Support system
The support equipment belonging to the support system does not have direct applicability.
The applicability is derived from the task where they are used. Support system has function
and the support equipment covers these functions. In the same way as equipment for
operational system, there can be more than one alternative to comply with the support
system function. This means that several pieces of equipment can have the same BER anddifferent hardware element realizations. Support equipment will also have design evolution
and therefore product variants of one support equipment can be found.

−

Configuration inside support equipment
There are modifications from a supplier of support equipment that authorize changes to the
support system. Support equipment configuration is managed in the same way as the otheritems of the operational system. So the recommendation for this support equipment is totreated as operational system equipment configuration. In these cases product variant isrecommended. In some cases the support equipment could be a very large piece ofequipment and the applicability of their components needs to be oriented to MSN of theequipment. In other words the support equipment is like a product.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6865-03000-00

6.5

Applicability management

6.5.1

General
It has been defined how to manage the change and how to create and maintain configuration
items for the whole system (operational and support systems). The configuration is not uniqueand every product can have different components. Therefore it is required to know theconfiguration of every product or, the other way around, for every item of the configuration the
products where it is assembled. This is provided by means of an applicability management.
The following figure shows how to obtain the applicability of a configuration item (in this case a
DM is used as an example) using the applicability of the criteria assigned to a configuration
item. Nevertheless, DM is S1000D terminology and is used here for any package of ILS/LSA
package of information. Examples of this DM usage are systems descriptions, maintenancetasks, Failure Modes and Effects Analysis and reliability data.

Applicability of criteria
from … toCriterion
Criterion

Design / Customer

DM criteria

DM criteria

Applicability of DM
from … toComponent

Component applicability
from … toCriteria
component
in/outAuthoring

Configuration calculation

ICN-B6865-S3000L0086-001-01
Fig 4 Applicability calculation based in the criteria applicability
This scheme will be explained in detail in the following paragraphs. Basically when a set ofcriteria is applied to a DM the applicability of every criterion in this set is transferred to the DM
creating the applicability or applicability of the DM and also the applicability of the components(in the case of a maintenance task: Spares, support equipment, steps, personnel, etc)
6.5.2

Manufactured serial number and fleet serial number concepts
From the customer point of view, operation or service are the targets for a system. In the end,
the operation is complied by a single product. A Manufactured Serial Number (MSN) identifies
this single product. It is a unique number to identify the product. It is mandatory that every
product has an MSN. Therefore, the range of MSN where it is mounted mainly identifies theapplicability of an item.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6865-03000-00

0001

0002

0003

0004

0005

0006

0007

0008

0009

The component is installed on aircrafts: 0001, 0003, 0004, 0005, 0007, 0009
Its applicability is:0001, 0003 – 0005, 0007, 0009

ICN-B6865-S3000L0087-001-01
Fig 5 MSN usage example
The Fleet Serial Number (FSN) is another possibility. The concept of fleet is based in the
combination of two concepts: customer and version. Version is a set of products with basicallythe same configuration because they are thought to comply with the same type of missions orwith the same operational characteristics. Minor differences can occur between the products
belonging to a version due mainly to evolutions or improvements. The conjunction of a productfor a customer is defined as the fleet. A product is identified by customer + version + serial
number inside version.
Fleet: IB01

001

Fleet: GAF01

002

n…

001

002

n…

Fleet: RAAF01

001

002

003

004

005

Customer version:
Version rank:

n…
RFR01
005
ICN-B6865-S3000L0097-002-01

Fig 6 Fleet example
There must be a correspondence between MSN and FSN.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6865-03000-00

item installed in

MSN

Standard

0001
0002

ST1
ST1

Customer version Version rank
IBF01
GAF01

001
001

0003

ST1

IBF01

002

0004

ST1

IBF01

003

0005

ST1

GAF01

002

0006

ST1

GAF01

003

0007

ST1

RAAF01

001

0008

ST1

RAAF01

002

0009

ST1

RAAF01

003

…..

…..

…..

…..

ICN-B6865-S3000L0098-002-01
Fig 7 FSN (fleet) versus MSN
S2000M defines the applicability by fleet numbering, providing the service (code to identify thecustomer) version (eg single seat aircraft, twin seat aircraft) and serial number inside theversion.
Due to the planning for manufacturing, normally the numbering for MSN and FSN are notcoincident. The first MSN is for one customer then the second MSN is for other customer andso on.
6.5.3

Effectivity of change/criterion
A change proposal can be applicable to all products or can be limited to one or more range of
products. This range is defined by two figures:−

MSN from
Identify the first MSN where the change is applicable. This item is included.

−

MSN toIdentify the last MSN where the change is applicable. This item is also considered included.

Other possibility of expressing the applicability of change/criterion is providing the version andthen the range inside the version. It is possible that a change/criterion apply to more than one
version/range.
6.5.3.1

Example: Design criteria applicability to LSA applicability
In the traceability management process it has been described how to indicate the affectation acriterion has to a configured item. The following example shows how to convert this into
applicability ranges for an item.
−
−
−
−
−

First step: The first criterion called criterion 1 is defined having the applicability by MSN
from 0001 to 9999.
It is used to create a new BER of A212101 and for a new hardware element realization of
P/N1. Criterion 1 makes applicable ("in") the range of serial numbers.
For that affectation BER of A212101 has an applicability from 0001 to 9999.
A new criterion with an applicability 0020-9999 creates a variant for the existing BER with a
new hardware element realization of P/N2 and the same product variant with a new block ofserialized items.
As a result of it :••breakdown element revision of A212101 and hardware element realization of P/N1 is
only applicable from 0001 to 0019
breakdown element revision of A212101 and hardware element realization of P/N2 is
only applicable from 0020 to 9999

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6865-03000-00

6.5.3.2

Example: Design criteria applicability to IP/IPD configuration item (CSN/ISN) applicability
The following figure shows an example of applicability calculation for IP/IPD items based on
CSN and ISN.
Authoring Toolcriteria: MOD-1
CSN

ISN

Impact

005

00A

Out

Pre MOD (out)

005

05A

In

Post MOD (in)Criteria, CSN, ISN,
impact (in/out)

CSN + ISN + applicability

Applicability calculation
criteria: MOD-1
criteria applicability: 0010-9999

005

00A

0001-0009

005

05A

0010-9999

ICN-B6865-S3000L0099-001-01
Fig 8 Applicability calculation
6.5.4

MSN versus FSN applicability management
MSN or FSN are used when the product or element with a change in its configuration does notchange its P/N. In this case the MSN or FSN is used to distinguish between the different
configured end Items. For example where the P/N of the aircraft is not changed, the MSN or
FSN is required to identify the different aircraft manufactured. In the case of an equipment
where the configuration of the equipment is changed, the P/N of the equipment is also changed.
Then the UOC is used to identify the applicability of the component of every equipment
identified by different P/N.
MSN applicability is oriented to the manufacturing. It is a number that does not change during
its life. Normally the applicability in design is given by this way so criteria coming from design
will usually have this type of applicability.
For FSN applicability, it is recommended that the rules and definition of S2000M are used. It is
recommended that the use this type of applicability is utilized because it is easy to customize
the information that is to be delivered.

6.5.5

Product variant management
Product variant (formerly represented by a Usable on Code, UOC) is used mainly for equipment
or other items where the configuration is not managed by MSN. In this case, when changes
occur, the P/N of the item also changes. This is a method to identify the configuration of a P/N
configured item similar to a color code (mainly used for equipments configuration management).
Product variant is used to identify each model of a product. The hardware element revision canbe associated with each applicable product variant to form the overall breakdown of a product.
Fig 9 is an example of using an applicability code (eg like a UOC) for the product variant.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6865-03000-00

A – SP01

Equipment levelA242101
IDG from supplier 1,
mounted in productversion SP01

Product level A
Versions: SP01 & GA01

A – GA01

A24 – 0000

System level A24
Electrical power, no item variants

A242 – 0000

Subsystem level A242
AC generation, no item variants

A2421 – 0000

Sub-subsystem level A2421
Integrated drive generator system,
no item variants

A242101 – 000A

A242101– 000B

Applic: SP01

Applic: GA01

Equipment levelA242101
IDG from supplier 2,
mounted in productversion GA01

1st component levelA24210101 – 000A

A24210102

A24210101 – 000B

Applic: SP01

Applic: SP01 & GA01

Applic: GA01

two versions of IDG piece part A24210101

ICN-B6865-S3000L0100-001-01
Fig 9 Example for applicability to Product versions
6.5.6

Serialized item management
Serialized Item Management is a requirement for delivery configuration management.
This is accomplished by marking populations of select items (parts, components, and products)
with a serial number identifier, enabling collection and analysis of maintenance data about theitems. As a minimum, it is appropriate to consider selecting item populations from within thefollowing categories:−−−

Repairable items down to and including sub-component repairable unit level
Life-limited, time-controlled, or other items with records (eg logbooks, aeronauticalequipment service records)
Items that require technical directive tracking at the part number level

For these serialized items it is necessary to provide the delivery configuration. This delivery
configuration is a list containing the following information:−−−−

MSN of the product
BER of serialized item
Part number of serialized item
MSN of the serialized item

6.6

Production and releases management

6.6.1

GeneralThe main objective of the CM is to know the build standard of the product (operational systemand support system). It is necessary to control the changes of a component of the end productas these changes may, in time, result in changes to the end product itself.
This includes a set of elements to be managed, like:

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6865-03000-00

−
−
−
−
6.6.2

End product identification
It is necessary to manage the identification of the different end products to be delivered to thecustomer. In the end product identification two factors need to be considered:−−

6.6.2.1

End product identification
Management of end product releases
Change traceability of the releases
Customization of releases

Function or operation of end product that implies the use of end product type identification
Timing evolution due to change implementation

End product type
Every end product has two components in its identification depending on the type ofdifferentiation used to make the classification:−

Operational system
It is the system that performs the mission required by the customer (eg passenger aircraft,or military transport aircraft or combat aircraft). The model and the version are used to
identify the different types of operational system products.

−

Support system
It is a system used to support the operational system. As the type of support to be provided
is different, a more detailed classification is needed. For example, technical manuals havedifferent functions. They serve as an operational manual used to provide the required
information to operate the operational system and as maintenance manuals used to repair
the operational system. Each must be managed in harmony with the operational system.
Similarly, the LSA database can be considered as a kind of support system product storing
the results of the LSA activities.

6.6.2.2

Versions, releases and issues of a productDepending on the changes included as a consequence of time evolution of the end product due
to design changes or customer requirements changes, another type of identification must be
included. This is the version identification. So the end product is identified by means of the typeof product plus the version or release identification.
−

Concerning operational system
This is identified by the version or more exactly by the MSN. When several MSN have thesame configuration they can be grouped in a version. But the version does not ensure that
all the Products included in the version have exactly the same configuration, as it was
explained previously.

−

Concerning support or training equipment
The product is identified by a P/N or for complex equipment it is also identified by a MSN.

−

Concerning support information (eg LSA database, technical documentation, training
courses) version, issues or release numbers are used to identify the product.

An identification process is required for the management of the different releases or versions(there are other possibilities of defining versions depending on the function of the item such as
single seat combat aircraft or double seat combat aircraft for pilot training purposes). Rules forproper releases identification must be included in the CM plan document.
6.6.3

Change traceability of releases
As it has been stated, the concept of the release is developed because there are changes
occurring over time. Due to this, it is necessary to know what is included in every release of a

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6865-03000-00

product. In other words, a list of criterion must be provided for every release. This list provides
the traceability of changes included in the release, as well as, the authority for this release.
Normally, it is required to identify any component of the release affected by a criterion. For
example an aircraft maintenance manual is an assembly of DMs. This requirement implies that,when a new release is issued, it is necessary to identify the DMs that have been modified
regarding previous issues, as well as the criterion or criterions that have led to that change.
6.6.4

Release management
Release management ensures a proper CM of the releases. The following is a list of therequirements needed to ensure efficient management and quality of a release.
−−

A release coordinator is required to organize the tasks to be performed in order to provide
the customer with a coordinated issue of the new release of all end products that aredelivered at a milestone. This job is linked to the high-level CM activities.
A set of tasks must be included covering the activities to be executed by the different ILS
disciplines in order to produce the support end products which are under their
responsibility. This end product must be prepared in a coherent way (eg the aircraft
maintenance manual must be in accordance with the IPD. It would not be acceptable thatthe aircraft maintenance manual makes reference to a spare that is not in the IPD. The
criterion used would be that spares in a task of the aircraft maintenance manual must be in
the IPD.
Because the release is defined as the changes included from the last delivery as aconsequence of implementing a set of criterion, a mechanism must be used to link therelease management to the criterion management. Only when the criterion included in therelease has been fully applied, the release can be considered as ready for delivery. This job
is linked to the detailed CM.

−

The status of the tasks provides a visibility of the status of a release.

The following figure illustrates the release management as the management of a set of activities
to be performed:−−

Tasks oriented to the preparation of the deliverables. Every one of these tasks is anotherset of tasks oriented to the jobs to be done to prepare the release.
Tasks oriented to the criteria. There is one task per criterion used to define the newrelease. So one release can be understood as a set of criteria. This process links therelease management to the change management.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 26

S3000L-B6865-03000-00

New release(activity)
GenerateBC/ABC
BC/ABC
Generate

GenerateLSA
LSA
Generate(activity)(activity)

GenerateBreakdown
BreakdownStructure
Structure
Generate
StoreininCSDB
CSDB
Store

GenerateTech.
Tech.
Generate
ManualManualAssembly
Assembly(activity)(activity)

Publishmaintenancemaintenancemanual
manualPublish……
……

(activity)(activity)

Criterion11
Criterion(task/activity)(task/activity)

ILS
disciplines
task status
ILS
disciplines
ILS
disciplinestask
taskstatus
statusILS
ILSdisciplines
disciplinestask
taskstatus
status……
Criterionnn
Criterion(task/activity)(task/activity)

ICN-B6865-S3000L0101-001-01
Fig 10 Release management
6.6.5

Customization of a release
When a release is delivered to a customer it is clear that the release is unique for that customer.
So the contents of every release are not only influenced by the criterion included in the releaseelaboration but depending on the customer, the contents of the release are different.
The applicability of the end product components is the key to provide customization. Since thecomponents have applicability referred to the mission product identification (MSN or versions or
customer fleet), it is possible to discard any component that it is not applicable to this customer.
Criterion that does not affect a customer should not be included in the release definition.

S3000L-A-04-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-04-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 4
2010-04-01 Page 27

S3000L-B6865-03000-00

Chapter 5
Influence on design
Table of contents

Page

Influence on design ........................................................................................................................ 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 3
2
Design considerations ..................................................................................................... 3
2.1
Availability ........................................................................................................................ 3
2.2
Reliability ......................................................................................................................... 5
2.3
Maintainability .................................................................................................................. 5
2.4
Testability......................................................................................................................... 5
2.5
Prognostics ...................................................................................................................... 5
2.6
Standardization ................................................................................................................ 6
2.7
Interchangeability............................................................................................................. 6
2.8
Environmental considerations ......................................................................................... 6
2.9
Human factors/ergonomics.............................................................................................. 7
2.10
Obsolescence .................................................................................................................. 7
2.11
Supportability ................................................................................................................... 7
2.12
Cost effectiveness ........................................................................................................... 7
2.13
Software design ............................................................................................................... 8
3
Development programs/projects...................................................................................... 8
3.1
Strategy for LSA influence on design .............................................................................. 8
3.2
Design influence on development programs ................................................................... 8
3.3
Supplier design ................................................................................................................ 9
3.4
Critical/milestone design reviews .................................................................................... 94
Checklists ...................................................................................................................... 10
4.1
Selection of parts/equipment ......................................................................................... 10
4.2
Reliability ....................................................................................................................... 10
4.3
Maintainability ................................................................................................................ 11
4.4
Testability....................................................................................................................... 11
4.5
Prognostics .................................................................................................................... 11
4.6Standardization .............................................................................................................. 11
4.7
Interchangeability........................................................................................................... 11
4.8
Environment................................................................................................................... 11
4.9
Human factors/ergonomics/accessibility ....................................................................... 11
4.10
Obsolescence ................................................................................................................ 12

List of tables
1

References ...................................................................................................................... 2

List of figures
1
2
3

Opportunity to influence design and support cost during product lifetime ...................... 3
Breakdown of availability as an approach to structure design influence ......................... 4
Effectiveness - balancing availability and life cycle cost ................................................. 8

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

References
Table 1 References
Chap No./Document No.

Title

Chap 7LSA Failure modes and effects analysis

Chap 8

Damage and special event analysis

Chap 13

Software support analysis

Chap 17

Disposal

1

General1.1

Introduction
This chapter covers the subject of LSA parameters influencing the design of the Product.
It should be a principle for the staff involved in the LSA and in the related ILS disciplines toclaim the influence on design as one of the main goals of supportability engineering. For staff
involved in design (software or hardware), Influence on Design is important in order to interact
between the Product design program and LSA program.

1.2

Objective
The broad objectives of LSA are to influence design, create the most effective support concept,
and define logistic support resource requirements. In this chapter, the focus is put primarily on
the influence of the Product design; however, it is not possible to isolate it from the iterative
work needed for an effective support solution or from requirements on logistic support
resources.
General objectives for the Product must be translated into more specific requirements for anindividual project. The key to a productive and cost effective LSA is the concentration ofavailable resources on activities which most benefit the program. Such concentration might becalled the analysis strategy. When deciding on an analysis strategy, it is necessary to consider
the type and scope of the development project. The possibilities of influence may also vary due
to previous design decisions and the life cycle status.
The opportunity for influencing design in order to fulfil LSA requirements is at its highest in the
beginning of a project, during the conceptual phases. Early design influence can reduce or
eliminate the need for later design changes (need for redesign) in order to make the Product fit
for operation and support. LSA requirements are considered useful for designing a new productwith regards to total system availability and cost effectiveness. The purpose is to influence thedesign with LSA requirements in a manner similar to how the design of the support system isinfluenced by the primary product design and requirements. This is done in a structured way
within a project through reviews and baselines.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

ICN-B6865-S3000L0077-001-01
Fig 1 Opportunity to influence design and support cost during product lifetime
Integrated design teams enable requirement and product design to benefit both the Product andthe customer. LSA is considered to be an integral part of systems engineering.
The logistics footprint, the physical size and distribution of the support resources of the
supporting logistics system is influenced by the Product design and a structured iterativeinteractive closed loop is necessary between design disciplines and LSA disciplines.

1.3

Scope
The scope of this chapter is to describe:
−
−
−
−
−

design parameters to be influenced by LSA and vice versa
how to make a strategy for LSA influencing design
the perspectives of supplier and vendors
reviews of milestones, critical or not
the benefits of LSA influencing the design

The approach to influence the design with the parameters of availability is applicable on
systems and subsystems within the Product as well as the support systems design anddevelopment.

2

Design considerations
Many considerations could be made upon design; the following are a list of features which could
be used to influence the design of a primary product with regards to making the end
product/system more efficient and cost effective.

2.1

Availability
Availability is the measure of the degree to which an item is in an operable and ready-for-use
state at the start of a mission or operation, when the mission or operation is called for at an
unknown time. This is sometimes called operational readiness.
Reliability, maintainability and supportability all contributes to the availability of a system.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

The inherent availability of a system is driven by the reliability and maintainability of the
Product. It could be described as the probability that a system, when used under statedconditions in an ideal support environment (ie no lack of support resources) will operatesufficiently at any point in time. It excludes preventive maintenance, delay times and isexpressed as

Ai =

MTBF
MTBF + MTTR

where MTBF is the mean time between failure and MTTR is the mean time to repair.
The achieved availability is similar to inherent availability with the exception that preventive
maintenance is included. It is expresses as

Aa =

MTBM
MTBM + M

where MTBM is the mean time between maintenance and M is the mean active maintenanceaction time.
Operational availability is achieved through the combination of the Product and its support
system. It could be described as the probability that a system, when used under statedconditions in an actual support environment, will operate sufficiently when called for. It is
expresses as

Ao =

MTBM
MTBM + MDT

where MDT is the mean maintenance down time.

1

Here is a most important point - the availability of the Product, is effectively gained by putting
requirements on both the Product and the support system, and is achieved by the combinationof the two through maintenance actions.

ICN-B6865-S3000L0078-001-01
Fig 2 Breakdown of availability as an approach to structure design influence

1

Availability definitions after Benjamin S Blanchard, Logistics Engineeringthand Management, 6 edition, Prentice-Hall, Inc., Englewood Cliffs, New
Jersey 07632
Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

2.2

Reliability
Reliability is a prime driver of support resources. It relates to the duration or probability of
failure-free performance of a Product under stated conditions, or the probability that an item canperform its intended function for a specified interval under stated conditions.
Products with high reliability are usually cost effective. The design of a Product could be madethat reduces and compensates for the implication of a low reliability so when a failure occurs, it
is easy to locate the failure and easy to perform corrective actions. To maintain availability, it is
to some extent possible to compensate low reliability with increased maintainability andsupportability.

2.3

Maintainability
Maintainability is the measure of the ability of an item to be retained in or restored to a specified
condition, when maintenance is performed by personnel having specified skill levels, usingprescribed procedures and resources, at each prescribed level of maintenance and repair.
Characteristics of maintainability are, for example, the time it takes to replace or repair a
Product or a system in order to restore or maintain its functionality, the amount and complexityof support resources that are required and the required skill levels of the personnel performing
the activities.
The design could be sensible or be able to withstand the environment in different degrees. For
example the design could be specific to withstand an operational and maintenance environment
in airports/airbases, loading/unloading with support equipment or to withstand sandstorms,
hail,and salt laden environments. For possible inputs to consider, please refer to Chap 8.
For maintainability aspects for software, such as software loading, please refer to Chap 13.

2.4

Testability
Testability is a design characteristic which allows the status (operable, inoperable, or degraded)of an item and the location of any faults/failures within the item to be confidently determined in atimely fashion.
The design solution to fulfil testability requirements could be achieved by a test system
integrated into the Product; or the test system as a part of the support resources requiring aninterface to the Product in order to locate failures.
Carefully designed test systems can reduce the work needed to locate and correct
failures/faults and can also be used to verify full system functionality.
Redesign driven by testability requirements, from the LSA FMEA, is a highly complex activity.
Milestones in the design program should be added to allow for necessary iterations. For more
information on LSA FMEA please refer to Chap 7.

2.5

Prognostics
Product parameters and data could be used in models to predict maintenance need or repair.
The functionality of maintenance or repair prognosis could either be part of the Product or the
support systems each have different advantages.
The benefits of prognostics are increased means of knowing a Product “health” status and,based on that knowledge, avoid critical failures and plan for activities to maintain system
functionality.
In a system that does not have a means of prognostics; preventive maintenance is used toprolong the system lifetime and system safety, and is balanced against the corrective
maintenance actions and resources.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

2.6

Standardization
It is usually cost effective to use standard equipment instead of equipment which is speciallydesigned. Development/design cost and time is reduced when using an existing part or systemthat fulfils the requirements.
Utilization of existing logistic support resources, which fulfil the requirements, could also be
possible when using standardized equipment and reduce the need for investments in design
and acquisition of support systems resources. Design decisions that lead to the need of
specially developed SE should be considered carefully since such equipment drives cost.
Other positive effects related to this could be increased product/system maturity and knowledge
and an increase of mobility of the operational unit.
Factors that support the potential benefits are the following:
−
−
−
−
−

Use of existing items avoids the development costs that would be incurred to develop new
support resources
Cost to develop new training programs may be avoided
Commonality of support resources may increase the availability on support resources andreduce the logistics footprint
Use of standardized items reduces the development time required to determine support
resource requirements
Personnel proficiency in using support and test equipment can be increased through anincrease in frequency of use of the same item, rather than having to learn how to use
different items

Standardization includes the requirement of interchangeability.
Software design could also be given standardization requirements and could be put on
languages, information structures or software and information carrying media for example.
To achieve the benefits, requirements on standardization must be established prior to initiationof the design effort so that the cost of designing or redesigning to meet requirements can be
minimized.

2.7Interchangeability
Products should be designed so that the equipment, components and parts are interchangeable
within or between Products, where applicable. The purpose is to increase flexibility of usage ofthe equipment and a reduction of spare stock levels.
To achieve the benefits, requirements on interchangeability must be established prior toinitiation of the design effort so that the cost of designing or redesigning to meet requirements
can be minimized.

2.8

Environmental considerations
Known operational environment and maintenance environment information could influence thechoices of equipment and design solutions. Temperatures, humidity, sandy and salty
environments, are examples of parameters that influence operation and maintenance.
It is also of interest to ensure that the Product fulfils requirements in-between operation- duringtransportation, assembly and disassembly and storage. Taking these considerations into
account increases the robustness.
Chemicals/materials needed for maintenance, operation and disposal from an environmental
perspective are also important. The implications to include hazardous materials, hazardous
waste, and environmental pollutants could have an impact on the Life Cycle Cost (LCC) as wellas the safety of personnel in contact with the Product. For more information and depth on thissubject, please refer to Chap 17.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

2.9

Human factors/ergonomics
Requirements on the Product for human factors and ergonomics could be formulated. The
Product could be designed in such a way that the accessibility for operators and technicians aretaken into consideration. Activities during operation and maintenance with humans in the loop
should be given consideration. Handling qualities, for example, parameters such as weight andsize could be relevant drivers for support resources in order to physically be able to perform
activities.
Design tools can be used to analyze (virtually or by other means) the accessibility for humanand the disassembly and assembly activities.
Chemicals/materials as part of the Product or needed for maintenance, operation and disposal
are also important from a human factors perspective. The implications to include hazardous
materials and environmental pollutants could have an impact on the safety of the personnel andthe need for support resources.
Product interface requirements such as access panels for technicians or maintenancepersonnel and operator stations requirements are a joint interest for LSA and design.

2.10

Obsolescence
Depending on the Product life cycle length, it could be useful to consider the possible situationof obsolescence during the design phase. Where obsolescence occurs, actions will benecessary to keep the functionality. Examples of typical actions are re-design/modification,
lifetime purchasing activities or scrapping of the system and replacement with a new system.
When designing or choosing systems or sub-systems to a design, it is useful to keep in mind
the future replacement of an item due to obsolescence.

2.11

Supportability
Supportability is the measure of the degree to which all resources required to operate andmaintain the Product are provided in sufficient quantity. Supportability encompasses allelements of ILS support resources such as technical information, support equipment, spares,
personnel etc.
Through careful system design, the amount of resources required for supporting a Product canbe reduced by considering maintainability and reliability. Product downtime, in reality consistingof active maintenance time, logistics delay times and administrative delay times can be
reduced. A Product that requires a lot of support resources is more exposed to the risk ofshortage of support resources, waiting or queuing for resources.

2.12

Cost effectivenessThe design and the choices involved in design have a cost implication for the life cycle cost. Life
cycle cost could be broken down into design/development, production/procurement, operationaland disposal costs. Comparative analyses between different alternatives of design solutions,
including the support resources, are required. The characteristics mentioned previously in thisparagraph and cost are necessary to balance availability and LCC.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

ICN-B6865-S3000L0079-001-01
Fig 3 Effectiveness - balancing availability and life cycle cost

2.13

Software design
Software is usually a part of modern Product design. Certain considerations could be made to
influence the software design in order to give the software some of the features mentioned
previously in this paragraph.
Considering the consequences of software support actions described in Chap 13, software
support analysis, decisions can be made regarding how the software should be designed andimplemented in order to achieve the availability requirement of the system.

3

Development programs/projects
Development programs/projects should include LSA and all efforts should be done in adocumented, structured, interactive closed loop process.
A representative for LSA should be appointed and part of the project team.

3.1

Strategy for LSA influence on design
The key to a productive and cost effective analysis effort is the concentration of available
resources on activities which most benefit the program. Such concentration might be called theanalysis strategy.
The broad objectives of LSA are to influence design, structure the most effective support
concept, and to define logistic support resource requirements. These general objectives mustbe translated into more specific objectives for individual projects. The amount of design freedom(flexibility) and opportunity of design influence varies with the type of program/project and is themain input when deciding on a strategy.
Objectives and the analysis strategy should be iterated, refined and balanced against available
resources until they become firm program goals or requirements.

3.2

Design influence on development programs
The very nature of development programs may vary from−new development programs where the Product and support products are developed fromthe very beginningor−

be system or subsystem design changes/improvements of an existing ProductorApplicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00−

be a fast track program using existing technology developed in-house or by a supplier.

The amount of design freedom and possible design influence therefore shifts. Often, adevelopment program of a complex Product is a combination of the different types. LSA effort
and objectives should be focused accordingly.
Furthermore, the possibility of design freedom may exist for the support system but not theProduct, and vice versa. The LSA objective of making reliability, maintainability andsupportability requirements an integrated part of Product requirements and design can best be
achieved if designers are oriented toward reliability, maintainability and supportability objectives
commencing with the design effort.

3.3

Supplier design
Supplier design ie design performed by a vendor or subcontractor, should be approached in thesame manner as in-house design.
It is important to provide the supplier with LSA goals and requirements specific to the supplier inorder to influence supplier design before the design efforts commence.
In conjunction with design influence by requirements and goals, the requiring party must initiallydecide and specify the LSA tasks that are to be done by the supplier, which tasks are to beshared between the requiring party and the supplier, and those that are to be performed solely
by requiring party. Once done, the LSA portion of the contracting plan can be developed andwork requirements written into the procurement documentation.
It is very useful to allow the prospective performing activities, under the bidding terms of the
procurement, to recommend adding or deleting LSA tasks and to provide a more detailed
subtask definition and schedule.
Additionally, prospective performing activities should be encouraged to make use of costeffective data generation procedures. Acquisition program objectives must be considered in
preparing procurement documents. For example, in technology demonstration procurement,
one may specifically exclude certain LSA task requirements. Supportability objectives for thistype of procurement would best be served through design influence and generation of an LSA
data for subsequent detailed analysis efforts when the technology is utilized. If the acquisition
program is oriented to develop and procure a Product, then other LSA tasks become equallyimportant.

3.4

Critical/milestone design reviews
It is of great importance to establish and document design review procedures (where
procedures do not already exist) which provide for official review and control of released design
information with LSA program participation in a timely and controlled manner.
These procedures shall define accept/reject criteria, the method of documenting reviews, thetypes of design documentation subject to review, and the degree of authority of each reviewing
activity.
Program/project planning must coordinate the design and development reviews and the LSA
reviews.
Formal review and assessment of LSA requirements shall be an integral part of each Productdesign review. Results of each Product design review shall be documented. Design reviews
shall identify and discuss all pertinent aspects of the LSA program.
Technical information generated and documented during the design process must be
disseminated among designers and supportability specialists in order to surface interface
problems between design concepts and operators, maintainers, and support equipment.
Technical design information such as diagnostic features, interfaces, reliability estimates,

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00

obsolescence evaluations, and item functions, which determines supportability, should be an
integral part of design documentation.
Scheduled reviews should be performed "bottom up" to include subcontractors and suppliers, as
appropriate.
Agendas shall be developed and coordinated to address the relevant topics as they apply to theprogram phase activity and the review being conducted.
Examples of topics are:−−−

LSA conducted by task and WBS element
LSA assessment of proposed design features including supportability, cost, and readinessdrivers and new or critical support resource requirements
Corrective actions considered, proposed, or taken, such as:
•
•
•
•
•

−
−
−
−

4

Support alternatives under consideration
System/equipment alternatives under consideration
Evaluation and trade-off analysis results
Comparative analysis with existing Products
Design or redesign actions proposed or taken

Review of LSA requirements - supportability (with review of specifications as developed)
Progress toward establishing or achieved goals
LSA documentation required, completed and scheduled
Design, schedule, or analysis problems affecting LSA

Checklists
To facilitate design work and reviews, the following checklists can be used as a starting point
and input. However, creativity in defining checklist questions and in adjustments to the programin question is absolutely necessary. Often, the checklists can be defined through dialogue2
between the LSA and design disciplines.

4.1

Selection of parts/equipment
−
−
−
−

4.2

Have appropriate standards been consulted for the selection of parts?
Have the selected parts/equipment been evaluated with regards to reliability, maintainability
and supportability?
Have supplier sources for component part procurement been established?
Is the supplier reliable in terms of quality level, ability to deliver on time, etc?

Reliability
−
−
−
−
−
−
−
−

Has the system/equipment wear-out period been defined?
Have failure modes and effects been identified?
Are item failure rates known?
Have parts with excessive failure rates been identified?
Has mean life been determined?
Has equipment design complexity been minimized?
Is protection against secondary failures (resulting from primary failures) incorporated where
possible?
Have reliability requirements been met?

2

Checklist developed from Benjamin S Blanchard, Logistics Engineeringthand Management, 6 edition, Prentice-Hall, Inc., Englewood Cliffs, New
Jersey 07632
Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6865-03000-00

4.3

Maintainability
−
−
−
−
−
−
−

4.4

Testability
−
−
−
−
−
−
−
−
−
−
−

4.5

−

Are modules and components that have similar functions electrically, functionally andphysically interchangeable?
Are components with the same part number but provided by different suppliers completelyinterchangeable?

Environment
−
−
−

4.9

Are standard equipment/parts incorporated in the design to the highest extent possible?
Are the same parts used in similar applications?
Is the number of different part types used throughout the design minimized?
Are identifying labels and markings and nomenclature standardized to the highest extent?

Interchangeability−

4.8

Is the functionality to predict maintenance need identified for the equipment?
Are the parameters used to predict maintenance need identified and obtainable?
Is the sampling frequency of the parameters used for prognostics adequate?

Standardization
−
−
−
−

4.7

Have self-test provisions been incorporated where appropriate?
Is the extent of self-test compatible with LORA?
Is the self test automatic?
Have direct fault indicators been provided? (eg light, message)
Are test points/interface provided to enable check-out and fault isolation beyond the level ofself test?
Are test points/interface accessible?
Are test points/interface functionally or conveniently grouped to facilitate sequential testing?
Are test points/interface provided for direct test of replaceable items?
Are test points labelled?
Can every equipment malfunction be detected by a no-go indication at system level?
Will software provide adequate test information?

Prognostics
−
−
−

4.6

Are the total numbers of different kinds of fasteners minimized?
Are the fasteners used standard items?
Have the fasteners been selected based on the requirement for standard tools incomparison with special tools?
Are equipment identified as replaceable items?
Is the time it takes to replace an item minimized?
Is consideration taken upon the operational environment, such as hail storms, sandy andsalty environment?
Is consideration taken on how to load software, loading times and media?

Are the hazardous material and pollutants identified and kept to a minimum?
Are the material and equipment chosen for the design costly to handle, store and todisassemble or waste?
Are special containers or facilities necessary when using the hazardous materials or
pollutants?

Human factors/ergonomics/accessibility−−−

Are doors provided where appropriate? Are they hinged?
Are the size and location of openings adequate for access?
Are the doors and openings labelled? What information is contained in the label?

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−

4.10

Are access doors fasteners minimized?
Are access doors fasteners of the type quick-release?
Can access be gained without tools?
If tools are needed to gain access are the number minimized and of standard variety?
Are access between modules and components adequate?
Are the hazardous material and pollutants identified and kept to a minimum?
Is it necessary to use protective equipment when performing the maintenance task?
Are maintenance tasks possible to perform with protective equipment if necessary (eggloves, helmet)?
Are number of lifting devices for heavy or bulky items minimized?
Is the time it takes to carry out a maintenance task reasonable compared with the working
position?
Are access requirements compatible with the frequency of maintenance?

Obsolescence
−
−
−
−
−

Is the item at risk for obsolescence during the lifetime of the product?
Is the design made to facilitate redesign if necessary due to obsolescence?
Is there a possibility of emulation or re-creation of the design?
Is there an after market source available?
Is the supplier required to inform and initiate a purchase process of parts to cover the restof the lifetime?

S3000L-A-05-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-05-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 5
2010-04-01 Page 12

S3000L-B6568-03000-00

Chapter 6
Human factors analysis
Table of contents

Page

Human factors analysis .................................................................................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
1.1
Introduction ...................................................................................................................... 1
1.2
Objective .......................................................................................................................... 1
1.3
Scope ............................................................................................................................... 2
2
Logistic support analysis and human factors .................................................................. 2
2.1
Human physical abilities .................................................................................................. 2
2.2
Limitation of human beings because of health threat ...................................................... 2
3
Human factors analysis aspects ...................................................................................... 3
3.1
Influence on design ......................................................................................................... 3
3.2
LSA guidance .................................................................................................................. 3
4
Human factors to be considered...................................................................................... 4
4.1
Anthropometric aspects ................................................................................................... 4
4.2
Ergonomic aspects .......................................................................................................... 4
4.3
Environmental aspects .................................................................................................... 4
5
Additional information ...................................................................................................... 5

List of tables
1
2
3

References ...................................................................................................................... 1
Sample limits for lifting ..................................................................................................... 4
Sources for additional information ................................................................................... 5

References
Table 1 References
Chap No./Document No.

Title

MIL-STD 1472F

Human engineering, design criteria for military systems,
equipment and facilities

1

General1.1

Introduction
This chapter describes the relationship and integration between human factors and the logistic
support analysis process. Human factors provide source data that can be used by LSA todetermine maintenance crew and support equipment requirements. This relationship begins in
the design process and continues through the development of the maintenance task analysis.

1.2

Objective
The functions of LSA, maintainability and supportability respectively must be closely
coordinated to ensure that potential support solutions are within established support thresholds

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

including the requirements of human factors. This is accomplished by considering the crew size
and the required support resources for operational and maintenance tasks. Limitations becauseof human factors influence the establishment of the support environment as well as the designof the Product itself. The factor human being determines the activities concerning usage of a
Product and support of a Product. Especially in the area of support, human factors havedecisive influence on the practicability of operational or maintenance activities

1.3

Scope
This chapter is directed at logistics personnel who perform technical and logistic analysis
activities. Some of the analysis activities are highly influenced by the abilities and the naturallimitations of a human being. The results of the human factors analysis should be documented
carefully and they should be available at a very early project phase. Some logistic decisions are
influenced decisively by human factors. Within the LSA database the influence of human factors
can appear at different places. For example warnings and cautions can be a typical criterion as
well as the need for specific equipment to perform a task and to protect the human being
against the unpleasing environment.

2

Logistic support analysis and human factors

2.1

Human physical abilities
The LSA and human factors integration occurs throughout the whole product life cycle. Each
modification or proposed design change could require changes in maintenance which require a
review of the human factor constraints and limitations. Especially at the end of the life cycle
during the disposal phase, human factors can be of crucial interest because of the need ofhandling material, which is critical for human health.
LSA and human factors functions have a very common objective but distinct purposes or goals.
The human factors aspects focus on the various standards concerning:−−−−

Anthropometric aspects
Ergonomic aspects
Environmental aspects
Other physiological aspects

LSA should take into account these standards to evaluate potential support solutions. One ofmany examples of this is the diameter of the average human forearm. Any access panel that
requires a reach beyond the wrist must conform to the minimum size that is standardized
accordingly. The human factors should influence the design to assure that this size requirement
is achieved for all access panels. In addition, LSA has to consider the need for special toolingthat may be required to complete a given task being performed under limited moving spaceconditions. During this analysis if an alternative is recognized that alternative may be presented
back to design for reconsideration.

2.2

Limitation of human beings because of health threat
Another aspect concerning human factors is the limitation of human activity because of healththreat. The handling of dangerous material or material which is hazardous to health must follow
strict regulations to ensure physical integrity. The same holds for work which must be carriedout under extreme environmental conditions like:−−−−very cold or very hot environment
very humid environment
working underground or underwater
critical environment because of other reasons (eg dust, exposure to fumes, noise)

Regulations have to ensure the protection of human beings against the implications of theseenvironmental impacts. These regulations must be taken into consideration for logistic analysis
activities as well as the limitations because of physical restrictions.

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

3

Human factors analysis aspects

3.1

Influence on design
There are many industry standards that address human factors design constraints andrequirements. These should be appropriately referenced as part of the developer/customer
agreements and included in the contract.
The human factors qualitative data have to be taken into account for determination of themaintenance crew skills, size and support equipment needs. For example, human factors will
provide weight limits for a single person lift. These weight limits are then used to identify the
maintenance crew size for a specific task. Same analysis will also identify the need formechanical lifts and/or maintenance stands. This information may be used in a trade-off study
for design alternatives as an iterative process. Human factors provide specifications andstandards that have to be applied to the individual maintenance tasks.
If applicable, the personnel requirement "crew size" should take into account the demographic
aspects as well. For example, an all male crew may have a greater lift limit than a mixed
male/female crew. Therefore, the weight of the item may define the proper number of people
required for lifting but that quantity could change with the specific crew demographics. The
weigh restriction is to be taken into account for mechanical lift requirements and therefore
impact support equipment requirements. The location may influence the need for maintenancestands but the maintenance crew size should be considered in the definition of the type of standrequired.

3.2

LSA guidance
The LSA guidance conference should identify the rules and guidelines that will be applied to the
LSA and human factors analysis which may include eg maintenance crew demographics, lift,
reach and other standards and limitations. The customer and contractor must agree on specificstandards that will be applied. In addition to agreeing on the standard it is advisable to review
the standard and document any exceptions.
LSA receive input from design and develop trade-off analysis of each drawing alternative. From
the first drawing effort, LSA will analyze the design and compare support requirements between
alternatives and make recommendations based on the supportability and life cycle cost. The
process involves identifying all the possible maintenance actions. Each maintenance actions
will result in a list of resources required to accomplish each task. These resources include part,
maintenance man-hours, training, support equipment and test equipment. The specificconsiderations relative to human factors will be the number of maintainers and the amount of
human factor related support equipment.
The number of maintainers may be influenced by the variety of skills required and the weightand size of the parts being changed during the maintenance action. Factors effective the skills
will be sub-tasks that are necessary to complete the maintenance action. The weight and theheight it must be lifted should also be taken into account in order to identify the maintenancecrew size. Each of the various Human Factor standards has weight limits for a single person lift.
The amount may vary based on crew demographics and the height it must be lifted. Also if theitem is to be carried over a distance the standards should define the weight and distance limits.
Table 2 below is taken from MIL-STD 1472F and is a sample of those limits reflecting US DOD
regulations.
These limits may vary between standards but in all cases should be applied to the maintenancetask analysis. Should the item exceed these limits then additional maintainers should be usedprovided the appropriate number of handles are attached. The two-hand lift defined above will
require two handles or two grip areas. If multiple persons are required for lifting then the charts
in the Human Factor standards that define maintainer size must be checked against thephysical dimensions of the item to assure that multiple persons can actually assist in themaintenance. If the weight or size exceeds personnel lift limits then the item may require
mechanical assist for lifting.

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

Table 2 Sample limits for lifting
Handling function

Population (male Populationand female)(male only)

Lift an object from the floor and place it on a surface notgreater than 152 cm (5 ft) above the floor.

16,8 kg (37 lb)

25,4 kg (56 lb)

Lift an object from the floor and place it on a surface notgreater than 91 cm (3 ft) above the floor.

20,0 kg (44 lb)

39,5 kg (87 lb)

Carry an object 10 m (33 ft) or less.

19,0 kg (42 lb)

37,2 kg (82 lb)

The entire process is an iterative process and will need to be used for each design change.
LSA will begin the more detailed maintenance task analysis once the final design is approved.
The maintenance task analysis will then compare each of the maintenance subtasks against thehuman factors standard to assure that the proper steps are documented.

4

Human factors to be considered
The following paragraph should give a very rough overview which human factors should betaken into consideration within LSA activities. The lists are not limited to the aspects given here
but should serve to receive an impression which aspects of human factors can influence thedesign of Products and, especially in the area of LSA, the design of the support environment(operational and maintenance related).

4.1

Anthropometric aspects
−
−
−
−
−
−
−
−

4.2

Ergonomic aspects
−
−
−
−
−
−

4.3

Lines of sight (visual field, vertical and horizontal)
Audio signals requirements
Muscle strength of arms, hands and thumb
Required muscle strength for vertical pull extensions
Required muscle strength for horizontal push and pull movements
Maximum weight of units to be lifted
Maximum weight of support equipment
Arm and hand access dimensions

Design of controls (eg switches, cranks, joysticks, ball controls, hand wheels, levers,
pedals, knobs)
Minimum handle dimensions
Workspace design (eg seated, standing, mobile)
Difficult accessibility - ramps and ladders
Doors and access panels dimensions
Illumination requirements

Environmental aspects
−
−
−
−
−
−
−
−

Effective temperature
Limits of extreme cold and warm temperature conditions
Influence of wind-chill on human beings
Decreased performance of human beings under extreme climatic conditions
Ventilation requirements
Exposure limits ultraviolet radiant energy
Exposure limits to pollution like dust, fumes, etc
Noise limitations

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00−

5Shock current intensities

Additional information
Each program should define a standard for use in the analysis process. The links below are
examples where you can find more detailed information to evaluate the human factor related
support requirements of any design.
Table 3 Sources for additional information
SourceURL

US Government standards

http://www.hfetag.com

Human Factors and Ergonomics http://www.hfes-europe.org
Society (HFES)
Designing for humans

http://www.designingforhumans.com

S3000L-A-06-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-06-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 6
2010-04-01 Page 5

S3000L-B6568-03000-00

Chapter 7
LSA failure modes and effects analysis
Table of contents

Page

LSA failure modes and effects analysis ......................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 3
1.4
Interface with related analyses ........................................................................................ 3
1.4.1
FMECA in design and development activities ................................................................. 3
1.4.2
LSA FMEA and design-oriented FMECA ........................................................................ 4
1.4.3
LSA FMEA and maintainability, maintenance and safety analysis ................................. 4
2
Analysis procedure and subprocess description ............................................................. 4
2.1
General flow chart............................................................................................................ 4
2.2
Establish FMEA for replaceable units ............................................................................. 5
2.2.1
Limit the breakdown level ................................................................................................ 5
2.2.2
Easy identification ............................................................................................................ 5
2.2.3
Take software into account in the breakdown ................................................................. 6
2.2.4
Physical breakdown and LSA FMEA ............................................................................... 6
2.2.5
Prediction of failure rates ................................................................................................. 7
2.3
Identify available means of failure detection ................................................................... 8
2.3.1
Detection means .............................................................................................................. 8
2.3.2
Detection rates and detectability ratings ......................................................................... 8
2.3.3
Identification of requirement for new test equipment....................................................... 9
2.4
Identify possible means of localization of failed items ..................................................... 9
2.4.1
Localization means .......................................................................................................... 9
2.4.2
Localization ability ratings .............................................................................................. 10
2.5
Analyze requirements for troubleshooting procedure .................................................... 10
2.5.1
Cases in which a procedure is required ........................................................................ 10
2.5.2
Detection confirmed upon possible false alarm ............................................................. 11
2.5.3
Interface with criticality analysis .................................................................................... 11
2.5.4
Troubleshooting upon detected but not localized failure ............................................... 12
2.6
Elements required for a troubleshooting procedure ...................................................... 12
2.7
Record results................................................................................................................ 12
3
Inputs ............................................................................................................................. 13
3.1
Physical breakdown ....................................................................................................... 13
3.2
FMEA ............................................................................................................................. 13
4
Outputs .......................................................................................................................... 13
4.1
Subprocess outputs to be recorded............................................................................... 13
4.2
LSA FMEA tabular report .............................................................................................. 14
5
Complementary analysis ............................................................................................... 16
5.1
Criticality analysis .......................................................................................................... 16
5.2
Removal criteria ............................................................................................................. 16
5.3
Software failure analysis ................................................................................................ 16
5.4
Troubleshooting task analysis ....................................................................................... 16
5.5
New test equipment management documents .............................................................. 17
6
Lessons learned ............................................................................................................ 17
6.1
Undetectable failures ..................................................................................................... 17
6.2
Random failures............................................................................................................. 17
6.3
Influence on design ....................................................................................................... 18
Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

6.4
6.5

Failure rates and failure modes rates ............................................................................ 18
Limits of software failure analysis .................................................................................. 18

List of tables
1
2
3
4
5
6
7
8
9

References ...................................................................................................................... 2
Failure mode ratio distribution ......................................................................................... 7
Failure mode ratings ........................................................................................................ 8
Detection ability ratings ................................................................................................... 9
Localization ability ratings ............................................................................................. 10
Troubleshooting upon false alarm ................................................................................. 11
Troubleshooting assessment from localization rate of built-in tests .............................. 12
Outputs of each sub process ......................................................................................... 13
Recommendations for LSA FMEA tabular report .......................................................... 14

List of figures1
2
3

Logical flowchart of analysis procedure .......................................................................... 5
From technical FMEA to LSA FMEA - grouping of failure modes ................................... 6
LSA FMEA tabular report .............................................................................................. 14

References
Table 1 References
Chap No./Document No.

Title

Chap 3LSA Business process

Chap 21

Terms, abbreviations and acronyms

1

General1.1

Introduction
Logistic Support Analysis (LSA) Failure Modes & Effects Analysis (FMEA) is part of eventdriven maintenance analysis.
Whereas Scheduled Maintenance Analysis (Chap 10) focuses on scheduled and preventive
maintenance, LSA FMEA (Chap 7) and Damage and Special Event Analysis (Chap 8) focus oncorrective maintenance.
More precisely, LSA FMEA establishes the methodology and decision logic that should be aprerequisite to the identification of corrective maintenance tasks to be applied to the Product incase of an inherent failure occurrence.

1.2

Objective
All items and equipment liable to fail are candidates for corrective maintenance whether they
are subject to servicing or preventive maintenance tasks or not. Some failures may be detectedor observed during operation or during a maintenance task or inspection. Other failures may be
detected but not localized, and others are not detectable at all.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

Therefore, in several cases, additional search and troubleshooting work will be necessary to
precisely identify and localize failed items so that they can be removed and replaced.
This work:−−−

is characterized by data that could be derived from a FMEA and must be populated in the
LSA record
must be documented in the maintenance publications
may require special tools and test equipment

The objective of this procedure is to provide a methodology that helps define the maintenancetasks rendered necessary by the inherent limits of reliability and testability (integrated or not),and the related support means.

1.3

Scope
The scope of this procedure is to:
−
−
−
−
−

exploit existing documents as far as possible (FMEA from the design office, for instance), or
build on existing FMEA data or build a new FMEA, tailored to LSA needs, if no existing
documents are available
analyze means available for detection of failures and for localization of failed items
identify possible requirements for specific troubleshooting procedures
identify possible requirements for special tools and test equipment
record all results

It is applicable on any item within the system, specifically developed for the needs of a new
system, re-used from a previous program, or acquired from the commercial-off-the-shelf range
of a supplier.

1.4

Interface with related analyses
Several types of FMEA and Failure Mode, Effects and Criticality Analysis (FMECA) exist as
parts of design, development and production management activities. According to the natureand requirements of the individual program, these FMECA may be:
−
−
−

1.4.1

mandatory to satisfy regulatory requirements (eg nuclear plants, chemical plants, transports
systems subject to airworthiness or seaworthiness regulations, military systems)
purposely implemented to manage the achievement of an objective (eg improve safety,
improve reliability, improve mission availability) throughout the program
purposely implemented to identify and justify corrective maintenance activities triggered byinherent failure causes: this is the purpose of LSA FMEAFMECA in design and development activities
The FMECA is an essential function in design from concept through development. The effective
FMECA is iterative and corresponds with the nature of the design process itself. The extent ofeffort and sophistication of approach used in the FMECA depends upon the nature andrequirements of the individual program. This makes it necessary to tailor the requirements for a
FMECA to each individual program. Tailoring requires that, regardless to the degree ofsophistication, the FMECA contributes meaningfully to program decision. A properly performed
FMECA is invaluable to those who are responsible for making program decisions regarding thefeasibility and adequacy of a design approach.
The usefulness of the FMECA as a design tool and in the decision making process depends
upon the effectiveness with which problem information is communicated for early design
attention. Timeliness is one of the most important factors in differentiating between effective andineffective implementation of FMECA. While the objective of a FMECA is to identify all modes offailure within a system design, its first purpose is the early identification of all catastrophic andcritical failure possibilities so they can be eliminated or minimized through design correction at
the earliest possible time. Therefore, the FMECA is generally initiated as a functional FMECA

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

as soon as preliminary design information is available at the higher system levels, and extended
to the lower levels as more information becomes available on the items in question.
Although the FMECA is an essential reliability task for design activities, it also provides
information for other purposes. The use of the FMECA or of some analysis derived from it iscalled for in maintainability, safety analysis, availability analysis, logistic support analysis,
elaboration of maintenance concept, and in failure detection and fault isolation. This coincident
use must be a consideration in planning the FMECA effort to prevent the harmful proliferation ofrequirements and the duplication of efforts within the same contractual program.
One of the analyses derived from FMECA is LSA FMEA.
1.4.2

LSA FMEA and design-oriented FMECA
Whereas design-oriented FMECA needs to analyze and quantify the reliability of each individualcomponent of a system, such a level of detail not always essential for maintenance purposes
because the maintenance activities may not focus on the individual components but on
replaceable or repairable units, which maybe located at a higher level of breakdown than that ofindividual components.
Therefore the LSA FMEA is generally coincident with, but not identical to, design-oriented
FMECA. Tight interface, coordination and milestones must be implemented between these two
activities to ensure adequate consistency, timeliness and traceability between them. Theinterfaces and specific data element needs shall be defined in the LSA Plan, and agreed
between LSA, design FMEA functions and testability analysis.

1.4.3

LSA FMEA and maintainability, maintenance and safety analysis
Other maintainability, maintenance or safety analyses use data from LSA FMEA or derived fromFMECA, eg Level of Repair Analysis (LORA), Reliability-Centered Maintenance (RCM) and
Scheduled Maintenance Analysis (SMA). In order to take full benefit of existing works and to
avoid useless duplication of works, these other activities must be tightly interfaced andcoordinated with FMECA and LSA FMEA in the LSA Program Plan, refer to Chap 3.

2

Analysis procedure and subprocess description

2.1

General flow chart
The workflow of the analysis procedure is presented on the general flowchart hereafter.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

Inputs

S3000L-B6568-03000-00

Product breakdown
intended down to s
replaceable units

Functional
analysis

Softwarefailureanalysis

Testability
analysisSub-processes

Influencing aspects

Operatingcontext(ORD)

Technical
FMEA / FMECALSA failure modes andeffects of item under
Logistic Support Analysis

Replaceable units
Possible failures
Failure modes
Failure effects

Identify available means offailure detection

Warnings
Built-in tests
Physical symptoms
Functional symptoms

Identify possible means oflocalization/verification of
failed item

Analyze requirement fortroubleshooting procedureWarnings
Built-in tests
Test equipment

Troubleshooting
tasks
Removal criteria

Record results

ICN-B6865-S3000L0080-001-01
Fig 1 Logical flowchart of analysis procedure

2.2

Establish FMEA for replaceable units
As a general consideration, the process described hereafter is based on the re-use, andpossible additional data elements to be added, of an existing FMEA/FMECA. These results
should be grouped as much as feasible in order to keep the effort to be spent at a sensible, lowlevel. This sub-process essentially consists of merging the FMEA/FMECA and the physicalbreakdown. Preparatory works may be necessary before this merging is rendered possible.

2.2.1

Limit the breakdown level
The physical breakdown generally goes down to individual components required for detailed
definition purposes. For the needs of malfunctioning analysis, it does not need to be developed
beyond the level of replaceable units, except if further development of breakdown helps inunderstanding or describing failure modes and/or possible inspection or repair of thereplaceable unit. A first step is to limit the physical breakdown at the appropriate level. This is
usually done by extraction and simplification of the complete physical breakdown.

2.2.2

Easy identification
Failures, failure modes and items of the physical breakdown will be frequently quoted in further
analysis and analysis reports. It is recommended to adopt an easy-to-use identification method
for these failures, failure modes and items.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

2.2.3

Take software into account in the breakdown
Replaceable units that have software should include this software as sub-component for
configuration management purposes. This is independent of the reload ability of software,
provided that reload ability is equivalent for software of replace ability for hardware. Note thatsome software may have defects, too, especially on non-mature systems.

2.2.4

Physical breakdown and LSA FMEALSA FMEA must be compliant with the physical breakdown. This means the items liable to failmust be taken among the items of the physical breakdown. This also means that failures mustbe listed or grouped for each replaceable unit.
Breakdownelement

Grouping resultof LSA FMEA

Failure mode 1
Failure mode 2
Failure mode 3
Failure mode 4
Failure mode ..

LSA
Failuremode 1

Repair procedure 1
Failure detection procedure 1

LSA
Failuremode 2

Repair procedure 1
Failure detection procedure 2

LSA
Failuremode 3

Repair procedure 2
Failure detection procedure 1

LSA
Failuremode 4

Repair procedure 3
Failure detection procedure 3

Failure mode..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..

Result oftechnical
FMEA/
FMECA

Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode ..
Failure mode n

ICN-B6865-S3000L0081-001-01
Fig 2 From technical FMEA to LSA FMEA - grouping of failure modes
Grouping should be performed by taking into consideration the following criteria:−−

All failure modes generated within a technical FMEA/FMECA, which cause one and thesame chain of maintenance activities, should be grouped to one LSA failure mode within
the LSA FMEA.
All aspects which have to be taken into consideration concerning grouping of failure mode
should be agreed between customer and contractor within the LSA guidance conference.
Fig 2 gives an overview how these crucial grouping criteria can be realized.

While grouping, the failure rate of the item under analysis will be distributed to the LSA failuremodes. This is required for calculation of the corresponding task frequencies of the rectifying
tasks linked to the LSA failure modes.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

Table 2 Failure mode ratio distribution
Failure Mode

FMR

Rectifying tasks

LSA failure mode 1

0,10 ( 10%)

Repair procedure 1 + Failure detection procedure 1

LSA failure mode 2

0,15 ( 15%)

Repair procedure 1 + Failure detection procedure 2

LSA failure mode 3

0,50 ( 50%)

Repair procedure 2 + Failure detection procedure 1

LSA failure mode 40,25 ( 25%)

Repair procedure 3 + Failure detection procedure 3

The Failure Mode Ratio (FMR) identifies the fraction of the individual failure mode on the entire
failure rate of the item under analysis.
Note
It must be considered that the distribution of failure rates in connection with physicalbreakdown elements must be analyzed from breakdown indenture level to the next
neighbouring indenture level. This principle is of crucial importance to get a coherent viewof failure rates within a complete physical breakdown.
In practice the breakdown is often incomplete down to the last small part. In this case it canbe possible that the sum of failure rates of indenture level n+1 is smaller than the failure
rate of the breakdown element on indenture level n. On the other side, a failure rate on
indenture level n, which is smaller than the sum of failure rates on the deeper indenturelevel n+1 is not logical and should be rechecked carefully.
In the case of an idealized situation of a complete breakdown, the sum of the failure rates
of indenture level n+1 should be the failure rate of the breakdown element of indenturelevel n.
2.2.5

Prediction of failure rates
For the purposes of LSA FMEA, failure rates must be established for each LSA failure mode.
If no analytical method is applicable, the failure rates may be assessed by best engineering
judgement from experience on similar systems of comparable complexity and operated in asimilar context.
Failure rates may be calculated by an analytical method (eg MIL HDBK 217, RDF-93, RDF2000 UTE-C 80-180).
If no dependable failure rate is available, a rough rating table should be established. The
following qualitative table is provided as an example. It can be tailored according to needs andto the operating context, which must be defined first.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

Table 3 Failure mode ratings
Rating Occurrence

Description

Probability of single
failure1

Very low likelihood

Very few failures likely

Less than 0.001

2

Low likelihood

Few failures likely

Between 0.001 and
0.01

3Moderately low
likelihood

Occasional failures likely

Between 0.01 and 0.10

4Medium likelihood

Medium number of failures
likelyBetween 0.10 and 0.20

5Moderately highlikelihood

Moderately high number of
failures likely

Higher than 0.20

Note
The above ratings 1 to 5 correspond respectively to the levels E to A of the qualitative
approach of MIL-STD-1629 Procedure for performing a failure mode, effects and criticality
analysis.

2.3

Identify available means of failure detection

2.3.1

Detection means
For each possible failure of a replaceable unit:
−
−
−
−
−

Check whether the failure is detected by any form of automatic detection which triggers awarning device.
Check whether the failure is liable to be detected by a BIT. If yes, assess the detection rate
and false alarm rate of this BIT. These rates are relevant here when related to replaceable
units, not to functions.
Irrespective of the answer to the previous question, check functional symptoms and/or
physical symptoms likely to help detect the failure. For this check, failure effects listed in
FMEA may be considered as a guideline.
List all failures detectable by any of the above means, record the associated detectionmeans.
List failures undetectable by any of the above means.

Note
These detection means are a generalization, irrespective of the level of maintenance, of the
failure detection methods and failure detection means of MIL-STD-1629.
2.3.2

Detection rates and detectability ratings
The detection rate is the probability of the detection means to effectively detect the failure.
If some built-in tests (BIT) are embedded in the replaceable units, detection rates may beassessed by an analytical method as part of testability analysis. Therefore the LSA FMEA
should be adequately interfaced with testability analysis in order to take benefit of the detection
rates issued from it. This data may not be available from the Technical FMEA/FMECA.
If no analytical method is applicable, a qualitative approach should be preferred. This qualitative
assessment may be based on best engineering judgment. The following table is provided as an
example. It must be tailored according to needs.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

Table 4 Detection ability ratings
Rating Detection
probability

Description

Detection rate

1

High likelihood

High effectiveness for detection

Higher than 80%

2Moderately highlikelihood

Moderately high effectivenessfor detection

Between 80% and 60%

3Medium likelihood

Has medium effectiveness for
detection

Between 60% and 40%

4Moderately low
likelihood

Moderately low effectiveness for
detection

Between 40% and 20%

5

Low likelihood

Low effectiveness for detection

Less than 20%

Note
The probability of the detection means to effectively detect the failure must be rated inaccordance with what is considered effective in terms of scheduled maintenance analysis.
That means that the above ratings must be consistent with the effectiveness of visualinspections, detailed inspections, special detailed inspection, visual checks, operational
checks and functional checks deemed effective for the purpose of scheduled maintenance.

2.3.3

Identification of requirement for new test equipment
The above table may be used to identify a requirement for additional test equipment or built-intest liable to raise detection probability from an unacceptable rating up to an acceptable one.
This identification is generally performed as part of testability analysis for BIT’s, and as part ofmaintenance task analysis for additional test equipment. Therefore the use of the above table
for the purpose of identifying a requirement for an additional detection means should beinterfaced with testability analysis and with Maintenance Task Analysis (MTA).

2.4

Identify possible means of localization of failed items

2.4.1

Localization means
For each detected failure of a replaceable unit:
−
−
−

−

−

Check whether an automatic detection (if any) triggering a warning device is likely to
localize without ambiguity the one replaceable unit that has failed, or if it is likely to localize
one out of n replaceable units that has failed (one-among-n ambiguousness).
Check whether a BIT (if any) is likely to localize without ambiguousness the one
replaceable unit that has failed, or if it is likely to localize one out of n replaceable units thathas failed (one-among-n ambiguousness).
Check whether a monitoring system is likely to localize without ambiguousness the one
replaceable unit that has failed, or if it is likely to localize one out of n replaceable units thathas failed (one-among-n ambiguousness). There are such monitoring systems for healthand usage monitoring, for example.
Check whether applicable functional checks, leading to detection by functional symptom,
are likely to localize without ambiguousness the one replaceable unit that has failed, or ifthey are likely to localize one out of n replaceable units that has failed (one-among-n
ambiguousness).
Check whether cross-checking of BIT results may help reduce the ambiguousness of thelocalization (i.e. reduce the value of n in the "one-among-n ambiguousness"). For thiscross-check, a special attention may be paid to BIT results which are impacted by acommon cause.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6568-03000-00

−

2.4.2

Check whether applicable visual checks or measurements without any dismounting or
removal, leading to a detection by physical symptom, is likely to localize without
ambiguousness the one replaceable unit that has failed, or if it is likely to localize one out ofn replaceable units that has failed (one-among-n ambiguousness).

Localization ability ratings
Localization is limited to detected failures.
Localization ability ratings may be elaborated as part of testability analysis on products entirely
covered by built-in tests. Some additional engineering may be required to the results of thesetests have to be cross-checked with other source of information (eg functional checks, visualchecks, visual inspections without removal) in order to reduce the ambiguousness. In somecases, this additional engineering may be performed by an activity external to LSA (eg fault tree
analysis); if it is the case, adequate interface must be implemented with LSA FMEA. This data
may not be available from the technical FMEA/FMECA. If that is the case the data should be
retrieved from the testability analysis.
The following table is provided as an example. It must be tailored according to needs.
Table 5 Localization ability ratings
Rating Localization
probability

Description

Localization ability
rating

1

High likelihood

High effectiveness of theabovementioned localization
means

Higher than 90%

2Moderately highlikelihood

Moderately high effectiveness for
localization

Between 80 and 90%

3Medium likelihood

Medium effectiveness for
localization

Between 60% and 80%

4Moderately low
likelihood

Moderately low effectiveness for
localization

Between 40% and 60%

5

Low likelihood

Low effectiveness for localization

Below 40%

2.5

Analyze requirements for troubleshooting procedure

2.5.1

Cases in which a procedure is required
Basically, a troubleshooting procedure is required when:−−a failed item is not likely to be localized without ambiguity by any of the localization means
described in Para 2.4.
a failure has been detected by a built-in test known to have a high false alarm rate.

However, cases in which such a procedure is required are hardly ever defined by a simple
cross-grid of the previous tables. The main reasons for this are:−−−detection rate and localization rate are statistical variables, and are generally bound to
failure rate and failure mode rate.
defining a threshold on the detection and the localization rates would create an artificial
threshold effect.
if the failure has been detected by a built-in test with a false alarm rate known to be high, its
results may not be ignored if the failure has some possible impact on safety. This remains
true even if the BIT has been repeated without detecting a failure.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6568-03000-00−

the requirement for troubleshooting is not entirely dictated by detection and localization
ability and should be analyzed in the light of complementary elements, such asaccessibility, removal and replacement costs, or safety.

Therefore, analyzing the requirement for a troubleshooting procedure needs some expert’s bestengineering judgment. The following guidelines may be used after being tailored according toneeds. They assume that detection rate and localization rate take the failure rate/failure mode
rate into account.
2.5.2

Detection confirmed upon possible false alarm
Prior to any troubleshooting, the failure detection may be confirmed if there is a doubt about thereality of the detected failure. However, it must be remembered that a non-repeated detection of
failure may be due to a random failure of the tested equipment itself, regardless of false alarm
rate of the testing device.
Therefore, it is recommended to assess the need for this preliminary step from the importanceof the consequences of the failure:
Table 6 Troubleshooting upon false alarmConsequencesof failure

Repetition of test forremoval of ambiguousness

Follow-on actions

Negligible

The test may be repeated acertain number of times (to be
determined) with the usual test
device or built-in test until it isconfirmed or invalidated.

If the failure detection isinvalidated, no further analysis is
to be carried out and theequipment may be declared backto operational status.
If the failure is confirmed, need fortroubleshooting is assessed as in
Para 2.5.4.

Not negligible but
acceptable

The test may be repeated acertain number of times (to be
determined) with anindependent test device until it
is confirmed or invalidated.

If the failure detection isinvalidated, no further analysis is
to be carried out and theequipment may be declared backto operational status.
If the failure is confirmed, need fortroubleshooting is assessed as innext paragraph.

Unacceptable

The test needs not be
repeated.

Proceed as in next paragraph.

In any case, the need for repetition of test and the follow-on actions must be documented in aprocedure which should be applicable prior to the troubleshooting procedure itself.
2.5.3

Interface with criticality analysis
On products on which a criticality analysis is performed, thresholds of acceptability used in theleft column of the above table must be consistent with the consequences of the failure mode
and/or the criticality of the replaceable item.
In this approach, the worst potential consequence of the failure must be taken in considerationand determined by the degree of injury, property damage, system damage or environmental
impacts that could ultimately occur. This analysis is addressed by the severity analysis in
FMECA methods (eg MIL-STD-1629).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6568-03000-00

This potential consequence of a failure mode may or may not be combined with the probabilityof occurrence of the failure, depending on the nature of the product. This combination isaddressed by the criticality analysis in FMECA methods (eg MIL-STD-1629).
The failure on critical or very severe failure modes should always be considered as
unacceptable, even if there is a possibility for the detection to be a false alarm. Therefore thetroubleshooting procedure requirement analysis must be interfaced with the FMECA.
2.5.4

Troubleshooting upon detected but not localized failure
The following table is just provided as a guideline. It should be tailored according to needs.
Table 7 Troubleshooting assessment from localization rate of built-in tests

2.6

Localization
ratingTroubleshooting required

1

No troubleshooting required. Localization will be performed by the BIT.

2

Troubleshooting is required but may be performed by cross-checking of
BIT results.

3

Troubleshooting is required and may require an intervention ofmaintenance team to perform additional research of symptoms

4 or 5

Troubleshooting is required, using test equipment likely to compensate
the inability of the BIT to localize the failed replaceable unit.

Elements required for a troubleshooting procedure
Elaborating on the troubleshooting procedure itself is out of the scope of LSA FMEA. However,in order to simplify subsequent works, several documents or analyses used to determine if sucha procedure is required should be noted for further use:
−
−

−
−
−
−
−

The technical documents and definition files that must be used to analyze thetroubleshooting requirement (eg technical plan, wiring diagram, interface description).
Logical order of the tests to be carried out until the failed replaceable unit is identified andlocalized. This logical order may be backed-up by a flow-chart diagram on which alldecisions should be applicable (that means, associated with the clear interpretation of asymptom or a BIT result). All decision not associated with such an interpretation should beconsidered as not applicable. Test equipment or inspection procedures which may benecessary should be documented.
Possible cross-checks that could help identify and localize the failed unit. Such crosschecks are fruitful for identifying sources of common cause failures. They should concern
items exposed to the effects of the common cause failure.
Symptoms to be monitored or recorded during these cross-checks.
Measurements to be carried out to check the physical and/or functional characteristics ofthe replaceable units.
Test equipment required by the above measurements.
Expected values for each of these measurements, and signification of unexpected
measures.

Refer to Para 5.4 for the elaboration of the troubleshooting procedure itself.

2.7

Record results
Results are to be recorded as troubleshooting tasks, which are preliminary tasks for corrective
maintenance. These tasks are to be attached to the next higher assembly including all thereplaceable units concerned. They shall list all the support elements which have been identified
during the above sub process in addition to usual data characterizing a maintenance task. The

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6568-03000-00

corrective maintenance task for removal and replacement of the failed replaceable unit is to bementioned. Troubleshooting task and removal/replacement tasks may be subtasks of a repair
task.

3

Inputs3.1

Physical breakdown
Physical breakdown (or product breakdown) provides an indented decomposition of the main
product. For FMEA purposes, it should be developed down to the level of replaceable units atleast. The corresponding depth of indenture may vary in accordance with the concerned item.
Further development to sublevels of these items may be necessary only when it helps
characterize the failure modes of the item or the related failure effects. Otherwise it can bedispensed with. Replaceable units should be easily identifiable in this breakdown.

3.2

FMEA
Failure Modes and Effects Analysis (FMEA) provides some or all of the following information:
−
−
−
−
−
−

a list of items likely to failthe associated failure rates
the related failure modes foreseen
the probability of occurrence of these failure modes
the consequences (effects) of these failure modes regarding the availability of thereplaceable unit and its impacts on safety and overall availability
the signature of the failure (eg physical symptoms, functional symptoms, BIT results)

This FMEA may be carried out as part of a product safety analysis, of a product mission
reliability analysis, or provided by the supplier of the equipment.

4

Outputs

4.1

Subprocess outputs to be recorded
The outputs listed in the following table are summarized in Fig 3.
Table 8 Outputs of each sub process
Sub-process

Outputs

Establish FMEA for replaceable unit

Replaceable units
Possible failures
Failures modes
Failure effects

Identify available means of failure
detection

Warnings
Built-in tests reports
Physical symptoms
Functional symptoms
Requirement for new test equipment

Identify possible means of localization Warnings
Built-in tests reports
of failed item
Ground test equipment
Requirement for new test equipment
Analyze requirements fortroubleshooting procedure

Applicable to: All

Answer yes/no to need for a troubleshooting
If yes, inputs for troubleshooting task analysis

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6568-03000-00

4.2

LSA FMEA tabular report
It is recommended to issue a tabular report that provides all important information and outputs
in a convenient form.
The columns of this table may be populated as sub-processes go along.
An example of LSA FMEA tabular report is given in Fig 3. Recommendations for filling thecolumns are provided in Table 9.
Note
Header possibly required for purposes of traceability and quality management of the LSA
FMEA has not been included. This header may provide release date, issue number,
author’s name, approval signatures, information required for identification of theitem/replaceable unit, etc.
This tabular report is to be tailored according to needs.

Relaceable unit identification

Function

Failure Modes

Failure causes

Failure effects

Failure mode ratio (FMR)

Detectability rating

Detection means

Localize ability rating

Localization means

Troubleshooting required

Procedure requirement

Test equipment required

Numbers in circles refer to recommendations provided in the table on the following page.

1

2

3

4

5

6

7

8

9

10

11

12

13

ICN-B6865-S3000L0083-001-01
Fig 3 LSA FMEA tabular report
Table 9 Recommendations for LSA FMEA tabular report
ColumnDescription

1

Replaceable unit identification
Item name. This item may be followed by its physical breakdown, provided thateach line contents only one item or sub-part of item. The item name may be
accompanied with or replaced by appropriate reference number or breakdown
element identifier.

2

Function
Function that the replaceable unit fulfils or contributes to

3

Failure modes
Cause-to-effect phenomena leading to the failure

4

Failure causes
Triggering event or circumstances of the failure mode

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6568-03000-00

ColumnDescription

5

Failure effects
Impacts and consequences of the failure, in terms of safety, function availability,
collateral damage, non-compliance with regulations or specifications. This
column is to be used to document effects of a LSA failure mode.
Failure effects may be sorted and analyzed as:-

Local effects: impacts of the failure on the operation and functions of thereplaceable unit in the breakdown level under consideration. The
impacts include second-order effects resulting from failure. The purposeof this characterization of local effects in LSA FMEA is to help define
local detection criteria of failures.

-

Next higher effects: impacts of the failure on the operation and functionsof the replaceable unit in the next higher breakdown level. The purposeof this characterization of local effects in LSA FMEA is to help define
detection criteria of failures.

-

End effects: total effect that the failure has on the operation, function, or
status of the Product. The end effect may by the result of a double
failure. For example, failure of a redundant device may result in an end
effect in the event that both the prime device and its backup (redundant)
device fail; otherwise the end effect is a reduction of reliability or safetylevels due to the loss of redundancy. The end effects resulting from adouble failure shall be indicated in the LSA FMEA tabular report.

If necessary, Column 5 may be split in sub-columns to clarify the presentation of
the above failure effects.
6

Failure rate
Frequency with which the replaceable unit fails, expressed in failures per hourfor each failure mode

7

Failure mode ratio or failure mode rating
LSA FMR derived from Technical FMEA or failure mode rating rated as in
Para 2.4.2.

8Detect ability rating
Detection rate as assessed in Testability analysis (if any and if appropriate) or
rated as in Para 2.3.2.

9Detection means
Short description of detection means available for this failure. These means may
be used during normal operating of the system (warning on control panel,
abnormal behaviour of the system, perceptible loss of function, functional
symptom) or during a maintenance activity (visual inspection, post-incident
checks, maintenance task, exploitation of BIT reports, physical symptoms).

10

Localize ability rating
Localization rate as assessed in Testability analysis (if any and if appropriate) or
rated as in Para 2.4.2.

11

Localization means
Short description of means available for localizing the replaceable unit or groupof replaceable units likely to have failed: warnings, built-in tests reports(especially Initiated BIT which may not be initiated during normal operation of
the system, use of ground test equipment). This column may be used to
document the signature of the failure.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6568-03000-00

ColumnDescription

12

Troubleshooting required
Yes or no, in accordance with Para 2.5.

13

Procedure requirement
Short summary or title of the maintenance task. This procedure may be either anexisting maintenance task (if no troubleshooting is required because failed unit
has been localized without ambiguousness, for instance) or a troubleshooting
procedure as described in Para 5.4.

14

Test equipment required
Short functional description of any additional test equipment found necessary or
helpful to simplify, shorten or facilitate the troubleshooting. This test equipment
may be Built-in Test Equipment (BITE) or separate equipment.

5Complementary analysis

5.1

Criticality analysis
If applicable and required, a criticality analysis should be carried out to identify critical items, forwhich failure would result in unacceptable impact. This analysis would support identification ofscheduled maintenance action that would preclude the critical failures from occurring. Refer toChap 10 Scheduled Maintenance Analysis (SMA).
After this scheduled maintenance analysis is performed, no critical item should be left with
undetectable possible failure.
Adequate identification means must be implemented to provide adequate traceability between
critical items and drawings, manufacturing, provisioning, technical publication and training. This
is normally part of System Safety Analysis, which should be interfaced with LSA FMEA in orderto review their consistency.

5.2

Removal criteria
For items exposed to progressive deterioration or to wear-out, removal criterion must be definedin terms of:
−
−

5.3

parameter to inspect or to monitor
threshold for removal

Software failure analysis
This analysis is complementary to physical FMEA and should identify software components
liable to be bugged or defective and should also identify the possible losses of functions and/or
apparent failures of the item (hardware and software) that may be induced by the defects of thesoftware. Refer to Chap 13, Software Support Analysis (SSA).

5.4

Troubleshooting task analysis
This work is carried out as any other maintenance task analysis and identifies detailed list oftools, spares, test equipment, preliminary tasks to perform for accessibility or safety, ingredientsand consumables, repair validation requirements.
This procedure will identify:−−

The technical documents that has to be used to perform the troubleshooting (eg technicalplan, wiring diagram, interface description). These documents will be included, quoted orsummarized in the troubleshooting work card.
Logical order of the tests to be carried out until the failed replaceable unit is localized.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6568-03000-00

−
−
−
−
−
−
−
−
−
−

5.5

Possible cross-checks that could help identify and localize the failed unit.
Symptoms to be monitored or recorded during these cross-checks.
Measurements to be carried out to check the physical and/or functional characteristics ofthe replaceable units.
Test equipment required by the above measurements.
Expected values for each of these measurements, and signification of unexpected
measures.
Skills and manpower required for the above cross-checks and measurements.
Possible requirement for a specific facility (eg dark room, dust-free atmosphere) in which
the troubleshooting must be carried out.
Recommended maintenance level (if applicable) at which the troubleshooting must be
carried out.
Removal criteria or repair criteria of each replaceable unit, if they are not already quoted in
the corresponding maintenance procedures.
Reference of maintenance procedures that are to be applied to fix, repair or replace thefailed item.

New test equipment management documents
Any test equipment or built-in-test deemed necessary to improve detection and/or localization
should be:−−−−

described in a specification,
managed through a development and qualification plan,adequately milestoned regarding planning for development of the system itself
adequately milestoned so that the test equipment can be taken into account in thetroubleshooting task analysis and in the maintenance procedure

6

Lessons learned

6.1

Undetectable failures
Special attention must be given to troubleshooting analysis of items:−−

exposed to failures undetected (or hardly detectable) during operation or routine
maintenancewhose failure may have hazardous effects

For these items, appropriate periodical inspection or check should be implemented in thepreventive maintenance and/or inspection plan.
For failures with catastrophic effects (ie more severe than hazardous) and, in some cases, for
failures with hazardous effects, this may be performed as part of the scheduled maintenanceanalysis (SMA, refer to Chap 10). If it is the case, no special attention is to be paid toundetectable failures during LSA FMEA process. However, LSA FMEA and SMA must be
adequately interfaced to ensure consistency of definitions, completeness of the failure modes
taken into account, and timeliness of analyses.

6.2

Random failures
Random failures may, in some cases, not be detected again during the troubleshooting.
This may be incorrectly interpreted as a false alarm generating erroneous failure detection on a
failure-free item. This interpretation is flawed, given that a failure actually occurred, even if it is
not detected again on replay.
The particular form of troubleshooting induced by random failures may generally not be
addressed by FMEA and is therefore out of the scope of this LSA FMEA procedure. It may be
addressed and managed through a specific procedure established on a case-by-case basis
upon detection of such a failure.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6568-03000-00

6.3

Influence on design
If discovered soon enough in the design process, unsolvable troubleshooting may lead topropose modifications of design, such as:−−−adding test sockets
enhancing accessibility so that a given test equipment or tooling may be used fortroubleshooting
improving testability and/or detectability

Such possible influence on design should be appropriately managed and milestoned in thedesign process, especially if a requirement for new built-in-test or test socket is deemednecessary to improve detection and/or localization (refer to Para 2.3.3).

6.4

Failure rates and failure modes rates
The failure rates and failure modes rates possibly provided by the FMEA may be used toassess which failure cause or failure mode is the most liable to occur leading to the failure. Thismay be useful to propose an order of priority among the checks and tests to be carried out aspart of the troubleshooting process.
However, it should be reminded that in several cases this order of priority is dictated byaccessibility reasons or by costs.

6.5

Limits of software failure analysis
This analysis, if present, usually does not help rating the failure occurrence probability.
In some cases, this rating may be assessed from Quality Insurance levels applied during thedevelopment of the software, or from knowledge and confidence level placed in the provider.
Moreover, a software failure is generally not associated with a failure rate, given that software
failures are not time-related. Software failures, if any, generally occurs during initial
deployments of the system and are progressively corrected through a maturity plan or a productquality improvement plan. Software failure is therefore often considered as a defect: after it iscorrected, it never happens again.
For these reasons, software failure may be considered as highly unlikely (or better) on maturesystems. Support and maturation of software are addressed in Chap 13, Software Support
Analysis.

S3000L-A-07-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-07-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 7
2010-04-01 Page 18

S3000L-B6568-03000-00

Chapter 8
Damage and special event analysis
Table of contents

Page

Damage and special event analysis .............................................................................................. 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 2
1.4
Terms, abbreviations and acronyms ............................................................................... 2
2
General flowchart............................................................................................................. 33
Sub process description/analysis procedure ................................................................... 3
3.1
Identification of special events......................................................................................... 3
3.2
Identify potential damage to be considered ..................................................................... 5
3.3
Define element or part of the product concerned ............................................................ 6
3.4
Criticality analysis ............................................................................................................ 7
3.5
Maintenance task requirement identification ................................................................... 7
4
Inputs ............................................................................................................................... 7
4.1
Physical breakdown ......................................................................................................... 7
4.2
Product usage description sheet ..................................................................................... 7
4.3
Statistical elements on special events ............................................................................. 7
4.4
Product definition ............................................................................................................. 7
5
Outputs ............................................................................................................................ 7
5.1
Special event and damage analysis tabular report ......................................................... 7
5.2
Complementary analysis ................................................................................................. 9
5.2.1
Influence on design ......................................................................................................... 9
5.3
Lessons learned .............................................................................................................. 9

List of tables
1
2
3
4
5
6
7

References ...................................................................................................................... 2
Terms, abbreviations and acronyms ............................................................................... 2
Causes of events ............................................................................................................. 3
Probability of occurrence of special events ..................................................................... 4
Technology behavior knowledge rating ........................................................................... 5
Technology sensitivity rating ........................................................................................... 6
Recommendations for damage and event analysis tabular report .................................. 8

List of figures
1
2
3

General flow chart of damage and special event analysis application logic ................... 3
Technology/damage evaluation rating ............................................................................ 6
Damage and event analysis tabular report ...................................................................... 8

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

References
Table 1 References
Chap No./Document No.

Title

Chap 12Maintenance task analysis

Chap 21

Terms, abbreviations and acronyms

1

General1.1

Introduction
Special events and damages caused during normal operation of the product will result in therequirement for maintenance as defined by the Maintenance Task Analysis (MTA) (refer toChap 12). This chapter deals with the identification and quantification of special events anddamages.

1.2

Objective
It is the objective of this chapter to present a methodology for identifying and justifying themaintenance tasks appropriate when a special event or a damage occurs to the product.
Inservice feedback on similar products in operation can be used to directly identify maintenancerequirements for special events and damages that occur on the new product. Use of thisinformation can shorten the analysis process contained in this chapter.

1.3

Scope
This chapter deals with special events and damages that may occur during the service life of a
product and the susceptibility of new technology to damage.

1.4

Terms, abbreviations and acronyms
The following specific terms, abbreviations and acronyms used within this chapter. More special
terms are explained directly within the appropriate paragraphs. Refer to Chap 21 for a full listingof Terms, abbreviations and acronyms.
Table 2 Terms, abbreviations and acronyms
Term

Definition

DamageA loss or reduction of functionality, excluding inherent failure (intrinsic
reliabilities). Normally a maintenance task will be required. Damages canbe grouped into damage families. For example concerning structures,
typical damages can be identified like scratches, dents or cracks. These
damage families are typical candidates for a standard repair procedure.

External cause

A cause is said to be external when an event independent of productusage occurs.

Internal cause

A cause is said internal when it comes from product usage by itself.

Special event

An event that occurs during a Product's life that cannot be considered as anormal way of operation. It can be due either to external causes (egmeteorological phenomenon) or to out of bound use (eg over-G maneuverof an aircraft).

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

2

General flowchart
The analysis logic is presented on the general flowchart in Fig 1.
Product usage approach

Technology approach

Identify special event to beconsidered

Identify potential damage to beconsidered

maintenance task justification

Identify element or part of the product concerned

Identify maintenance task requirement

ICN-B6865-S3000L0068-001-01
Fig 1 General flow chart of damage and special event analysis application logic

3

Sub process description/analysis procedure

3.1

Identification of special events
This subprocess is based on a simple product usage analysis. It consists of identifying thedifferent possible causes and analyzing them through each phase of the product's life todetermine whether they can lead to a special event or not. Identify the relevant special events,using the following methodology:
Step 1: List the different causes that can produce an event.
Events can be due to external or internal causes and affected by natural phenomenon or
humankind. Table 3 provides examples of different types of causes. A more complete tableshould be developed for each project.
Table 3 Causes of events

External
causesTypes of causes

ExamplesNatural phenomenon

Meteorological
AnimalStones, trees, etc.

Caused by humankind

Combat threat
Material maneuver

Caused by operation environment

Electromagnetic field
Salt/ sand/pollution laden atmosphere

Caused by transport and storage
conditions (sea, air, truck, rail, etc)

Shocks, movements and vibrations
Depressurization

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

Internal
causesTypes of causes

ExamplesCaused by unusual use

Over operational limits like "hardlanding", "over-g maneuver"Caused by internal dysfunction

Excessive heat
Excessive pressure
Excessive vibration

Step 2: Identify each usage phase of product (eg operation, maintenance, storage, transport). If
necessary each one may be subdivided into sub phases (eg for an aircraft: take off, flight andlanding).
Step 3: Apply pertinent type of causes to the different phases of product life to identify all
possible events.
Examples of special events due to external source:
−
−
−
−
−

Impact on external skin due to ground handling equipment during servicing
Impact on external skin due to cargo handling equipment during transportation preparation
Multiple impacts due to hail
Impacts on inner external skin due to runway debris during take off
Lightning strike

Examples of special events due to internal source:−−−−

Water entrapment due to a leak
Excessive stress on a tank structure due to dysfunction of pressure relief valve during a
refueling operation on ground
Excessive temperature in a bay in case of warm air leakAn unexpected wear-out of mechanical parts

Step 4: Analyze each possible event in order to characterize its probability of occurrence.
For some special events a quantitative approach may be applied based on feedback fromprevious similar products. For example: number of bird strikes happening every year.
When it is not possible to get sufficient statistical elements, a qualitative approach may be
applied using Table 4.
Table 4 Probability of occurrence of special events
RatingOccurrence

Description

1

Extremely unlikely

A special event whose probability of occurrence isessentially zero2

Remote likelihood

A special event whose probability of occurrence isunlikely. Rare numbers of special events are likely tohappen.

3

Occasional

A special event whose probability of occurrence is
occasional. A few special events are likely to happen.

4

Reasonably probable

A special event whose probability of occurrence ismoderate. A certain number of special events are likely tohappen.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

RatingOccurrence

Description

5

Frequent

A special event whose probability of occurrence is veryhigh. This special event is almost certain to occur.

Step 5: Depending on the occurrence rating from the previous step, categorize the special
event as maintenance significant or not for continuation in the process (refer to Para 3.3). The
rating level may be used to determine a threshold to tailor analysis activities.

3.2

Identify potential damage to be consideredThis sub process is based on a technology approach. Experience shows that technologies used
can be more or less sensitive to damage. The approach consists of identifying the technologies
used on the different subsystems/items of the product and analyzing them through two
considerations:−−

Is the technology well-known or new?
Is the technology damage proof or sensitive to damage?

Identify the potential damage to be considered using the following methodology:
Step1: For all subsystems/items of the product, identify the technologies used and characterize
it regarding knowledge of its behavior.
Table 5 may be used for a qualitative approach to characterize this knowledge. The grade of
accuracy of the rating may be adjusted depending on the individual program.
Table 5 Technology behavior knowledge rating
RatingTechnology behavior
knowledge

Description

1

Well known

This technology has been used on many similar programs

2

Known

This technology has been used on similar programs but
has been marginally modified for the intended program3

Quite newThis technology has been already used on similar recent
program but very little feedback is available

Step 2: Evaluate sensitivity of the technology.
For each technology identified in Step 1, identify the possible damage types that may occur. For
example:−−−Corrosion on metallic parts (general, galvanic or other types of corrosion)
Stress corrosion on a metallic assembly with constraints installed
Delaminating or humidity absorption on composite material

Evaluate its sensitivity to damage types in relation with possible damage sources.
Table 6 can be used for a qualitative approach to characterize this sensitivity. The grade of
accuracy of the rating may be adjusted depending on the individual program.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

Table 6 Technology sensitivity rating
RatingSensitivity degree

Description

1

Extremely low

This technology has an extremely low chance of damage
during product life2

Low

This technology has a very low chance of damage during
product life

3

MediumThis technology has a low chance of damage during
product life

4

High

This technology is likely to be damaged during product life

5

Extremely highThis technology is very likely to be damaged during
product life

Step 3: Select the association technology/potential damage as relevant or not to go ahead in
the process. Combining the technology behavior knowledge rating (refer to Table 5) and thetechnology sensitivity rating (refer to Table 6) from the previous steps can result in Fig 2
example. It can be used to tailor the process according to requirements. The selection threshold
can be adjusted depending on the needs of the individual program.
Sensitivity

Technology
behavior

1

2

3

4

5

1

1

1

2

3

4

2

1

2

3

3

4

3

2

3

4

4

4

ICN-B6865-S3000L0088-001-01
Fig 2 Technology/damage evaluation rating

3.3

Define element or part of the product concerned
The link between the two approaches (special event and technology) can be done in terms of
the resulting potentially damageable items:−−

A relevant special event can generate damage to an item that is made with sensitivetechnology
An element made with sensitive technology may be damaged because of a special event

The two approaches are complementary and identify potentially damageable items that may be
encountered during product life. To identify the potentially damageable items to be considered,
the following methodology is provided:
Step 1: For each special event selected, identify the affected items of the breakdown structure.
Step 2: For each association technology/damage selected, identify the affected items of the
breakdown structure.
Step 3: For each item of the breakdown structure identified at the previous steps, analyze theinstallation area/design to evaluate exposure to the different threats. For example, level of
exposure to corrosion depends on where the structural part is located. An item in a landing gear
bay is very exposed to corrosion while a watertight bay very rarely opened is significantly lessexposed to corrosion.
Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

Step 4: Using the results of the previous steps, decide for each potentially damageable items
whether or not it should be considered in the process.

3.4

Criticality analysis
In order to focus on the most significant special events /damages, a criticality analysis should beconsidered.
For each potentially damageable item evaluate the criticality in terms of consequence on the
product service life.
The following aspects should be taken into consideration:
−
−
−
−

3.5

Does the damage result in lowering safety level?
Does the damage result in lowering availability?
Does the damage result in significant ownership deterioration?
Does the damage result in significant cosmetic deterioration?

Maintenance task requirement identification
Previous steps of the process have identified and selected the significant item of the breakdown
structure affected by a special event or a possibility of being damaged during service life.
Each significant item and event must be analyzed in terms of the maintenance requirement.
This involves identifying the different maintenance tasks required to be able to:−−

Detect, localize, measure or follow each damage that might occur (eg visual inspection, nondestructive test)
Restore the function of the element (eg remove and replace task, repair task, refurbish
task)

Some elements can be grouped into families and associated damages are candidates forstandard repair procedures.

4

Inputs4.1

Physical breakdown
Physical breakdown (or product breakdown) provides an indented decomposition of the productinto systems, subsystems and items.

4.2

Product usage description sheet
Product usage description sheet provides information like operation environment andmaintenance situation.

4.3

Statistical elements on special events
Feedback from previous similar programs to quantify the occurrences of special events.

4.4

Product definition
Elements of the product definition needed are those regarding technologies employed in the
different products, systems, subsystems and items.

5

Outputs

5.1

Special event and damage analysis tabular report
It is recommended that a tabular report be developed that provides all important information andoutputs in a convenient form. These results should be recorded in an LSA database in order tokeep the traceability of maintenance task requirements.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

An example of a damage and special event analysis tabular report is given in Fig 3. A
description of each column is contained in Table 7.
Note
Although not shown in Fig 3, header information to include release date, issue number,
author’s name, approval signatures, information required for identification of themaintenance task and other program identifiers should be included.

Significant element identification

Special event description

Special event occurrence rating

Technology description

Damage description

Technology/damage
evaluation rating

Exposure evaluation rating

Criticality analysis result

Maintenance task requirement

This tabular report should be tailored to meet program needs.

1

2

3

4

5

6

7

8

9

ICN-B6865-S3000L0069-001-01
Fig 3 Damage and event analysis tabular report
Table 7 Recommendations for damage and event analysis tabular report
ColumnDescription

1

Significant element identification
Element name. This element name can be followed by its breakdown element
identifier. Some elements (typically structural elements) can be grouped intofamilies in order to minimize the number of entries in the table.

2

Special event description
The special event is described by a complete name. The special event may affectmore than one element of the breakdown structure. In this case identify each one
on a different line.

3

Special event occurrence rating
Gives the rating and description of occurrence.

4

Technology description
Give a short technical description of the technology. The technology may concern
more than one element of the breakdown structure, in this case try to group themby families in order to minimize the number of entries.

5

Damage description
Give a short description of damage. If more than one damage can affect the sameelement then identify each one on a different line.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

ColumnDescription

6

Technology/damage evaluation rating
Give the rating and description explaining the rating in terms of sensitivity andnewness.

7

Exposure evaluation description
Give a short technical description of the location of the element identified and how
it is exposed to threats.

8

Criticality analysis result
Describe the justification of importance of damage regarding its consequences.

9

Maintenance task requirement
A short summary or title including the type of maintenance task and the element on
which it applied. If more than one maintenance task is needed to cover the sameelement then identify each one on a different line. Conversely, the same
maintenance task can address more than one element or damage. This is typicallythe case of a standard repair procedure.

5.2

Complementary analysis

5.2.1

Influence on design
Early in the program development/design process there is the opportunity to influence thedesign from the standpoint of special events and damage occurrences. Design modifications
can reduce/eliminate special events and damages, for example:−−−

Adding protection
Enhancing accessibility/removals
Changing the technology

Such possible influence on design should be appropriately managed and mile stoned in thedesign process.

5.3

Lessons learned
This section could give examples of best practices or bad experiences to be taken into accountfor future studies.

S3000L-A-08-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-08-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 8
2010-04-01 Page 9

S3000L-B6865-03000-00

Chapter 9
Logistics related operations analysis
Table of contents

Page

Logistics related operations analysis ............................................................................................. 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Logistics relevant operations ........................................................................................... 3
2.1
Usage supporting aspects ............................................................................................... 3
2.1.1
Preparation for usage ...................................................................................................... 3
2.1.2
Servicing .......................................................................................................................... 3
2.1.3
Adjusting .......................................................................................................................... 4
2.1.4
Weighing .......................................................................................................................... 4
2.1.5
Loading and unloading .................................................................................................... 4
2.2
Packing, handling, storage and transport aspects .......................................................... 5
2.2.1
Packing and unpacking ................................................................................................... 5
2.2.2
Handling ........................................................................................................................... 5
2.2.3
Storage ............................................................................................................................ 6
2.2.4
Stacking ........................................................................................................................... 6
2.2.5
Lifting ............................................................................................................................... 6
2.2.6
Transportation.................................................................................................................. 6
2.2.7
Mooring ............................................................................................................................ 7
2.2.8
Shoring ............................................................................................................................ 7
2.3
Software and data aspects .............................................................................................. 7
2.4
Product or system recovery ............................................................................................. 7
2.5
Special scheduled maintenance ...................................................................................... 7
2.6
Disposal and recycling ..................................................................................................... 8
2.7
Logistics relevant operations out of the ordinary ............................................................. 8
3
Documentation of logistics relevant operations tasks ..................................................... 8
3.1
LSA database aspects ..................................................................................................... 8
3.2
Operational and customer requirements as a source ..................................................... 8
4
Checklist of logistics relevant operations tasks ............................................................... 8

List of tables
1
2

References ...................................................................................................................... 2
Checklist for logistics related operations analysis ........................................................... 8

List of figures1
2
3

Logistics related operations analysis within technical documentation ............................ 2
Typical servicing tasks ..................................................................................................... 4
Typical PHST tasks ......................................................................................................... 5

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

References
Table 1 References
Chap No./Document No.

Title

Chap 3LSA Business process

Chap 10

Scheduled maintenance analysis

Chap 13

Software support analysis

Chap 17

Disposal

S1000DInternational specification for technical publications using
a common source database

1

General1.1

Introduction
Beside the activities concerning maintenance and repair of a product, there are additional
aspects concerning the operation and the handling to be considered. Logistic relevant
operations are tasks, which cannot be assigned to an area of direct usage of a product(documented in operating instructions) or an area of maintenance (documented in maintenancemanual). However, these tasks can be of importance for the proper usage of any product. Many
aspects such as ease of operation, usability, flexibility of usage or mobility are restricted bylogistics relevant operations tasks. The border between pure usage of a product and thelogistics relevant operations is subjective and it must be decided individually for each project,
how and where these aspects will be documented. Sometimes it can be difficult to assign amaintenance task exactly to one of these two areas.
It is recommended to clarify at an early stage of any project the responsibility of both,
performance of logistic analysis and documentation of logistics relevant operations.
Technical documentation

User
Usermanual
manualLogistics
Logistics
relevant
relevant
operations
operations

Maintenance
MaintenancemanualmanualLogistics relevant
operations analysis

ICN-B6865-S3000L0039-001-01
Fig 1 Logistics related operations analysis within technical documentation
All tasks that are identified by the logistics relevant operations analysis will close the possible
gap between user manual and maintenance manual.
Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

1.2

Objective
This chapter should be a guideline for identifying relevant operational activities. To support theanalyst, a detailed list of potential operational or handling activities is provided in Para 4.

1.3

Scope
This chapter is directed to the logistics personnel responsible for analyzing the logistics relevant
operational tasks.

2

Logistics relevant operations
In the following sections the typical logistics relevant operations are described in more detail toexplain the concept. The collection of examples is limited to the most common tasks. There canbe more activities, especially in relation to environmental conditions (eg preparation fortransport under extreme climatic conditions such as an arctic environment). For each example ashort description is given along with special aspects to be considered.
The identification of logistics relevant operations, including the requirements concerning
personnel, support equipment, consumables, spare parts, facilities and required training, is an
important area of logistics analysis tasks. Some of the tasks listed below require very earlyconsideration in the development life cycle and some can be considered later, eg when aprototype of the Item under Analysis (IuA) is available.

2.1

Usage supporting aspects
The activities that support the usage of the IuA are described in the following paragraphs.

2.1.1

Preparation for usage
This aspect describes the tasks required to prepare a product for a special operation. Thispreparation can include, for example, the exchange of special equipment within the IuA toprovide a special capability. In addition to the modification of the IuA by changing some piecesof equipment, it can be possible that peripheral products/components must be prepared for aproper usage.
Typical preparation tasks can be classified as servicing tasks, (eg the cleaning of windows
before driving a vehicle). Others are typical preparation tasks, which describe the complete
conversion of a product for another use case, such as the change of the tooling within amachine to produce a new product line. Typical examples for tasks concerning preparation for
usage, which can be considered by Logistics Relevant Operations Analysis, are the following:
−
−
−
−

2.1.2

Preparation of machines for new production segment (eg by exchange of tooling or dies)
Role change of a vehicle (role change of a normal transport vehicle to an ambulancetransport vehicle)
Preparation of an aircraft for a reconnaissance mission by installing special equipment
Preparation of a ship including each necessary equipment for sailing

Servicing
The term servicing can describe a wide range of tasks performed on a product (also in
connection with usage preparation). Other aspects are handling after usage or the upkeep of
the system. This includes, for example, a simple visual inspection for foreign objects during
washing or cleaning procedures as well as simple visual inspections concerning damage or thegeneral condition of equipment (eg condition of tires).

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

Washing

Cleaning

Polishing

UpkeepPreservation

Fuels / liquids

Lubrication

Oil change

Check offill levels

Rinsing

Draining

Bleeding

Desalination

Visual checks

others …

Servicing tasks

ICN-B6865-S3000L0040-001-01
Fig 2 Typical servicing tasks
Servicing tasks should be examined by the means of a Maintenance Task Analysis (MTA) to
identify the requirements. Servicing tasks can have an important impact on resources, toinclude personnel, support equipment (eg for lubrication), consumables and facilities (egwashing facilities with oil separator and water recycling equipment). Typical examples for tasks
in connection with servicing are the following:
−
−
−
−
−
−
−
−
2.1.3

Engine washing of any vehicle
Lubrication of a gear
Oil change of an engine
Polishing and following preservation of a vehicle
Bleeding of brakes
Change of hydraulic liquid
Replenishment of fluids
Desalination and rinsing of equipment after diving

Adjusting
The typical adjust tasks can also be performed in connection with preparation for usage.
Product functionality is not changed, but precision and quality considerations are addressed as
preconditions for the usage of the product. Typical examples for tasks in connection withadjusting are the following:−−−

Leveling of the entire product as a basic task
Calibration of measuring instruments
Adjustment of the sight of a gun

2.1.4

Weighing
The analysis of weighing tasks involves the preparation of the IuA for weighing and theprocedure itself. This includes information on the weighing equipment to be used. The purposeof the weighing procedure should be defined and agreed to between the contractor and thecustomer (eg weighing as a mission preparation task or a task to establish proof of specification
requirements of the product).

2.1.5

Loading and unloading
Loading and unloading procedures should be analyzed for each product that can be used forthe transport of cargo. This information should be collected in an early stage in the development
life cycle. Examples of loading and offloading techniques, interior layout, floor loadings, locationand strength of lashing points, methods of stowing and securing, capacities and dimensions ofcompartment and doors should be documented carefully. The following aspects should beconsidered:−−

What kind of cargo is planned to be transported?
Which size and weight parameters must be considered?

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00−

Is the expected cargo sensitive to special impacts (acceleration, magnetic or electric fields,
pushes, humidity, etc)?
Is the cargo critical or even dangerous in case of improper handling?
What type of cargo securing (lashing and lashing points, stowing) is required?
Will a container concept be employed?
Are special loading devices required because of the type of the load (eg rolling devices)

−
−
−
−

The requirements for special support equipment for loading and unloading should also be
addressed.
−
−

2.2

Is it necessary to use special support equipment or vehicles for the loading/unloading?
Is special support equipment required to secure the cargo?

Packing, handling, storage and transport aspects
This paragraph describes the activities in connection with the packing, handling, storage andtransport (PHST) of the IuA during other than normal use.

Packing

Conservation

Safety precautions

StorageTransportation

TowingParking

Winching

Stacking

Mooring

Securing

Shoring

Container concept

Liftingothers …

PHST aspects (packing, handling, storage, transportation)

ICN-B6865-S3000L0041-002-01
Fig 3 Typical PHST tasks
2.2.1

Packing and unpacking
A packing concept for the IuA and/or for components should address the following:
−
−
−
−
−
−

2.2.2

Is packing required for short term storage and/or for long term storage?
Is packing required for transportation and what kind of transportation will be carried out?
Is a special container required for storage or transport?
Is special preservation required because of extreme climatic conditions during the storage
or transportation period (eg sea transport)?
Is it required to unpack and repackage the IuA during transportation or storage period, forexample, to perform maintenance activities (storage tasks)?
What is required for the unpacking and removal of preservation concerning support
equipment and facilities?

Handling
Handling tasks for the IuA should address the following:−−−−

Safety precautions and limitations due to handling
Instructions necessary to park, tow, winch or move the IuA in any way, other than normal
usage.
Instructions necessary to jack the IuA including jacking points, required adapters, supports
for special components, balance weights, jacking procedures, etc
Additional equipment and materials required when handling the IuA (eg tow bars or cables).

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

2.2.3

Storage
To guarantee product functionality during a storage period and at the conclusion of storage,
storage procedures should be analyzed and documented. Storage tasks should address thefollowing:
−
−
−
−
−
−
−
−
−

Is the required storage considered long term storage or short term storage solution?
Is the product/component to be stored of special sensitivity?
Is it necessary to remove components from the product to be stored and to store thesecomponents separately under special conditions?
What type of inspection and preventive maintenance is required to safeguard structural andsystem integrity during storage (eg wheel rotation, provision with electrical power, engine
running, pressure checks)? Provide a timescale for such in-storage maintenance.
Are there any extreme climatic conditions which are expected during storage period (heat,
frost, humidity)?
Are there any special techniques required for entry into storage (eg cleaning andpreservation, fluid system draining/replenishing, static grounding, protective blanking,removal of special components)?
Are there any special techniques required for removal from storage and to return to usage(eg cleaning and removal of preservation, fluid system replenishing, re-installation of
special components, functional checks, preparation for usage)?
What kind of securing is required during storage period (eg mooring, blocking of movable
components, securing against light in a dark storage place)?
Is it necessary to consider the storage time in connection with the life of the stored
product/component?

2.2.4

Stacking
A special aspect of storage and transportation of any product/component is stacking. What are
the safety requirements for stacking for simple storage or for transport? For example, the impact
of external events such as pushing should especially be analyzed for storage.

2.2.5

Lifting
A lifting concept should include all necessary procedures to lift the IuA with corresponding hoist
devices, cranes, jacks or slings for the following reasons:−−−

Lifting for transportation or loading purposes
Lifting for repair or maintenance purposes
Lifting for recovery

In addition to the lifting of the complete product, the lifting of components should be considered
as well (eg the lifting of the engine of an aircraft).
2.2.6

Transportation
Based on customer requirements, the transportability of the product should address thefollowing:
−
−
−
−
−

What is the effort and duration of the preparation for transport and for recovery after
transport?
What are the requirements for preparation for transport and for recovery after transport
concerning personnel, tools, consumables, and facilities?
What are the additional environmental requirements for transportation under special
conditions (eg extreme climatic conditions such as sea transport, sandy desert
environment, humidity, heat, frost)?
What are the additional safety requirements for transportation under special conditions (egmooring within a transport aircraft in case of air transport)?
What are the required servicing actions during the transportation period (especially during
long journeys)?

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00−−

Is it necessary to remove components for transportation or to disassemble the entire IuA
down to a specific level?
Should a container concept be considered? Is the usage of sledges and/or pallets
acceptable?

2.2.7

Mooring
Analysis of mooring tasks for the IuA must be addressed under all weather conditions or fortransportation within any transportation vehicle. Mooring is considered as a long or short term
activity, whose purpose is to tie down or otherwise secure the IuA to the ground or within atransportation vehicle to avoid any damage. Also, information such as special techniquesapplicable to ballasting, definition of lashing points and installation/use of special support
equipment applicable to mooring should be included.

2.2.8

Shoring
Similar to mooring, shoring should be analyzed concerning shoring points, shoring procedures
and the shoring equipment used during, for example, maintenance, repair and recovery.

2.3

Software and data aspects
Logistics relevant operations related to software are addressed in Chap 13, Software Support
Analysis.

2.4

Product or system recovery
Analysis concerning recovery should include any information on planned recovery procedures
and the required support equipment needed to recover any IuA from any condition to which it
may be subjected.
Product recovery during the testing phase should be addressed separately. It is important toguarantee a fast reaction to any unexpected event, where it is necessary to recover the productfrom an undesired condition. It must be clear, what action is required to avoid any endangeringof personnel or environment. A recovery plan for all emergency situations should be detailed
enough to avoid endangering personnel or the environment.
Recovery also includes rescue procedures or safeguarding of an area after a catastrophic
event. All procedures that are necessary to rescue any product after an accident must be
analyzed before the first usage of the product. For example, an aircraft performing its first flightmarks a specific risk of a crash. All required activities after a potential crash must be analyzed
and documented carefully before the first usage of the system. Recovery training should be
included as part of the analysis process in order to reduce the risk of extended damage tohumans or the environment in case of a catastrophic event. All aspects must be covered, eg anaccident on land, in water (eg the foundering of a ship with the requirement to salvage thewreckage) or within areas that are difficult to access.

2.5

Special scheduled maintenanceIn general, the identification of Scheduled Maintenance is described in Chap 10. However,servicing tasks or tasks in connection with preparation for usage can be of a scheduled nature,
but are not identified by the extended Scheduled Maintenance Analysis (SMA). These tasks canbe of high impact, eg for personnel requirements, because they are performed frequently (egeven daily). Examples include the following:−−−−

Visual check before the start of usage (eg starting of an engine)
Visual check after special missions
Scheduled replenishment of fuel, fluids or other consumables to guarantee proper function
Cleaning before or after each usage

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

2.6

Disposal and recycling
Analysis concerning requirements after the life cycle of a product is of increasing importance.
This includes both the disposal of the complete product, and the handling of components andconsumables to be disposed of during the life cycle of the product. For this reason, these
aspects are described in detail in Chap 17 - Disposal.

2.7

Logistics relevant operations out of the ordinary
Other logistics relevant operations include, but are not limited to the following and should be
addressed in the analysis process:
−
−
−
−
−
−

Decontamination of a vehicle
Disinfection of personnel before starting a job
De-icing of an aircraft or ship
Check of electrical charge
Check of the strength of magnetic fields during storage
Paperwork for statistic purpose

3

Documentation of logistics relevant operations tasks

3.1

LSA database aspects
The identification of any required logistics relevant operation should be documented within the
LSA database using the appropriate information code. It is recommended that logistics relevant
operations tasks be documented at the product level or the appropriate breakdown level (use ofa mixed physical/functional breakdown provides the most flexibility). This will support theexchange of this data with for example, S1000D for technical publications.

3.2

Operational and customer requirements as a source
In general, the requirements for logistics relevant operations tasks can be derived from theoperational and customer's requirements, which are collected and documented within theestablishment of product usage data. This process is described in detail in Chap 3. It is
recommended to use the content of the relevant documents ORD (Operational Requirements
Document) and CRD (Customer Requirements Document) as a first input for the Logistics
Relevant Operations Analysis. Each aspect concerning usage of the IuA, which can be found in
the ORD or CRD, can trigger the requirement for a logistics relevant operations task.

4

Checklist of logistics relevant operations tasks
The following alphabetical checklist for potential relevant activities is provided as a guide.
Table 2 Checklist for logistics related operations analysis
Activity

Analysis
Probable large
recommended at impact onrequirement for
which phasefacilities

Probable large
impact on
requirement for
special support
equipment

Probablelarge
impact on
designAdjusting

When necessary

No

PossibleNo

Bleeding

When necessary

No

No

No

Calibration

When necessary

No

Yes

No

Checking

When necessary

No

No

Possible

Cleaning

Early phase

Yes

Possible

No

Conservation

Early phase

Yes

Possible

No

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00

Activity

Analysis
Probable large
recommended at impact onrequirement for
which phasefacilities

Probable large
impact on
requirement for
special support
equipment

Probablelarge
impact on
designContainerconcept

When necessary

No

No

Possible

Conservation
removal

Early phase

Yes

No

No

Desalination

When necessary

No

No

No

Disposal

Early phase

Possible

Yes

Yes

Draining

When necessary

No

Possible

Possible

Jacking

Early phase

Possible

Yes

Yes

Leveling

Early phase

Possible

PossibleNo

Lifting

Early phase

Possible

Yes

Possible

Loading cargo

Early phase

Yes

Yes

Yes

Loading data

Early phase

Yes

Possible

No

Loading
Software

When necessary

No

PossibleNo

Lubrication

When necessary

No

Possible

Possible

Mooring

When necessary

No

Yes

Yes

Oil Change

When necessary

No

No

No

Packing

When necessary

Possible

Possible

No

Parking

When necessary

Possible

Possible

No

Polishing

When necessary

No

Possible

No

Preservation

Early phase

Possible

Possible

No

Recovery

Early phase

No

Possible

Possible

Recycling

When necessary

Possible

Possible

Yes

Replenishment

When necessary

No

Possible

Possible

Rinsing

When necessary

PossibleNo

No

Safetyprecautions

Early phase

Possible

PossibleNo

Securing

When necessary

No

Possible

Possible

Shoring

When necessary

No

Possible

Possible

Stacking

When necessary

No

Possible

No

Storage

Early phase

Yes

Possible

No

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00

Activity

Analysis
Probable large
recommended at impact onrequirement for
which phasefacilities

Probable large
impact on
requirement for
special support
equipment

Probablelarge
impact on
designTowingWhen necessary

No

Yes

Possible

Transportation

Early phase

Possible

Yes

Possible

Unloading cargo Early phase

Possible

Yes

Yes

Unloading data

When necessary

No

Possible

No

Unloading
Software

When necessary

No

Possible

No

Unpacking

Early phase

Possible

Yes

No

Upkeep

Early phase

Possible

Possible

No

Washing

Early phase

Possible

PossibleNo

Weighing

Early phase

Possible

Yes

No

Winching

When necessary

No

Possible

No

S3000L-A-09-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-09-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 92010-04-01 Page 10

S3000L-B6568-03000-00

Chapter 10
Scheduled maintenance analysis
Table of contents

Page

Scheduled maintenance analysis .................................................................................................. 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 2
1.4
Terms, abbreviations and acronyms ............................................................................... 2
2
Division of scheduled maintenance analysis ................................................................... 3
2.1
System and power plant analysis .................................................................................... 3
2.2
Structure analysis ............................................................................................................ 3
2.3
Zonal analysis .................................................................................................................. 4
3
Preventive or scheduled .................................................................................................. 44
LSA candidates and SMA candidates ............................................................................. 5
5
Scheduled maintenance analysis procedure ................................................................... 5
6
Thresholds and intervals from scheduled maintenance analysis .................................... 6
6.1
PO threshold .................................................................................................................... 6
6.2
PE threshold or interval ................................................................................................... 6
6.3
Mixture of PO and PE thresholds .................................................................................... 6
6.4
Triggers ............................................................................................................................ 77
Thresholds and intervals from other sources .................................................................. 78
LSA tasks......................................................................................................................... 8
9
Scheduled maintenance harmonization and task packaging process ............................ 8

List of tables
1
2
3

References ...................................................................................................................... 2
Terms, abbreviations and acronyms ............................................................................... 3
Terminology - preventive and scheduled maintenance ................................................... 4

List of figures
1
2
3
4
5
6
7

Preventive/scheduled maintenance ................................................................................ 5
PO threshold .................................................................................................................... 6
PE interval ....................................................................................................................... 6
PO and PE thresholds dependent from each other......................................................... 7
Triggers ............................................................................................................................ 7
Main aspects for decrease and increase of intervals/thresholds (example) ................... 8
Packages from single scheduled LSA tasks ................................................................... 9

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

References
Table 1 References
Chap No./Document No.

Title

Chap 21

Terms, abbreviations and acronyms

MSG-3

ATA MSG 3 - Operator/Manufacturer Scheduled
Maintenance Development

RCM

Eg
MIL-STD-1843 (USAF) - Reliability-centered maintenancefor aircraft, engines and equipment
MIL-STD-2173 (AS) - Reliability-centered maintenance fornaval aircraft, weapon systems and support equipment
UK MoD DefStan 02-45 - Requirements for the applicationof reliability-centred maintenance - techniques to HM
ships, submarines, royal fleet auxiliaries and other naval
auxiliary vessels

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

1

General1.1

Introduction
The identification of required scheduled maintenance is of vital importance for the operation of acomplex product. Safety, economic, environmental and ecological aspects must be consideredvery carefully. It is a common tendency to minimize scheduled maintenance and to come tocondition based maintenance concepts. However, experience (especially in safety critical areas)shows that a certain amount of scheduled maintenance can not be avoided.

1.2

Objective
This chapter introduces the well known methods of Scheduled Maintenance Analysis (SMA),
like S4000M, MSG-3 or Reliability Centered Maintenance (RCM) analysis, and how they should
be linked to the LSA process and where the connecting aspects are.

1.3

Scope
This chapter is directed at logistics personnel who perform SMA and look for an appropriate
place to document the results of this extensive analysis. The LSA database is the correct place,not only to document the results from the analysis which provides the identification of ascheduled maintenance activity, but also to document the results of the corresponding
maintenance task analysis.
It should be noted that the extensive analysis activities are carried out outside the LSA
database (eg FMECA, LORA, SMA). However, the results of these technical/logistic analysis
activities have to be documented in the LSA database as agreed between contractor andcustomer for a specific project.

1.4

Terms, abbreviations and acronyms
The following specific terms, abbreviations and acronyms used within this chapter. More special
terms are explained directly within the appropriate paragraphs. Refer to Chap 21 for a full listingof Terms, abbreviations and acronyms.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

Table 2 Terms, abbreviations and acronyms
Abbreviation/Term Definition

2

Preventive
maintenance

Maintenance activities that prevent the occurrence of critical failures ordamages in conjunction with safety, economical or ecological aspects.
Preventive maintenance also includes activities following special events(for these events chronological intervals or other regular thresholdcannot be defined)

Scheduledmaintenance

Maintenance activities that prevent the occurrence of critical failures ordamages in conjunction with safety, economical or ecological aspects.
These maintenance tasks are defined with a corresponding interval or
threshold (eg after certain time, cycles, rounds, distance). Scheduled
maintenance is a subset of the preventive maintenance.

SMA candidate

Element of the breakdown, which is identified as a potential candidate forwhich a scheduled or preventive maintenance task could be necessary.

Division of scheduled maintenance analysis
The Scheduled Maintenance Analysis (SMA) documented in international specifications such as
S4000M, MSG-3 (civil specification) or RCM (Reliability Centered Maintenance, military
specification) are grouped into three general main areas. These are:−−−

System and power plant analysis
Structural analysis
Zonal analysis

Each of these analysis methods has its own methodology and own procedures to determine
scheduled/preventive maintenance tasks and the corresponding intervals.

2.1

System and power plant analysis
The method for determining the scheduled maintenance tasks and intervals for systems andpower plants, including components and equipment, uses a progressive logic diagram
described in the various SMA specifications. This logic is the basis for an evaluation techniqueapplied to each maintenance significant item (eg system, subsystem, module, component,
accessory, unit, part), using the technical data available. In principle, the evaluations are basedon the item's functional failures and the respective failure causes. As additional knowledge andexperience of the product is gathered during the inservice phase (eg fault/damage reports,
maintenance work orders), the existing tasks shall be reviewed periodically.

2.2

Structure analysis
The structure analysis contains guidelines for developing applicable and effective scheduled
maintenance tasks with intervals for the mechanical structure of a product (eg vehicles,
aircrafts, ships, tanks). These are designed to relate the scheduled maintenance tasks to theconsequences of structural failure or damage that has remained undetected.
Each structural item with details (if selected) is assessed in terms of its significance to continued
operational safety, impact on availability for operation or missions, susceptibility to any form of
failure or damage, and the degree of difficulty involved in detecting such failure or damage.
Once this is established, scheduled structural maintenance can be developed to be effective in
detecting and preventing structural degradation due to fatigue failure, environmental
deterioration and/or accidental damage. Resulting scheduled tasks are to be performed fromthe beginning of the inservice phase throughout the operational life of the product underanalysis. As additional knowledge and experience of the product is gathered during theApplicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

inservice phase (eg fault/damage reports, maintenance work orders), the existing tasks shall be
reviewed periodically.

2.3

Zonal analysis
Zonal inspections for products may be developed from application of a zonal analysis
Procedure coming from the various SMA specifications. This requires a summary review of
each zone of the product and normally occurs as analyses of structures, systems and power
plants are being concluded. Identified general visual inspection tasks from those analysis steps
may subsequently be included in the zonal inspections where intervals can be harmonized withthe zonal inspection intervals. As additional knowledge and experience of the product isgathered during the inservice phase, the existing tasks shall be reviewed periodically.

3

Preventive or scheduled
For a common understanding of terminology, the terms preventive and scheduled should be
defined clearly:
Table 3 Terminology - preventive and scheduled maintenance
Term

Description

Preventive

All activities to avoid critical failures or other critical situations should besummarized as preventive activities. This includes:

Scheduled−

Scheduled maintenance activities with a replace, repair or overhaul activity
such as the replacement of components after a specified period of use (egtime change items) or after another specific interval (eg rounds, cycles,
distance)−

Scheduled inspections after specific intervals or thresholds (tests, checks orsimilar activities to make a critical failure obvious)−

Activities after damages or special events to establish the condition of theanalyzed technical system after an event beyond of normal usage

All activities to avoid critical failures or other critical situations with a certain
interval or threshold−

Scheduled maintenance activities with a replace, repair or overhaul activity
such as the replacement of components after a specified period of use (egtime change items) or after another specific interval (eg rounds, cycles,
distance)−

Scheduled inspections after specific intervals or thresholds (eg tests, checks
or similar activities to make a critical failure obvious)

Corresponding to this definition given in Table 3, scheduled maintenance can be regarded as asubset of preventive maintenance as shown in Fig 1. The main characteristic of a scheduled
maintenance task is the existence of a specified interval or threshold.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

Preventive maintenance
Scheduled maintenance
Scheduled activities (eginspection, lubrication, test,
replacement of time change
items) after time limitations, liketime intervals or thresholds

Scheduled activities (eginspection, lubrication, test,
replacement of time change
items) after non-time limitations
like intervals and thresholds
based on eg cycles, rounds,
distances

Inspection activities after
special events

ICN-B6865-S3000L0042-001-01
Fig 1 Preventive/scheduled maintenance4

LSA candidates and SMA candidates
The criteria for the selection of SMA candidates and LSA candidates are different. The selection
rules documented in the various SMA specifications are mainly safety driven. In newer
specifications such as S4000M, economic and ecological aspects are considered. The selection
rules of typical LSA candidates are mainly driven by maintenance relevance. Nevertheless,there is an interconnection between these two types of candidates.
A Maintenance Significant Item (MSI) selected for SMA generally becomes a LSA candidate, ifscheduled maintenance activities are identified for the item. These identified tasks and theirintervals will be documented and further analyzed for task requirements within the LSA
database.
For structural items, it can be necessary to expand the system breakdown for additional items
representing only special areas or details of a large structural item (eg an aircraft wing
structure), for which a structure analysis must be performed. These artificial breakdown
elements are only introduced in order to allow the assignment of the analysis results to acorresponding object. This method is described in detail in S4000M, structure analysis. The
corresponding scheduled or preventive tasks and their intervals, identified within the SMA in thecase of structure, will be documented and further analyzed for the consequent task
requirements within the LSA database against a structural breakdown element, which thenbecomes a LSA candidate.
The zonal analysis is a special area where the item of SMA is not a physical hardware
component or a group of hardware components, but a local area within a product, where a lot ofdifferent items of different types (including the carrying structure) may be located. It is possiblethat the zone may only contain structural items. All identified scheduled maintenance tasks(normally general visual inspections) and their intervals will be documented and further
analyzed for task requirements consequently within the LSA database. The method for
addressing LSA candidates for zones must be defined carefully and harmonized with thecustomer during the LSA guidance conference. It is recommended that the SMA results forzones under dedicated breakdown elements are gathered and the required maintenance tasks
be grouped by interval criteria.

5

Scheduled maintenance analysis procedure
The SMA is driven by three main aspects. First of all, safety related aspects are the mostimportant ones. Economic and ecological aspects are also of increasing importance, especiallythe ecological effects.
Detailed analysis of potential failures and damage, their effects and causes is necessary. The
result of these analysis steps will be the identification of potential tasks to avoid any critical

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

failures or damage. The result of the analysis can also be that no scheduled maintenance task
is required. However, a complete SMA of a product concerning safety relevant failures ordamage should be considered mandatory.
The last activity of a SMA analyst is to analyze the identified potential scheduled maintenancetasks to decide which are the most effective and to determine the maintenance intervals or
thresholds. Finally this result will be documented in the LSA database as LSA tasks that arelinked to the corresponding event threshold or interval.

6

Thresholds and intervals from scheduled maintenance analysis
Along with the introduction of an LSA task to perform the maintenance task analysis for thescheduled maintenance activity resulting from SMA, the justifying event will be defined. Forscheduled maintenance, an event will be defined that represents the specific threshold. It
should be pointed out that the thresholds and the intervals can be of different types.
−
−
−

6.1

Perform Once (PO) thresholds
Periodical (PE) thresholds/intervals
Triggers

PO threshold
A maintenance task that is only performed once is characterized by a PO threshold. Typicalexamples for such tasks can be a check of wheel nuts after a certain distance or a torque of
special screws after a certain time of usage.
check wheel
nuts after 500
kilometers[time, cycles, rounds, distance, etc...]PO threshold

ICN-B6865-S3000L0043-001-01
Fig 2 PO threshold

6.2

PE threshold or interval
A maintenance task that is performed repeatedly during the life time of a product ischaracterized by a PE threshold/interval. Typical examples for these types of tasks can be aperiodic inspection or a periodic servicing task, eg engine oil change.
Inspection after
1000 operation
hours

Inspection after
1000 operation
hours

Inspection after
1000 operation
hours …..
[time, cycles, rounds,
distance, etc..]

PE threshold(interval)

PE threshold(interval)

PE threshold(interval)

PE threshold(interval)

ICN-B6865-S3000L0044-001-01
Fig 3 PE interval

6.3

Mixture of PO and PE thresholds
The common practice of combining PO activities with PE activities can often be found andshould be documented carefully in the LSA database. These different activities can bedependent upon each other, because the second maintenance task is driven by the PE interval
and will not be performed before the related PO activity.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

1st inspection
after
500 cycles

Inspection after
1000 cycles

Inspection after
1000 cycles

Inspection after
1000 cycles ….
[time, cycles, rounds,
distance, etc..]PO
thresholdPE threshold(interval)

PE threshold(interval)

PE threshold(interval)

PE threshold(interval)

ICN-B6865-S3000L0045-001-01
Fig 4 PO and PE thresholds dependent from each other

6.4

Triggers
A more common approach to the fact that intervals or thresholds can be variable over thecomplete life cycle is the object of a trigger. In general, a trigger is an event which terminates aperiod of specific scheduled maintenance and starts another one with different intervals or othermaintenance activities.
Inspection after
1000 operation
hours

Inspectionafter
650 operationhours

PE threshold PE threshold PE threshold(interval)(interval)(interval)
Trigger forchange of theinspection
interval[time, cycles, rounds,
distance, etc..]

PE threshold(new interval
after trigger)

ICN-B6865-S3000L0046-001-01
Fig 5 Triggers
A typical purpose for triggers is the consideration of familiarization, learning phases and phases
after the achievement of a certain age of a product, when deterioration effects can force theimplementation of a modified scheduled maintenance concept.

7

Thresholds and intervals from other sources
In addition to the identification of scheduled maintenance activities via SMA, there are further
sources from which scheduled maintenance can be derived. It should be pointed out the SMA isa rather extensive analysis activity. For that reason, the number of SMA candidates that can be
examined in detail is a matter of budget. In addition to SMA results, scheduled maintenancerequirements may be identified by:
−
−
−
−
−
−
−
−

Recommendation of the original manufacturers
Best engineering judgment
Experience from other projects
Determination by customer's regulations
Certification maintenance requirements
Fatigue related inspections
Safety engineering requirements
Recommended scheduled activities during storage time of components

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

8

LSA tasks
The scheduled or preventive maintenance actions, including the threshold or interval
information, will be documented for affected LSA candidates within the LSA database. The
tasks will be analyzed in detail for requirements concerning personnel, support equipment,
spares, consumables and facilities. The interconnection between the final LSA tasks and theunderlying SMA should be established as effectively as possible to guarantee the consistencyof data (eg IT-based linking of data within the LSA database).

9

Scheduled maintenance harmonization and task packaging
process
As the final step, the identified effective and applicable scheduled maintenance actions which
are documented as LSA tasks will be analyzed again to identify equal or similar intervals and forgrouping. For example, if there is a complicated removal task to gain access to different items,
to be inspected, this can influence the final harmonization of preventive and scheduled
maintenance. In this case, the goal could be to avoid the repeated performance of thisextensive removal activity at different intervals.
In practice, it is necessary to harmonize all the identified scheduled maintenance tasks around a
Maintenance, repair and overhaul plan which allows specific values for scheduled maintenanceintervals. To find a proper harmonization of scheduled maintenance is challenging for the
maintainability engineers because it must be clear that intervals resulting from SMA do notalways perfectly fit into the planned intervals in a Maintenance, repair and overhaul plan of theindividual customers. For that reason, the adaptation of intervals or thresholds is often required.
1000 operation hours
Original interval from ascheduled maintenance analysis(S4000M, MSG-3, RCM)
decrease interval

increase interval

Budgetrelevant
relevant
BudgetSafetyrelevant
relevant
SafetyDecreaseofofintervalinterval
Decreasecauseshigher
highercosts
costs
causesandhigher
highercapacity
capacity
andutilisationofoffacilities
facilities
utilisation

Intervaldetermined
determined
Intervalby
SMA
cannotbe
beby SMA cannotchangedoffhand
offhandchanged(certification)(certification)

ICN-B6865-S3000L0047-001-01
Fig 6 Main aspects for decrease and increase of intervals/thresholds (example)
It is important to remember that intervals relating to safety relevant maintenance activities
cannot be modified without further analysis. The extension of intervals is a very sensitive issue
and must not be done without reconsideration of the SMA. Normally, an extension of intervals
must correspond to a design change or an alteration of the scheduled maintenance activities.
Extensions of intervals for scheduled maintenance concerning economical aspects are also to
be investigated carefully. In this case, the risk of a possible economic loss must be balanced.
Even more sensitive is the estimated ecological consequences of the extension of intervals forscheduled maintenance and a resulting occurrence of an ecological critical failure. In general
you should be aware that the extension of scheduled maintenance intervals is a critical subject.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

Also, the shortening of scheduled maintenance intervals cannot be done without deeper
investigation. In this case, tasks will be performed more frequently than is really necessary. This
will cause additional costs and must be discussed and harmonized with the customer.
Collection of SMA tasks inclusive interval

LSA task / interval
MTA
LSA task / interval
MTA
MTA
LSA task / interval
MTA
LSA task / interval
LSA task / interval
MTA
LSA task / interval
MTA
MTA
LSA task / interval
MTA
LSA task / interval
LSA task / interval
MTA
MTA
LSA task / interval
MTA
LSA task / interval
LSA task / interval
MTA
MTA
LSA task / interval

Package(e.g. 1000 OH)

MTA
for package…

…

ICN-B6865-S3000L0048-001-01
Fig 7 Packages from single scheduled LSA tasks
As shown in Fig 7, a maintenance task analysis for the complete package should also be
performed. Additionally, it must be taken into consideration that the scheduled maintenancepackages can contain a large number of single tasks. These tasks will not normally be
performed sequentially, but in parallel. All requirements, for example, personnel and support
equipment, must be harmonized for the complete package in comparison to the collection of thesingle LSA tasks.
If a scheduled maintenance package is finalized, each of original tasks, which are written
against the corresponding hardware breakdown elements, are no longer of special interest
concerning the calculation of logistic values. The original tasks should be maintained. It must be
possible, at any stage of a project, to trace the scheduled maintenance package back to its
origin tasks from the corresponding SMA and to trace each scheduled maintenance task backto the corresponding SMA (S4000M, MSG-3, and RCM). By following this methodology, you
can ensure the complete consistency of the scheduled maintenance from the first analysis steps
within the extensive special analysis procedures to LSA tasks and to scheduled maintenancepackages within a Maintenance, repair and overhaul plan.

S3000L-A-10-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-10-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 10
2010-04-01 Page 9

S3000L-B6865-03000-00

Chapter 11
Level of repair analysis
Table of contents

Page

Level of repair analysis .................................................................................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 22
LORA Candidate selection aspects ................................................................................. 2
3
Repair or discard decision ............................................................................................... 3
4
Identification of optimum maintenance level by ELORA ................................................. 3
5
Data gathering for LORA ................................................................................................. 4
5.1
Determine parts hierarchy ............................................................................................... 4
5.2
Determine LORA candidates ........................................................................................... 4
5.3
Collect unit prices ............................................................................................................ 4
5.4
Collect maintenance related cost data ............................................................................ 5
5.5
Other maintenance relevant data .................................................................................... 66
Performance of ELORA and preparation of results ......................................................... 7
6.1
ELORA baseline run ........................................................................................................ 7
6.2
Sensitivity analysis........................................................................................................... 7
6.3
Maintenance solution recommendation ........................................................................... 8
6.4
LORA Report ................................................................................................................... 8
6.5
Maintenance solution documentation in the LSA database ............................................ 8
7
Example for maintenance level definitions ...................................................................... 9
7.1
General ............................................................................................................................ 9
7.2
Level 1 ............................................................................................................................. 9
7.3
Level 2 ............................................................................................................................. 9
7.4
Level 3 ........................................................................................................................... 10

List of tables
1
2

References ...................................................................................................................... 1
Overview of typical cost elements ................................................................................... 5

References
Table 1 References
Chap No./Document No.

Title

Chap 3LSA Business process

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

1

General1.1

Introduction
Level of Repair Analysis (LORA) is an analysis performed to assist in the establishment of an
optimized maintenance solution based on a support philosophy harmonized with the customer.
This includes the determination of where repairable LSA candidates are removed, replaced,
repaired or discarded. Repair decisions should consider both economic and non-economic
factors such as costs, reliability values, maintainability/testability constraints or availability goals
for the system. The results of the analysis influence maintenance tasks and corresponding task
requirements (eg support equipment, personnel and spare parts).
The two main aspects of the LORA process are the technical assessment and commercial(costs) balancing. The mainly commercial approach, Economical LORA (ELORA), can be
performed in conjunction with LCC analysis activities (costs for maintenance activities are a
crucial part of the complete life cycle costs). It should be emphasized that only the combinationof technical and commercial aspects will lead to a proper LORA result.
The LORA requires a two stage approach:−−

Determination of whether the Item under Analysis (IuA) should be repaired or discarded(supporting the repair/discard decision by the customer). This repair/discard decision can
include non-economic as well as economic factors.
Identification of the optimum maintenance level for the required maintenance tasks, also
called ELORA.

These two stages are described in more detail in Para 3 and Para 4.
The requirement for a LORA is usually documented in the LSA program plan or similar
documents. Depending upon the individual phase of the project, a LORA should be performedfor different purposes using different methods.
The LORA process should be repeated as often as necessary during the design and the inservice phases as the design matures to determine whether the maintenance solution remains
as predicted or has changed due to the change in design or other factors. The results of the
LORA process can also be used to drive supplier selection by illustrating the various options,and could lead to the adoption of phased support.

1.2

Objective
The purpose of a LORA is to provide the customer with decision guidance for the selection of
the best balanced maintenance solution. It should be pointed out that different customers may
come to individual decisions depending on their intentions or preconditions. In the early stage ofa project, LORA aspects must be considered in order to influence the design (eg testability
features, modularity, accessibility requirements) as well as to support customer strategy
decisions (eg 2-level maintenance strategy, single source principle).

1.3

Scope
This chapter is directed at contractor and customer logistics personnel who perform LORA
activities. Results of the LORA will be documented in appropriate LORA reports. The LSA
database should be used to document the derived maintenance solution per LSA candidate.

2

LORA Candidate selection aspects
The identification of potential LORA candidates is usually based on the LSA Candidate Item List
(CIL), which is established in accordance with the project’s LSA candidate selection process.
For details, refer to Chap 3.
As already mentioned above, the LORA is a two step process. The first step in the LORA is todecide whether a LSA candidate is potentially repairable or not. When the item is potentially
repairable, a decision must be made on which of these LORA methods is feasible to use:

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

−
−
−
−

Best engineering judgment
Simplified LORA (based on information collection and consideration of values)
LORA based on mathematical models (supported by commercial software packages)
Simulation (supported by commercial software packages)

In either case, a justification based on best engineering judgment must be performed.
In addition to these factors, other additional constraints or fixed customer decisions that should
be considered include:
−
−
−
−
−
−
−
−

Exclusions concerning repair due to danger of destruction or hazardous/unsafe situation
LORA relevant input by system integrator or Original Equipment Manufacturer (OEM)Cut off values or design driven influences (a set of predefined cut off values may help in the
reduction of the number of ELORA candidates. These cut off values are usually based ontechnical and economic factors such as low task frequency, low unit price, repair costs)
Customer imposed maintenance constraints external to the LORA
Existing maintenance infrastructure of the customer derived from Operational
Requirements Document /Customer Requirements Document (ORD/CRD)
Customer requirements derived from ORD/CRD
Contractual requirements or LSA Guidance Conference (LSA GC) decisions
Clear understanding of the requirements of LORA by other disciplines

These external influences or requirements should be addressed at the LSA GC. Such factors
must be agreed upon during the LSA GC, failure to do so may have negative impacts later in
the Project.

3

Repair or discard decision
A Repair/Discard decision is the prerequisite to any ELORA. It is, in effect, a screening process
in order to minimize the number of ELORA candidates using a logical process of elimination.
Each LSA CIL has numerous items that are potential ELORA candidates. The Repair/Discard
decision must be carried out in order to identify which of these items are candidates for further
ELORA analysis. This is achieved by determination of the repair feasibility for the items.
For each potential item, crucial technical questions must be clarified first:−−−

Does the design of the item allow repairs in general?
If so, this item is a potential ELORA candidate.
Is the repair of the item limited to certain maintenance levels?
If so, this item is a potential ELORA candidate. The analysis must be limited to the possible
maintenance levels.
Does the design of the item disallow repairs in general?
If so, this item must be removed from the ELORA candidate list. However, the proper
maintenance level for replace and discard must be identified and documented carefully.

This decision, and the logic leading to this decision, must be recorded in the LSA database orsimilar database for future traceability. For items that have been identified as potentially
repairable, the next stage is to further determine the method of performing the ELORA. This
stage presents the opportunity to have any external influences/requirements taken into account(eg existing maintenance solutions used by the customer, cut off values or design driven
influences).

4

Identification of optimum maintenance level by ELORA
The repair/discard decision process will result in a list of remaining ELORA candidates. These
candidates are identified as potentially repairable. The objective of the ELORA is to determine
the optimum maintenance solution for these candidates. This is carried out using mainly
economic cost factors such as spare parts, support equipment required to diagnose andperform repairs, personnel, training, facilities, technical documentation, Packaging, Handling,

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

Storage and Transportation (PHST), and also non-economic factors such as availability
requirements, reliability, and maintainability can be taken into account.
There are many different mathematical ELORA models available and supported by different
commercial software packages. Alternatively, a project specific or tailored model can be used. A
project specific or tailored model might allow better consideration of customer requirements,
constraints (both customer and OEM), available infrastructure, etc. This approach is often usedwithin a simplified LORA.
It is of vital importance that all LORA analyses within a project use the same LORA model.
Failure to do so will lead to differing results.

5

Data gathering for LORA
The required data for a LORA should be collected carefully. A LORA data set can containsimple data such as whether or not there is a need for:
−
−
−
−
−

Spare parts
Facilities
Support equipment required to diagnose and perform repairs
Personnel and required skill levels
Extended training

But a LORA data set can also contain comprehensive data giving in-depth details of therequirements and especially the costs associated with those requirements.
Once the data elements have been agreed upon in the LSA GC, the LORA data can begathered from a variety of sources such as drawings, technical documents, contracts, supplierinformation, commercial department, etc. The following paragraphs detail some of the data
gathering tasks.

5.1

Determine parts hierarchy
Failure modes in LORA are assigned to the hierarchical structure of the system. Failures at the
top level of the system are assumed to be primarily caused by failures of the items (orsubsystems) at the next lower indenture level. Similarly, failures of the items in the 2nd level ofindenture are mainly initiated by failures of the items in the next lower indenture level. For thisreason, it is impractical to perform a LORA until hierarchical relationships are defined. For
systems that are currently in production, the hierarchy and subsequent LORA candidate items
should be easily determined from existing LSA data concerning system breakdown.

5.2

Determine LORA candidates
After the parts hierarchy is established, the analyst must determine which parts will beconsidered in the analysis. On the surface it might seem logical to include all of the parts,
however, inclusion of non repairable or consumable parts such as nuts, bolts, gaskets, etc, will
add no value to the analysis. Candidate items can be determined via a rule set based on
existing repair or maintenance codes, unit price, repair level, or other criteria.

5.3

Collect unit prices
Unit prices for all items are required to fill an ELORA data model and to perform the analysis.
Sources for unit prices can be LSA databases, provisioning records or other sources. Unit pricefor all ELORA candidate items is necessary to determine the economic feasibility of repair. It
must be ensured that for ELORA calculation purposes, the correct values for unit prices will be
used. It should be noted that unit prices can differ dramatically from the production phase to thein-service phase (spare part price can be very different from production unit price). Sometimes
precise values are difficult to obtain and are therefore estimated.

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

5.4

Collect maintenance related cost data
Maintenance cost data includes labor time, training, spare parts and consumables, support
equipment, facilities, technical documentation and PHST aspects. Concerning these data it
must be distinguished between initial and recurring costs. These data have to be used in thecalculation of cost at each possible maintenance level.
The following table gives an overview of which typical types of cost elements should beconsidered in an ELORA (additional data can be required depending on the Project).
Table 2 Overview of typical cost elements
Cost element

InitialRecurring

X
X

X
X
X

Personnel
Labor time costs
Training costs (teachers and staff)
Training equipment costs (eg simulators, classroom equipment,
training facilities)
It should be pointed out that not only direct labor should beconsidered, but also required indirect labor (eg line managers,
inspectors, work preparation department)
Spare parts / consumables
Spare parts / consumables provision
Spare parts / consumables storage
Disposal costs

X

X
X
X

Support equipment to diagnose and repair
X

Support equipment provision and replacement
Support equipment maintenanceSupport equipment upgrade
Development of customized software (eg test software)
Support of customized software for support equipment
Disposal costs

X
X
X
X
X

Facilities and infrastructure
Building of facilities and infrastructure
Maintenance of facilities and infrastructure
Costs of operation for facilities and infrastructure
Costs for modification of facilities and infrastructure

X

X

X
X
X

X

X

X
X

X
X

Technical documentation
Documentation costs (eg user handbooks, maintenance andtraining manuals, illustrations, spare part catalogues)
PHST aspects
Packaging costs
Stock keeping costs (eg maintenance tasks and handling duringstorage, special storage containers, administration of stock)
Transportation costs (transport to maintenance facilities and backto user)

Applicable to: All

X

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

Cost element

InitialRecurring

Average repair costs at industry
Additional costs (documentation, administration, preparatory workand post processing)

X
X

X
X

Cost per reorder action

X

X

Cost per requisition

X

X

Disposal costs

X

X

Discount rate

X

X

Holding cost percentage

X

XInterest rate

X

X

Others5.5

Other maintenance relevant data
Besides the direct costs related data there is other information of interest for ELORA
calculations. The following list gives an overview of data that should be considered in an
ELORA.
Time and duration information
−
−
−
−
−

Reliability information (Mean Time Between Failure (MTBF), Mean Time between
Unscheduled Removal )Task frequency of corrective maintenance task
Scheduled maintenance interval
Task duration
Logistics down time (waiting time for logistic resources)

Note
Data for repair time is often difficult to obtain, especially for new systems. LSA databases
sometimes contain this information. Some developmental systems specify desired andmaximum times to repair a failure. This can be used as a repair time for items that are
directly removed and replaced. For the repair of lower indenture items, it will probably benecessary to use the repair time for a similar item on another system.
Availability values−−−

Minimum availability of IuA (usually, operational availability is specified)Availability of spare parts in stock
Availability rate of personnel for maintenance activities

Stock relevant values−−−

Procurement lead time
Pipeline transit times
Repair turnaround times

General information
−
−
−
−
−
−

Number and type of contractor industrial facilities
Number of operational sites
Number of system operated per site
Distances between sites
Inflation/discount rate
Repair policy (eg 2-level maintenance strategy)

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

History shows that the majority of cost influencing decisions must be made in a very early stageof the project, even if the information is very limited and the design is not yet stable. Thisemphasizes that the LORA must be repeated throughout the life cycle so that the requirement
for adoption of the maintenance solution can be identified in a timely manner.

6

Performance of ELORA and preparation of results
After successful collection and harmonization of data with the Customer, the ELORA is
performed. This can be done simply by balancing the given information (best engineering
judgment). However, when using complex mathematical calculation models, a commercial
software package may be selected. The data set to be collected depends upon therequirements of the specific software package. The results of the calculation runs should be
prepared in an ELORA report and distributed according to established rules.

6.1

ELORA baseline run
The first step of an ELORA, using a supporting software package, is the baseline run based on
the gathered ELORA data. This baseline run will result in a first set of information regarding thecost situation for the individual maintenance levels. The result can be clear cut or an ambivalentsituation between the different maintenance levels. In either case, it is recommended to confirm
the baseline run results by executing a sensitivity analysis.

6.2

Sensitivity analysis
A sensitivity analysis should be performed on various cost significant parameters. The results ofthe various sensitivity runs will indicate whether the maintenance solution from the baseline run
is stable or not. Parameters used in a sensitivity analyses include:−−−

Major cost influencing parameters of the IuA itself (eg unit price, MTBF)
Any parameters that are critical to cost intensive logistic requirements (eg facilities,
infrastructure, support equipment, highly educated personnel)
Any parameters using assumptions or estimates because there was no data available (eghistoric or similar data from other products)

Once the parameters for the sensitivity analyses have been selected, the next step is toestablish an appropriate numerical range for the parameter. Finally, when all the requirements
have been established, an ELORA is performed for each parameter variation. Changing single
parameters will keep the number of runs to a minimum. Multiple parameter changes at thesame time will lead to nested runs and therefore should be avoided because evaluation of theresults can be confusing.
The output of the sensitivity analyses can be used as a baseline to establish a preliminary
maintenance solution. Additionally, it can be used to influence other logistic disciplines and/or
design, in order to change their input to drive the equipment to enable an intended maintenancesolution.
A sensitivity analysis is usually conducted to complement baseline results. Sensitivity runs are
performed for cost significant parameters that have a low confidence level or to accomplish a
trade-off study. For a sensitivity analysis of low confidence values, the most common method is
to perform runs using the worst and best case data. If there is no shift in maintenance solution
result between these two runs, then no additional executions using intermediate values are
required.
An example of this is sensitivity for the MTBF of an item. Suppose an estimated value of 50000
hours is used in the baseline run. Preliminary analysis revealed that MTBF’s of similar items
range from 15000 hours to 150000 hours. The first sensitivity runs performed would include
values of 15000 and 150000 hours for the MTBF of this item. If the most cost effective repair
level for both sensitivity runs is the same as the baseline run, no further sensitivity analysis forthis MTBF is necessary. However, if a change in repair level occurs for one or both runs,

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

additional executions using values of MTBF between the high and low value may be necessary
to identify the break points.

6.3

Maintenance solution recommendation
For a concluding maintenance solution recommendation, it is necessary to consider the cost
aspects resulting from an ELORA, as well as technical aspects that can have a major impact on
the recommendation of the maintenance solution to the customer (eg critical repairs that might
destroy the IuA, dangerous repair tasks). Additionally, the customer’s preferences should beconsidered.
It is also important to harmonize the maintenance activities in order to avoid a split of similar
maintenance activities to different maintenance sites. For example, the allocation of a piece ofelectronic equipment for replacement and subsequent repair of different components should not
be split between industry and customer industrial sites.

6.4

LORA Report
A report documenting the analysis results must be generated. The LORA report should contain,
as a minimum, the following:
−
−
−
−
−
−

Agreements reached between the customer and/or the contractors regarding LORA
A brief description of the system/equipment under analysis
Comprehensive list of any assumptions and estimations including their rationale
Data sources
Comprehensive list of the LORA data elements
Input values
•
•
•

−
−
−
−
−
−
−

Operational environment data used for the process
Breakdown of IuA
Cost and maintenance data

Realization of mathematical methods applied within a simplified ELORA
Utilization of ELORA software package
Result of baseline run
Results and explanations of sensitivity analysis runs
Trade-off studies
Consolidation of technical and cost aspects
Concluding recommendation of the maintenance solution including discard decision

It is recommended to develop the report structure and layout early in the analysis process.
Important information and logic can be overlooked during the course of a lengthy analysis.
For good traceability, it is recommended to use a standardized format within the LORA reportfor the maintenance solution recommendation and related customer decision. The customer
decision will be documented in the LSA database.

6.5

Maintenance solution documentation in the LSA database
The content of the maintenance solution is related to the corresponding maintenance activities
as documented in maintenance tasks in the LSA database. Each task for an LSA candidate
should be provided with attributes that reflect the maintenance solution. This information should
contain, as a minimum, the following:
−
−
−
−
−

Is the maintenance task to be performed scheduled or unscheduled?
For scheduled tasks: interval or threshold data.
Is the maintenance task to be performed "on" or "off" product?
The maintenance level at which the task must be performed.
The place at which the maintenance tasks are to be performed.

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00−−−

Special remarks or warnings (eg when the croduct is used under special circumstances,inspection interval has to be reduced from 6 to 3 months)
References to standard repair tasks
Data source information for traceability (eg identification of LORA report)

It is recommended to agree to the basic data set that reflects the maintenance concept during
the LSA GC, in order to enable a common understanding. Proper documentation within the LSA
database enables a strong reporting ability for different aspects of the maintenance concept.
Examples:
−
−
−
−
−

Complete overview of the maintenance activities at all maintenance levels
Summary of maintenance activities performed at certain maintenance levels
Overview of scheduled/unscheduled maintenance activities
Expected effort at certain maintenance levels
Support for quality checks concerning completeness and conclusiveness of themaintenance solution

7

Example for maintenance level definitions

7.1

GeneralAn example of a maintenance strategy is given in the following subchapters, based on threelevels of maintenance, which indicates the capability of personnel, availability of special
facilities, time limits and the environmental conditions to be assumed in determining thefunctions to be accomplished at each maintenance level.

7.2

Level 1
The goal of level 1 maintenance is to allow the product to remain available. This implies a fastand easy exchange of LRU’s and/or the replacement of modules, performed on the product byorganizational personnel when a mal-function occurs.
Level 1 activities are expected to include:
−
−
−
−
−
−
−
−
−

7.3

Servicing activities
Usage preparation and role changes
Pre- and post- inspections
Functional checks
Trouble shooting
Preventive maintenance
Corrective maintenance (repair by replacement and system adjustment)
Loading of software (operational and engineering) and data retrieval
Simple modifications

Level 2
The goal of Level 2 maintenance is to maintain the highest possible level of availability.
Operating site maintenance activities are extended to the repair of subassemblies, modules and
LRUs after their replacement at maintenance Level 1. Testing on test-benches or integration
tests could be performed. Subsequently, Level 2 maintenance can be performed either on or off
product.
Level 2 activities are expected to include:
−
−
−
−
−

Repairs down to module and subassembly level
Moderate structural repairs
Major scheduled inspections
Moderate modifications
Technical assistance to the Level 1 organization

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00−−

Software servicing concerning engineering data
Preservation of complete product

Level 2 activities include corrective and preventive maintenance and specific maintenanceactivities that will be performed both on product (during maintenance the product will be
unavailable for use), and off product. Level 2 includes tasks beyond those accomplished at
Level 1 in order to facilitate the return of the equipment to its full operational state. Level 2
maintenance will be performed at facilities capable of accommodating the maintenance tasks,
which could include special equipment or specialized workshops, and will be performed byappropriately trained and specialized personnel.

7.4

Level 3
The goal of Level 3 maintenance is to assure the highest possible availability of the product, as
well as providing engineering support for operational aspects. All repairs and overhaul activities
beyond Level 1 and Level 2 capabilities shall be assured. Major modifications to improve thedesign and/or operational activities will be prepared and, if necessary, executed at this level.
Level 3 activities are expected to include:
−
−
−
−
−
−
−
−

Repairs down to full reconditioning
Repairs requiring special or rare skills or support equipment
Major structural repairs
Major scheduled inspections
Extended modifications and update programs
Technical assistance to the Level 1 and Level 2 organizations
Software modification
Preservation of the complete product

Level 3 maintenance shall assure a maximum of autonomy for the user organizations.
International cooperation may allow the set-up of an effective and economic authorized level ofmaintenance. Single source repair should be considered the best solution.
Level 3 maintenance will be performed in appropriately equipped facilities or component repair
facilities of the Customer or the Contractor (or subcontractors). Level 3 requires appropriately
trained and specialized personnel. Level 3 maintenance also involves the return of defective
items (suspected or confirmed) to the OEM for repair/overhaul/retest.
Note
The Level 3 activities as the "highest" maintenance level can also be subdivided into two or
more levels (eg Level 3 and Level 4). This can be used when required to clearly separate
the user operated activities from the contractor operated activities at industry facilities. In
this case, the maintenance strategy would contain four levels of maintenance (or possiblymore).

S3000L-A-11-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-11-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 112010-04-01 Page 10

S3000L-B6568-03000-00

Chapter 12
Maintenance task analysis
Table of contents

Page

Maintenance task analysis ............................................................................................................. 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Introduction ...................................................................................................................... 3
1.2
Objective .......................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
1.4
Terms, abbreviations and acronyms ............................................................................... 3
2
Task justification .............................................................................................................. 4
3
Categorization of activities ............................................................................................... 5
4
Task documentation ........................................................................................................ 6
4.1
General aspects............................................................................................................... 6
4.2
Practical considerations ................................................................................................... 6
5
Task structure .................................................................................................................. 9
5.1
Rectifying and supporting tasks....................................................................................... 9
5.2
Structure of supporting tasks ......................................................................................... 10
5.3
Structure of a rectifying task - referencing method........................................................ 11
5.4
Task preconditions, pre-work and post-work ................................................................. 12
5.5
Narrative description ...................................................................................................... 13
6
Task frequency .............................................................................................................. 13
6.1
Maintenance activities due to inherent equipment failures ........................................... 13
6.2
Task frequency for supporting tasks.............................................................................. 14
6.3
Maintenance activities due to damages or special events ............................................ 15
6.4
Scheduled maintenance activities ................................................................................. 16
7
Task resources and task duration ................................................................................. 16
7.1
Resources ...................................................................................................................... 16
7.2
Resources out of references ......................................................................................... 18
7.3
Harmonization of support equipment and spare parts .................................................. 19
7.4
Task location aspects .................................................................................................... 19
7.4.1
Location in conjunction with the product itself ............................................................... 19
7.4.2
Location in conjunction with the required facility/infrastructure ..................................... 19
7.4.3
Location in conjunction with the zone within the product itself ...................................... 19
7.5
Product and system availability during maintenance performance ............................... 19
7.6
Support solutions (task variants) ................................................................................... 20
7.7
Task duration ................................................................................................................. 20
7.8
Parallel activities within maintenance tasks .................................................................. 21
8
Training requirements .................................................................................................... 23
9
Examples of assigning rectifying tasks to LSA candidates ........................................... 23
9.1
Example 1: Major failure of equipment, non-repairable................................................. 25
9.2
Example 2: Mainboard failure of equipment 401 - Option 1 .......................................... 27
9.3
Example 3: Mainboard failure of equipment 401 - Option 2 .......................................... 28
9.4
Example 4: Failure of device 01, repairable at operational site .................................... 30
9.5
Example 5: Complex maintenance procedure on several levels .................................. 32

List of tables
1

References ...................................................................................................................... 2

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Terms, abbreviations and acronyms ............................................................................... 3
Examples for possible categorization of tasks ................................................................ 5
Assembly view versus breakdown view .......................................................................... 6
Component types............................................................................................................. 7
Typical situations of task documentation requirements................................................... 8
Typical rectifying tasks for typical events ........................................................................ 9
Formula symbols (task frequency rectifying tasks) ....................................................... 13
Formula symbols (task frequency supporting tasks) ..................................................... 15
Assignment of task resources ....................................................................................... 16
Summary of resources .................................................................................................. 18
MET and labor time ....................................................................................................... 20
Comparison of resources for sequential or parallel subtasks ....................................... 22
Breakdown of equipment example ................................................................................ 24
Explanation of formats in the schematical LSA representations ................................... 26
Different spare part triggers ........................................................................................... 32

List of figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Event-task correlation ...................................................................................................... 4
General equipment example ........................................................................................... 6
Remove procedure including preliminary work ............................................................. 10
Remove procedure without preliminary work activities ................................................. 11
Typical rectifying task - repair procedure ...................................................................... 12
Task resources .............................................................................................................. 18
Parallel activities and their resources/durations ............................................................ 22
Equipment example ....................................................................................................... 23
Breakdown of Equipment 401 ....................................................................................... 24
Major failure of equipment, non-repairable .................................................................... 25
Schematical LSA representation of example 1 ............................................................. 26
Mainboard failure of equipment 401 - rectified by equipment 401 replacement ........... 27
Schematical LSA representation of example 2 ............................................................. 28
Mainboard failure of equipment 401 - rectified by equipment 401 repair ...................... 28
Schematical LSA representation of example 3 ............................................................. 29
Failure of device 01, repairable at operational site........................................................ 30
Schematical LSA representation of example 4 ............................................................. 31
Major failure of equipment, only repairable at higher level ............................................ 32
Schematical LSA representation of example 5 ............................................................. 34

References
Table 1 References
Chap No./Document No.

Title

Chap 7

LSA failure modes and effects analysis

Chap 8

Damage and special event analysis

Chap 9Logistic related operations analysis

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

Chap 10

Scheduled maintenance analysis

Chap 21

Terms, abbreviations and acronyms

S1000DInternational specification for technical publications using
a common source database

1

General1.1

Introduction
The requirement for a maintenance task has to be analyzed from different perspectives. The
first step will be to divide up the entire task into appropriate working steps, which will be called
subtasks. This is necessary to apply a useful structure to a complex and time-consuming
activity. It is not unusual for repair or replace procedures to contain hundreds of subtasks. The
sequence of each of the subtasks must be clear. The decision to divide up an activity depends
on the requirements for the depth of information. Depending on the use case, it may besufficient to break down an activity into 10 subtasks with some general information. In other use
cases, where there is a requirement to perform a deep analysis, the same task, which was
broken down in just 10 subtasks before is now divided up into 40 subtasks. Additionally, ananalysis of the tasks concerning the resources is required. Everything that is needed to performthe maintenance task must be identified within the Maintenance Task Analysis (MTA).

1.2

Objective
This chapter is a guideline for the analysis of an identified maintenance task concerning its
logistic requirements. This mainly includes spare parts and consumables, support equipment,
personnel, facilities and task duration information. Additional information such as task criticality,
task location, training needs, pre- and post-conditions or safety requirements should also betaken into consideration.

1.3

Scope
This chapter is addressed to analysts who perform analysis activities within the LSA process to
identify corrective and preventive maintenance tasks. After the identification, a deeper analysisof the maintenance activities is required. It is recommended that the establishment of close cooperation between disciplines such as maintainability, testability and reliability, together with thepersonnel to perform an MTA, is created. An ideal solution would be to combine these duties
and assign them to one analyst.

1.4

Terms, abbreviations and acronyms
The following specific terms, abbreviations and acronyms used within this chapter. More special
terms are explained directly within the appropriate paragraphs. Refer to Chap 21 for a full listingof Terms, abbreviations and acronyms.
Table 2 Terms, abbreviations and acronyms
Term

Definition

Supporting task

A supporting task is a part of a complete maintenance activity. As astandalone task it cannot rectify an event, such as failures, damages,
special events or thresholds. A supporting task contains subtasks in termsof working steps.

Rectifying task

A rectifying task is any maintenance activity that resolves an event, suchas failures, damages, special events or thresholds. A rectifying task
contains subtasks in terms of referenced supporting tasks and/or definite
working steps.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

2

Task justification
Any maintenance task or operational activity that is identified as required will cause effort withinsupport engineering and logistic disciplines. For that reason there should be a rational
justification for the performance of each activity in the environment of maintenance andoperational tasks. The principle of event driven maintenance is one of the main aspects.
Maintenance tasks and related operational tasks to be considered by an LSA are justified bycorresponding logistic analysis activities. Failures, damages, special events and thresholds are
the primary drivers for maintenance activities and are described in their specific chapters.
Refer to:−−−Chap 7 LSA FMEA
Chap 8 Damage and special event analysis
Chap 10 Schedule Maintenance Analysis

Additionally, there are additional general tasks which originate from other sources (eg handlingand servicing requirements or software and data loading).
Refer to:−Chap 9Logistics Related Operations Analysis

For proper documentation of the connection between the justifying source and the related
maintenance activity a corresponding structure in the LSA database should be established. The
following figure gives an overview of the relationship between maintenance/operational tasks
and their justification.
Product- General tasks- On demand- For preparation

System breakdown

Failure modes

Corrective
maintenancetasks

Damage modes

Corrective
maintenancetasks
Standard repair
proceduresSpecial events

Inspections
after
special events

Thresholds

Scheduledmaintenance
tasks
MRO
packages

Operation
tasks

Data andsoftwareloading

Maintenance Task Analysis

ICN-B6865-S3000L0049-001-01
Fig 1 Event-task correlation
Especially in the area of operation tasks or data/software loading, it can be difficult to address
exactly whether the task is a maintenance task with a clear justification by a maintenancerelevant event or the task is a general supporting task.
Example: The towing of an aircraft can have different reasons:−−−Towing out of the hangar to prepare for a mission
Towing for refueling purposes
Towing to the maintenance hangar in case of a failure

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

In this case, it is not possible to indicate clearly whether the towing task is part of a maintenanceactivity or an operational activity. However, this task must be considered as a specificsupporting task, which is required for different needs. Documentation of these activities and thequestion of who is responsible for them must be agreed upon between the customer and thecontractor, within the LSA guidance conference, in order to avoid later misunderstanding oreven the neglect of such activities. The integration of these activities within the system
breakdown is described in Chap 3.

3

Categorization of activities
For unique task identification, the use a coding system such as that given in S1000D fortechnical publication is recommended. The activity is clearly categorized in two data elements,
information code and information code definition. Taking into account that technicaldocumentation and the LSA are strongly interconnected, it is recommended that the use of thesame task categorization method in the LSA database is considered. This avoids therequirement for a translation matrix from the LSA task coding and nomenclature to the coding
and naming within a technical documentation system. This approach improves communality,
traceability and, in the end, ILS quality.
In the description of a code for a special activity, there must always be an appropriate verb,
which clearly identifies the activity. Avoid the usage of general terms. In the following table you
will find some examples from S1000D.
Table 3 Examples for possible categorization of tasks
Information code

Information code description

250

Clean

251

Clean with chemical agents

256

Polish and apply wax

341

Manual test

342

Automatic test

520

Remove procedure

720

Install procedure

752

Data loading

921

Remove and replace procedure

Note
With the help of the information code of S1000D, activity groups are defined. There are
more general information codes, such as 250 for clean. Additionally, more specificprocedures concerning cleaning activities can be applied with a more detailed information
code such as 251 for cleaning with chemical agents.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

4

Task documentation

4.1

General aspects
The selection criterion for LSA candidate items is described in Chap 3. Maintenance concepts
for breakdown elements selected as LSA candidates can be documented in different ways. This
paragraph should sensitize the analyst to proper selection of LSA candidates and thecorresponding task documentation method. For these purposes, a very simple general example
is given in Fig 2 to begin clarification of the different methods that can theoretically be used.

Assembly(eg equipment)

Part 01
Part 02
Part 03
Part 04
Part 05

Part nICN-B6865-S3000L0050-001-01
Fig 2 General equipment example
The assembly in Fig 2 above contains n different parts. Theoretically, the assembly itself andeach part within the assembly can fulfill criteria to be selected as a potential LSA candidate.
From a maintenance point of view, there are different possibilities by which to document theidentification of maintenance tasks concerning the repair of the assembly:
Table 4 Assembly view versus breakdown view
Assembly view

Breakdown view

One LSA candidate selected = assembly itself, n LSA candidates selectedeg equipment(each part could become an LSA candidate,because it can be replaced)n maintenance tasks to be documented:
repair assembly by replacement of part 1 topart nn maintenance tasks to be documented:
replace part 1 to part n

Table 4 shows the extreme situation of an either-or decision. As the documentation of an LSA
candidate should be considered as a cost intensive activity, it is recommended to beeconomical with addressing breakdown elements to be an LSA candidate.

4.2

Practical considerations
The situation in reality is more complex than described in Para 4.1. The parts from the simple
example above can be repairable themselves or be discard items. Being repairable can make a

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

specific part within a piece of equipment an LSA candidate also. In this situation, having a LSA
candidate Item within another LSA candidate Item cannot always be avoided.
One of the decisive questions will be which component of the equipment has what kind of
properties concerning the possibility of repair at which maintenance level. This has a large
impact on the storekeeping method of the different items. To clarify terminology, it should be
distinguished between several types of repairable.
Table 5 Component types
Component type

Description

Non-repairable

A part that will not be repaired at any maintenance level. The reason
can be technical and/or economical.
The methods of replacement within the storekeeping must be
clarified.

Repairable on industry
maintenance level

An equipment/part which can be repaired only on industry level.
For such items, only the replacement will be described in the LSA
database. It is recommended to identify the possibility of repair on
industry level in the LSA database; a detailed description of repair
tasks is not required.
The ways of replacement within the storekeeping must be clarified.

Repairable on customer A part/equipment that can be repaired on a specialized customer
maintenance level,
level. For such items, the replacement tasks and the repair
procedures can be described in the LSA database. The level ofdepot site
technical documentation for the maintenance activities should beclearly defined within the LSA guidance conference.
The methods of replacement within the storekeeping must be
clarified.
Repairable at customer
maintenance level,
operational site

A part/equipment that can be repaired at customer level at an
operational site. For such items, the replacement tasks and therepair procedures should be described in the LSA database. The
level of technical documentation for the maintenance activities
should be defined clearly within the LSA guidance conference.
The methods of replacement within the storekeeping must be
clarified.

This rough classification of equipment/parts additionally depends on the influencing events on
the items. There can be failures that lead to the disposal of the complete equipment/part, andother failures will result in the equipment/part being repaired. Each event has to be analyzed to
identify which maintenance activity at which maintenance level must follow to rectify the event. It
should be pointed out that a definitive decision is not always possible. There will be events thatcan be rectified on several maintenance levels. In this case, not only the types of influencing
events are significant, but also the economic aspects must be considered carefully. For
example the result of a Level of Repair Analysis (LORA) can be the replacement of thecomplete equipment (with a following discard) because of economic aspects, however theequipment would be repairable. Also, mixed scenarios are possible. For example, a certain
percentage of a specific failure is rectified at the customer maintenance level, and the balance
will be returned to the industry maintenance level because of capacity constraints at customer
maintenance level.
In practice, many different situations concerning maintenance driving events (especially failures)and the following required chain of maintenance activities can occur. For better understanding,Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

Table 6 gives an overview of typical examples. Additionally, an example of a rather simple pieceof equipment is given in Para 9 (different maintenance situations and how they should be
documented in the LSA).
Table 6 Typical situations of task documentation requirements
Event

Rectifying task

Possiblefollowing task

RemarkFailure of a nonrepairable
component ofequipment

Repair equipment
by replacement offaulty component
at operational site

Disposal of
faultycomponent

Non-repairable component is required as aspare part

Failure of arepairable
component of anequipment

Repair equipment
by replacement offaulty component
at operational site

Repair faulty
component at
operational site

Failure of arepairable
component of anequipment

Repair equipment
by direct repair offaulty component
at operational site

None

Failure of repairable
component of anequipment,
component isrepairable atcustomer depot site

Repair equipment
by replacement offaulty component
at operational site

Forwarding
component tocustomer depot
site

Failure of repairable
component of anequipment,
component isrepairable atindustry level

Repair equipment
by replacement offaulty component
at operational site

End item is not waiting until the completion of
the repair of the component
Component is required as a spare part
End item is waiting until the completion of therepair of the component
Component is not required as a spare part,
because the repaired component will be reinstalled

Repair faulty
component at
customer depot
site

Failure of
Replace faulty
equipment, only
equipment at
repairable atoperational siteindustry or customer
depot site

If the documentation of the discard of thefaulty component is required, a specificdisposal procedure would be documented
against the component (as the appropriate
LSA candidate) as a separated rectifying task

Forwarding
component toindustry

Forwarding
equipment toindustry
Repairequipment at
industry or
customer depot
site

Applicable to: All

Repairable component is required as a sparepart at operational site
If the documentation of the repair of the faulty
component as a following task is required, itwould be documented against the component(as the appropriate LSA candidate) for the
repairRepairable component is required as a sparepart at operational site
Documentation of repair on industry level not
required

Equipment is required as a spare part at
operational site
If the documentation of the repair of the faulty
equipment at customer depot site as afollowing task is required, it would be
documented against the equipment (as theappropriate LSA candidate) for the repair

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

Event

Rectifying task

Possiblefollowing task

RemarkMajor failure of
Replaceequipment, no repair equipment at
possible
operational site

Discard faulty
equipment

Equipment is required as a spare part on
operational site
If the documentation of the discard of thefaulty equipment is required, a specificdisposal procedure would be documented
against the equipment (as the appropriate
LSA candidate) as a separated rectifying task

It is not possible to document all combinations of events and the following repair/replace
activities within this chapter. The examples given are typical ones. Depending on additional
aspects (eg abilities at the different maintenance levels, scrap rates of equipments orcomponents, end item waiting for repair or not), the sequence of activities can be influenced in
multiple way. The examples should help clarify the principle of summarizing maintenanceactivities within a few full LSA candidates. A number of following tasks on higher maintenancelevels need not to be analyzed in detail. Only the identification of such possible tasks can beimportant. In most cases, a failure of equipment is rectified by two different task types:−−

Replacement of the entire equipment (represented by a specific breakdown element)
Repair of equipment by replacement of parts (as a following task)

The following tasks describe the repair procedures that must be carefully analyzed in order todecide where these activities must be linked to and how deep of a detailed description isrequired. Another aspect to be considered is that not every replace task can be performed at acustomer operational site. For this reason, it may be necessary to transport the complete
product/end item itself to a higher level maintenance site. In this case, the replacement ofdefective equipment will be performed at industry level or at a customer depot site.

5

Task structure
Previous experience has shown that a common understanding of how to create a proper
maintenance task structure may not be accomplished without any problems. For this reason,
the following paragraphs give an introduction of how to categorize maintenance activities, how
to introduce a hierarchy of tasks and subtasks and how to use information within existing tasks
efficiently with the help of an intelligent referencing system.

5.1

Rectifying and supporting tasks
One important step to give a structure to the tasks is to divide them into two classes of tasks.
−−

Rectifying tasks ("event solver")Supporting tasks

Each maintenance activity is driven by an event. This event can be a failure, damage, a special
event or a deadline, which has expired. All of these events require a maintenance action to becompleted. Each task that is able to resolve such an event should be defined as a rectifyingtask. Typical examples for rectifying tasks are the following:
Table 7 Typical rectifying tasks for typical events
Event

Rectifying tasks

FailureRepair or replace procedures

DamageRepair or replace procedures

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6568-03000-00

Event

Rectifying tasks

Special event

Inspection/fault location

Threshold

Scheduled maintenance action (eg scheduled replace of a time change item)

As opposed to the rectifying task, a supporting task cannot be the solving task for an event. The
supporting task as a standalone task can never resolve a failure or damage and can never be
the standalone activity after a special event. Also, operational needs can cause specificactivities which belong to the group of supporting tasks. Typical supporting tasks are thefollowing:
−
−
−
−
−

Test procedures
Gain access/undo accessRemove and install procedures
Assemble and disassemble procedures
Jacking up of a vehicle

It should be clear that even supporting tasks can be complex and time-consuming, therefore, it
must be possible to divide these tasks into subtasks.

5.2

Structure of supporting tasks
With the help of supporting tasks, the analyst is able to create a library of task modules, which
can be used later to support the creation of the more extended rectifying tasks. The supportingtask can be divided into work steps. In the following figures, you can see a simple approach forthe arrangement of a rather simple remove procedure:
Remove procedure(for equipment 401)
Prework step 1

Remove cover 1 (opening 4 quick fasteners)

Prework step 2Open 24 screws for removal of cover 2

Prework step 3

Remove cover 2

Prework step 4

Remove sealing

Working step 1

Remove electrical connector E01-013

Working step 2Open safety screws S01 and S02

Working step 3

Open attaching screws A01 to A07

Working step 4

Remove equipment 401 from housing

Pre-work
not directly
connected to theequipment to be
removed (egactivities to gain
access)Activities
directlyconnected
to theequipment tobe removed

ICN-B6865-S3000L0051-001-01
Fig 3 Remove procedure including preliminary work
As shown in Fig 3, this example contains both the pre-work and the working steps indicatingthat the pre-work steps must be completed before the real work concerning the IuA begins. Thissituation should be avoided when building supporting tasks. All of the preconditions to performthe working steps concerning the IuA itself should be considered as completed when startingwith the first working step. For this reason, the situation shown in Fig 3 reduces to a task
structure described in Fig 4.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6568-03000-00

Remove procedure(for equipment 401)
Working step 1

Remove electrical connector E01-013

Working step 2Open safety screws S01 and S02

Working step 3

Open attaching screws A01 to A07

Working step 4

Remove equipment 401 from housing

Activities,
directlyconnected
to theequipment tobe removed

ICN-B6865-S3000L0052-001-01
Fig 4 Remove procedure without preliminary work activities
This second way of documenting the supporting tasks is the recommended one. The working
steps should be described with the help of subtasks within the supporting task. References toother existing supporting tasks must not be used in order to avoid nested references.

5.3

Structure of a rectifying task - referencing method
After the creation of a library of supporting tasks, the next step will be to arrange the rectifying
maintenance tasks, this means those procedures that can serve as "event solvers". In Fig 5, thestructure of a typical repair procedure of equipment is shown. Within this repair procedure, there
are a number of subtasks. Some of them are subtasks that have already been described onanother breakdown indenture level (eg the removal of the cover 2). Some of them are subtasks
that are ready described on the same breakdown indenture level (eg the removal or the
installation of the equipment 401). Both are possible, however, it is not necessary to describe
the removal of the cover 2 again within the repair procedure. This is already done at the
breakdown level of the cover 2 . Therefore, it is recommended to use a reference to this existingtask. Never use copies of existing task structures. It is possible that special supporting tasks
may be referenced frequently within a project. Therefore, for updating reasons, the original
information should be documented only once within the LSA database. In case of modificationsof the supporting task, the change needs only to be performed once. All references would be
updated automatically.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6568-03000-00

Repair procedure(for equipment 401)

Subtask 1

Reference on: Fault location procedure

Subtask 2

Remove cover 1 (opening 4 quick fasteners)

Subtask 3

Reference on: Remove cover 2
Working step 1

Open 24 screws for removal of cover 2

Working step 2

Remove cover plate

Working step 3

Remove sealing

Reference on: Remove equipment 401

Subtask 4

Subtask 5

Working step 1

Remove electrical connector E01-013

Working step 2Open safety screws S01 and S02

Working step 3

Open attaching screws A01 to A07

Working step 4

Remove equipment 401 from housing

Reference on: Disassemble equipment 401
Working step 1

……………

………..

……………

Subtask 6

Remove defective component 5

Subtask 7

Install new component 5

Subtask 8

Reference on: Assemble equipment 401

Subtask 9

Reference on: Install equipment 401

Subtask 10

Reference on: Test function of equipment 401

Subtask 11

Reference on: Install cover 2

Subtask 12

Install cover 1

ICN-B6865-S3000L0053-001-01
Fig 5 Typical rectifying task - repair procedure
In Fig 5 you can see a typical arrangement of a rectifying task. There are both subtasks andreferences to existing supporting tasks within the sequence of the entire repair procedure. In an
extreme case, a rectifying task may contain only references to existing supporting tasks.
Note
The use of references is recommended for all activities, which are always the same,
independent of where and how often the IuA is installed in the product (eg disassemble orassemble tasks are normally always the same, when the items are removed from theproduct). Installation and removal tasks on the other hand can be very different, if an item isinstalled in several locations in the product.

5.4

Task preconditions, pre-work and post-work
For each task, a number of preconditions must be fulfilled in order to carry out the activity. Suchpreconditions are of special interest for technical publications. Preconditions concerning safety
must be carefully documented. The following aspects should be covered:−−−General preconditions:This area should describe the general preliminary work that must be carried out in order toachieve the conditions, so that the real task can be started.
Safety preconditions:This area should cover all aspects necessary to achieve conditions in which the task can be
carried out in a safe environment (warnings and cautions).
Personnel preconditions:
In this area, all personnel aspects should be covered. This includes the requirement ofApplicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6568-03000-00

additional abilities or certifications of the person as well as the need for special personalrequirements to achieve safety regulations.
The activities that must be carried out before reaching the required preconditions should appear
in the sequence of the complete maintenance task (supporting or rectifying) as corresponding
subtasks.
Another aspect is the identification of pre-work and post-work activities. In extended repair or
replace procedures containing a large number of subtasks, there can be a number of subtasks
which are necessary for the preparation of the subject repair or replace procedure (eg gain
access or failure location procedures). Such subtasks for preparation should be marked in the
LSA database as pre-work. The same applies to post-work activities, which do not belong to thereal repair or replace procedure, but have to be performed in order to actually close thecomplete maintenance task (eg cleaning of support equipment, paperwork).

5.5

Narrative description
First of all, it should be pointed out that the narrative description of a maintenance activity is
primary a matter of technical documentation. For this reason, performing one and the sameactivity twice should be avoided. An extended description of a task within the LSA is notdesirable. A short description of the working steps can be given, but the wording should be
brief. The LSA needs to identify the maintenance activities and analyze the identified tasks. The
use of narrative texts in the LSA as a draft for technical documentation should be verified
carefully. Technical documentation normally must obey strict rules concerning language,
formatting and layout.

6

Task frequency
An important piece information concerning maintenance activities is the frequency of theanalyzed rectifying task. The frequency that a maintenance activity will be performed within ayear is of central significance for the planning of logistic resources. The task frequency is
directly linked to the frequency of the triggering event. The frequency of some events can beforeseen rather well, while others can be only estimated with the help of statistic methods.

6.1

Maintenance activities due to inherent equipment failures
Equipment failures statistically occur after a logistic time parameter called the Mean Time
Between Failure (MTBF). This is a value for the average duration between two failures ofequipment. With the assumption of a constant MTBF over the entire usage time and a single
installation of equipment, a predicted task frequency of a rectifying task can be calculated with asimplified formula:k

TFrec = ∑ FMRi ⋅
i =1

AOR
⋅ λcorr ⋅ λMB
MTBF

Table 8 Formula symbols (task frequency rectifying tasks)
Formula symbol

Explanation

TFrec

Task frequency of the rectifying task (1/year)

AOR

Annual operating requirements [operating hours/year]
For equipment that works in continuous operation, AOR is 8760 hours per
year. The measurement base of the AOR can also be something otherthan operating hours (eg distances or number of cycles).

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6568-03000-00

Formula symbol

Explanation

MTBF

Mean Time Between Failure [operating hours]. The measurement base of
the MTBF also be something other than operating hours (eg distances or
number of cycles).

FMR

Failure mode ratio
The failure of equipment can be distributed between several components.
Each component can be responsible for the failure of the whole equipmentwith a certain ratio.

λcorr

Correction factor for MTBF (in case of special conditions at special
installation areas). This correction factor can differ at each installation
location of equipment. Especially in the case of a multiple installation ofequipment, this correction factor can be of special relevance.

λMB

Correlation factor to convert different measurement bases of AOR and
MTBF (eg a MTBF is given not in operational hours, but in case of avehicle in a specific distance measurement base like kilometers, miles).

iIndex for the identification of the FMR of the single failure modeiwithin theanalyzed equipment.

kNumber of different failure modes to be considered for the accumulation.

The formula above can be considered to be the simplest possibility. A more precise task
frequency calculation is only possible with more complex formula taking into account otherinfluence factors such as:−−

No failure found factors (eg Built in Test (BIT) cannot duplicate)
Correction factors for different environmental influences ( λcorr in the formula above)−

Correlation factors to convert different measurement bases of AOR and MTBF ( λMB in theformula above
MTBF can be a function of time MTBF(t), then integral calculation has to be used
MTBF can be of different types (eg predicted, allocated, measured), the one to be usedshould be selected carefully
Correction because of induced failures can be required−−−

The logistic value MTBF is of special interest when different types of equipments are analyzed.
The distribution of the MTBF value over the entire life cycle of equipment can have different
behavior depending on the type of the equipment. It should be pointed out that MTBF values
can change over the life cycle of equipment. Mechanical equipment with obsolescence has
behavior that is different than for, for example, electronic equipment. Such reflections will bemade by reliability analysis activities. With the help of mathematical functions, different failure
distribution behavior can be described in detail. In this context refer to special literature
concerning reliability.
In case of multiple installation of equipment it is recommended that the task frequencies foreach installation point be calculated separately. For a required accumulation of task frequencies(eg for maintenance tasks being performed in a special repair shop) the calculated single task
frequencies can be summarized. Depending on the installation area, the frequency of the failureof equipment can be dramatically different.

6.2

Task frequency for supporting tasks
For supporting tasks, a task frequency cannot be calculated in the same way as for rectifying
tasks. Supporting tasks are not linked directly to any event like the rectifying tasks are.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6568-03000-00

However, supporting tasks are normally "called" by rectifying tasks using the referencing
method. By adding the task frequencies of the referencing rectifying tasks, a "sum up" task
frequency of any supporting task can be calculated with the help of the following simplified
formula:n

TFsupp = ∑ λQ ⋅ TFrec ,i
i =1Table 9 Formula symbols (task frequency supporting tasks)
Formula symbol

Explanation

TFsuppTask frequency of the supporting task (1/year)

TFrec ,iTask frequency of the referencing rectifying task (1/year)

λQ

Number of "calls" of the rectifying taskifor the supporting task to be
calculatedi

Index for the referencing rectifying tasksnNumber of the referencing rectifying task

It should be noted that the task frequency of supporting tasks must be used with care since therelated task requirements are already covered by the rectifying tasks themselves whichreference the supporting tasks.
Care must be taken to avoid double counting any requirements.
When is the calculation of the task frequency of a supporting task meaningful?
The task frequency of a supporting task may, however, be of interest concerning statisticalfigures that may be used for:−−Identification of maintenance drivers to be assessed for potential improvement of design
Quantification of maintenance activities depending on the real usage/maintenance of an
item

Example: Opening and closing of covers
The remove and install tasks of a cover can be referenced many times by different rectifying
tasks from many different LSA candidates. It can be important how often a cover is reallyremoved and installed within one year because of the need for some spare parts after a certain
number of removal and installation. The remove and install of the cover due to inherent failure
or because of damage is normally only a small fraction of the real removal and installation
activity. The dominating fraction results from the need to gain access to other equipment behindthe cover.
Because of the frequent removal and installation of a cover, the design aspect needs to be user
friendly (eg by the usage of quick release fasteners).

6.3

Maintenance activities due to damages or special events
Failures of equipment for other than inherent reasons cannot be predicted in the same way as
described in Para 6.1 since the task frequency can only be estimated. If there is any experience
concerning the occurrence of damages or special events, with the help of statisticalinvestigations for example, the results can be used to get a feel for how frequent these
unpredictable events occur and how frequent the corresponding maintenance activities willarise.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6568-03000-00

However difficult it is to forecast the frequency of these events, it is important to get an
estimation based on the best information available. All maintenance activities, which are
triggered by these events, have their corresponding requirements concerning material andpersonnel. To estimate the resources and the capacity utilization, these unpredictable events
must be taken into account.

6.4

Scheduled maintenance activities
In the case of scheduled maintenance, no additional calculation or estimation is required
because the interval of the maintenance activity is fixed by the corresponding Scheduled
Maintenance Analysis (SMA) and by maintainability activities by assembling proper scheduled
maintenance packages.

7

Task resources and task duration

7.1

Resources
The resources necessary to perform a maintenance tasks should be defined at a common levelwithin the task itself. Generally, it should be possible to identify when a resource should beavailable within the sequence of the task. Additionally, it can be of interest for training purposes,
which personnel are relevant for the usage of special support equipment. Based on the principleof the structure of tasks, which can be arranged by subtasks and references to supportingtasks, the assignment of the resources should be done accordingly. It is recommended to follow
the basic principle that each resource should be linked to that activity, when the resource
actually is needed. Table 10 gives an overview of possible resources and the method of linking
it to the corresponding activity.
Table 10 Assignment of task resources
Resource

Description

Spare parts

Spare parts should be assigned to the subtask, where they are actuallyrequired. To get an overview of the required spare parts for the entire task,
all spares from the subtasks or from the referenced supporting tasks can besummarized.

Consumables

Consumables should be assigned to the subtask, where they are actuallyrequired. To get an overview of the required consumables for the entire task,
all consumables from the subtasks or from the referenced supporting tasks
can be summarized.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6568-03000-00

Resource

Description

Supportequipment

Support equipment should be assigned to the subtask, where it is actuallyrequired. To get an overview of the required support equipment for the entire
task, all support equipment from the subtasks or from the referenced
supporting tasks can be summarized. Identical support equipment that isused in parallel should be summed up.
Information can also be added about which personnel use the support
equipment. In complex subtasks, more than one person could be actively
using several pieces of support equipment. For training requirements, it
should be possible to associate support equipment with the relevant
personnel resource.
The assignment of support equipment often identifies the need only. In thiscase, the identification initiates a process to procure or to develop
corresponding support equipment based on an adequate specification.
Therefore, the following cases are possible for the analyst in the MTA
concerning support equipment:−

Selection of existing and proven support equipment−

Selection of a specification for support equipment−

Identification of the need to develop a new specification of completely
new support equipment

Personnel

Personnel should be assigned to the subtask, where they are actuallyrequired. To get an overview of the required personnel for the entire task, allpersonnel from the subtasks or from the referenced supporting tasks can besummarized.

Facilities

Facilities should be assigned to the subtask, where they are actually
relevant. To get an overview of the required facilities for the entire task, allfacilities from the subtasks or from the referenced supporting tasks can besummarized.

Technical
documentation

Technical documentation requirements (eg original manufacturer's
documentation) should be assigned to the subtask, where it is actually
relevant.

Note
Although the S3000L data model enables the material resources to be linked to both task
and subtask, it is highly recommended that they are assigned to the subtask, where it isactually required. In some specific cases it can be reasonable to link a resource on task
level, eg if the resource is in use during the entire task and the task contains a large
number of subtasks.
On the level of the entire task, all resources from the subtasks and referenced supporting tasks
should be summarized and harmonized. This summary can be presented by reports concerning
the different resources (or even for all resources in one report). An example is given in Fig 6.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6568-03000-00

Install procedure for equipment 401
Subtask

SparesConsumables

Supportequipment

Personnel

Install equipment
401 into housing

Seal
[1x]

Adhesive C[as required]

None

Electrician 1
Electrician 2

Close attaching
screws
A01 to A07

Washer
[7x]

None

None

Close safety
screws
S01 and S02

None

None

Install electricalconnector
E01-013

None

None

Specialfacilities

MET

Labor
time

None

1 min

1 min
1 min

Electrician 1

None

3 min

3 min

Torquewrench[1x]Electrician 1

None

2 min

2 min

None

Electrician 1

None

0,5 min

0,5 min

ICN-B6865-S3000L0054-002-01
Fig 6 Task resources
The summary for the install procedure from Fig 6 on task level would be the following:
Table 11 Summary of resources

7.2

Resource type

Resource

Quantity

Spare parts

Seal
Washer1
7

Consumables

Adhesive C

As required

Support equipment

Torque wrench

1

Personnel

Electrician

2

Special facilities

noneTechnical documentation

not required

Mean Elapsed Time (MET)
Labor time

6,5 minutes
7,5 minutes

Resources out of references
Within the methodology of referencing on supporting tasks, it should be considered that theresources of the referenced tasks will be taken over to the referencing rectifying task. At firstglance, this seems to be a proper approach. However, this approach can result in a false
estimation of personnel requirements. Normally, simple working steps are performed bypersonnel with a lower qualification (eg the removal of access covers). For that reason, these
personnel are normally documented within these simple supporting tasks. If the supporting task
is referenced within an extended repair or replace procedure, there must be the option in thiscontext to change the real executing personnel to another person (with another/higher
qualification), who is also able to perform the referenced activity and who is involved in thecomplete task anyway.
Similar to personnel, the use of support equipment originating in referenced supporting tasks
should be analyzed carefully. Perhaps it is possible to replace the support equipment from theoriginal supporting task by another, which is also used within the complete rectifying task at
another position and which can also fulfill the needs of the original support equipment. In thisApplicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6568-03000-00

case, it is possible to reduce the amount of different support equipment that must be used within
the rectifying task.

7.3

Harmonization of support equipment and spare parts
To reduce administrative effort and to avoid needless costs, it should be ensured that all
identified support equipment and spare parts will be harmonized on the product level. The list of
support equipment must be analyzed whether there are options to replace several prices ofequipment by combined equipment or if there are support equipment of different manufacturers
with exact the same functionality. The mixture of spare parts from different manufacturers
should be avoided where identical items of supply are installed in the same location.

7.4

Task location aspects
To cover all aspects concerning the location at which a task is performed three different location
information types should be distinguished.

7.4.1

Location in conjunction with the product itself
Comparable with the S1000D data element Item Location Code, this aspect must be covered in
S3000L, also. In previous projects the terminology "On" and "Off" tasks can be referred tofrequently. This means the location of the maintenance activity with regard to the product. An"On"-task concerning location means that the activity is performed directly on the product (forexample in or directly at the aircraft). For example, a removal task of a LRU is always an "On"task, because the LRU is always removed directly from the product. The disassemble task after
the removal may be performed in a special maintenance shop is a typical example for an "Off"task concerning the location.

7.4.2

Location in conjunction with the required facility/infrastructure
Another piece of information concerning location of a task is the attribute of a required facility.
Additional to the "On" and "Off" information from Para 7.4.1 the required facility is an attribute at
the subtask level. The selection of a facility object as the location of a subtask does not fix
automatically the location information concerning "On-" and "Off-" activities. Examples forinfrastructure or facilities can be the following:
−
−
−
−

7.4.3

Maintenance hangar
Individual shops such as electronic shop or engine shop
Movement area
Out of area

Location in conjunction with the zone within the product itself
If the Product is divided into physical areas (zones) this information can be added as anadditional attribute (eg a zone identifier) to the subtask. In this case, the location aspect isrelated to the layout of the product. The information can be used to estimate the amount ofactivity within each local zone of the product.
Note
Information concerning zones can also be used for the documentation of the result of azone analysis in conjunction with an SMA. In this case, the zones will be documented in theform of non-hardware breakdown elements. The identified scheduled maintenance tasks
can be documented against these breakdown elements (refer to Chap 10).

7.5

Product and system availability during maintenance performance
Further important information concerning the product or different systems within the product isthe availability during maintenance activities. This information can be documented with the helpof corresponding codes on different breakdown levels.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6568-03000-00

This information covers the ability to operate the product during maintenance procedures. It
should be distinguished between the following situations which can be documented by using
corresponding codes:
−

−
−

7.6

Product not available during maintenanceIn this case, the product cannot be used during, for example, a repair procedure or aninspection. The product must wait until the maintenance action is finished before it isavailable again. A typical situation can be the removal of a defective component and therepair of the defective component (eg in a special maintenance shop). After successful
repair, the repaired component will be re-installed into the product. During the entire repair
activity on the defective component, the product was waiting.
Product available during maintenance with reduced capability
In this case, the product can be used during, for example, a repair procedure or aninspection with reduced capability.
Product fully available during maintenanceIn this case, the product can be used during a repair procedure or an inspection with fullcapability. A typical example is the replacement of a defective component by a new one.
Upon completion of the replace procedure, full capability is recovered. However, thedefective component may be repaired in a special maintenance shop, but this repair does
not have any influence on the availability of the product. After the successful repair, therepaired component will be stored for later use.

Support solutions (task variants)
Maintenance activities can differ depending upon the environmental conditions during theperformance of the task. In this case, the task itself can be nearly the same, however additional
support equipment may be required or the task itself is different from the original one. Reasonsfor variants of tasks could be:
−
−
−
−
−

Performance of the task under different environmental conditions (climatic aspects)
Performance of the task at different places
Performance of the task for another customer with different preconditions concerning
personnel and equipment of the operational site
Permanent repair or temporary repair
Differences from peace time to war time scenarios

The task variants should be differentiated via applicability, depending upon the project.

7.7

Task duration
To get an overview about the capacity utilization of personnel and support equipment, time
information about the tasks is required. Within the task, it must be distinguished between the
duration of a task and the working time of the personnel. The following table explains thedifference between Mean Elapsed Time (MET) and labor time.
Table 12 MET and labor timeTime

Description

Mean Elapsed Time
(MET)

Duration of the entire task. The duration should be addressed against
the subtasks. The duration of the whole task can be calculated as thesum of times coming from the subtasks and from the referenced
supporting tasks.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6568-03000-00

Time

Description

Labor time

Summarized duration of personnel work. The duration should be
addressed against the subtasks. If more than one person is working
parallel on a subtask, the labor time for each different skill level mustbe summarized.
For example three persons of the same skill level are working parallel
within a subtask, which takes 20 minutes. In this case for this subtask
the following times can be documented:
MET:
20 minutes
Labor time: 60 minutes

Concerning times/durations of maintenance tasks, it must be considered as to what kind of
duration should be documented in the MTA. Taking into account the non-productive times toestimate personnel requirements is an especially important aspect. In the LSA database,normally so-called "spanner-in-hand" times are documented. This means that all preliminary
work concerning preparation of the real maintenance activity (eg paperwork, fetching of support
equipment or material) normally is not included. To take into consideration non-productive
times, estimates outside the LSA should be performed.
Another aspect is the consideration of logistic delay times. Any delay caused by waiting times
for logistic resources (eg support equipment or facilities not immediately available, waiting for
personnel, waiting for materiel) is usually not documented in the LSA. To take into consideration
logistic delay times, estimates outside the LSA should be performed similarly to the nonproductive times described in the paragraph above.
Note
Waiting times caused by integral parts of a maintenance task such as the curing of materielor the drying of paint should not be considered in the same way as non-productive times orlogistic delay times. Another aspect could be the need for authorized inspection before
continuing the entire maintenance task with the next step. These well predictableprocedures should be documented within a maintenance task as its own subtask with its
specific duration and logistic requirements.

7.8

Parallel activities within maintenance tasks
For the sake of completeness, a means to handle work steps that can be performed in parallel
should be described. Especially for complex maintenance tasks containing many subtasks that
may be performed by different personnel, the simultaneous performance of work steps should
be considered. This simultaneity of activities of course has influence on MET for the complete
maintenance task, as well as for the task resources concerning support equipment andpersonnel. This is explained by the following example:

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6568-03000-00

tot1 = 1 min

t3 = 8 min

t2 = 4 min

t4 = 12 min

t5 = 15 min

ST5

ST8

P3 SE A SE B
ST1
ST2
P1 P1 SE A

P1

ST3
P2

t6 = 18 min t7 = 20 min

P3
ST4
P2 SE B

ST6

ST7
P1

P1

time

Mean Elapsed Time (MET) = 20 min

P1

Person 1 – Mechanic basic

Labor time = 16 min

P2Person 2 – Mechanic advanced

Labor time = 8 min

P3

Person 3 – Mechanic basic

Labor time = 11 min

SE A

Support equipment A

SE B

Support equipment B

Labor time = 35 min

ICN-B6865-S3000L0055-001-01
Fig 7 Parallel activities and their resources/durations
The example above should clarify the different effects of parallel activities.
The parallel subtasks ST5 to ST3/ST4 require the support equipment SE A and SE B. For
subtask ST5 the same support equipment as in subtask ST2 can be used because these
activities are not performed in parallel. The consequence for the complete task is therequirement of one support equipment SE A. For support equipment SE B, we have anothersituation. Because of the parallel use of support equipment SE B in the partly parallel subtasks
ST4 and ST5, there is a requirement of two support equipments SE B for the complete
maintenance task.
A similar situation holds for the personnel. The person with the qualification mechanic basic is
required in parallel for the subtasks ST3 and ST5 as well as for ST7 and ST8. This causes therequirement of an additional person P3 with the same qualification as person P1.
The following table should clarify the differences between a simple approach using a sequential
methodology (one subtask after the other) or the possibility of parallel activities.
Table 13 Comparison of resources for sequential or parallel subtasks
Step by step sequence

Parallel activities

Mean Elapsed Time:MET = 35 min

MET = 20 min

Support equipment requirements:
SE A: 1
SE B: 1

SE A: 1
SE B: 2

Personnel requirements:
Mechanic basic:
1 (P1)
Mechanic advanced: 1 (P2)

Mechanic basic:
2 (P1 and P3)
Mechanic advanced: 1 (P2)

To document the parallel and sequential performance of subtasks, the elements
subtask_timeline_event and subtask_timeline_lag contained in the Chap 19 data model can be
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6568-03000-00

used to document the relationship of subtasks. This can also be used to create a draft version
of a working plan by eg deriving a graphic schedule of a maintenance task from the LSA
database content..

8

Training requirements
The identification of training requirements concerning maintenance activities can be derived
from the maintenance tasks documented in the LSA database. In this context they need to
distinguish between special training needs and training needs which are covered by the abilities
which can be attained by normal professional education. However, especially in many
international projects, the aspect of national situations concerning education may make it
difficult to identify general training needs for each partner nation.
To support the Training Needs Analysis (TNA), there is a need to document special training
requirements to perform a maintenance task. For this reason, the task should be analyzed
concerning requirements on the subtask level (eg the use of a complex support equipment
which requires training) as well as on the task level to judge the complexity of the task as awhole. The following aspects should be considered:
−
−
−
−
−
−
−
−

Responsible section or department for the maintenance task
Selected skill level of personnel performing the subtask
Need for team training due to the complexity of the task
Use of special support equipment which requires training
Required special training to perform the task/subtask
Required training methods
Required experience to perform the task/subtask
Complexity of the task as a whole

It should be noted that the information concerning training should be collected at the subtask
level. At the subtask level it is possible to analyze each activity in detail and to assign special
support equipment to the affected person performing the activity. Summarizing the results of the
training information on the subtask level for the complete task is the last step.

9

Examples of assigning rectifying tasks to LSA candidates
The following examples should help to get a better understanding how to assign tasks to thecorresponding LSA candidates. For that reason, a simple example of equipment should be used
for the following typical cases.

Equipment 401
Device 01

MainboardPart 01
Part 02
Part 03

Board 01

Power supply
Connector
Transformer

ICN-B6865-S3000L0056-002-01
Fig 8 Equipment example
This equipment example contains the following components with corresponding properties:

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6568-03000-00

Table 14 Breakdown of equipment example
BEI

Name

Component type

Next higher
BEI

46-01-01

Equipment 401

Equipment (LSA candidate)-46-01-01-01

Device 01

Repairable at customer operational site

46-01-01

46-01-01-01-01

Part 01

Repairable at industry

46-01-01-01

46-01-01-01-02

Part 02

Non-repairable

46-01-01-01

46-01-01-01-03

Part 03

Non-repairable

46-01-01-01

46-01-01-02

Board 01

Repairable at industry

46-01-01

46-01-01-03

Mainboard

Non-repairable

46-01-01

46-01-01-04

Power supply

Repairable at customer depot site

46-01-01

46-01-01-04-01

Connector

Non-repairable

46-01-01-04

46-01-01-04-02

Transformer

Repairable at industry

46-01-01-04

Equipment 401
46-01-01

Device 01

Board 01

Mainboard

Power supply

46-01-01-01

46-01-01-02

46-01-01-03

46-01-01-04

Part 01

Part 02

Part 03

Connector

Transformer

46-01-01-01-01

46-01-01-01-02

46-01-01-01-03

46-01-01-04-01

46-01-01-04-02

ICN-B6865-S3000L0102-001-01
Fig 9 Breakdown of Equipment 401
The following paragraphs should help to receive an impression how maintenance activities canbe presented within the LSA database. From a rather simple situation like an equipment
replacement to an extended one with several activities at several maintenance levels theexamples should sensitize to the diversity of maintenance tasks and to the need of careful
documentation of every information which is crucial to complete a maintenance activity. For
each event driven situation there are several potential solutions to rectify the failure. In theexamples typical possible solutions are shown. In the figures which show the representation of
the LSA database content the information is reduced to the essential steps in terms of LSA.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6568-03000-00

9.1

Example 1: Major failure of equipment, non-repairable
Customer´soperational
site

Customer´smaintenancedepot/storage

Equipment 401
Device 01

MainboardPart 01
Part 02

Power supply

Part 03
Board 01

Equipm ent 401

Connector

Device 01

Transformer

Part 02

MainboardPart 01

Power supply
Part 03
Connector

Board 01

Transformer

Spare part

1
4

5

Maintenanceshop atoperational site

Industry
Manufacturer

Discard
DisposeEquipm ent 401

Device 01

Equipm ent 401

MainboardPart 012

Device 01

Part 02
Power supply

Power supply

Part 03

Part 03
Connector

Connector

Board 01

MainboardPart 01

Part 02

Transformer

Board 01

Transformer

3
ICN-B6865-S3000L0057-002-01
Fig 10 Major failure of equipment, non-repairable
Event:
Failure of equipment 401 which cannot be repaired by replacement of components, a complete
equipment change is required
LSA candidate: Equipment 401
Complete maintenance procedure description:
1

Remove faulty equipment 401 at customer's operational site

2

Test faulty equipment 401 at maintenance shop (need for a new equipment 401 to replace
the faulty equipment 401 identified).
Discard/dispose faulty equipment 401 (following task)

3

Receive spare part (complete equipment 401) from customer's maintenance depot

4

Install new equipment 401 at customer's operational site (replacement of equipment 401)
Failure rectified, product can be used again

5Re-order new equipment 401 from industry to restock customer's maintenance depot

Rectifying task for the event:Replace equipment 401
Following maintenance related tasks:
Discard/dispose faulty equipment
Other following activities:
Re-order new equipment 401

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6568-03000-00

The following table explains the usage of formats in the schematical LSA representations.
Table 15 Explanation of formats in the schematical LSA representations
FormatExplanation

White box, black
letters

Breakdown element

Orange box, black
letters

Failure at LSA candidate level

Green box, black
letters

Rectifying task for the failure at LSA candidate level

White box, black
letters, red dashedframe

Following task triggered by a failure at LSA candidate level

Arrows, black

Relations from:Breakdown element to a subsequent breakdown element
Breakdown element to the related failure at LSA candidate level
Breakdown element to the rectifying task

Dashed arrows,
black

Relations from:
Failure to rectifying task
Failure to following task

Arrows, red

Relation from rectifying task to supporting task (only for example 4)

Schematical LSA representation of rectifying and following tasks:
Equipment 401
46-01-01
Main failureof equipment 401
Replaceequipment 401

On-sitemaintenance

Customer‘s
responsibility

Dispose faulty
equipment 401

ICN-B6865-S3000L0103-001-01
Fig 11 Schematical LSA representation of example 1

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 26

S3000L-B6568-03000-00

9.2

Example 2: Mainboard failure of equipment 401 - Option 1
2
Customer´soperational
site

Customer´smaintenancedepot/storage

Equipment 401
Device 01

MainboardPart 01
Part 02

Power supply

Part 03
Board 01

Equi pm en t 40 1

Connector

Device 0 1

Mainb oar dPart 01

Part 02

Transformer

Power su pply
Part 03
Conne ctor

Board 01

Tra nsfor mer

Spare part
Mainboard

5

1
Maintenance
Shop atoperational site

6
Industry
Manufacturer

Discard
DisposeMainboard

3

Equi pm en t 40 1

Device 0 1

Mainb oar dPart 01

Part 02
Power su pply
Part 03
Conne ctor

Board 01

Tra nsfor mer

4
ICN-B6865-S3000L0058-001-01
Fig 12 Mainboard failure of equipment 401 - rectified by equipment 401 replacement
Event:
Failure of mainboard (component itself is not repairable)
LSA candidate: Equipment 401
Complete maintenance procedure description:
1

Remove faulty equipment 401 at customer's operational site

2

Receive spare part (complete equipment 401) from customer's maintenance depot
Install new equipment 401 at customer's operational site (replacement of equipment 401)
Failure rectified, product can be used again

3

Remove faulty mainboard from equipment 401
Discard/dispose faulty mainboard

4

Receive spare part (new mainboard) from customer's maintenance depot
Repair faulty equipment 401 by installation of new mainboard

5

Send back repaired equipment 401 to customer's maintenance depot

6

Re-order new mainboard from industry to restock customer's maintenance depot

Rectifying task for the event:Replace equipment 401
Following maintenance related tasks:
Dispose faulty mainboard
Repair faulty equipment 401 by installation of new mainboard
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 27

S3000L-B6568-03000-00

Other following activities:
Re-order new equipment 401
Schematical LSA representation of rectifying and following tasks:
Equipment 401
46-01-01
Failureof mainboard
Replaceequipment 401

Repair faulty
equipment 401 by
replacement of
mainboard

On-sitemaintenanceOperator‘s
responsibility

Mainboard
46-01-01-03
Dispose faulty
mainboard

ICN-B6865-S3000L0104-001-01
Fig 13 Schematical LSA representation of example 2

9.3

Example 3: Mainboard failure of equipment 401 - Option 2
Customer´soperational
site

Customer´smaintenancedepot/storage

Equipment 401
Device 01

MainboardPart 01
Part 02

Power supply

Part 03
Board 01

Connector

Spare part

Transformer

Mainboard

1

5

Maintenance
Shop atoperational site

Industry
Manufacturer

Discard
DisposeMainboard

2

Equi pm en t 40 1

Device 0 1

Mainb oar dPart 01

4

Part 02
Power su pply
Part 03
Conne ctor

Board 01

Tra nsfor mer

3
ICN-B6865-S3000L0059-001-01
Fig 14 Mainboard failure of equipment 401 - rectified by equipment 401 repair
Event:
Failure of mainboard (component itself is not repairable)
LSA candidate: Equipment 401
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 28

S3000L-B6568-03000-00

Complete maintenance procedure description:
1

Remove faulty equipment 401 at customer's operational site

2

Remove faulty mainboard from equipment 401
Discard/dispose faulty mainboard

3

Receive spare part (new mainboard) from customer's maintenance depot
Repair faulty equipment 401 by installation of new mainboard

4

Re-install equipment 401
Failure rectified, product can be used again

5Re-order new mainboard from industry to restock customer's maintenance depot

Rectifying task for the event:Repair equipment 401 by replacement of mainboard
Following maintenance related tasks:
Discard/dispose faulty mainboard
Other following activities:
Re-order new mainboard
Schematical LSA representation of rectifying and following tasks:
Equipment 401
46-01-01
Failureof mainboard

Repair faulty
equipment 401 by
replacement of
mainboard
On-sitemaintenanceOperator‘s
responsibility

Mainboard
46-01-01-03
Dispose faulty
mainboard

ICN-B6865-S3000L0105-001-01
Fig 15 Schematical LSA representation of example 3

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 29

S3000L-B6568-03000-00

9.4

Example 4: Failure of device 01, repairable at operational site
Customer´soperational
site

Customer´smaintenancedepot/storage

Equipment 401
Device 01

MainboardPart 01
Part 02
Part 03
Board 01

Power supply
Connector

Spare part

Transformer

Part 02

1

7

Maintenance
Shop atoperational site

Industry
Manufacturer

Discard
DisposeEqui pm en t 40 1

Part 02
Device 0 1

Mainb oar dPart 01

6

Part 02
Power su pply
Part 03
Conne ctor

3

Tra nsfor mer

Board 012

5

Device 01
Part 01
Part 02
Part 03

4
ICN-B6865-S3000L0060-001-01
Fig 16 Failure of device 01, repairable at operational site
Event:
Failure of Device 01 (component itself is repairable at operational site)
LSA candidate: Equipment 401 and device 01
Complete maintenance procedure description:
1

Remove faulty equipment 401 at customer's operational site

2

Remove faulty device 01 from equipment 401

3

Remove faulty part 02 from device 01
Discard/dispose faulty part 02

4

Receive spare part (new part 02) from customer's maintenance depot
Repair faulty device 01 by installation of new part 02

5

Re-install device 01 into equipment 401

6

Re-install equipment 401
Failure rectified, product can be used again

7

Re-order new part 02 from industry to restock customer's maintenance depot

Rectifying tasks for the event:Repair equipment 401 by re-installation of repaired device 01
Repair device 01 by replacement of part 02
Following maintenance related tasks:

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 30

S3000L-B6568-03000-00

Discard/dispose faulty part 02
Other following activities:
Re-order new part 02
Schematical LSA representation of rectifying and following tasks:
Equipment 401
46-01-01
Failure ofpart 02

Repair faulty
equipment 401 by
replacement of part02 within device 01

Device 01
46-01-01-01
Disassemble
device 01

On-sitemaintenanceOperator‘s
responsibility

Remove faulty
part 02
Install newpart 02
Assemble
device 01
Part 02
46-01-01-01-02

Dispose part 02

ICN-B6865-S3000L0106-001-01
Fig 17 Schematical LSA representation of example 4
Note
Example 4 demonstrates a possible solution for a more complex situation as in theexamples before. On closer examination the example describes a classical problem how to
document rectifying maintenance tasks. Device 01 and equipment 401 are both repairable.
At the same time device 01 is a component of equipment 401. That means, both could
serve as typical LSA candidates which can be repaired by the replacement of components.
This situation can be described as "full LSA candidate contains another full LSA candidate".
The way to handle this situation as described in example 4 is one possible solution. The
failure is documented against equipment 401 (in this case, testability and detectability
properties must allow the failure detection and localization on the level of equipment 401).
Consequently, the rectifying task is also documented against the equipment 401 (hereRepair faulty equipment 401 by replacement of part 02 within device 01 and thesubsequent re-install of the repaired device 01). The detailed activity within device 01(remove, disassemble, assemble, re-install), can be documented as supporting tasks within
device 01 as a partial LSA candidate (the rectifying task will refer to these supportingtasks). The exchange of part 02 will be documented as a work step within the rectifying task
to trigger the need for the spare part itself (in this case part 02).
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 31

S3000L-B6568-03000-00

Depending on the situation whether the entire product is waiting for the re-installation of a faulty
equipment/component after any repair activity, the representation within the maintenance tasks
in the LSA database is of different character. The need for spare parts is influenced on thisdecision (wait for repair or not). In general two main situations can occur:
Table 16 Different spare part triggers

9.5

Product waiting situation

Consequence

Product is waiting for repair ofequipment

The entire equipment is not needed as a spare part,
because the same equipment will be re-installed (after
a successful repair) into the productProduct is not waiting for repair ofequipment

The entire equipment is needed as a spare part,
because a new equipment will be installed to repair
the product and to be able to reuse the product assoon as possible. The repair of the equipment will bedone later, when the product is already in use again.

Example 5: Complex maintenance procedure on several levels
Equipment 401
Device 01

Customer´soperational
site

Mainboard

Customer´smaintenancedepot/storage

Part 01
Part 02

Power supply

Part 03
Board 01

Connector
Transformer

3

Power su pply

Connect orPower su pply
Tran sfor mer
Connect orTran sfor mer

7
Transformer

Spare parts

1

5

Maintenance
Shop atoperational site

Transformer

129Equi pm ent 401

Device 0 1

Mainb oar dPart 01

Part 02

4

Power su pply

Connect orIndustry
Manufacturer

Power su pply
Part 03

Tran sfor mer
Connect orTran sfor mer

Board 0 1

Transformer

2
Transformer

11Power supply
Connector

8

Transformer

6

10

Transformer

ICN-B6865-S3000L0061-001-01
Fig 18 Major failure of equipment, only repairable at higher level

Event:
Failure of power supply (component itself is repairable at operational site by replacement ofpart, part itself is repairable at industry site)
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 32

S3000L-B6568-03000-00

LSA candidate: Equipment 401 and power supply
Complete maintenance procedure description:
1

Remove faulty equipment 401 at customer's operational site

2

Remove faulty power supply from equipment 401 at customer's operational site

3

Receive spare part (new power supply) from customer's maintenance depot

4

Install new power supply into equipment 401

5

Re-install equipment 401
Failure rectified, product can be used again

6

Remove faulty transformer from power supply

7

Receive spare part (new transformer) from customer's maintenance depot

8

Repair faulty power supply by installation of new transformer

9

Send back repaired power supply to restock customer's maintenance depot

10 Send back faulty transformer to industry
11 Repair faulty transformer at industry site
12 Industry to send back repaired transformer to restock customer's maintenance depot
Rectifying tasks for the event:Repair equipment 401 by replacement of power supply
Following maintenance related tasks:
Repair power supply by replacement of transformer at operational site
Repair transformer at industry site
Other following activities:
Send back repaired power supply from operational site to customer's maintenance depot
Send back repaired transformer from industry to customer's maintenance depot

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 33

S3000L-B6568-03000-00

Schematical LSA representation of rectifying and following tasks:
Equipment 401
46-01-01
Failure of
power supply

Repair faulty
equipment 401 by
replacement of
power supply

Power supply
46-01-01-04

On-sitemaintenanceOperator‘s
responsibility

Industry
maintenanceIndustries
responsibility

Failure oftransformer

documented anddescribed in LSA

documented in
LSA (without
detailed
description)

Repair power
supply byreplacement oftransformer

Transformer
46-01-01-04-02

Repair transformer
at industry

ICN-B6865-S3000L0107-001-01
Fig 19 Schematical LSA representation of example 5

S3000L-A-12-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-12-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 122010-04-01 Page 34

S3000L-B6865-03000-00

Chapter 13
Software support analysis
Table of contents

Page

Software support analysis .............................................................................................................. 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Introduction ...................................................................................................................... 3
1.2
Objective .......................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Software support analysis in the different project phases ............................................... 4
3
Breakdown concept ......................................................................................................... 5
3.1
Functional and physical breakdown principles ................................................................ 5
3.2
Physical software categories ........................................................................................... 5
3.2.1
Field-loadable software ................................................................................................... 6
3.2.2
Shop-loadable software ................................................................................................... 6
3.2.3
Resident software/firmware ............................................................................................. 6
3.3
LRU and SRU aspects .................................................................................................... 6
3.4
Functional software categories ........................................................................................ 6
3.5
Data ................................................................................................................................. 7
4
Software support analysis ............................................................................................... 7
4.1
SSA process – commonality with the LSA business process ......................................... 7
4.2
SSA candidate selection .................................................................................................. 8
4.2.1
Selection of physical candidates (operational/maintenance aspects) ............................. 8
4.2.2
Selection of functional candidates ................................................................................... 8
4.3
Maintenance relevant events for software (support initiators) ......................................... 9
4.3.1
Operational events .......................................................................................................... 9
4.3.2
Technical events .............................................................................................................. 9
4.3.3
Software improvement requirements............................................................................... 9
4.3.4
Software failures ............................................................................................................ 10
4.4
FMECA/FMEA aspects .................................................................................................. 11
4.5
SMA for software ........................................................................................................... 11
4.6
LORA aspects................................................................................................................ 11
4.7
Software support tasks .................................................................................................. 125
Software support concept framework ............................................................................ 12
5.1
Software support profile ................................................................................................. 13
5.1.1
Software support levels ................................................................................................. 13
5.1.2
Software support roles ................................................................................................... 14
5.1.3
Software support activities (scenarios) .......................................................................... 15
5.2
Support classes ............................................................................................................. 15
5.2.1
Processes ...................................................................................................................... 15
5.2.2
Product .......................................................................................................................... 15
5.2.3
Environment................................................................................................................... 16
5.3
Support functions and software related support tasks .................................................. 16
5.3.1
Operational servicing support ........................................................................................ 16
5.3.2
Management support ..................................................................................................... 19
5.3.3
Software modification tasks ........................................................................................... 20
6
Supportability factors ..................................................................................................... 22
6.1
Compatibility matrix ....................................................................................................... 22
6.2
Deployment.................................................................................................................... 22
6.3
Documentation............................................................................................................... 22
6.4
Easy loading/unloading and installation ........................................................................ 23
Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16

Easy transportation on hardware carriers ..................................................................... 23
Expansion capability ...................................................................................................... 23
Modularity ...................................................................................................................... 24
Modification frequency ................................................................................................... 24
Recovery........................................................................................................................ 24
Safety integrity ............................................................................................................... 24
Security .......................................................................................................................... 25
Size ................................................................................................................................ 25
Skills .............................................................................................................................. 25
Software distribution ...................................................................................................... 26
Standardization .............................................................................................................. 26
Technology .................................................................................................................... 26

List of tables
1
2
3
4
5
6
7
8

References ...................................................................................................................... 2
Failure classes ............................................................................................................... 10
Software support levels ................................................................................................. 14
Tasks for disposal of new functionality and/or ability .................................................... 17
Tasks for recovery of a system and for problem reporting in case of failures ............... 18
Organizational tasks ...................................................................................................... 19
Maintenance support tasks............................................................................................ 19
Software modification tasks ........................................................................................... 21

List of figures
1
2

Software support analysis in the different project phases ............................................... 4
Aspects of a SSC........................................................................................................... 13

References
Table 1 References
Chap No./Document No.

Title

Chap 3LSA Business process

ASD S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

MSG-3

ATA MSG 3 - Operator/Manufacturer Scheduled
Maintenance Development

RCM

Examples include
MIL-STD-1843 (USAF) - Reliability-centered maintenancefor aircraft, engines and equipment
MIL-STD-2173 (AS) - Reliability-centered maintenance fornaval aircraft, weapon systems and support equipment
UK MoD DefStan 02-45 - Requirements for the applicationof reliability-centred maintenance - techniques to HM
ships, submarines, royal fleet auxiliaries and other naval
auxiliary vessels

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

Chap No./Document No.

Title

RTCA/DO-178B

Software Considerations in Airborne Systems andEquipment Certification

SAE JA1004

Software Supportability Program

SAE JA1005

Software Supportability Implementation Guide

SAE JA1006

Software Support Concept1

General1.1

Introduction
In modern products, software aspects are of increasing importance. More and morefunctionalities are supported or realized by complex software packages. For hardware
components, concepts and processes are established to guarantee a proper supportability ofthe system during the entire life cycle. The appropriate tool to achieve this goal for hardware is
the LSA process. The same requirement applies for software. Hardware and software are ofequal importance for the proper function of a product. For this reason, an analysis methodology
called Software Support Analysis (SSA) should be applied in order to develop an adequate
Software Support Concept (SSC).
An SSC should take into account all activities in order to allow a continued usage of software
within a product. To find a common understanding of the handling of software support, astandardized concept for software support documentation should be part of the LSA plan
harmonized between the contractor and the customer.
Similar to the logistic analysis tasks for hardware, software must be analyzed concerning its
operational and maintenance requirements. In this area, special operational aspects are ofemphasized interest for the end user of a product because this particularly influences the dayto-day business. Aspects covering software modification, such as bug-fixing and software
improvement (eg software upgrades), must also be considered.

1.2

Objective
This chapter provides the logistic analyst with guidelines for how to handle the specificrequirements concerning software in the environment of maintenance and operation. Theinterrelation between software and hardware should be defined clearly and the method of
integrating software aspects into the overall LSA process should be explained.
For software itself, a clear distinction between operational/maintenance aspects and real
software modification should be established. For example, operational aspects might include
the simple act of loading working software or required data to equipment, whereas software
modification covers aspects that deal with the change of the source code to fix a problem,
improve the performance of a software package, or adapt to changes in procedures, data, or
systems that affect the software performance.

1.3

Scope
This chapter is directed to ILS managers and/or LSA analysts for both contractors andcustomers who must analyze systems containing software. With the means of LSA and SSA, anappropriate support concept for such equipment can be established. With the help of thevarious analysis results it can be assured that the customer's needs concerning supportability,
readiness and operability of hardware that contains software can be achieved.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

2

Software support analysis in the different project phases
1

Similar to the application of LSA, Software Support Analysis (SSA) is an analysis activity,
which should be applied throughout the entire life cycle of a product containing software. In the
different life cycle phases various analysis tasks must be performed. Depending on the phase,some activities increase in importance, others decrease. For example in the design anddevelopment phase, the application of SSA is of high importance to influence softwarearchitecture and software design to consider the requirements of supportability in case of laterneeds to load, service, or modify the software packages. In an early concept phase, SSA should
help to identify basic software support requirements. During the in-service phase, similar
aspects as for hardware are valid. Technical modifications will force the analyst to repeat
detailed considerations concerning the logistic concepts for the affected hardware/software. For
this reason, an iterative SSA/ILS process will occur in different depths, depending on the extent
of the technical modifications. The activities to be performed here are basically the same as in
the design and development phase and in the production and introduction phase, but normallyto a smaller extent.

Early phases
Conception
phase

Design & Development
phase

Risk reduction
phase

Production
andintroduction
phase

Waste
disposal
phase

In-service phase

TIME

First
logistic analysis
tasks
Analysis for
identification ofgeneral SSA
needs
Comparative
analysis
Basic Software
SupportConcept (SSC)….
Iterative
SSA / ILS
process

Finallogistic
analysistasks
Erasureof data

Periodic assessment

Migrationof dataArchivingof data

Detailed software analysis tasks:
Configuration assessment
Software Support Analysis (SSA)
Level of Repair Analysis (LORA)
for software
Maintenance Task Analysis (MTA) forsoftware related tasks
Software delivery
Software installation and configuration

Management of technicalmodifications during In-service
phase (additional to the periodic
assessment)

ICN-B6865-S3000L0062-001-01
Fig 1 Software support analysis in the different project phases
In the disposal phase, it must be ensured that during the disposal of hardware that thecorresponding software and/or data are handled carefully. The handling of data can be of highinterest. Sensitive data must be erased from scrapped hardware (eg in a military environment).
For archiving purposes, existing data must be preserved from disposed hardware components.

1

Methodology to analyze software with the purpose of supplying the Customer with allnecessary information to establish a cost effective SSC. This includes all equipment, tools,
personnel, documentation, infrastructure and required skills and training.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

If existing data is needed for further operation of newly implemented systems, the possibilities ofdata migration must be analyzed and concepts for data migration must be established.

3

Breakdown concept
Chapter 3 provides guidance on the development and assignment of breakdown element
identifiers for hardware and software. Examples of physical and function breakdowns, toinclude software, are provided in Chap 3 This guidance and the examples should be followed indeveloping the breakdown relationships of software within the context of the hardware.
For software, it is possible to obtain a breakdown element identifier similar to that of hardware
by following the concepts of physical or functional breakdowns. However, due to different
characteristics, it can be difficult to associate software within the traditional physical/functional
breakdown. This is especially true for advanced systems (eg modular avionics), where thephysical location of a specific software can be vague. Often, software is not a clearly defined
physical entity; therefore it can be difficult to identify the appropriate indenture level for thesoftware item within a physical or functional breakdown. Even in the case of a clear assignmentof software to hardware, the question could arise as to where the software should be allocated:−−−

Is it part of the hardware element, where the software is loaded?
Is it part of the hardware element, where the software is executed?
Is it part of the hardware element, where it physically resides?

The breakdown, in this context, is different from the traditional physical/functional hardware
breakdown and it is important to establish a consistent approach to the breakdown of softwarein relation to the hardware. The physical breakdown should be used to identify software within asystem breakdown for operational purposes, and provide the necessary software view fortraditional system maintenance purposes. The functional breakdown is a software engineeringview that facilitates how software will be modified and integrated, and provides the relationships
between the different software elements that must be considered when a redesign is performed.

3.1

Functional and physical breakdown principles
Software items identified within a physical breakdown are normally elements that can behandled by the operator. This is the software that must be considered for operational aspects
such as, for example, loading/unloading. The software can reside on different indenture levelsof the system breakdown.
It must be noted here that the allocation of physical software to a specific indenture level isactually driven by the need to maintain an adequate configuration control of the system and also
to highlight the logistics impact that such software might have on standard operation andmaintenance. Though traditionally software was always assigned “below” a hardware element,
new configuration management issues and approaches have changed this concept to the extent
that within the LSA, software can be its own replaceable unit (LRU or SRU) or a part/component
by its own right. This is further explained in Para 3.3.
Software items identified within a functional breakdown are elements that are used to describe
the functional/design aspects that are important for the software designers, especially becausesuch a breakdown usually indicates the need for integration with other software. This kind ofbreakdown must be considered for software modification support. Thus, it is important that thefunctional breakdown follows as close as possible the software design.

3.2

Physical software categories
There are basically three categories of physical software: Field Loadable Software (FLS), ShopLoadable Software (SLS) and resident software (also called firmware). The basic concept for
the three categories is established in the configuration management principles that control theconfiguration of a specific system.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

3.2.1

Field-loadable software
FLS is any software that can be installed to one or several pieces of equipment on asystem/product without the need to dismount the equipment from its existing installation
location. FLS is considered an item in its own right within the breakdown and therefore, amodification of FLS results in a change of the FLS part number and a change of theconfiguration of the system where it resides. However, FLS loading does not cause a change in
hardware part number. The reason for this is, obviously, that software that is loaded without
requiring disassembling hardware from a system should not force such disassembly merely to
tag the hardware with a new part number due to a new software part being installed. The
system configuration is affected because the function of the system changes when using a
different piece of software.

3.2.2

Shop-loadable software
Shop-loadable Software (SLS) is any software that can be loaded into a LRU, but requires that
the LRU to be dismounted from its installation in the system where it is located. A replacementof any hardware component is not required. A modification of the SLS not only changes the partnumber of the SLS, but also the part number of the LRU where it is loaded. This is the same as
when a SRU is replaced by a different one, so as to maintain the form, fit and function principlethat drives configuration management (when replacing software by different software, thefunction is changed). Note that the system configuration is affected, but in this case, only due tothe change in the hardware part number.

3.2.3

Resident software/firmware
Resident software (also called firmware) is any software that can be loaded into a LRU or SRU
but requires that LRU/SRU to be dismounted from its installation on the operational system andrequires the replacement of a component. Although such resident software may have its own
part number when it is installed on a component or loaded onto a SRU, the part number ischanged for the component or SRU where it is installed. This also entails a change to the partnumber of the next higher assembly.

3.3

LRU and SRU aspects
From the previous section, it becomes evident that the easiest way to handle software within an
LSA system breakdown is to identify such software as LRU, SRU or part/component, dependingon the software category. This not only simplifies the overall system configuration management,
but it also clarifies how to handle the system configuration when using FLS and there are notags on the target hardware regarding the software it contains – this becomes a non-issue when
the configuration is handled at the next higher level.
Similarly, a loading task due to a hardware repair or software update is quite easy to integrate
into the overall maintenance tasks because a specific (software) SRU or LRU is affected. Thus,in principle, it is not different than performing a task on a hardware SRU/LRU and subsequently
performing additional tasks at the next higher breakdown level. Therefore, loading software after
a hardware repair is very similar to, for example, replacing a consumable.

3.4

Functional software categories
The functional software breakdown, as indicated above, should follow the software design
requirements, as it is mainly oriented towards software modification. Thus, the classic Computer
Software Configuration Item, Computer Software Configuration and unit level views may be
used but, contrary to “traditional” software engineering, it is also necessary to provide the higher
levels of abstraction (subsystem and system level), as this indicates interdependencies andneed for integration, including the need for system or subsystem level integration rigs. In thiscontext, software assembly items within a functional breakdown can support the grouping offunctionality that is documented as a whole (same principle as for artificial assemblies within
physical breakdowns). Such artificial items can be used to provide a helpful additional level ofabstraction without changing the overall structure and functionality of the software design.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

It should be highlighted here that the use of a breakdown element revision identifier is also
recommended, but only in the event that a major version of the software is generated thatsignificantly changes the software structure, functionality or supportability elements (eg changeof programming language of a specific module) that might entail a modification of the support
tasks and/or support infrastructure. It does not provide any added value to perform the fullanalysis simply because there is a change in an algorithm, but it might be essential to perform it
if for example the software risks class changes.

3.5

Data
Data can be handled similar to software, considering it from both the physical and functional
point of view, with the peculiarity that the physical data can be loaded/unloaded (while
executables are usually not unloaded, only erased) but also prepared. This is different from thepure software aspect, since software modification is a design activity, while a data preparation
can be considered an operational activity. The border, however, is not as clear-cut as it looks,
and there might be uncertain cases.
However, in general, data would be included in the LSA database in the same way as software,
including preparation if applicable, but would be also be included in the functional breakdown inorder to ensure the configuration and dependencies. For example, a software modification
might entail a modification in the mission preparation systems.
Whether data should be considered software or a special category within the LSA database iscurrently open to debate and should be previously agreed upon. Though standards such as
RTCA/DO-178B include data under the software heading, there are merits to consider it aseparate element for logistics purposes. As of today, the software supportability field has notreached an agreement on this subject and this particular aspect should be considered before
making any logistics decision.

4

Software support analysis
Software Support Analysis (SSA) is a consistent methodology to guarantee proper software
supportability throughout the requirements, specification and design phases in order to define
the most cost effective support concept that meets the operational and software modification
requirements. It must be ensured that the necessary support infrastructure is established in time
before the product enters into the in-service phase. The main goals of a SSA are theestablishment of supportability requirements concerning software in the early program phases
and the influence of the software design to ensure supportability for both, system operation andlater modification processes. The outline for a stand-alone software supportability program canbe found in SAE JA1004, Software Supportability Program.

4.1

SSA process – commonality with the LSA business process
In general, the SSA process should cover the logistic aspects as already described in chapter 3
for the LSA process. However, within this chapter, all special aspects concerning software arecovered to ensure a proper supportability analysis process for software as well as for hardware.
Additionally, the interconnection aspects between hardware and software are identified.
For a product that contains software as a basic element of the complete system, a number ofsoftware support activities must be applied depending on the situations, which are the trigger forthe support. In the area of software support activities, two main fields of analysis are identified:−−

Operational/maintenance aspects (eg loading of data or software to the corresponding
hardware, system recovery, data transport and archiving)
Software design aspects (eg real modification of software for bug-fixing or improvement
purposes)

When carrying out SSA, it is necessary to consider the relationship and differences between theabove task categories, and the representation of software items in the functional and physicalsystem breakdowns. One basic aspect is that support activities that do not involve modification
Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

should be analyzed against physical breakdown items. It should be pointed out that the analysis
results concerning operational aspects should be recorded in the LSA database. Here you candocument tasks such as the loading of data and software against the carrying hardware
element within the breakdown. For example, the change of equipment can require that software
and/or data must be reloaded to the new equipment and configured after or before installation
into the system. The usage of hardware for special purposes can require the loading of a
special software or data package to support this kind of operation. Nothing will be modified
within the software itself.
The software modification itself is another area in which the software source code is normally
influenced directly and changes in the source code are performed. The analysis of this kind ofactivity is software design related. The requirements for these activities are different from theoperational aspects concerning software. For this reason, the documentation of these activities
should be separated from the operational aspects. The breakdown elements, to which these
activities can be addressed, should be functional software breakdown elements. Software
packages that should be analyzed concerning their requirements for real software modification
tasks can be treated as SSA candidates similar to LSA candidates for hardware. Aspects for theselection of SSA candidates will follow in the next chapters.

4.2

SSA candidate selection
In general, SSA candidates are elements of either physical or functional breakdowns that are
subject to any kind of SSA. The candidates should be selected carefully concerning operationalor supportability significance. Taking into account that software support activities are divided inoperational/maintenance and software modification activities, candidate selection should be
carried out within these areas separately.

4.2.1

Selection of physical candidates (operational/maintenance aspects)
A SSA candidate identified in a physical breakdown should take into consideration all software
items that can be loaded and/or installed separately by the operator. The candidate itself can be
the hardware item that is the carrier of the software. For distributed software, it can be a
subsystem or a system within the physical breakdown. Loading and/or installation tasks are
typically documented against the corresponding hardware. Other operational tasks can also be
documented against a software breakdown element (eg transportation or distribution ofsoftware).
A special area is the handling of data. Data is normally of electronic nature and is handledsimilar to the corresponding software. Therefore, the support of software and dependent data
can normally be analyzed together (although not in the same way). Special support aspects fordata concerning the selection as a SSA candidate are the following:
−
−
−
−
−
−

4.2.2

Is a data preparation process required that needs special software or hardware?
Is a data validation process required?
Are special transmission media or networks required?
Are there special security aspects to be considered for data loading?
Are there special compatibility requirements with the existing executable software?
Are there special requirements concerning size and format (databases, file formats)?

Selection of functional candidates
A SSA candidate identified in a functional breakdown should take into consideration all software
items that are subject to software modification activities. Each software item should be analyzed
concerning the following questions in order to decide whether it is subject to a software
modification activity:−−

Are there any support initiators to be expected for the software items that require a
modification of the software source code?
Does the software item in the breakdown include all software within the system or within theequipment?

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00

−
−
−
−
−

4.3

Does the software item use a separate design?
Does the software item require special hardware and/or software tools for development?
Does the software item contain proprietary software such as run-time libraries or COTS
(Commercial Off-The-Shelf) elements?
Are there different versions of the same software item for usage on different platforms?
Are there deviations of the software items to the general design environment?

Maintenance relevant events for software (support initiators)
Similar to the methodology of LSA for hardware, the starting point of documenting themaintenance relevant aspects should be the identification of any event that initiates
maintenance activities. These events can also be described as software support initiators. The
event driven methodology should also be applied to SSA, however, the events concerning
software are somewhat different from the events for hardware. They can be grouped according
to the implication of:
−
−
−
−

4.3.1

Operational events
Technical events
Software improvement requirements
Software failures

Operational events
This type of event is related to an operational requirement. Operational events should be
documented within the related hardware item. The same applies to the corresponding
operational task. Typically the following aspects should be covered:−

Hardware maintenance/repair of computing hardware
After hardware maintenance, different types of tasks may be necessary, eg reloading ofdata and/or software, installation and configuration of software packages on a new installed
equipment.

−

Usage (mission) preparation
The preparation for special usage of a system may require (besides the installation of
additional hardware) the installation of supporting software packages or the loading ofspecial mission data.

−

Post mission requirements
After a special usage of a system, data created during the mission must be unloaded orarchived. Software packages that were required for the special mission must be deinstalled and the system must be reconfigured to a standard configuration.

4.3.2

Technical events
Besides the hardware maintenance, other technical events can trigger software support
activities. These events normally require adaption of the existing software packages to themodified environmental preconditions. Typically the following aspects should be covered:
−
−
−
−

4.3.3

Changes of the parent hardware
Changes of the parent software (eg upgrade of operating systems, of corresponding
database systems or of firmware)
Changes in technology of inter-operating systems
Changes in technology of network interconnectivity

Software improvement requirements
Software should be the subject of a permanent improvement process. Normally, software
release changes take place in particular intervals dependent upon the complexity and size ofthe software package. The primary inputs for new releases are (besides the fixing of real

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00

software failures) dedicated end user requirements or changes in the environmental
preconditions. Improvement in this context means the introduction of new features to improve or
extend functionality or the usage comfort of an existing software package.
4.3.4

Software failures
System failures initiated by software are, of course, main support initiators. The reaction to
failures depends on the severity of the failure. Not every failure caused by software will initiate asoftware modification activity.
Considering software failures, it is recommended to introduce a classification concerning
severity. For each failure class, a sequence of actions should be defined within a SSA. In every
case, proper documentation is required to support later diagnosis.
Table 2 Failure classes
Class

Description

Minor

In general, these are failures concerning the user comfort. In many cases,
these events are not real failures but only poorly designed features of thesoftware or they are real failures that can be bypassed by other features of thesoftware or an alternate handling.
However, these minor events should be documented and collected carefully
and reported to the software support organization. This information should
guarantee the incorporation of improvements into a further release of thesoftware package. It should be pointed out that especially the correction of
marginal insufficiency can considerably increase user's acceptance.

MediumThese are events that cause decreased functionality of the system. If this typeof bug occurs, the user is not able to continue the work as expected, however,the system as a whole works without severe disturbance (eg no shutdown will
be performed). The ongoing usage of the system is possible with reduced
performance or even with no restrictions.
These events normally need a timely correction, and a defined workaround todeal with the failure until the final correction is made with the help of a bug
fixing procedure. Normally, a software modification is necessary.

Major

A major software failure should be considered as an unacceptable event. The
failure causes the shutdown of the entire system or the necessity to operate
the system under very restricted conditions. The normal capability of thesystem is considerably degraded.
These events need a correction within a small amount of time. In case of
emergency situations, the software support organization should react as soon
as possible to recover the entire system to full operation. The reaction times
should be defined within service contracts between the customer/user and thecontractor.

A software failure cannot be treated exactly like a hardware failure. In the case of a hardware
failure, any relevant maintenance action such as a repair or a replace can be defined rather
clearly. In case of a software failure, it is not normally possible to identify the required activity
immediately. Perhaps a restart of the system is sufficient to recover the system and the failure
will not occur again. On the other hand, the failure can be severe and the system performs a
shutdown and should not be restarted in order to avoid the repetition of the failure and a further
corruption of the entire system.
An important aspect can be the corruption of data or executable code. This event can beinitiated, for example, by a virus infection or by corrupted carrying hardware (eg the loss ofApplicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6865-03000-00

functionality of a hard disk). In this case, there is no real inherent failure in the software sourcecode. This event should be handled as external damage.

4.4

FMECA/FMEA aspects
The results of a technical Failure Mode, Effects and Criticality Analysis (FMECA) are relevant
for software since the FMECA represents an analysis method carried out for the overall
equipment/system (covering hardware and software aspects). For any identified failure mode, adecision should be made as to whether the associated functionality is dependent on or evenprovided completely by software. During the design/development of the software, this failuremode information can be used to design a software architecture that eliminates, or at least
mitigates, the possibility of the software failing in such a manner as to cause a specific system
failure. In addition, the design can be instrumented so as to ensure that any such potential
software failures are detected and recorded, including their associated information, and that thesystem continues operation in a safe mode.
During the inservice phase, system failures due to software failures are drivers for software
modification activities. It is a principle of FMECA/FMEA (Failure Mode and Effects Analysis) togroup together all of the software failures that lead to one specific system failure, and perhaps
even to group together the specific system failures that lead to the same software modification
request. The analysis should be based on the functionality that the software performs. However,
it is typically not practical to carry out the FMECA/FMEA of the single functional failure effects
down to the level of specific defects in the source code.
Another consideration during the in-service phase is not only to provide the necessary
information to the software engineers about a specific failure, but also to prevent unnecessary
maintenance tasks due to software failures. A software built-in-test reporting a software specificfailure that can be identified by the operator will reduce the number of disassemblies (as you
cannot rectify a software failure by replacing the equipment) and number of hardware No
Failure Found cases.

4.5

SMA for software
Scheduled maintenance analysis (SMA) such as ASD S4000M, MSG-3 or RCM is notapplicable to software packages in the same way as for hardware. Software failures are theresult of unintended effects of the software design. Such failures cannot be avoided by themeans of SMA since they correspond to design flaws. However, potential software failures canaffect safety. It could be possible that the result of SMA carried out for a piece of hardware
equipment containing software identifies scheduled maintenance tasks that are of operational
character concerning software. However, the analysis remains a SMA for hardware, taking into
account software elements. A stand-alone software package normally will not be a candidate forSMA.
A SMA on the software itself should not be considered as performing regular maintenance tasks
on the software itself, but rather as periodic assessments of it during the software life. It must be
kept in mind that software to a great extent shows a “bathtub” like failure profile, with initiallymany failures. These bugs are fixed with successive software releases leading to a stablebehavior. Later, failure rates may increase again due to the increasing degradation of thesoftware as it is modified beyond its initial scope. A periodic assessment of the failure rate could
determine whether the software is reaching its end of life due to increasing software failures or
because the added functionality can no longer be properly processed by the underlying
hardware, thus forcing either a software rewrite or perhaps even a complete system redesign.

4.6

LORA aspects
The identification of which support level a task will be performed can be supported by means ofa Level of Repair Analysis (LORA) procedure. For operational aspects, the performance oftasks such as software or data loading can be covered within a LORA for the hardware related
tasks, or at least by means of a process that is very similar to it. Note, however, that the“triggers” for such tasks may sometimes not be the traditional identified tasks, but might be due

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6865-03000-00

to external factors such as a new software release, or the need for specific operational softwareor data loading. If these tasks occur frequently enough, the result of the LORA might actually bequite different than the one that would be obtained when associating these tasks to thecorresponding hardware.
For real software modification, detailed information is required concerning equipment (softwaredevelopment environment concerning hardware and software developer tools) and capabilitiesof the personnel. Also, contractual warranty and software ownership aspects can influence thedetermination of an appropriate support level for software modification activities. For logistics
management tasks, the process also becomes important in order to determine the best location
to perform tasks such as, for example, generation of software or data media.

4.7

Software support tasks
After the identification of the relevant support initiators (events), the appropriate tasks(operational/maintenance tasks or modification tasks) must be identified. It should be pointed
out that there is a flexible boundary, but it must be ensured that none of the support activities
concerning software be forgotten. It doesn't matter whether a task will be defined as operational,
maintenance, or modification relevant, the identification of the related resources and further task
characteristics, such as duration, man power requirements, preconditions or safety conditions is
the main goal.
To give guidelines for the analyst regarding which type of software support tasks can occur
within the different areas of events, the following Para 5 gives a more detailed overview. Further
information can also be found in SAE JA1005, Software Supportability Implementation Guide.

5

Software support concept framework
Similar to hardware, the achievement of a proper supportability framework should be one of themost important design principles for software. This requires the establishment of a SSC (in an
early stage of the software design process). The earlier the design pays attention to logistic
requirements, the better the supportability will be. It should be easy to modify software if change
requirements are addressed from different sources. Also loading, installation and configuration
procedures should be as easy as possible.
To take into account all of these aspects, a basic guideline should be given to the logistic
analyst using this specification. The framework should cover all of the important areas
concerning software support. This guideline should support contractual agreements between
the customer and the contractor, which are agreed upon during the LSA GC, and all of the
aspects should be tailored to the required extent of the Project.
There are different perspectives of a SSC, which shall be described in the following paragraphs.
All of these views are interconnected and influence each other.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6865-03000-00

Support Classes

AgentsActivities

vir
En

m
on

t
en

or
pp
u
S

ModificationtManagement

LevelsoPrcduOperation

Support Profile

oc
Pr

s
se
es

cti
un
F
t

s
on

ICN-B6865-S3000L0063-001-01
Fig 2 Aspects of a SSC
It depends upon the extent of a software development or procurement project, whether theprocess to establish a SSC can be a part of the overall LSA business process (described in
Chap 3). Aspects of software support can be covered by the procedures of the general LSA
business process. Relevant documents such as an Operational Requirements Document (ORD)or a Customer Requirements Document (CRD) should cover software support aspects
concerning the required usage data. The LSA GC should also cover the software support
aspects and the relevant and contractual agreements should be agreed upon in the documentsfrom the LSA program plan and the GCD. The candidates for a detailed SSA can be selected
within the Candidate Item List (CIL). The rules for SSA candidate selection should be fixed here,too.
As a general note it should be pointed out that in large and complex systems with aconsiderable amount of software, software supportability is worth being treated as its own area.
A separate SSA program plan can be created and implemented, and a separate Guidance
Conference (GC) for software aspects can be established. However, the interaction between
hardware and software development must be considered. Software is designed to address
functionality to hardware components. Therefore, both must work hand in hand and processes
that guarantee proper cooperation must be harmonized, documented, reviewed and put into
practice. A more detailed representation of aspects concerning a SSC framework can be foundin SAE JA1006, Software Support Concept.

5.1

Software support profile
The software support profile takes into consideration the aspects of where the software support
is located and which organizations and related persons are the relevant players in a software
support environment. Additionally, the processes regarding how the different instances work
together in an integrated way should be established and agreed upon between the customer
and the contractor.

5.1.1

Software support levels
Similar to the maintenance levels within the LSA for hardware, levels of support should be
addressed for software support. The support levels for software can be different from the
hardware support levels and would be used as input to the LORA decision process for thesoftware. Also, classification is similar to the maintenance levels for hardware, but some special
aspects concerning software should be considered additionally. The following table gives an
overview.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6865-03000-00

Table 3 Software support levels

5.1.2

Support level

Description

Level 1
(Operational level)

This support level describes the location at which software isin operational use. Within this level, normally only simple
support tasks can be carried out. These tasks are covered by
the operational servicing support.

Level 2(Intermediate support level)

An Intermediate support level can cover all support activities
which are related to operational servicing support but also to
management support. Especially user support in the form ofhelp desks and hotline can also be covered by intermediate
support level. An example for intermediate support level is theService Repair Vehicle concept. The Service Repair Vehicle
is able to perform, for example, communications, download ofsoftware or firmware update in a flexible way (like a quickly
available help desk). It is located near to the operational area
but is not part of the operational site.

Level 3(High support level)

This support level is normally located at a central site.
Activities from the management support can be covered here
as well as modification support. It depends on the software
packages themselves (eg complexity, size, modularity,
programming techniques) and on the equipment (eg tools,
personnel, facilities) of the support sites as to how far thecapability to modify software packages is available.

Level 4
(Software vendor and/or
original developer)

The vendor level is normally the best skilled support level forthe high demanding tasks concerning software modification.
In many cases, the vendor is the original developer of thesoftware, equipped with all necessary developer tools andpersonnel. Often, this level is selected for modification support
because the user itself does not have the required capabilities
for these complex support tasks. Additionally, aspects of
responsibility and liability must be considered, which can force
the user to address software modification to the originalvendor.

Software support roles
As a first step to clarifying software support roles, customer (buyer and users) and supplier(vendor and supporters) roles should be clarified. As a second step, the roles concerning
software usage and support should be addressed to persons who are able to offer the required
services. These roles can be:−−−

Simple user without any rights to modify or to recover any software system (not a real
support role, but in general only a service receiver). The main task of a simple user should
be to keep the software operationally running and report any system/software failures.
Power user with some basic knowledge and the ability to perform a system recovery. Thiskind of role can be involved in the software support by performing simple operational
support actions in order to keep the software running, such as installation and loading ofdata. Normally a power user is not involved in any software modification activities.
System administrators are power users on a higher level. They should be able to cover all
activities concerning operational support and eventually management support. Normallysystem administrators are not able to modify software itself, but software configuration likechanging of performance parameters and loading of additional software packages or
installation of updates are typical administrative tasks. System administrators are normally

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6865-03000-00−−

concerned with the direct support for the simple users or power users in working with thesoftware packages. Normally a system administrator is not involved in any software
modification activities.
Service provider, who is able to provide qualified operational support and additional
services, such as a hotline. Service providers can be located onsite with the customer andvendor, and in some cases, are able to provide modification support.
Vendor or original software developer, who is able to provide modification support up to thehighest support level.

All these roles must be equipped with the required skills, capabilities and rights necessary to
carry out their tasks. The roles, including their profile, should be documented in the SSC. The
limits of competence should be clearly defined, documented and accepted by all persons
affected.
5.1.3

Software support activities (scenarios)
Concerning the different support roles and support levels, a scenario should be described,
indicating how the different resources at different locations work together and which processes
are the basis for the cooperation. This support scenario should be agreed upon by both sides,
the customer and the contractor, and should be carefully established and controlled.

5.2

Support classes
The quality aspect of a SSC is extended to all objectives involved. The implementation of quality
standards to ensure the keeping of rules is recommended. In the next chapters three software
support classes should be considered.

5.2.1

Processes
All processes being established should be discussed between the customer/user and thesoftware support provider. A written documentation of how these processes should be
implemented should be available. Process characteristics concerning inputs, outputs, controls
and resources should be clearly addressed:
−
−
−
−

5.2.2

Is there any written documentation of the process (flowcharts, descriptions, requirements,
responsibilities)?
Is an accepted standard used to describe the relevant processes (international or company
internal)?
Are there any real measurable performance control parameters available and what are themeasures for performance control?
Are inputs and outputs, procedures, requirements and an effective control mechanism
defined and documented?

Product
Supportability aspects should be considered as early as possible in the software productcharacteristics. Inherent quality characteristics of software are dependent upon how well orbadly the software has been designed. Requirements for a good software design include many
aspects starting with the software specification and ending with a perfect user handling,supported by a proper graphical user interface. Typical quality aspects are the following:
−
−
−
−
−
−

Modularity
Changeability and expandability
Simplicity and easy handling
Stability and consistency
Performance concerning processing speed
Instrumentation (in the sense that the software is purposely instrumented for anunderstanding of how it is operating)

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6865-03000-00

The better these aspects are considered in the development process, the easier it should be tohandle or to support the software package. However, it should be pointed out, that even welldesigned software can cause a lot of problems by implementing a bad support concept.
5.2.3

Environment
Environmental aspects concerning quality start with the persons that are involved in the usage
and/or support of software. To implement proper software support, personnel characteristics
should be considered very carefully:
−
−
−
−
−

Who is the right person for a software support job?
What are the required skill levels and how much experience is recommended?
How many persons are required to guarantee a trouble-free software support?
Is the motivation of the personnel on a high level?
What fluctuation can be expected?

But not only personnel aspects influence the quality of the environment. Very simple aspects
such as the quality of physical facilities, computer workplace equipment, size of offices andquality of ventilation can ultimately affect the quality of the support services themselves.

5.3

Support functions and software related support tasks
Maintenance tasks related to software can be divided into different categories. This depends onthe following aspects:−−−−

Is the task simple software loading/unloading task or a simple software transportation task
(from a device A to a device B)?
Is it necessary to remove hardware from a system to load/unload software?
Is the maintenance task connected to any case of failure recovery or documentation of any
trouble related to software problems?
Is any case of software modification involved?

Especially the last aspect of the list above, software modification, leads to a wide area of special
support tasks, which must be carefully considered.
5.3.1

Operational servicing support
The operational servicing tasks describe all activities concerned with the day-by-day operationof the system. However, even these tasks can have a different quality and depth of impact on
the usage of the system (eg downtime, test requirements). In general, these tasks are rather
simple tasks carried out by the user on support Level 1 or Level 2, which only require thesoftware package to be available on a compatible medium plus a corresponding installation
manual. The method of installation should be considered. On a stand-alone system, a systemadministrator will have some other requirements that with a large computer network system. In
modern network architectures, software and data installation and loading will be carried out withthe help of software deployment systems supported by corresponding tools.
The following tables will give an overview of what kind of tasks can occur, including the further
definition of some terms concerning the handling of software packages. These tasks will begrouped in three subcategories:−−−

Tasks for the disposal of new functionality and/or ability
Tasks for recovery of a system and for problem reporting in case of failures
Organizational tasks

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6865-03000-00

Table 4 Tasks for disposal of new functionality and/or ability
Type of task

Description

Softwareinstallation

Installation of a software package means the pure disposal of a possiblefunctionality realized by the means of software by carrying out an
installation routine.

Software deinstallation

De-installation of a software package means the definite removal of a
possible functionality realized by the mean of software by carrying out ade-installation routine or by simple deleting of files from a storage
device.

Software loading

Software loading should be understood as a task that is one step higher
than the pure installation. In additional to the pure installation routine,
which is part of the software loading, the configuration of software must
be considered. In many cases, this step of software loading is more
complex than the pure installation.

Softwareconfiguration

In this context, the term configuration means the change of internalparameters (eg operational parameters, granting of user rights,
performance parameters, path information, database connections) for
the operation of the software. This action requires no new installation of
the software package itself. For the change of configuration parametersof the software, the functionality of the software package itself issufficient. For the configuration, it is important to have sufficient accessrights (eg administrator account for login into a software) to realize thesechanges.

Data loading

Normally, data will be loaded with the help of the existing functionality of
an installed software package in order to provide special abilities to the
product. The border between software and data in this case is flexible,
depending on the type and format of the data that must be loaded into
the existing system. Data loading tasks are also typical tasks for
preparation of operation or of a mission.
Data does not change the basic functionality of the installed software
package. For example, the maps in a navigation system can beconsidered as data, the software of the navigation system uses thisdata, for example, for the graph of a city map. With the loading ofanother data set (eg package of another country), the functionality of thenavigation system will not change (it will stay a navigation system),
however the usage may possibly change, by the allocation of data.

A special aspect of installation and loading of any software/data is the embedded software or
firmware respectively. In this case, the allocation of new functionality or abilities can be a moredemanding activity. Normally, some special tools and support equipment (eg to gain access)are required to transfer the new software code or the new data to the storage devices of
embedded software (eg resident storage chips on a computer main board). These requirements
should be identified within the Maintenance Task Analysis (MTA) of the installation or loadingtask for the embedded software or firmware.
For each change of software by installation/loading it is recommended to define how proper
function of the product after the change can be ensured. The necessity of a functional test and aconfirmation of proper work by an adequate skilled specialist should be investigated carefully
and, if required, documented (eg in the installation instructions).

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6865-03000-00

Table 5 Tasks for recovery of a system and for problem reporting in case of failures
Type of task

Description

Software recovery Software recovery includes all activities of basic diagnostic and simple
recovery actions such as a reboot/restart of a system after a system orsoftware shutdown. Normally, these activities can be carried out safely
by low skilled personnel. Even in case of a successful recovery to fullsystem operation, a diagnosis of the system is strongly recommended.
All available data concerning the problem occurrence and the recovery
actions should be carefully documented for evaluation. This might leadto a number of outcomes to immediately rectify the cause of the problem
or to sustain full system operation by alternate means. If the underlying
problem cannot be solved within a short time, a temporary downgradingof system capability should be considered.
Recoveryproblemreporting

In any event of a system failure involving software, a problem report
should be generated, even after a successful simple recovery, such as
restarting or reloading. This problem report should consider thefollowing aspects:
−

−
−
−

What was the system condition/configuration (software andhardware platform) at the time of failure? This information isimportant in the fault investigation on transitory effects, where theability might be needed to reproduce the failure effect in an
appropriate test environment or reference system.
Type of software failure?
Was a software recovery action successful (yes/no/partial)?
Severity of failure?

Problem reports should be communicated to the relevant personnel who
would investigate the problem further to establish its priority anddetermine any workarounds and any needs for temporary operational
limitations.
Post operational
data extraction

Software support tasks carried out immediately after operation will
generally be concerned with data extraction (for operational and/or
engineering analysis) and fault investigation, and non-logistics functions
such as the sanitation of classified software/data. With respect to datarelated functions, a range of data administration tasks might be required(eg the provision and upkeep of data which is routinely needed bysoftware a program to fulfill its operational role). Fault investigation tasks
will relate to both activities on the prime system and to the deeper-leveltesting carried out on remote reference systems which replicate or
simulate the prime system environment.

All tasks related to recovery of a system do not normally contain any software modification
activities. However, recovery of a system can require the involvement of an updated software
package.
Problem reporting can be a starting point of the need for modification. Even if recovery tasks
were successful, it could be necessary to modify software to rectify the failures that occurred to
avoid the repetition of the failure situation.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6865-03000-00

Table 6 Organizational tasks
Type of task

Description

Software delivery

In the context of operational servicing tasks software delivery covers thereceipt of new software by the user from the distribution organization.
Receipt implies a number of activities including both quality aspects andvalidation aspects:−−−−

Operational
configuration
control

Checking condition and completeness of delivery
Checking configuration status information
Checking license information
Checking compatibility between delivered software and the system

This task takes into consideration the compatibility of software to special
hardware. A specific software package may only work on certain
variants of hardware items. On the other hand it can be possible toinstall/load different software packages to equipment, depending on therequired functionality. The user must know what is compatible.
Establishing configurations that are not tested or even not allowed must
be avoided.
Within the area of operational configuration control, the compatibility ofdifferent software packages working on various pieces of hardwareinterconnected within a bus or network system should not be
considered.

5.3.2

Management support
The management support tasks are tasks that cannot be considered as pure operational
support. However, a modification of software is not part of these tasks either. This kind of
support is located somewhere between the operational support and the real software
modification tasks. The activities can be carried out across all levels of support and by users aswell as by support organizations.
Table 7 Maintenance support tasks
Type of task

Description

Problem reporting This type of problem reporting should cover more aspects than therecovery problem report. The implementation and upkeep of amanagement system for failure reporting and for corrective activities (ega bug tracker system) is a central activity in this area. Within this system
all actions should be monitored and organized:−

Prioritization related to the severity of problems−

Request for software modification−

Monitoring of software modification and bug fixing procedures

An additional aspect can be the continuous monitoring of systemeffectiveness and the development of support costs. To guarantee best
software performance and supportability it can be necessary to change
software because of these kinds of problems.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6865-03000-00

Type of task

Description

Systemconfiguration
control

In addition to the operational configuration control, the system
configuration control is of increasing importance. The interconnection ofmany computer systems in large networks within a complex productrequires configuration control on a higher level. Of course, as a firststep, it must be ensured that no software package is installed on noncompatible hardware equipment. This is covered by operational
configuration control.
As a second step, system configuration control must ensure that allcomponents within a product that carries software/data and that areinterconnected, work together properly without any problems. In modern
products this can become a complex challenge. A compatibility matrix
for software/hardware should be established. Only tested configurationsof an assembly of hardware and software components can be operated
under safe conditions.

5.3.3

Delivery andinstallation

In the context of management support tasks, these activities are carriedout by the contractor or by the supporting organization. In particular,
after the modification of software and the creation of a new software
release, the modifying organization will be concerned with the best way
of providing the new software product to the affected users, which canbe a single client or in case of widespread products, thousands ofclients. Packaging and distribution paths will be of special interest in thecase of secret or security relevant software.

User support

User support covers a wide range of activities carried out by the
supporting organization. The interactions between the supporter and theuser can be:−

Support for installation, set-up or operation of software−

User help desk/hotline−

User queries, which are answered by the supporting organizationby providing result reports−

User training

Software modification tasks
These tasks are related to a longer-term process of implementing changes to software.
Normally these activities are carried out by a supporting organization of the contractor on a highlevel of support (manufacturer or vendor of software). However, modification of software canalso be carried out by the customer (especially changes of lower criticality). This requires
corresponding equipment as well as the appropriate skilled personnel. Software modification
tasks cover the software modification activity itself (coding, change implementation, testing) as
well as the related tasks, such as problem investigation and configuration control.
The reasons for the necessity to change software can be of different quality.
−−−

Corrective changes
Adaptive changes
Perfective changes

The most critical reason, in general, is the occurrence of real failures, which leads to an
unacceptable situation within the operation of the entire product. Such a failure will normallylead to a corrective modification of software. Also, the necessity of adaptive changes can be a
critical situation, but normally this kind of change can be predicted and planned for slightly
better than for a corrective activity (including emergent). The time schedule for adaptive
Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6865-03000-00

changes is not normally as critical as for a corrective action. However, in today's systems it
becomes more and more difficult to predict the adaption needs concerning software over alonger period.
Perfective changes are for increasing the user-friendly properties of the software or forincreasing the functionality. Normally these changes are implemented through an upgradeconcept. The requirements of the users will be collected during a certain time period and will be
implemented within a new release of the software package.
Table 8 Software modification tasks
Type of task

Description

Probleminvestigation

The initial concern of problem investigation is usually to determine how
the affected software can be further operated with the actual failure (egwith lower capability). As a next step, it must be ensured that a real
software bug or a real technical problem exists. It must be avoided totrigger any real software modification because of, for example, user
mishandling. After the problem has been correctly identified and any
appropriate interim measures put in place, an analysis will follow on how
the software can be modified so that the problem would be resolved
permanently.
For a proper problem investigation, the required needs should beavailable. This can be a simple programming environment with certain
compilers and debuggers, but also a complex environment which allows
simulation and failure reproduction.

Changeimplementation

The implementation of changes into software packages requires
carefully considering some crucial aspects. Normally, the supportingorganization should have access to a complete repository of the entire
software development process from the beginning to the actual status.
Coding, compilation and testing of software requires special tools, whichmust be available. Additional appropriate trained and experienced
personnel are necessary.
It should be considered that any basic change in technology can cause
support problems. Examples could be obsolescence or the supersedingof tools that are required for software modification or the change ofbasic operating systems on computers. This can have a large impact on
costs or even require the upgrade of entire software packages to a newrelease when the former software package is not compatible with the
new environment.
In the SSC, the relevant standards and procedures that are used should
be defined.

Change release

A new release of a software package marks the end of its change
implementation process. The new software package containing the
installable and executable files/code, which is tested and certified, canbe now delivered to the customer/user. All additional information is alsoavailable for the end user, such as installation instructions and modified
documentation.
The supporting organization should ensure that the distribution ofmodified software releases is well organized. This should be a part ofthe overall SSC.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6865-03000-00

Type of task

Description

Configuration
control

Configuration control of software during modification is concerned withmanaging individual change development and controlling different
software versions and documentation. For this reason, the usage of asoftware development repository is strongly recommended. The
compatibility between the new software packages and the existing
hardware/software configuration must be ensured.
In the SSC, the relevant standards and procedures should be defined.

6

Supportability factors
To establish a proper supportability of software, the analyst must consider a range of factorsthat can influence software supportability. All of them must be taken into account carefully,
dependent to the special project. The following list shall support the analyst, who must deal withsupport requirements for software. As described in the chapters above, some of the aspects are
more related to operational support and some of them are related to software modification
support. These supportability factors are generally either attributes of the software itself or the
associated development process, or of the environment within which the software is operated
and supported. For special projects, of course there can be additional aspects which are notcompletely covered by the following list, but it is a good starting point for any analytical activity
concerning logistic aspects of software.

6.1

Compatibility matrix
In systems where multiple software carrying equipment work together in a network, it isimportant to guarantee the compatibility of the equipment. It must be ensured that different
versions of software on different hardware items are able to interoperate properly in a
networked system. On the other hand, the compatibility of different versions of a software
package with different hardware items is also of interest. The following recommendations on
where to document these compatibilities should be considered:
−
−

6.2

Software to hardware compatibility can be documented within the LSA database within thephysical breakdown containing corresponding software items.
A compatibility matrix concerning networked equipments carrying software packages, whichmust document the allowed configurations of the complete system concerning compatibilityof software issues, should be established outside any LSA and SSA databases.

Deployment
Software deployment is a crucial aspect for software supportability. Each location, in whichsoftware packages are in use, must be sufficiently supported. The linkage of the locations to
support capabilities (eg installation support, user helpdesk, troubleshooting and recovery
support) must be carefully considered and should be agreed upon by the customer and the
support organization.

6.3

Documentation
In general, documentation refers to two main aspects:−−

Software developer supporting documentation
Software user supporting documentation••

End user documentation (user handbook)
Administrator documentation (installation/update and configuration handbook foradministrative purposes)

In order to ensure software supportability for the developers, documentation should be
produced conforming to an agreed standard and it must be available to the organization
Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6865-03000-00

charged with delivering software support. Any software tools used in the creation of
documentation must be included in the support facility and arrangements must be defined fortheir life cycle support.
Concerning operational aspects, the documentation for the administrator or for any power user
is of special interest. It should contain installation and configuration manuals as well as
troubleshooting tips in case of some malfunctions, which can be rectified easily. In case of more
severe malfunctions, the documentation must contain the relevant data for the supportingorganization, which must be contacted.

6.4

Easy loading/unloading and installation
The duration of loading of software and data is of importance (this includes cost aspects).
Software should be designed so that a loading procedure takes a minimum amount of time (ega loading duration of several hours may not acceptable by the customer. For this reason, thesoftware, as well as the loading devices, should be optimized for proper and fast loading
processes. The same applies for the unloading of data or software after special missions or
usages of the system. If a large amount of data must be downloaded from a system after a
mission, there should be a fast and easy download procedure available.
An additional aspect of loading is the safety requirement. It must be ensured with the help of
appropriate test procedures, that the loading or the installation was actually successful and thesystem works without any problems.

6.5

Easy transportation on hardware carriers
If it is necessary to transport software with the help of hardware devices, some aspects must be
considered. Which kind of carrier will be selected is dependent upon the type, size and safety
requirements of the software. Is it possible to transport the software on chip cards or USB
sticks? Do you need DVD or even hard disks as a carrier for the software? What are the safety
aspects (eg is it allowed to transport the software on a carrier, where the files can be modified
easily)?

6.6

Expansion capability
Expansion capability is an aspect of system design. Though related to the software andsometimes influenced by the software design, it is usually a hardware characteristic that must
be considered within the overall system design. It is concerned with the degree to whichsoftware may be modified without being limited by restrictions on computing resources.
Examples of such constraints on computing resources are:
−
−
−
−
−
−

Available memory
Processor performance
Mass storage capacity
Input/output bandwidth
Database capacity
2
3
Network performance (LAN , WAN , internet connectivity, firewall performance)

If expansion capability is not considered sufficiently, software modification will be limited
considerably or modification costs will explode. Especially in systems with rather fixed hardware
configurations or embedded real-time applications, expansion capability is of high importance. If

2Local Area Network. Computer network which covers a small geographic
area (eg home network, network in an office covering, for example, a groupof buildings)
3

Wide Area Network. Computer network that covers a broad area. WAN areused to interconnect several local area networks (LAN).
Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6865-03000-00

expansion capability is not considered, a required change of the hardware configuration cancause a large amount of additional activities and costs.

6.7

Modularity
Modularity is an attribute of the structure of a software design. Different areas of function withina software package should be structured with the help of a number of modules. The possibilities
to apply modularity to a software design are determined by the choice of design method,
programming tools and programming language. However, in general, the optimum approach toachieve modularity will be one that balances functional and performance requirements against
the need to provide an understandable and supportable design. Insufficient modularity can
result in increased modification effort and costs because of the need to implement
consequential modifications in different parts of the software.

6.8

Modification frequency
Modification frequency (also called change traffic) is a measure of the rate at which software
modification is necessary. Before the software is in use, estimates should be made with the helpof comparison with similar applications (any data available from comparable in-service systems
on change traffic and effort will be of significant value). Some calculation methods based on thecharacteristic properties of the software can be used for change traffic estimation. Experienceduring test and trial phases can also be included in the investigations. Modification frequency
influences stability, software integrity and system operation. Change traffic will affect the volume
of software support activity. Higher change traffic will require more software modification
activity.
High modification frequency involves a higher risk of downtimes of the entire system because of
implementation problems or even because of bugs from new software releases. So, a goodbalance between the frequency of new software releases and the needs from adaptive,
perfective or corrective requirements must be found.

6.9

RecoveryIn case of any system halt caused by a software failure, it must be possible to reset the system
to full or at least to degraded functionality in an acceptable amount of time. This should beconsidered in early phases of software development in order to provide a proper
instrumentation for recovery purposes. This might include:−−−

State of health monitoring
Fault-tolerant handlers
Design for debug features

This aspect is particularly important in systems deployed to space or other exposed locations. If
software fails in such far away systems, it is crucial to have a potential recovery capability using
the available instrumentation for operational real-time upgrade (eg download updated software
and/or data).
Recovery procedures must be carefully documented and should be well known to the
responsible users or administrators. Recovery procedures should be tested before a real
emergency occurs. In this case it should be clear what to do and how (eg critical data can berestored from a data backup). The best backup is worth nothing if during an emergency thestored data cannot be restored because of unattended circumstances. Training for the
personnel to react properly is recommended and proper function of recovery should be
simulated regularly.

6.10

Safety integrity
The safety integrity required of a software package is determined by the safety criticality of thefunctions that it provides. The overall safety criticality of a system should be established by theapplication of an appropriate hazard analysis technique. The criticality of particular software
items will be the consequent of the partitioning of system functions in the system design.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6865-03000-00

Designs should guarantee that software items that implement critical functions should be
minimized or at least segregated from other parts of the software. System requirements should
define safety criticality categories and software safety integrity levels. Constraints andrequirements for software design, testing and modification will be associated with each safety
integrity level.
However, safety integrity is not only a matter of software design. During transportation,
installation and operation of the software, some activities can be necessary to achieve a
sufficient safety level. For example, the granting of user access rights on the basis of allowed
software functionalities or data areas is an important safety relevant activity, as well as theproper transportation of critical or secure data.

6.11

Security
The aspect of security primarily concerns the software itself. To meet security requirements forsoftware usage, for example, the following methods can be applied:−−−−

Cyclic redundancy check
Encryption
Digital signature
Activation or license keys

The security classification of data, executable code and documentation can constrain software
support activities. The main influence on equipment will be to impose special handlingrequirements. This might limit access to the software and introduce design requirements whichraise the importance of specific software support tasks and equipment. The security
classification of a software item will be dependent upon the application and the equipment
design. Wherever possible, software should be designed in that way that highly classified
software parts are physically segregated from all other software within the system. Security
requirements should provide criteria for security classification of software items and should
specify modification and handling constraints associated with such classifications.
Another aspect of security is of operational character. It must be ensured that a software
package can operate in a secure environment. This means internal security concerning a proper
user access control policy as well as external security. Intruders from outside must be held off
and internal users must be limited and controlled concerning their activities (eg via the internet).
These operational security requirements can cause a number of support activities such as:
−
−
−

6.12

Network administration activities (eg granting access rights to specific data areas, fileservers or application services)
Firewall administration activities
Virus detection and defense activities

Size
The size of software packages influences supportability parameters, both in terms of the level ofchange traffic expected and the resources required to implement modifications. The size of thesoftware within a system is dependent upon the application and the design solution. Software
requirements should state any constraints on the size of run-time software imposed by thesystem design. Many software support and supportability projections will be based on software
size and complexity. Software development requirements should define requirements for datacollection and analysis to measure software size and to verify models or estimates of
supportability parameters, which are dependent on software size.

6.13

SkillsRequired skill levels for personnel that are faced with software must be considered from several
perspectives. The normal user must be able to handle the functions of the software in a
professional manner. Operators with administrative responsibilities will require a deeper
education concerning the functionality of the software in the corresponding IT environment. The

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6865-03000-00

highest level of skill is required for software modification. In this case you need personnel withappropriate software engineering skills. Requirements for particular qualification are associatedwith the application domain and the technology or the methods used. Skill requirements will be
determined by the system design, the software design and the applicable software support
policy.

6.14

Software distribution
With the increasing significance of networked environments, software or rather data distribution
should be considered under enhanced conditions. Software can be distributed on a variety ofdifferent media types, and distribution via the internet or other network environments, such as
LAN or WAN structures, is also possible.

6.15

Standardization
Standardization should be applied to the computing environment within which the software isoperated. The same holds for technologies and engineering processes used to develop thesoftware and the associated software documentation. Standardization helps to reduce thediversity of tools and methods. This considerably reduces the effort for training of personnel andfor the required equipment at the support facilities. Also, for operational aspects, standardization
can be helpful (eg loading/unloading or backup procedures can be defined to conform toexisting standards).

6.16

Technology
Technology aspects should be considered with respect to the software engineering methods
and tools used in development and implementation. This includes:
−
−
−
−
−
−

Software design methods and supporting tools
Operating systems
Programming languages
Compilers and debuggers
Software test methods and test environments (hardware and software)
Project specific tools and techniques

Technology influences operational aspects, also. For example, the technology of storage
devices within a system can influence support activities substantially or the usage of WEB
based technologies can dramatically ease the maintenance of client computers in a clientserver application environment.

S3000L-A-13-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-13-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 132010-04-01 Page 26

S3000L-B6865-03000-00

Chapter 14
Life cycle cost considerations
Table of contents

Page

Life cycle cost considerations ........................................................................................................ 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
LCC objectives................................................................................................................. 2
1.3
LCC typical applications .................................................................................................. 32
LCC Process.................................................................................................................... 3
2.1
LCC Problem definition .................................................................................................... 3
2.2
Alternatives definition ...................................................................................................... 4
2.3
Cost elements definition (Cost breakdown structure/tree) .............................................. 4
2.4
Cost modeling .................................................................................................................. 4
2.5
Data collection ................................................................................................................. 4
2.6
Cost profile development ................................................................................................. 5
2.7
Evaluation ........................................................................................................................ 5
3
Cost breakdown ............................................................................................................... 5
3.1
Acquisition ....................................................................................................................... 6
3.1.1
Research development test and evaluation .................................................................... 6
3.1.2
Investment or procurement.............................................................................................. 6
3.2
Ownership ........................................................................................................................ 6
3.2.1
Operating and support ..................................................................................................... 6
3.2.2
Disposal or phase out ...................................................................................................... 6
4
Entry data ........................................................................................................................ 6
4.1
Minimum data required to perform the analysis .............................................................. 6
4.2
Tailoring of data ............................................................................................................... 7
4.3
Estimation of data ............................................................................................................ 85
Outputs and reports ......................................................................................................... 9
6
Sensitivity and trade-off analysis ................................................................................... 11
6.1
Trade-off analysis .......................................................................................................... 11
6.2
Sensitivity analysis......................................................................................................... 11
6.3
Simulation ...................................................................................................................... 127
LCC tools ....................................................................................................................... 12

List of tables
1

References ...................................................................................................................... 2

List of figures
1
2
3
4
5
6

Acquisition costs vs. ownership costs (iceberg effect) .................................................... 2
Example for a LCC process logic .................................................................................... 5
CBS example ................................................................................................................... 8
LCC summary cost, yearly budget - Example ............................................................... 10
LCC summary cost, yearly budget split - Example........................................................ 10
LCC breakdown - Example ............................................................................................ 11

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

References
Table 1 References
Chap No./Document No.

Title

None

1

General1.1

Introduction
Life Cycle Cost (LCC) is the cumulative cost of a product over its life cycle from Entry into
Service to disposal as determined by a process of economic analysis that allows for theassessment of the total cost of acquisition, ownership and disposal of the product.

1.2

LCC objectives
The objective of the Life Cycle Costs Analysis (LCCA) is to provide the managers with an
economic enlightening of each alternative presented in order to determine the most costeffective support. LCCA approach from a series of alternatives in order to achieve the minimum
LCC that guarantee the effectiveness figures required to the product.
The following figure shows the relation between acquisition cost and support and operation costfor buying decision.

Total LCC

Acquisition cost

Acquisition
cost

Operation

MaintenanceTechnical publication

Facilities
Training
SparesOwnership cost

Support equipment

Disposal

Disposal cost

ICN-B6865-S3000L0070-001-01
Fig 1 Acquisition costs vs. ownership costs (iceberg effect)
The costs of ownership and operation, usually exceed significantly all cost of acquisition and,
therefore, the decision to purchase a system/product should be not only be influenced by the
product's initial cost (acquisition cost) but also by the product's expected operating andmaintenance cost over its life (ownership cost) and disposal cost.
LCCA can also be applied to evaluate the costs associated with a specific aspect, for example,
the effects of different maintenance concepts/approaches to cover a specific part of a product,
or to cover only selected phases of a product’s life cycle. It is essential to identify what the main
cost drivers are (LCC elements which have a major impact on the LCC) and what can be done
Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

to keep them as low as possible. For this purpose, additional investigations may be offered inorder to justify the significance of cost driving elements (eg so-called "sensitivity runs" and/or
operational simulations).
Once the cost drivers have been identified, a decision making process could be initialized toevaluate and select the equipment and/or support solution offering the most cost effective
solution to meet a defined need.
In order to support the customer in decision making, beside the purely LCCA results, a
conclusive recommendation should be offered by taking into account aspects concerning
standardization, potentially technological evolutions, cost trends (eg after closing of productionlines), readiness drivers, risks of obsolescence, preconditions for support contracts, etc.

1.3

LCC typical applications
LCCA may be applied for:
−
−
−

−

−
−
−
−

2

Evaluation and comparison of design alternatives. In the case of modifications or designchanges to be embodied on the product, the LCCA assesses the impact on costs of therelated items.
Evaluation and comparison of alternative support concepts.
For the same design of a mission system it is possible to consider different support
concepts alternatives (eg Maintenance Level 1, Maintenance Level 2, Maintenance Level 3
and Maintenance Level 4 versus Maintenance Level 1 and Maintenance Level 4 only). It is
possible to have different definitions of the support levels increasing the capabilities of alevel and decreasing the capabilities of another. LCCA must be performed quite close to
the support concept decision and the LORA analysis.
Affordability studies, assessment of economic viability of projects/products. Through the
LCC an estimate of the total cost of a program or project over its useful life could beobtained providing information as to whether or not a customer can afford a project or
product.
Identification of cost drivers and cost effective improvements. Having identified the cost
drivers, a decision making process could be carried out to evaluate and select theequipment offering the most cost effective solution to meet a defined need.
Evaluation and comparison of different approaches for replacement, rehabilitation/life
extension or disposal of systems/products. LCCA could be used as a guide to examine theeffects of different solutions upon support cost and therefore upon total costs.
Assessment of product assurance criteria through verification tests and their trade-offs;
Long-term budget planning and tracking. LCCA results in information and data that may
help in developing budgeting or in providing inputs to the programming, planning andbudgeting systems.

LCC Process
Although it could be necessary to adapt the LCC process to the system being considered, there
are common steps that may be essential in all the LCC processes. The depth of the analysis forevery step needs to be adapted to the requirements of each project, and therefore, some kind of
tailoring will need to be agreed at the beginning of the program.

2.1

LCC Problem definition
1

Definition of the aims and objectives of the study

2

Definition of the boundaries and assumptions of the study

3

Cost driver identification. Refers to those items of the product that have an important
contribution to the LCC

4Constrains analysis

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

5

2.2

2.3

2.4

Risk identification

Alternatives definition1

Support concept analysis

2

Current operation and standardization opportunities for support

3

First draft support alternatives identification

4

Feasibility alternatives trade off

5

Final support alternatives definition, including detailed specification (personnel skill
available, storage, transport, support equipment and facilities belonging to each support
alternatives)

Cost elements definition (Cost breakdown structure/tree)
1

Cost elements identification. Describing each cost element

2

Cost element key performance indicators identification

3

Cost element analysis approach. Including source data identification

Cost modeling1

Analysis of different cost models
Whatever cost model is to be selected, Pareto rule should be considered for selection ofvital few cost contributors. The purpose of Pareto charts is to identify the vital few cost
contributors so the details can be itemized and ignore the many trivial issues. Pareto rules
say that 10% to 20% of the elements of a cost analysis will identify 60% to 80% of the total
cost. These items are the vital few items of concern and need to be carefully considered.
For example, when selecting the components with more influence on the repair cost, thekey value to be considered for Pareto rule application could be "Component Unit
Price/MTBF" since both high prices and low MTBF could be considered as the main cost
contributors to the total repair cost. By selecting the items adding up the 80% of the total
for the key value "Component Unit Price/MTBF", components with more influence on the
total cost are defined.

2

Cost model evaluation.
Experience on the existing model as well as the availability of data required for the modelor consideration of efficiency analysis must be taken into account when selecting one
model per each program/project. Appropriate cost model should be selected depending on
the product to be analyzed and objectives of the LCCA. In some cases, existing costmodels could suit needs but, in other cases, customized models could be required toarchive expected objectives. The selection of the cost model should be done taking into
account the benefits and also the costs of using one or another solution.

3

2.5

Cost model tool availability in the market or cost model tool design and development.

Data collection
1

Identification of data requirements for the selected model.

2

Identification of sources for data (department responsible)

3

Data collection from sources. Include preparation of requirements for equipment suppliers
and subcontractors.

4

Data validation to check the quality of the data and also the coherence between different
sources of a data.

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

2.6

Cost profile development
This is the complicated section where all the details are assembled. Of course the morethorough the collection process, the better the LCC model.

2.7

Evaluation
1

Running of the model for different alternatives

2

Sensitivity analysis performance3

Analysis of results and decision of the best alternative. During the evaluation it is necessary
to check if the results meet the criteria defined in the first step of the LCCA. If it does notsatisfy the criteria, it should be modified as an alternative and the LCCA of the alternative
should be evaluated in order to find the best alternative.

Step 1

Problems definition
Step 2

Alternatives definition
Step 3

Cost elements definition
Step 4

Cost modelling
Step 5

Data collection
Step 6

Cost profile development
Step 7

Evaluation
ICN-B6865-S3000L0071-001-01
Fig 2 Example for a LCC process logic

3

Cost breakdown
The Cost Breakdown Structure (CBS) identifies all cost items or ‘cost-elements’ affecting thetotal LCC of the system/product. In order to avoid ignoring significant cost elements, it isrecommended that the cost elements are defined in a systematic manner.
Cost elements depend on the system/product to be analyzed and CBS should be tailored foreach application area for LCCA.
Costs can usually be divided into Non-Recurring Costs (NRC) those that occur once over alimited period of time and Recurring Costs (RC) that occur repeatedly over time according to thedegree of utilization of the system/product.
The appropriate life cycle phases should be selected to suite the special needs of each specificanalysis but, in a general way, the total costs of a product through its life can be broadly defined
as follows:

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

3.1

Acquisition

3.1.1

Research development test and evaluation
Research Development Test and Evaluation - the sum of all funded costs required to bring a
product’s development from inception to production.

3.1.2

Investment or procurement
Investment or procurement - the sum of in-house costs, both NRC and RC, need to transformthe results of Research & Development into a fully deployed operational system.

3.2

Ownership

3.2.1

Operating and support
The costs of operation, maintenance and supply support of products and support equipment are
incurred throughout the expected life of the system/product.

−

Costs associated with operation••−

Costs associated with preventive maintenance

•
•

•

−

NRC, eg costs for initial training of staff, documentation, initial spares, equipment,
facilities and special tools
RC, eg costs for labor, consumables, power, on-going training and upgrading

NRC, eg costs for acquisition of test equipment and tools, initial spares andconsumables, and initial training of staff and initial documentation and facilities
RC, eg costs for labor, spares, consumables, on-going training and documentation
replacement of parts with limited lifetime (may be recurring or non-recurring)

Costs associated with corrective maintenance••

NRC, eg costs for test equipment, tools, initial spares, initial training of staff, initial
documentation and facilities
RC, eg costs for labor, spares and consumables, on-going training and documentation
It should be noted that operational costs (eg fuel consumption), personnel expenses,
real estate costs, etc, which may arise on the customer side are either purely
estimated or to be contributed by the customer.

3.2.2

Disposal or phase out
The sum of all costs required to remove the system or equipment from the inventory, and which
may be offset by some residual value.

4

Entry data

4.1

Minimum data required to perform the analysis
Data required to perform the LCCA will be dependent on the complexity and detail of the costelement structure defined but, in general, the following minimum data elements are required
when performing the LCCA:−

Environmental data elements. The environmental data set is divided into two categories of
input variables:•

Support constants, that are divided into:−

Program independent factors, describing the world in which the product is
operating (eg personnel costs, personnel turnover rate, inflation rate).

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00−•−

Deployment and operating program variables. These variables represent information
about the number of products to be considered and the extent and type of operations
in which they are involved (eg, product delivery/retirement planning, product mission
profile and variables).

Product data elements. The product data elements are divided into:
•
•

4.2

Contractor constants, describing the conditions under which the system ismaintained (eg support concept limitations to be considered for the analysis).

Product data elements that describe the product’s design characteristics (eg scheduled
maintenance tasks, time to repair).
Product configuration items data elements, that describe the systems or parts
considered for each indenture level according to the configuration tree under study (egMTBF, MTBUR, time to repair, unit prices).

Tailoring of data
The selection of cost elements should be related to the complexity of the product, as well as tothe cost categories of interest in accordance with the required cost breakdown structure.
Differences between programs and projects require a flexible approach when defining the costelement structure and it is difficult to produce a single cost structure for all LCC applications.
Nevertheless, the basic structure of the CBS should not change. Using this basic structure, thecost element structure should be expanded to levels of detail to meet the specific need being
analyzed.
The following figure shows an example of a CBS expanded into four levels.

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

LCC cost breakdown
1. Life cycle phases
1

Aircraftacquisition

2

Entry into service

2. Main cost
1.1

Aircraft & Mission
systems acquisition

2.1

Support equipment

2.2

Spares

2.3

Training

2.4

Technical publication

3. Categories

4. Sub-categories

2.5

Facilities
2.6 Eng. & logistic services
2.7
Technical services
3.1

3Operation

3.1.1

Crew

3.1.2

Mission personnel

3.1.3

Fuel

3.1.4

Consumables

3.1.5

Aircraft insurances

3.1.6

Air navigation &landing fees

3.2.1

3.2

3.2.2
3.2.3

Scheduled maintenanceRepairs

3.2.3.1

Personnel

3.2.3.2

Material

3.2.4.2 2nd level maintenance3.2.4.3 3rd level maintenanceOperation & Support

3.2.5
Training refreshment
Support
3.2.6

Technical publication

3.2.7

3.2.8
3.2.9
4.1

Major modification

4.2

Minor modification

5.1

Through life disposal
cost

5.2

Final disposal cost

Disposal

3.2.5.1

Crew

3.2.5.2

Maint. technicians

3.2.5.3

Other pers. training

3.2.5.4

Training aids

3.2.5.5

CBT licenses

3.2.6.1

Update3.2.6.2 Reproduct & Distribute
3.2.7.1

Training facilities

3.2.7.2 Maintenance facilities

Facilities

5

Material

3.2.4.1 1st level maintenance
GSE maintenance

A/C Mods & Upgrades

Personnel

Life limited parts

3.2.4

4

3.2.1.1
3.2.1.2

3.2.7.3 Mission system centre
3.2.7.4
Logistic facilities

Eng. & logistic support

3.2.8.1

Engineering services

3.2.8.2

Logistic support

Technical support
service

ICN-B6865-S3000L0072-001-01
Fig 3 CBS example

4.3

Estimation of data
Accuracy of input data is crucial to improve the certainty of the LCC prediction. Factual data
should be available to quantify cost elements in a CBS. Each cost element may be quantified bydirectly applying the collected actual data to the model of LCC. If actual data are not available,
the cost elements relevant to the non-available data may be estimated.
To estimate the value of data, in a particular cost data, some methods are proposed:

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00−−−

Analogy Method. This method draws on the relationship between current and similar
previous data with adjustments made from expert judgment to reflect characteristics of thedata under consideration.
Parametric method. It is based on statistical analysis of historic databases. It usually results
in a cost estimating or cost factor relationship.
Engineering Method. This method consists in the application of analytic formulae thatprocess known system/product characteristics to yield the cost value. This method is also
known as "bottom-up estimate".

The selection of a cost estimating technique depends basically on the level of detailed data
which is available at the time the LCCA is prepared. In general, analogy and parametricmethods are most useful during the early stages of the product’s life, serving as an order-ofmagnitude estimate of potential costs. As the design is stabilized and more information isavailable, the parametric method becomes a more useful technique. Later, when there is adetailed product, engineering estimates may become a more appropriate device for estimatingcost. Since analogy or parametric methods are normally less costly than the more detailed
engineering estimation technique, it is important to decide whether the more detailed estimate isworth the higher cost. More detailed estimating techniques do not necessarily provide moreaccurate estimates.
When the characteristics of the product and its operating scenario become known the bestsource of information for many cost elements is the ‘actual’ or in-service data. In-service data
should be used as it becomes available because this is often the most credible source of
information.

5

Outputs and reports
The results of the life cycle costing should be documented and presented by using so many
reports and graphs as required allowing users to clearly understand both the outcomes and theimplications of the analysis.
The final LCCA report should contain at least the following:
−
−

−
−
−

−

Purpose and scope. A statement of the LCCA objective, including a definition of theintended product use environment, operating and support scenarios; assumptions,constrains, and alternative courses of action considered in the analysis.
LCC model description. A summary of the LCC model, including relevant assumptions, a
depiction of the LCC breakdown structure, an explanation of the cost elements and the way
in which they were estimated, and a description of the way in which cost elements were
integrated.
LCC model analysis. A presentation of the LCC model results, including the identificationof cost drivers, the results of sensitivity analyses, and the output from any other related
analysis activities.
Sensitivity and Trade-off analysis results
Conclusions and recommendations. A presentation of conclusions related to theobjectives of the analysis, and a list of recommendations regarding the decisions that are to
be based on the analysis results, as well as an identification of any need for further work or
revision of the analysis.
Graphs. Different graphs showing the LCC outputs. Fig 4, Fig 5 and Fig 6 show somedifferent charts that could be obtained as result of the LCCA:

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00

ICN-B6865-S3000L0073-001-01
Fig 4 LCC summary cost, yearly budget - Example

ICN-B6865-S3000L0074-001-01
Fig 5 LCC summary cost, yearly budget split - Example

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6865-03000-00

ICN-B6865-S3000L0075-001-01
Fig 6 LCC breakdown - Example

6

Sensitivity and trade-off analysis
Sensitivity and Trade-off analyses are performed by changing LCC model inputs and noting theimpact on the LCC results.

6.1

Trade-off analysis
Trade-off analysis deals with examinations of alternative strategies. Trade-off analysis is used
to evaluate proposed alternative systems or equipment configurations in terms of estimatedcosts, risks, benefits and operational effectiveness. These studies are designed to assist
decision makers in selecting the most desirable system/product configuration among the baseline system and the alternatives evaluated in the LCCA.
During the LCCA, it is checked if the system/product meets the criteria defined at the beginningof the LCCA. If it does not satisfy the criteria, it should be modified as an alternative system andthe LCC of the alternative system should be evaluated. In LCCA, the optimization process of
seeking the best is applied to each alternative in accordance with the decision evaluation. In a
broad sense, the optimization process generally means to find a set of parameters thatminimizes the LCC of the total system/product, however, in a narrow sense; the optimization
may be applied to specific activities in the LCC processes such as design optimization,
maintenance optimization, etc.

6.2

Sensitivity analysis
Sensitivity analysis examines the impact of changes to cost drivers or cost with big impact in the
LCC results. Varying the input parameters over a range to see the impact on cost can help
highlight the major factors affecting costs.
Sensitivity analysis can be performed in two ways:−−

Multiple overall values. Entries are based on a percentage of the value.
Detailed examination of a single value. A range of values for one specific parameter isdefined and also the number of iterations.

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6865-03000-00

6.3

Simulation
It is very important to consider the aspect related with the simulation capabilities of the LCCA.
Considering that LCCA is used to make tradeoff, LCC can be performed to simulate different
support scenarios or different design solutions of a product.
Varying parameters used to calculate the cost of the whole life cycle are used during thesensitivity analysis in the same way can be simulated the impact of changes in the different
characteristics of the mission system alternatives as well as the support system changes.

7

LCC tools
There are many software packages for LCCA on the market but the most appropriate tool
should be selected depending on the specific system/product to be analyzed and the objectivesof the LCCA.
The use of tailored LCC models could be preferred in some cases if there are requirements for
adopting a range of approaches particularly to evaluate the costs associated with a specificactivity, for example, the effects of different maintenance concepts, to cover a specific part of a
product, or to cover only selected phase or phases of a product’s life cycle according to a
supplier-user agreement.
In the same way, and taking into account that the selection of cost elements within the LCC
model are related to the complexity of the product and that the cost categories of interest should
be in accordance with the required CBS, standard LCC tools could not suit some specific needs
and customized tools could be required for these cases.
The selected LCC tool, in order to be realistic, should:
−
−
−
−
−

Represent the characteristics of the product to be analyzed, including its intended use
environment, maintenance concept, operating and maintenance support scenarios as wellas any existing constrains and limitations.
Be comprehensive in order to include and highlight all factors that are relevant to LCC.
Be simple enough to be easily understood, managed and updated in case of specific needs
requiring customization of the tool.
Concentrated on the main cost drivers that considerably influence the total LCC to avoid
ignoring significant elements and also to avoid those insignificant cost elements that do notalways provide additional accuracy to the final results.
Flexible to allow the evaluation of different approaches or scenarios.

In some cases, the LCC tool may need to be specifically developed for the problem understudy, while for some other cases commercially available models may be used. Knowledge ofthe contents and the conditions under which they apply are important in order to assure
adequacy of the use of one or another tools.
Where possible it is recommended that all parties in the project use the same LCC tool.

S3000L-A-14-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-14-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 142010-04-01 Page 12

S3000L-B6568-03000-00

Chapter 15
Obsolescence analysis
Table of contents

Page

Obsolescence analysis .................................................................................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
1.1
Introduction ...................................................................................................................... 1
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 3
2
Obsolescence strategy .................................................................................................... 3
2.1
Reactive obsolescence management ............................................................................. 3
2.2
Proactive obsolescence management ............................................................................ 3
2.3
Obsolescence monitoring ................................................................................................ 4
2.4
Strategy tools ................................................................................................................... 4
3
Develop an obsolescence management plan ................................................................. 5
3.1
Scope and content of an obsolescence management plan ............................................ 5
4
Implementation of obsolescence solutions ...................................................................... 6
4.1
Budget for obsolescence management costs ................................................................. 6
4.2
Linking obsolescence to the risk management activity ................................................... 7
4.3
Obsolescence and life cycle costs................................................................................... 7
4.4
Ensuring industry plans and manages obsolescence ..................................................... 7
5
Conclusion ....................................................................................................................... 8

List of tables
1
2
3

References ...................................................................................................................... 1
Options for reactive obsolescence management ............................................................ 3
Options for proactive obsolescence management .......................................................... 4

List of figures
1

Life cycle phases ............................................................................................................. 2

References
Table 1 References
Chap No./Document No.

Title

None

1

General1.1

Introduction
Obsolescence occurs due to the length of time it takes to develop and field a product (Fig 1)
and then the subsequent long life cycles of products. Obsolescence affects all products andsystems and is not limited to hardware and components, but includes test and support

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

equipment, software, tools, processes, logistic products, standards, specifications andexpertise.
Early phases

D&D

Up to 5 years for Up to 5 years forthe concept
the design &phasedevelopment
phase
Conceptandtechnology
development

Systemdevelopment
anddemonstration

Production/implementation

Inservice

Up to 25 years for the
production phase

30 or more years for inservice
phase

Production
anddeployment

Operations
andSupport

Disposal

Disposal

ICN-B6865-S3000L0093-001-01
Fig 1 Life cycle phases
Obsolescence occurs for a number of reasons:
−
−
−
−

−

The life spans of the components that make up the product are decreasing, especially thelife cycle of electronic components (presently approximately 5 years or less per innovation
cycles).
Obsolescence occurs because the manufacturing base, subcontractors and vendors, aresubject to market forces. Manufacturers can go out of business and essential parts or sub
assemblies can become unavailable.
The loss of design and technical know how can have a big impact on the supportability oflong life cycle products particularly if bespoke software and components (ASICS for
example) were used in the original design.
Increasing environmental legislation regarding the use a specific chemicals (MEK for
example) or materials (beryllium copper for example) has also increased the pace ofobsolescence as it restricts the use of materials and this should be considered from theearliest phases of a project.
The costs of scarce materials, production facilities and support services (software
maintenance for example) can also make a product unaffordable to support.

The rate of technological innovation coupled with long utilization of systems and services meanthat it is almost inevitable that obsolescence will have an impact at some time in the life cycle.
Despite this inevitability, obsolescence can be managed and mitigated. The cost of mitigation
however increases significantly as the system, product or service moves closer to becoming
obsolete. Obsolescence management (OM) should therefore be undertaken as early as
possible and as an integral part of the design, development, production and inservice support
phases in order to minimize potential remedial expenditure and thereby the overall Life Cycle
Cost (LCC).

1.2

Objective
The relationship between LSA and obsolescence is that both processes occur repetitively in the
product life cycle and obsolescence must be an integral part of the LSA process as it impacts
supportability, operability and LCC and therefore must be closely managed until the disposal
phase. The objective of this chapter is to advise on the preferred practice for OM. It offers
guidance on obsolescence planning to mitigate the risk of obsolescence and minimize the LCC
of long life cycle products. Please note that this chapter is intended as an introduction andoverview of the issues related to OM. Authoritative guidance can be found in the European
standard EN 62402:2007 Obsolescence management - Application guide.

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

1.3

Scope
This chapter is aimed at engineering, quality, logistic, supply chain and sustainmentorganizations. It provides guidance on:
−
−
−
−
−
−
−

2

Defining an obsolescence strategy
Implementation of obsolescence solutions
Develop an OM plan
Linking obsolescence to the risk management activity
Obsolescence and LCC
Ensuring OM costs are budgeted for
Ensuring industry plans and manages obsolescence

Obsolescence strategy
There are two basic strategies for managing obsolescence, reactive and proactive and theseare outlined below.

2.1

Reactive obsolescence management
Reactive OM implies that there is either no specific provision for the task of managing
obsolescence or for the resolution of the obsolescence issues when they occur. Eachoccurrence is dealt with in isolation, unless they occur concurrently, and there is no link into therisk management activity. Resolution is funded from within the budget allocated to otheractivities or additional funds are sought. If a reactive approach is being taken your management
options are limited to:Table 2 Options for reactive obsolescence management

2.2

OptionDescription

Do nothing

This is a valid choice. Your decision to have a reactive strategy may
have been based on the extended life and very low consumption of
the item. This obviates the need for additional procurement activity.

Re-design

Usually an expensive option but it may be unavoidable. Costs may
have been mitigated by limited design transparency.

Alternative partprocurement

This activity usually requires a parts search and also covers
cannibalization of other items.

Proactive obsolescence management
Proactive OM implies that there is specific resource provision and a plan generated for
managing obsolescence issues. It is linked into the risk management activity and has a budget
allocated. It also has a stakeholder group identified for addressing issues as they arise.
Monitoring of the system creates time to review resolution options and justify decisions. It may
also be considered that a combination of these two approaches should be applied. This may beparticularly appropriate where very large numbers of components are concerned, some of which
could be identified as low risk. This option reduces the management cost of the OM task andalso focuses on the high-risk items. Though there is increased risk attached to this approach
which should be considered against cost and impact considerations. Care should be taken if
considering reactive OM in the early phases of a project as it may not be possible to recoverimportant information necessary to support proactive OM later in the program. It is
recommended that the proactive strategy is considered initially for all programmers. If aproactive approach to OM is being taken your management options are extended accordingly
to:Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

Table 3 Options for proactive obsolescence management
OptionDescription

Do nothing

As for reactive obsolescence management

Life time or end of lifebuy

A valid approach which can offer the best value. However care must
be taken to consider the possibility of equipment life extension,changes in consumption rates and costs of ownership (eg storage,
handling, exercising).

Planned upgrades

These offer good opportunities to address multiple issues at once,
but would usually need to be coupled to obsolescence monitoring
activities whether the upgrade is requirement or obsolescencedriven. Care would also need to be taken to ensure sufficient spares
are available between upgrades and dates and budgets strictly
controlled.

Obsolescencemonitoring

A key component of any OM strategy which if implemented correctly
will at least ensure that you have time to plan and consider yoursolution. Once the obsolescence is noted you can then determine
your preferred solution from the options available.

Design out
obsolescence

Clearly this approach needs to be implemented in the earliest
phases of a program. The intention is to design the equipment suchthat a sub-assembly capability is not tied to a particular solution.

It should be noted that mixed strategy is perfectly acceptable. This approach may be considered
because proactive OM carries a cost which increases with the number of components
considered and monitored. The cost needs to be weighed against the possible impact onavailability and obsolescence rectification costs. The cost of OM is a driver in the choice of thestrategy.

2.3

Obsolescence monitoring
When implementing an obsolescence monitoring solution there are various options whichshould be considered and some are discussed below. The use of the Design Authority (DA) to
manage obsolescence is an obvious choice. The DA is best placed to develop a list of parts,
identify solutions and modify the design. This is particularly so during the early phases of the
project when the design may be influenced by OM considerations. An alternative solution which
may be considered, particularly in the in service phase is the use of a third party contractor witha dedicated OM portfolio of skills. There are many companies which offer an OM service, eachto varying depths, which can be tailored to meet the requirements of the customer. The
advantages of using such a contractor may be that they have specialized skill sets in the OM
area and experience of doing this work over many years. Any overhead would be spread overmany other projects and therefore may offer better value. They do not have a vested interest in
identifying obsolescence issues unless they are also contracted to identify solutions. A further
option would be to employ a combination of the DA and third party. The DA could be employed
to do the bulk of the work whilst the third party may offer specialist skills and through its
independence could be used to verify DA obsolescence claims, since the DA may have avested interest.

2.4

Strategy tools
A valuable tool to assist in the strategic decision making process is the decision triplet.

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

A significant discriminator in the OM strategy and decision making process is the use of thecost, impact and probability triplet. This basic aid to the decision making process should be
employed during the analysis activity. The data supporting its application may, initially, be based
solely on the judgment and experiences of the team but this should improve as the program
develops.
In essence the triplet considers the following:
−
−
−

3

the cost of the occurrence of an obsolescence event. This should include the total system
life cycle cost addressing the design, production and implementation elements of theimmediate system and any rework or support activity costs (cost of ownership).
the impact of an event on the capability of the system. This should be considered with thecustomer or user and includes consideration of any reliability, maintainability and availability
aspects.
the probability of the event occurring. This includes possible environmental and safety
legislation considerations. These three elements should be considered together todetermine the classification of the obsolescence event. This classification may be used todetermine the obsolescence strategy, the level of monitoring, whether further investigationis required and the periodicity of review.

Develop an obsolescence management plan
The first step in managing obsolescence is to assemble a comprehensive obsolescencemanagement plan. This document should implement the strategy that will be applied during thelife of the system or program. It should be initiated at the earliest phase of the program andreviewed at least at the end of each program phase for applicability. It may start as quite a small
document but will develop and be refined as the lessons and decisions of the design anddevelopment phases are incorporated. As the program progresses it will develop into a throughlife record of the strategies employed, options considered and decisions made. It may
incorporate the contractor's OM plan, which will be provided in response to the Invitation to
Tender and contract.
The OM plan shall:
−
−
−
−
−
−

3.1

achieve the optimum compromise between whole life costs, performance, availability andmaintainability for the entire systemcover all materiel, including hardware, software, tools, test equipment, human resources
and training
be compatible with the customer’s current support arrangements
provide a clear basis upon which obsolescence management requirements can be
negotiated with suppliers and partners
show consideration of the need for component or equipment requalification/re-certification
following component or module substitution
identify the linkages and interfaces into the risk and life cycle cost program activities

Scope and content of an obsolescence management plan
The generation of the plan and its contents are the responsibility of the project team and shouldreflect the scope, complexity and cost of the program. There are certain minimum requirementsof the OM plan which are highlighted below.
It shall:−−−−identify obsolescence issues in the platform
identify obsolescence standards to be used
identify obsolescence performance metrics
record the choice of strategy and provide detail of any plans and OM decisions

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

−
−

−

−

−

−

4

for decisions made it shall include a note of the options considered, analyses and trade-off
decisions behind any choice for later reference (subsidiary documentation should contain afull record of the factors)
details of the stakeholder community personnel with authority for decision making on tradeoffs between cost and impact. OM requires input from the customer, OEM, subcontractor
and suppliers in some cases. A team with the correct stake holders needs to be assembled.
The composition of this team will vary with the product and potentially the life cycle of the
product. The team needs to establish a good working relationship so information anddecisions can be quickly determined. The longer it takes to implement a solution reduces
the chances it will be successful.
Establishing a schedule and strategy to refresh the electronics will allow the capability
upgrades as well as allow the product to be supported in the future. The strategy depends
on the product and could be broken down into electrical/electronic parts, systems or sub
systems and non-electrical/electronic parts systems or sub systems. This is also where thefrequency of scanning the product breakdown should be set. The more often the productbreakdown is scanned the less likely that an obsolescence alert will become a serious
issue. However, the more often the scan is performed, the more expensive the process will
become.
Identification of a tool set to predict the life cycle of electronic components will enable areview a bill of materials and predict when an electronic component will no longer be
supported. The tool should have the ability to read all levels of a product breakdown. The
tool should have the ability to predict when a component or assembly may become
obsolete.
To effectively manage obsolescence issues there needs to be a source identified toreceive notices from companies of discontinuances. Discontinuance notices alert
customers that production is concluding for a specific part. The notices usually contain partnumbers, last order and shipment dates, and minimum order quantities. Collection of
discontinuance notices is essential to be proactive in the management of obsolescence.
Establish a secure data repository for obsolescence data. Establishing a secure area where
information can be exchanged and stored is essential. This protects the intellectual propertyof all parties. This data can be used again for similar products in the same stage of their life
cycle.

Implementation of obsolescence solutions
When there is an obsolescence occurrence the choice of solution is wholly dependant on the
program and market circumstances at that time. Therefore each occurrence should be treatedas an individual event for which at least the following may need to be considered:
−
−
−
−
−
−
−
−

4.1

reclamation
last time buy
life time buy
re-manufactureuse of an interchangeable item
adaptive solutions
reverse engineering
new design

Budget for obsolescence management costs
It is essential that budgetary provision is made for the OM task itself. OM carries its own
resource cost and this must be included in the program budget. In addition costs must be
included for the resolution of the obsolescence issues that may arise. These will vary as the
program develops and should be regularly reviewed. This cost forecasting effort should belinked to the program risk activity to ensure that a consolidated approach is taken and that items
are not accounted for twice or not at all.

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

4.2

Linking obsolescence to the risk management activity
Managers must consider the operational risks over the life of the equipment associated withobsolescence:−−−

What would be the impact of equipment being unavailable due to lack of spares or of
performance degradation due to substituted parts?
What would be the likely cost of premature replacement or of other measures to circumvent
obsolescence?
What is the probability of obsolescence occurring (including considerations of technology
advances and the introduction of new legislation)?

Obsolescence is a key contributor to any risk assessment. How the program will address
obsolescence in its risk processes should be established early on in the program and reflectedin the appropriate management plans. Having good visibility of the obsolescence risks is thefirst key step required to minimize the negative effects. This will allow the programmed
management to identify and implement the most appropriate action to deal with any issue in themost cost-effective way. It is important to keep in mind that at the end it is always the systemuser the most affected during inservice phase in terms of readiness, supportability and life cycle
costs. It should be noted that obsolescence is always a risk but it can create opportunities whenalternative parts offer improved performance

4.3

Obsolescence and life cycle costs
Obsolescence can lead to major changes in design, it may lead to changes in support
philosophy, it may impact support arrangements. Because obsolescence can impact all phasesof a program any review of solution options must consider the implications for the life of the
program. Hence the need for OM to be linked to the LCC activities. A whole life approach must
be considered when addressing cost issues. This should be reflected in the appropriate
management plans.

4.4

Ensuring industry plans and manages obsolescenceIndustry must plan for obsolescence from the very beginning of the design process including“obsolescence prevention” as another objective of the supportability engineering and logistics
activities, maintaining this objective in all the phases of the program. Industry should:
−
−
−

−
−
−
−

−

produce an OM plan
conduct obsolescence critical analysis in the program to identify the system items with thehighest risk of obsolescence and in accordance with a predefined criteria, using similar
methodologies used for the safety hazard analysis and mission critical analysis
adopts a pragmatic approach by putting into practice, as a continuous effort with all levels
of industry participants, timely and cost-effective obsolescence engineering practices,management tools, methods and practices to avoid the negative effects of obsolescence inthe program
prepare obsolescence risk mitigation strategies for their incorporation in the Statement ofWork (SOW) for all provisioning contracts during the system life cycle
detail OM data requirements clearly within the statement of work and rights of access are
addressed during commercial negotiations
determines the obsolescence status of parts before its procurement
All stakeholders plan the most cost effective time scales for in service technology
updates/upgrades (technology road maps), managing obsolescence in existing equipment
to extend their service life (this has to be in line to the logistics and also to the necessary
qualification/certification processes)
Apply practices already taken in other programs for obsolescence mitigation whenever it isdeemed convenient and cost-effective

It is imperative that the Invitation to Tender for all phases of a program includes the requirement
for an OM plan. The format and contents of the plan may be left to the discretion of thecontractor but must as a minimum conform to the requirements of a recognized standard.
Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

Intellectual property rights must be considered with regard to OM and in particular to ensure
access to data required to support the OM strategy. The requirements of OM should also be
considered in the context of an exit strategy, to ensure that all the data necessary to manage
obsolescence is available in the event of a contract break.
One commercial strategy, which may be employed, is to pass responsibility for the managementof obsolescence to the contractor completely. This hands-off solution can be adopted and in its
simplest form consist of paying a fixed price to solve any future obsolescence arising. This is
not at all an optimal technical solution but rather a more commercial or contractual approach,passing all liability for future obsolescence cases to industry during a specific period of time. In
some cases, this could be accompanied by a redistribution of payment plan by putting forward
some payments in order to cover potential obsolescence arising during a specific period of time.
There are certain drawbacks to this approach. Although “risk is being transferred to thecontractor” for a fee, care must be taken to ensure that there is at least limited visibility from thecustomer side so that he can see where action is being deferred or risk carried. These decisions
could impact the customer on contract closure. Alternatively provision should be made toaddress obsolescence risk at the approach to contract conclusion, if this is achievable. In
addition, during the fixed price negotiation, it may be difficult to justify or investigate costs unlessthe contractor proposal is supported by a detailed risk based obsolescence costed analysis.

5Conclusion
There are many causes of obsolescence. The loss or impending loss of manufacturers or
suppliers of critical items, raw materials, intellectual resources, exponential costs of scarce partsand materials, rapid changes in technology, uneconomical production requirements,
competition, environmental or safety legislation all impact the sustainability of a product during
it’s life cycle. OM is an activity intended to minimize the impact of this potential loss of supply
through the identification, quantification and resolution of obsolescence and aims to achieve
optimum cost-effectiveness. OM focuses on the system-wide application of risk management
and is applicable to the entire program life cycle, becoming an integral part of the design,development, production and inservice support phases of the program.

S3000L-A-15-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-15-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 15
2010-04-01 Page 8

S3000L-B6865-03000-00

Chapter 16
Inservice data feedback
Table of contents

Page

Inservice data feedback ................................................................................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
1.1
Introduction ...................................................................................................................... 1
1.2
Objective .......................................................................................................................... 2
1.3
Data sources.................................................................................................................... 2
2
Data usage ...................................................................................................................... 3
3
Conclusion ....................................................................................................................... 3

List of tables
1

References ...................................................................................................................... 1

List of figures
1

Acquisition logistics main business processes ................................................................ 2

References
Table 1 References
Chap No./Document No.

Title

S1000DInternational specification for technical publications using
a common source database

S2000M

International specification for material management

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

S5000F

International specification for operational and maintenancedata feedback

1

General1.1

Introduction
The feedback of inservice data is one of the most important functions of inservice support.
It enables fleet and support managers and defense system manufacturers to perform athorough analysis of operational and maintenance performance of a product.
The results of this analysis can be the basis for−−enhancement of the operational effectiveness
improvement of the product by modifications and retrofit activities

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

1.2

Objective
This chapter should be used as guidance to establish the requirements for and the importanceof the of inservice operational maintenance data.
S5000F – Operational & maintenance data feedback

LSA data
Equipment
identification
Designdata

Provisioning

Logistic
SupportAnalysis

Logs
Mat
and
data

Order
Administration

S2000M
IP datasubsets

LSA tasks / data

S3000L S4000M

Provisioning
dataTechnical
Documentation

IETM,
other
media

In service operation

Design of systems andsupport equipment

OPS data

Design data

S1000D

ICN-B6865-S3000L0065-001-01
Fig 1 Acquisition logistics main business processes
The feedback of inservice data is an essential element in any Integrated Logistics Support (ILS)
program. The data feed from inservice operations and maintenance has many uses. The data
forms the basis for the empirical validation, update and correction of the theoretical, calculated
and predicted values that have been established within the Logistic Support Analysis (LSA)
activities. The values measured through the inservice operation of the product can be used toverify and update the values in the LSA to ensure that the LSA stays current with the actual
operation of the product.

1.3

Data sources
The following are examples of inservice data that can be used to update existing Logistic
Support Analysis programs. This can be through updates to the Failure, Modes Effect andCriticality Analysis (FMECA), adjustments to the maintenance schedules, update and revision tomaintenance tasks:
−
−
−
−
−
−
−
−
−
−
−
−
−

Location of repair and operating environment
Operational environment
Operational regime
Maintenance level
Skill level/Shop that performed the repair
Maintenance man hours and elapsed time
Failure/Damage cause
Induced failures/damage
Operational condition or type of mission when the failure occurred
Repair actions taken
Materials consumed
Replacement parts
Field service reports (maintainer/customer feedback, support equipment
performance/accuracy, etc)

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

2

Operator reports/debrief
Equipment availability incident
Troubleshooting data (includes unresolved failure detection – cannot duplicate)
Failure rates
No defect rates
Item identifier (part number, serial number, configuration, version)
Item configuration (service bulletin, in service modifications, retrofit, etc.)
When discovered (used to verify and optimize maintenance intervals)
Sampling study (in service observation/tracking)Accumulated flight and/or operational hours
Reason for action
Fault symptoms or indication of failure
Inventory/Location of material/parts/hardware
Logistics downtime – administrative delays
Logistic delays
Supplier/Provider feedback
Data cleansing/validation of in service data
Warranty information
Customer local directives/work around/interim proceduresTechnical publication change requests

Data usage
Analysis and compilation of In Service Feedback data may provide a means to:
−
−
−
−
−
−

3

Accurately define/forecast spares provisioning at all maintenance levels
Justify the need for scheduled/preventative maintenance task. The cycle of an existing task
can be updated from in service data using a sampling program.
Update manpower requirements & staffing levels
Correct the required quantities of support resources
Update other maintenance planning related documents
Identify items that may require product improvement

Conclusion
The feedback of inservice data is not only for logistic analysis purposes. The data that is
captured inservice is also used for fleet planning and management, product liability andwarranty claims, material and stock forecasting and provisioning.
The overall aim to be achieved through inservice data feedback is to increase of availability ofthe product and optimize its effectiveness and to establish better information and data for futurecontract and programs.

S3000L-A-16-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-16-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 16
2010-04-01 Page 3

S3000L-B6568-03000-00

Chapter 17
Disposal
Table of contents

Page

Disposal ......................................................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Disposal tasks during Product life cycle phases ............................................................. 4
2.1
Concept definition phase ................................................................................................. 4
2.2
Development phase ......................................................................................................... 4
2.3
Inservice phase................................................................................................................ 5
2.4
Disposal phase ................................................................................................................ 53
Disposal analysis ............................................................................................................. 5
3.1
Disposal analysis activities .............................................................................................. 6
3.1.1
Define a disposal strategy ............................................................................................... 6
3.1.2
Integration of disposal requirements in design ................................................................ 6
3.1.3
Disposal method analysis ................................................................................................ 7
3.1.4
Hazards ........................................................................................................................... 8
3.1.5
Configuration management ............................................................................................. 8
3.1.6
Monitor and control of sub-suppliers ............................................................................... 8
3.1.7
Task Input ........................................................................................................................ 8
3.1.8
Task output ...................................................................................................................... 9
3.2
Disposal operation task identification .............................................................................. 9
3.2.1
Disposal process breakdown analysis ............................................................................ 9
3.2.2
Task identification .......................................................................................................... 10
3.2.3
Disposal hazard analysis ............................................................................................... 10
3.2.4
Task input ...................................................................................................................... 11
3.2.5
Task output .................................................................................................................... 11
3.3
Level of disposal analysis .............................................................................................. 11
3.4
Disposal task analysis ................................................................................................... 11
3.4.1
Task description............................................................................................................. 11
3.4.2
Task input ...................................................................................................................... 12
3.4.3
Task output .................................................................................................................... 12
4
Product disposal file ...................................................................................................... 13
4.1
PDF content ................................................................................................................... 13
4.2
PDF compilation process ............................................................................................... 13
4.3
PDF data elements ........................................................................................................ 15
5
List of regulations........................................................................................................... 18
5.1
European Union directives ............................................................................................ 18
5.2
Transportation regulations ............................................................................................. 18
5.3
Support equipment and ground equipment ................................................................... 18
5.4
Navy equipment ............................................................................................................. 19
5.5
Air equipment................................................................................................................. 19
5.6
Ammunition .................................................................................................................... 19
5.7
Nuclear waste ................................................................................................................ 20

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

List of tables
1
2
3
4
5
6

References ...................................................................................................................... 2
Residual product .............................................................................................................. 8
Risk score example ....................................................................................................... 10
PDF data elements ........................................................................................................ 15
Environment aspect codes ............................................................................................ 16
Websites for additional information concerning disposal .............................................. 20

List of figures
1
2
3
4

LSA aspects of disposal analysis process ...................................................................... 6
Disposal analysis activities .............................................................................................. 6
PDF compilation process ............................................................................................... 14
Example of a PDF (for a given subsystem of a Product) .............................................. 17

References
Table 1 References
Chap No./Document No.

Title

None

1

General1.1

Introduction
Disposal is both a business process and the name of a phase in a product life cycle. This
chapter describes the disposal business process.
Regarding disposal, it is no longer acceptable to dump worn out equipment into the sea or
anywhere else that might allow it to cause harm to human health or the environment. Disposal
needs to be performed in a controlled manner that does not impact human health and does notcause the contamination of land, water or air.
It must be stated that:−−

disposal is an event that occurs only once during a product life cycle. Once disposed, theproduct no longer exists
the probability that disposal will actually occur is 100%, at some point in some mannerThis leads to the conclusion that disposal requirements must be implemented into the designfrom the very beginning of a development program. The general disposal principles to be
applied are:−−to have as much material as possible to be recycled
to minimize landfill waste resulting from the product’s lifecycle

Therefore, disposal must be considered as one of the major business processes to be
implemented within the framework of an ILS/LSA program development strategy.
To dispose of a product means to phase it out at the end of the product's service life. This
paragraph deals with disposal of products. Typically the disposal of products happens during
the last phase of their life cycle, however, disposal must be considered from the very earlyphases of every program that acquires a product.
Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

1.2

PurposeThis chapter provides guidance for developing a disposal procedure applicable for a product(existing or under development), that can be demonstrated to be safe, efficient, environmentally
acceptable and cost effective.
It also provides guidance to analyze required operations and disposal tasks for the equipment
to:
−
−
−
−
−
−
−

1.3

Identify logistic support resource requirements for each task
Identify new or critical logistic support resource requirements
Identify transportability requirements
Identify support requirements that exceed established goals, thresholds, or constraints
Provide data to support participation in the development of design alternatives to reduce
disposal costs and optimize logistic support resource requirements
Provide guidelines on what must be done during each product phase and how to properly
measure the effort
Provide source data for the preparation of required ILS documents (eg disposal
instructions, training program, manpower and personnel lists)

Scope
Due to growing concerns, disposal activity must consider the following issues:−−−

Destruction/neutralization of toxic substances such as carcinogenic, mutagenous,
reprotoxical that harm humans or the environment for short or long periods of time (egchemicals, radioactive substances)
Allow a sustainable development by recycling materials (eg reuse of assemblies, rawmaterial) or converting them into energy (eg burning with toxic gas processing)
Demilitarization of defense products to avoid weapons proliferation and use by terroristgroupsThis applies to:−−the product disposal at end of the service life
the waste generated throughout the product operation life cycle including, but not limited to:
•
•
•
•
•
•
•
•
•
•
•
•

−

Ozone depleting substances (CFC, HCFC, halons)Global warming effect (sustainable development)
Health care waste and sanitary waste
Stores (eg paints, solvents)
Ballast water and sediments
Anti-fouling paints (eg biocides)
Oily bilge water (sludge)
Wastewater (black and grey water)
Galley food waste
Solid waste (eg glass, paper, plastics)
Exhaust emissions (eg NOx, SOx, COx)
Spares and consumables (eg batteries, nuclear sources, oils)

All of the resources deployed and used to operate and support the mission product (eginfrastructures, facilities, support equipment)

The disposal process impacts the product’s following phases:−

Operation and Support phase••

Take the necessary provisions to design safe Operation and Support tasks against
dangerous substances contained in the product,
Disposal process of consumables and items removed as a result of performance ofOperation and Support tasks (health and environment impact limitation).

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

This information shall be available in the LSA database and in the product’s technicalpublications (Operation and Support tasks).
−

Disposal phase•••

Dismantling a disassembling
Demilitarization
Dispose of products (eg energetic recovery, material recovery, re-use, landfill waste)This information shall be available in Product Breakdown Structure (PBS) and ProductDisposal File (PDF).

2

Disposal tasks during Product life cycle phases

2.1

Concept definition phase
A product disposal strategy is created along with a concept of operation and a support policy.
This strategy must make provisions to appropriately address the following:
−
−
−
−
−

2.2

Sustainable design to limit the use of scarce resources, and the environmental impact of
product disposal
Identification of health and environmental regulations that are applicable (refer to Para 5)
Identification of the list of black and grey substances that will be respectively forbidden andlimited in use and quantity
Definition of the method for tracking the dangerous substances, applicable in house andflowed down to suppliers
Estimate of the Rough Order of Magnitude of product disposal cost

Development phase
The disposal activity during development phase is twofold:−

Design the disposal
This includes all plans made during the product design in a sustainable development
approach, such as limiting the use of scarce resources, reducing the environmental impactof Product disposal (eg no toxic substances, identification of materials for easy recycling).
For this, a PDF is compiled (refer to Para 4).
Cancerigenous, Mutagenous, Reprotoxical substances used in the product design arerecorded in the Product breakdown as part of Product Data and Configuration Management(CM). Chemical substances are identified by their Chemical Abstract Substance code (orequivalent), according to the REACh European regulation requirements.
As the product design matures, the PDF information is updated.

−

Dispose of the design
This includes all plans made during development to further prepare for product disposal
phase. It includes the following:••

Perform a product dismantling task analysis, where tasks required to dispose of the
Product are identified and characterized (eg tasks duration, required resources).
This work can be considered as an extension of the Maintenance Task Analysis (MTA)
performed as part of the product Logistic Support Analysis (LSA), using the samestructured approach.
Assess the impact of disposal on product logistic support elements such as additional
support equipment required to perform the product disposal, describe the disposal
tasks in the technical publications, training courses to teach operators how to disposeof the product (including health and safety cautions).

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00•

2.3

Estimate the cost of the product disposal. This work can be a part of the product global
Life Cycle Cost (LCC) analysis work, using the same structured approach.

Inservice phase
During this phase:−the PDF is updated to take into account the following:
•
•

−
−

Design changes in the product during its phase of Operation and Support
Evolution of applicable regulations (eg new banned substances, strengthening ofhealth and safety)

resources required for product disposal are produced and delivered
disposal demonstration can be performed on product prototypes to validate:••

Relevancy and completeness of information compiled in the PDF.
Dismantling and disposal operations (eg people skills, technical publications contents,
support equipment adequacy)

Equipment to be replaced (eg batteries, oils) according to the maintenance plan must be
disposed of in compliance to disposal requirements identified in the disposal analysis performed
during the previous product life cycle phases.

2.4

Disposal phase
During this phase:−−

The disposal strategy defined during the concept definition phase is implemented todispose of the product (eg dismantling, recycling, energetic valorization)
The disposal operations are facilitated due to:
•
•

−

3

A product design that is disposal oriented (design the disposal)
An available set of resources developed in order to perform the product disposal(dispose of the design)

Lessons learned are collected (eg cost, best practice, things to avoid) to be fed back toother programs

Disposal analysis
As shown in the figure below, the LSA activities logic to determine the disposal process,disposal tasks, and support resources required, starts with the disposal analysis that needs tobe tailored to the program.
This analysis applies to both:−−

Product subassemblies to be disposed of all along the product life cycle, as a result of the
product maintenance plan implementation
The entire product, at the end of its operational life

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

Stakeholder
requirements

LSA
sub processes

Recommended
design objectives

PBS

Disposalrequirements

Disposalcriterias

Material safety
data sheets

ISO/IEC 15288
Processes outside of LSA

Disposal analysis

Disposal operations task identification

Level of disposal analysis(disposal concept)

Disposal task and support resources analysis

ICN-B6865-S3000L0089-001-01
Fig 1 LSA aspects of disposal analysis process

3.1

Disposal analysis activities
This paragraph describes the LSA activities to be considered and tailored for the disposal at theend of a product’s life. The task logic of the disposal analysis can be illustrated as given in Fig
2:

Define adisposalstrategy

Integration of
disposalrequirements into
the design

Disposal
methodanalysis

Configuration
management

Subcontractor
monitoring
and control

ICN-B6865-S3000L0090-001-01
Fig 2 Disposal analysis activities
3.1.1

Define a disposal strategy
Define the disposal criteria for each item in the PBS and establish a Design Solution.

3.1.2

Integration of disposal requirements in design
Upon the development of a new product, the disposal requirements must be balanced against
those for performance, reliability, safety and life cycle cost.
The design principles shall be a guide for design work and design considerations. Materials
used in the design of the product and its packaging shall be selected to meet planned service
life requirements.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

3.1.2.1

Recommended materials
Materials to be used in the design of the product and its packaging shall be selected tominimize:−−−hazards to personnel or property during preparation for disposal
hazards to personnel, property or the environment as a result of the processes used indisposal
residual hazards from the products of the disposal process

All materials shall be fully specified, along with their associated hazards, in their primary stateand during the stages of the disposal process. Material identification and marking processes
must be defined. This information should be recorded in the PDF (refer to Para 4).
3.1.2.2

Accessibility and extraction of components and hazardous materials
Provide design recommendations with requirements for a minimum of non-standard processes,
tools and technical expertise for access and extraction, and identify any non-standard
processes or tools needed for access to components and hazardous materials, as well as any
hazards associated with such processes.

3.1.2.3

Select components and materials to facilitate safe recovery and recycling
Identify the components and the base materials likely to be recovered from the product and theirpotential for recycling. The assessment shall consider the possibility of degradation andcontamination of components and materials during their service life such as to render recovery
and recycling no longer viable.

3.1.2.4

Complete material list
List all materials used in the product in a supplier material list and make it available to all
personnel it may concern in the program. As a minimum, the list shall include, but not be limited
to:
−
−
−
−
−
−
−

3.1.3

Components
Materials
Compatibility aspects
Residual products used by the productResidual products at planned disposal
Impact on the environment at planned disposal
Applicable health and environmental regulations

Disposal method analysis
1 Identify potential alternative applications (re-use) for the product, sub-products, assemblies
and components, including software. Demonstrate that they are technically achievable,
environmentally acceptable and economically viable
2

Identify components and material that must be recycled

3

Identify components and material that must be recovered

4

Identify components and material that will be land waste

5

For each alternative above, define the residual products. Refer to Table 2.

6

Document the results in a disposal PBS

7

Disposal of sensitive information
When products to be disposed of contain proprietary, confidential or classified software anddata, the dismantling procedure shall include the two following steps:
7.1 The transfer of the necessary historical information to a media or other storage device
for proper preservation or historical archiving,

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

7.2 The destruction of the data/software media or the erasure of the sensitive, proprietary,and classified information and software in an adequate manner so as to ensure thatsuch information/software cannot be recovered by third parties, in accordance with theproper security regulations.
Table 2 Residual product3.1.4

Re-useable/
recyclable [g]Combustible [g]Waste [g]Accumulated
weight [g]

Sum

20

2000

3000

5020

Hazards
Identify all hazards associated with the design and in particular:
−
−
−
−
−

3.1.5

Residual
products

Provide an estimate of the likely levels of noise, flash, and toxic or corrosive fumes
produced upon operation/firing/launching.
Identify any disposal activity hazards associated with the product design that requires
additional safety arrangements other that the existing disposal resources.
Identify any residual hazards from the disposal of the product that requires additional safety
arrangement other than the existing disposal resources.
Consider possible means of fail safe.
Identify any features that might pose an unusual hazard to Explosive Ordnance Disposal
operatives, for example, anti-tampering/interference fuses or energetic materials withparticularly high levels of sensitivity. This assessment must consider the effects of aging on
the product.

Configuration management
For any component/design change, assess its impact on the:−−product life extension
reduction of health and environment hazards

and demonstrate that such changes are both technically achievable and economically viable.
3.1.6

Monitor and control of sub-suppliers
Product elements obtained from suppliers shall meet the disposal requirements. This effort
applies to equipment obtained from any supplier, regardless of tier. Review all sub-suppliercontracts and perform evaluations of their disposal procedures.
If Government Furnished Equipment is used, they shall be treated as ordinary sub-supplier
items. The same requirements shall be applied as for those suppliers.
During the subsequent phases of the development program, sub-supplier specifications shallincorporate aspects such as:
−
−
−

3.1.7

Disposal requirements
Design constraints and requirements
Material Safety Data Sheets (MSDS)

Task Input− Disposal strategy− Disposal requirements− Disposal criteria− PBS− MSDS detailing:

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

•

•
•
•
•
•
•
•

•
•
•
•
•

The product name used on the label, and chemical and common names of ingredients
which have been determined to be health hazards, and which comprise 1% or greaterof the composition, except carcinogens shall be listed if the concentrations are 0.1% or
greater.
The chemical and common names of all ingredients which have been determined topresent a physical hazard when present in the mixture.
Relevant physical and chemical characteristics of the hazardous chemical (such asvapor pressure, flash point).
Relevant physical hazards, including the potential for fire, explosion, and reactivity.
Relevant health hazards, including signs and symptoms of exposure, and any medical
conditions generally recognized as being aggravated by exposure to the chemical.
The primary routes of entry into the body.
The Occupational Safety and Health Administration permissible exposure limit andAmerican Conference of Industrial Hygienists threshold limit value. Additional
applicable exposure limits may be listed.
Whether the hazardous chemical is listed in the National Toxicology Program Annual
Report on Carcinogens (latest edition) or has been found to be a potential carcinogenin the International Agency for Research on Cancer Monographs (latest editions), or by
Occupational Safety and Health Administration.
Precautions for safe handling and use, including appropriate hygienic practices,protective measures during repair and maintenance of contaminated equipment, andprocedures for clean-up of spills and leaks.
Appropriate control measures, such as engineering controls, work practices, or
personal protective equipment.
Emergency and first aid procedures.
The date of preparation of the MSDS or the last change to it.
The name, address and telephone number of the chemical manufacturer, importer,
employer or other responsible party preparing or distributing the MSDS, who canprovide additional information on the hazardous chemical and appropriate emergency
procedures, if necessary.

3.1.8

Task output− Scope of the disposal business process to be applied.
− A disposal PBS list, detailing which items should go for re-use, recycling, recovery or landfill
waste.

3.2

Disposal operation task identification

3.2.1

Disposal process breakdown analysis
Define a representative set of activity sequences to identify all required services that correspondto anticipated disposal process of a product and environments.
The task shall list the method recommended for disposal of the product items. Disposal involves
two aspects:−−

Dismantling the productDisposal of materials and contaminated items, including contaminated solvents

A breakdown of the recommended process shall be updated as details of the design become
available.
This requires the use of the following data elements:−−

a disposal task code
disposal recovery codes for the Source Maintenance & Recoverability (SMR) code, coding
for the method by which the product is intended to be disposed of (eg recycled, energy
recovered, landfill waste)

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6568-03000-00

3.2.2

Task identification
Identify and document the operations/tasks that must be performed for disposal of theequipment. These tasks shall be identified to a level commensurate with design, including
disassembly diagrams, step-by-step procedures, safety precautions and component andmaterial tables, taking into account possible changes due to aging, and final destination of all
products. Any special tools and equipment required and any limitations on locations are to be
identified.
A task inventory shall be prepared for the equipment. This task inventory shall identify all tasks
that operators, maintainers, or support personnel must perform with regard to disposal of theequipment (hardware and software) based on the disposal process breakdown analysis, andscenarios/conditions. Tasks shall be identified to a level of detail commensurate with design andthe disposal scenario development. The task inventory shall be organized in terms of a task
classification which defines scenario/conditions, function, job and duty, task and subtask andtask elements. The task inventory shall be composed of task descriptions, each of which
consists of:−−

An action verb which identifies what is to be accomplished in the task
An object which identifies what is to be acted upon in the task

Task descriptions shall be clear and concise. Hazardous materials, generation of waste, releaseof air and water pollutants and environmental impacts associated with each task shall beidentified. Where the same task appears in the duty of more than one job, and is therefore
identified in a collective task for training purposes, it will be identified as such within the task
inventory. All verbs shall be unambiguously defined within the task classification.
3.2.3

Disposal hazard analysis
The hazard analysis of the chosen disposal process shall identify the hazards related to theprocess and its products, and shall quantify the associated risks. The results of the analysis canbe presented using a matrix, where the risk scores are:−−−Serious = 2
Moderate = 1
Harmless = 0
Table 3 Risk score example

Risks

Type of Risk

WeightHazards from planned disposal
process

Total(Risk x Weight)

2

Safety3

Detonation of warhead at
dismantling of missile

6

1

Health3

Toxic gases produced at burning oflaunch rocket motor propellant

31

Environmental

2

Environmentally polluting gases
2
produced at burning of launch rocket
motor propellant.

The hazard analyses of the product shall include a description of the product with its
configuration. The composition and mass of each material shall be listed along with anaggregate mass of all materials in the item. The hazards associated with each material shall beidentified along with any special handling requirements as follows.
Both primary hazards and secondary hazards (those derived from material changes that occur
as a result of the processes used in disposal) shall be described in the analyses. All materials tobe transported shall be accompanied by safety data sheets.
Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6568-03000-00

Risks to be listed and considered are, for example:−

Explosive hazards
Risks associated with explosive materials in the product−

Fire hazards
All flammable and oxidizing materials−

Caustic hazards
All caustic materials−

Ingestion, absorption, inhalation and adsorption
All materials that have a physiological effect on personnel or may damage property. The list
shall indicate the physical form of the material, the means of attack and the protection
required−Trauma inducing
All non-explosive energy stores such as batteries, electrical and electromagnetic generating
devices, capacitors, sources of static charge, springs under tension or compression, andany material that can transfer energy upon release, sufficient to cause trauma. The list shallindicate likely energy output, likely effect and the protection required−

Environmental hazard
Any potential environmental hazard not already covered. These shall include potential
damage to the atmosphere, soil and groundwater

3.2.4

Task input− Delivery identification of any data item required.
− Identification of equipment hardware, software and firmware on which this task will be
performed and the indenture levels to which this analysis will be carried.
− Identification of the levels for disposal of hardware, software and firmware which will beanalyzed during performance of this task to identify operations and tasks.
− Any documentation requirements over and above the LSA database, such as functional
flow diagrams or drawings.
− Description of equipment concepts under consideration.
− Disposal method (disposal PBS).

3.2.5

Task output− A task inventory documented in the LSA database, or equivalent format approved by the
project, identifying disposal operational tasks requirements, to include task descriptions on
Product hardware software and firmware and to the indenture levels specified by the
project.
− Identification of any hazard risks involved in satisfying the disposal operational tasks
requirements.

3.3

Level of disposal analysis
The level of disposal will be driven by the hazardous substances location in the productbreakdown. The product must be dismantled and disassembled to a level of subassemblies
which can be disposed of using the same disposal method as defined in Para 4.

3.4

Disposal task analysis

3.4.1

Task description− Conduct a detailed analysis of each operation, maintenance and support task contained in
the task inventory and determine the following:

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6568-03000-00

•
•
•
•
−

−
−

3.4.2

Identify new or critical logistic support resources required to perform each task, and thehazardous materials, hazardous waste and environmental impact requirements associatedwith those resources. New resources are those which require development in order todisassemble the new equipment. These can include support and test equipment, facilities,
new or special transportation products, new computer resources, and new test or
inspection techniques. Critical resources are those which are not new but require special
management attention due to schedule constraints, cost implications, or known scarcities.
Unless otherwise required, document new and modified logistic support resources in the
LSA database, or with equivalent documentation approved by the project, in order toprovide a description and justification for the resource requirement.
Conduct a transportability analysis on the equipment and any sections thereof when
sectionalization is required for transport.
Document the results in the LSA database, or by an equivalent format approved by the
project.

Task input− Identification of equipment hardware and software on which this analysis will be performed− Identification of indenture levels to which this analysis will be performed− Identification of the levels of disposal operations that will be documented duringperformance of this task
− Known or projected logistic support resource shortages− Any supplemental documentation requirements over and above the LSA database (egtransportability clearance diagrams)− Delivery identification of any data item required− Information available from the project relative to:
•
•
•
•
•
−
−
−
−

3.4.3

Logistic support resources required (considering all ILS elements) to perform the task.
Elapsed time and man-hours of the equipment intended disposal facility/environment.
Maintenance level assignment based on the established support plan.
Environmental impact of the tasks, including use of hazardous materials, generation of
hazardous waste and its disposal, and the release of air and water pollutants.

Existing and planned personnel skills, capabilities, and program of instruction
Lists of standard support and test equipment
Facilities available
Training devices available
Existing transportation products and capabilities

Description of personnel capabilities (target audience) intended for disposal of theequipment at each level of disposal
Operations and disposal task requirements from task (disposal operations task
identification)
Recommended disposal plan for the equipment from task (level of disposal analysis)
Supportability and supportability related design goals and requirements

Task output− Completed LSA database on equipment hardware and software to the indenture levelspecified by the project, or equivalent format approved by the project.
− Identification of new or critical logistic support resources required to operate and maintainthe new product.
− Alternative design approaches where tasks fail to meet established goals and constraints
for the new equipment or where the opportunity exists to reduce disposal costs or optimize
logistic support resource requirements.
− Identification of management actions to minimize the risks associated with each new or
critical logistic support resource requirement.
− Validation of key information documented in the LSA database.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6568-03000-00−−

4Output summaries and reports as specified by the project containing all pertinent datacontained in the LSA database at the time of preparation.
An LSA database that is updated as better information becomes available and as
applicable input data from other product engineering programs is updated.

Product disposal file
The Product Disposal File (PDF) is intended to compile all data information regarding productdisposal. It must be updated throughout the product lifecycle in order to reflect product changes(configuration management), maintenance plan evolutions, and health and environmental
regulations modifications.
This file must allow the product program management to clarify the operational limits of theauthorized substances over a given period, in order to anticipate the research of alternative
solutions which are more suitable in terms of:
−
−

4.1

Sustainable development
Health and safety impact on humans and environment

PDF content
Whatever the product, the PDF may compile information such as, but not limited to thefollowing:−−−−

Product breakdown and associated functional and physical description.
Related to the product breakdown (with illustrations wherever possible), identification ofcomponents, products or ingredients (eg containing hydrocarbon, lubricating, paintings).
For each dangerous substance identified in the product, list of the risks for people andenvironment.
For each type of product subassembly, according to the type of technology (eg electronic,
mechanic, hydraulic and pyrotechnic) and the contained substances, identify their possible
processing at disposal.
•
•

−
−
−
−
−
−
−

4.2

those immediately reusable on another productthose containing high value material (eg gems, precious metals)

The methods of elimination that will make the difference between potentially harmful
substances and harmless material.
Conditions for disassembly and the destination of the components (eg re-use, recycling,energetic valorization).
The procedures of disassembly down to the required level of depth, such that all thematerials (including in particular those harmful or dangerous) can benefit from theprocessing and their mode of elimination.
The rules, instructions, measurements or provisions to apply that guarantee safe practices
at a sufficient level.
The collection of all safety data for all the harmful or dangerous materials composing theentire product.
The procedures for dismantling and disposal, detailed step by step.
A list of proposed organizations certified for proper recycling and elimination of thedangerous residues, according to the applicable regulation.

PDF compilation process
The PDF compilation process is shown in the flowchart given in Fig 3:

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6568-03000-00

Type of ProductInitialize the PDF
compilation

Disposal data
elements initialization

Product design status

No

PDF
already
exists?

- Disposal strategy- Product description- Dismantling process

Yes

No

Product design andconfiguration file

Yes

Dangerous substances
identification andcharacterisation

Disposaldata elements alreadyexists?

Yes
Product
designchange?

No
Product Disposal File

- Disposal strategy- Product description- Dismantling process- Disposal information- Dangerous substances
identification and characterisation- Product design and configuration

ICN-B6865-S3000L0091-001-01
Fig 3 PDF compilation process

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6568-03000-00

4.3

PDF data elements
This paragraph presents a proposed list of data elements to be compiled in the PDF. This list is
not limitative, and must be agreed to on a case by case basis, depending upon the context ofeach specific program and contract.
Key of PDF Columns Header
Text in italic refers to data elements from the S3000L standard database
Table 4 PDF data elements
HeaderMeaning

Subsystem
Assembly identifier

Identifies the subunit to which the item belongs in the ProductPart_identifier

Item
Part nameName of component according to drawing
Part_name

Article number
Part number

Refers to drawing No. for unequivocal identification or (for somecomponents such as screws and adhesives) other article number
Part_identifier

Material Denomination
Material description

Short description of material in component (if known)
Part_material_description (ADD Material Class TO THE MODEL)CatMaterial Category

The main substances category : black (forbidden), grey (authorizedwith limitation), green (authorised with no limitation)(Include date when recorded)

CAS
Material Code

Chemical Abstract Substance identification number(Material hazardous classification)

Phrase of Risk
Type of Risk

Phrases of risk (as per REACh regulation safety Data Sheet data)
Risk_description associated with the Material class

MSDS ref.
MSDS

Reference of the associated Material Safety Data Sheet
Document classified as ‘Material Safety Data Sheet, assigned to theMaterial Class in the role of ‘Reference’

Service life
Service life

Product service life
Minimum_product_service_life associated with Part

Mass (g)Mass

Weight of component (in grams)
Quantity of material included in PartReg.
Regulations

Applicable environmental regulations
Document assigned in the role of ‘Regulation’

SLA No.
Serial Number

Serial number of component
Material included in a specific serial number range for the Part

Risk factor (SLA)
Risk Criticality

Judged risk factor (criticality) of component (1 to 4 scale)
Risk Criticallity

Critical property
Justification

The most important property for the function of the component
Material_justification_description associated with Material usage Part

Proceedings inconnection with use
Disposal concept inuse

Describes how the component is to be disposed of during theinservice phase
Derived from any of eg Data_module or Task_overall_description or
Task_requirement_specification (related to the Part)

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6568-03000-00

HeaderMeaning

Proceedings inconnection withplanned disposal
Disposal concept endof life

Describes how the component is to be disposed of during planned
disposal

Waste products inconnection with use
Waste products in use

States the waste products when the component is disposed ofaccording to the procedure during use or after being used
Narrative related to the Part

Waste products inconnection withplanned disposal
Waste products
disposalStates the waste products when the component is disposed ofaccording to the procedure for planned disposal.

Derived from any of eg Data_module or Task_overall_description or
Task_requirement_specification (related to the Part)

Narrative related to the Part

Environmental aspects, Classification of environment aspects during use. Refer to codes inusethe "Environment aspect codes" table below
Environmental aspects Classification related to Partin useEnvironmental aspects, Classification of environment aspects at end of life. Refer to codes inplanned disposal
the "Environment aspect codes" table below
Environmental aspects Classification related to Partend of life
Task

Dismantling tasks characterization and description, identifying
required resources and associated safety cautions to be taken topreserve human beings and environment.
Task_requirement_specification

Task requirement
Last updated
SLA/Environ
Date

Date of latest changes SLA respective environmental partMaterial_char.._recording_date

Table 5 Environment aspect codes
Code

Meaningtox

Harmful to environment according to note g and h in MBT04072.
(toxic, bioaccumulation and/or difficult to decompose)

acid

Acidification

ozon

Dangerous for ozone layer

gwp

Greenhouse effectmw

Material waste

pos

Environmental aspects, positiveeneEnergy regaining by burning

mr

Material recycling

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

Applicable to: All

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

64363172799541

Slotted
screw
MCS
M4x25

Connector
cover10363883

Stainless
Steel ISO
1207

4113498

SupportStand

Adhesive

PC 10% glass
fibre Black5229068

Plug

Loctite 406

Aluminium EN
1706
AC42000-T6
ChromatedCr

PC 10% glass
fibre BlackPC 10% glass
fibre Black4113499

Outsidetube

Material
denomination(specification)

Articlenumber

Item
C
A
T

C
A
S
R
I
S
K

P
H
R

MSDS
ref.

Service
life

0

5,0

3,0

26.7

1.1

58.0

Mass
(g)
R
E
G

3

368

10

4

2

1

SLA
No.

4

2

1

4

4

4

R
I
S
K

S
L
A

Adhesion

Mechanicalstrength

Mechanicalstrength

Mechanicalstrength

Mechanicalstrength

Mechanicalstrength

Critical
Property(important forservice life
qualifi-cation)

ThrownThrownThrownThrownThrownThrownBurnedRecycling

Recycling

Burned/recycling

Burned/recycling

Burned/recycling

StableAl

SteelStableStableStable

COx,
NOx

Al

Steel

COx /PC

COx /PC

COx /PC

Planned/
Disposal

Use

Use

Planned/
Disposal

Waste products inconnection with

Proceedings inconnection with

mw

mw

mw

mw

mw

mw

Use

ene,
gwp,
acid,
ozon

mr

mr

ene,
gwp/mrene,
gwp/mrene,
gwp/mrPlanned
Disposal

Environmental
aspects

T
A
S
K

030130030301030130040327040327040327

Last
up-dated
SLA/
Environ

S3000L-B6568-03000-00

ICN-B6865-S3000L0092-001-01

Fig 4 Example of a PDF (for a given subsystem of a Product)

S3000L-A-17-00-0000-00A-040A-A

Chap 17

2010-04-01 Page 17

S3000L-B6568-03000-00

5

List of regulations
This list identifies international regulations for health, safety and environmental conditions.
The applicability status of the regulations will have to be defined on a case by case basis foreach specific program and contract.

5.1

European Union directives
−
−

−
−
−
−
−
−

5.2

The European Union directive (2002/96/EC), Waste from Electrical and Electronic
Equipment (WEEE) valid from 2006, may be used as a guideline stating target values for
Recovery, Recycling and Re-use.
Registration, Evaluation and Authorization of Chemicals REACh (Directive CE n°
2006/121/CE) concerning the recording, the evaluation and the authorization of thechemical substances, as well as the restrictions applicable to these substances, instituting
a European agency of the chemicals, modifying directive 1999/45/CE and abrogating theregulation (the EEC) N 793/93 of the Council and regulation (EC) N 1488/94 of theCommission as well as directive 76/769/CEE of the Council and directives 91/155/CEE,
93/67/CEE, 93/105/CE and 2000/21/CE of the Commission.
Directive 2002/95/CE of the European Parliament and the Council of January 27, 2003
relating to the limitation of the use of certain dangerous substances in electric andelectronic components.
PCB & PCT disposal (Directive CE n° 96/59/CE)
Asbestos ban (Décret 1996-1133) for France
Battery disposal (Directive CE n° 91/157/CEE)
Ozone depleting substances (Directive CE nº 2037/2000)
ROHS (Directive CE 2002/96)

Transportation regulations
Transportation of products recommended to be returned for safe disposal, needs to beapproved by national/state-run Competent Authorities which issues transport certificates stating
the components transportation classification based on the UN recommendation on the transportof Dangerous Goods ("orange book"). This international recommendation classifies dangerous
goods by type of risk involved, UN classification code, and product category codes, UN
Number.
The UN Number defines the packing group and packing instruction for the Product, maximum
weight of the package and how the package shall be labeled for each mode of conveyance.
Note that the packing itself need to have type approval issued by a Competent Authority.
The recommendations need to be tailored for transportation by road, railway, sea and air.
−−−−Agreement on Dangerous Goods by Road (Europe)
Regulations Concerning the International Transport of Dangerous Goods by Rail (European
law)
Dangerous Goods Regulations IATA - international recommendation for air transports
International Maritime Dangerous Goods (United Nations) for sea transports

The Transport certificates are often national and normally have a period of validity of a
maximum of 10 years. At the time for disposal, new certificates must be applied for at theCompetent Authorities concerned.

5.3

Support equipment and ground equipment
The PDF will be based upon the 2000/53/CE directive from the European Parliament and thecouncil relating to Vehicles out of use.
This directive is valid only for the civil vehicles of a weight lower or equal to 3,5 ton. This
directive will be used as a basis for the development of a future regulation which will include all
the civil and military vehicles. This directive envisages certain measures and incentives so that

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6568-03000-00

the phase of dismantling is taken into account from the start of the design of the equipment. It
will particularly be based upon new standards, established according to scientific evolutions.
The principal objective of this directive is the human, animal and environment protection, which
will be done by better Vehicles out of use management, whose base will be the compilation of adisposal file which will allow providing the adequate solutions for the assumption of the waste
responsibility or the use of less harmful replacement materials to the environment.

5.4

Navy equipment
The PDF should comply with the "green passport" requirements, whose principles are stated in
the A.962(23) resolution from the International Maritime Organization (IMO) of December 5,
2003, supplemented by the A.980(24) resolutions and especially the A981(24) resolution of
December 1, 2005, which is pressed on international texts into force such as the convention ofBasle about trans-border transfer of waste.
The A.962(23) resolution is an equivalent of 2000/35/CE directive applicable to the maritime
equipments of which one of the components is the "green passport", which is an instrument
intended to facilitate the operations of dismantling and recycling of any ship that arrives at theend of its lifetime by the adoption of good practices all for the length of the life cycle of the ship
(respectful of environment on the level of the dismantling site and making safe for the personnel
carrying out this work), the objective being a progressive reduction of the use of any dangerous
materials lasting the service life of the ship.
In order to have further information on the "green passport", we will refer to the NI 528
document published by Bureau Veritas.
The directives are intended to provide to the flag States, port States and re-user States, ownersof ships, manufacturers of ships, suppliers of navy material and recycling installations, several
indications on the "best practices", which take account of the ship recycling process throughout
the ship life cycle.
They take account of certain codes and protocols relating to the environmental protection.
The list of the substances to be tracked is based on the directive 67/548/CEE of the European
Parliament and the council, to which substances suggested by the states will be addedintervening for the drafting of the convention.

5.5

Air equipment
No regulation or guidelines has yet been set up worldwide to dispose of aircrafts at the end of
their service life.
However, the PDF could be compiled taking advantage of the PAMELA process: Process for
Advanced Management of End of Life of Aircraft.
This process has jointly been developed in 2005 by Airbus, SITA France, EADS JRC, EADSSOGERMA Services and the prefecture of the Hautes-Pyrénées in the frame of the LIFE("L'Instrument Financier pour l'Environnement" = The Financial Instrument for the Environment)
European environmental project.
This project makes it possible to characterize the best practices of aircrafts dismantling at theend of its lifetime in order to reach a rate of recycling of 85% from here 2008.

5.6

Ammunition
The PDF will comply with the STANAG 4518 edition 1 (2001) "Ammunitions disposal".
The goal of this NATO standardization agreement is to provide a common base to the NATOmembers on the principles and requirements of safety for the design and the evaluation
procedures in order to guarantee the safety of the operations of elimination of ammunitions.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6568-03000-00

5.7

Nuclear waste
Each state member of the International Atomic Energy Agency has its own standards tomanage nuclear waste.
However, the Agency released the three following documents (Safety Guides and information
Circular) addressing nuclear wastes safety:−−−

Environmental and Source Monitoring for Purposes of Radiation Protection (RS-G-1.8),
Management of Waste from the Use of Radioactive Materials in Medicine, Industry,
Research, Agriculture and Education (WS-G-2.7),
Code of Practice on the International Transboundary Movement of Radioactive Waste(INFCIRC/386)

Moreover, the Board of Governors approved a Safety Requirements publication, co-sponsoredby the Organisation for Economic Co-operation and Development/Nuclear Energy Agency(OECD/NEA), on geological disposal (WS-R-4).
For further information, here is a list of major websites:
Table 6 Websites for additional information concerning disposal
Site address

Organization

Francehttp://www.andra.fr/

National radioactive waste management agency

http://www.cea.fr/

French government-funded technological researchorganisation

http://www.asn.fr/

The French Security Nuclear Autority

USA
http://www.wipp.energy.gov/

Waste Isolation Pilot Plan

http://www.ocrwm.doe.gov/

Office of Civilian Radioactive Waste Management

http://www.energy.gov/

USA Department of Energy

http://www.nrc.gov/

USA Nuclear Regulatory Commission

http://www.epa.gov/

USA Environmental Protection Agency

Canadahttp://www.nwmo.ca/

Nuclear Waste Management Organisation

http://www.nuclearsafety.gc.ca/

Canadian Nuclear Safety Commission

Germany
http://www.bfs.de/Federal Office for radiation Protection

http://www.dbe.de/Company for the Construction and Operation of Waste
Repositories

Belgium
http://www.nirond.be/

ONDRAF : Belgium Agency for Radioactive Waste And
Enriched Fissile Materials

http://www.fanc.fgov.be/Federal Agency of Nuclear Control

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6568-03000-00

Site address

Organization

Finland
http://www.posiva.fi/

Nuclear Waste Management Expert

http://www.stuk.fi/

Radiation and Nuclear Safety AuthorityJapan
http://www.numo.or.jp/

Nuclear Waste Management Organisation of Japan

http://www.nisa.meti.go.jp/

Nuclear and Industrial Safety Agency

Switzerland
http://www.nagra.ch/

National Cooperative for the Disposal of Radioactive Waste

http://www.hsk.ch/

Division Principale de la Sécurité des installations nucléaires

Swedenhttp://www.skb.se/

Swedish Nuclear Fuel and Waste Management Co

http://www.ski.se/

Swedish Radiation Safety Authority

Europehttp://www.nirond.be/

ONDRAF: Organisme National des Déchets Radioactifs etdes Matières Fissiles enrichies

http://ec.europa.eu/

European Commission about human and environment safety

International
http://www.nea.fr/

Nuclear Energy Agency with 28 member states

http://www.iaea.org/

International Agency Energy Atomic with 144 member states

http://www.unscear.org/

United Nations Scientific Committee on the effects of atomic
radiation

S3000L-A-17-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-17-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 17
2010-04-01 Page 21

S3000L-B6568-03000-00

Chapter 18
Interrelations to other ASD specifications
Table of Contents
Interrelations to other ASD specifications ...................................................................................... 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 22
Benefits of Using the ASD specifications suite ................................................................ 2
2.1
Conceptual background of ASD specification ................................................................. 2
2.2
Integrated concept of operation ....................................................................................... 4
3Interrelation to S1000D .................................................................................................... 4
3.1
Purpose of S1000D ......................................................................................................... 4
3.2
S3000L/S1000D .............................................................................................................. 44Interrelation to S2000M ................................................................................................... 5
4.1
Purpose of S2000M ......................................................................................................... 5
4.2
S3000L/S2000M .............................................................................................................. 55Interrelation to S4000M ................................................................................................... 6
5.1
Purpose of S4000M ......................................................................................................... 6
5.2
S3000L/S4000M .............................................................................................................. 6
6Interrelation to S5000F .................................................................................................... 8
6.1
Purpose of S5000F .......................................................................................................... 8
6.2
S3000L/S5000F ............................................................................................................... 8

List of Tables
1

References ...................................................................................................................... 1

List of figures
1
2
3
4

Acquisition logistics main business processes (1) .......................................................... 3
Acquisition logistics main business processes (2) .......................................................... 4
Process overview from SMA tasks via LSA tasks to maintenance packages ................. 7
Traceability of scheduled maintenance ........................................................................... 8

References
Table 1 References
Chap No./Document No.

Title

Chap 1Introduction to the specification

DEX1A&D

Aerospace and Defense Product Breakdown for Support

DEX3A&D

Aerospace and Defense Task Set

S1000DInternational specification for technical publications using
a common source database

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

Chap No./Document No.

Title

S1003X

S1000D and S3000L interface specification

S2000M

International specification for material management

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

S5000F

International specification for operational and maintenancedata feedback

1

General1.1

Introduction
The S3000L should not be considered as a stand alone entity. In the environment of logistics,
there are existing AeroSpace and Defence Industries Association of Europe (ASD)
specifications which describe the development of technical documentation (S1000D) and define
the materiel management processes and procedures to be used in support of a product(S2000M). Also the new specification S4000M concerning Scheduled Maintenance Analysis(SMA) fits perfectly into the complete specification suite. The future specifications concerning
the handling of inservice data (S5000F) and a super ordinate specification concerning theIntegrated Logistic Support Management (SX000I) will complete the specification suite and thenwill cover the most important areas of product supportability.

1.2

Objective
This chapter provides an overview of how the existing ASD specifications and the S3000L will
be harmonized. It explains where the connecting point are and what benefits can be achievedby using the S3000L together with the other existing and well proven ASD specifications
S1000D, S2000M and the new specification S4000M.

1.3

Scope
This chapter is directed to logistics personnel who organize logistic analysis activities like an
Integrated Logistics Support (ILS) manager or a Logistic Support Analysis (LSA) manager. Theinterdisciplinary character of the logistic supportability should be highlighted by this chapter.

2

Benefits of using the ASD specifications suite

2.1

Conceptual background of ASD specification
The underlying basic concept for the development of a suite of ASD specifications in order tosupport the acquisition logistics main business processes was developed in early 1993.
During an international workshop in Paris, with high-level industrial and government
participation, the major domains of logistic support during an acquisition phase (generally for
newly built systems and major retrofit campaigns) were identified and networked. These
domains provide the framework for future specification development activities with the goal ofcovering the complete product life cycle.
These domains were:−−−−

Logistic support analysis
Provisioning
Order administration
Technical documentation

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

LSA data
Equipment
identification
Designdata

Provisioning

Logistic
SupportAnalysis

Provisioning
data

Order
Administration

Logs Matand data

IP datasubsets

LSA tasks / data

Technical
Documentation

IETM,
other
media

In service operation

Design of systems andsupport equipment

OPS data

Design data−
ICN-B6865-S3000L0064-001-01
Fig 1 Acquisition logistics main business processes (1)At the time of the ASD workshop in Paris, mentioned above, the technical documentation
domain was already covered by S1000D and the provisioning and order administration domains
were covered by S2000M.
No ASD specification existed, however, for the LSA at that time. In a first effort to close this gap,
the ASD decided to develop a new specification, S4000M - International procedure handbook
for the development of scheduled maintenance programs for military aircrafts. Then in 2005, theASD together with the Aerospace Industries Association of America (AIA) started thedevelopment of S3000L - International procedure specification for Logistics Support Analysis.
Details thereof are provided in Chap 1 - Introduction to the specification, and are therefore notrepeated here.
In the meantime it was obvious that another specification was needed to satisfy therequirements for the support of the full product life cycle. The functionality will concentrate on
maintenance and operational data feedback and the specification will be known as S5000F.
The development of S5000F commenced in October, 2008. Estimated time for completion is 15
months.

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

S5000F – Operational & maintenance data feedback

LSA data
Equipment
identification
Designdata

Provisioning

Logistic
SupportAnalysis

Provisioning
data

Logs
Mat
and
data

Order
Administration

S2000M
IP datasubsets

LSA tasks / data

S3000L S4000M

Technical
Documentation

IETM,
other
media

In service operation

Design of systems andsupport equipment

OPS data

Design data

S1000D

ICN-B6865-S3000L0065-001-01
Fig 2 Acquisition logistics main business processes (2)The future network will comprise a total of five specifications which will cover the major support
functions of the product life cycle.

2.2

Integrated concept of operation
The individual ASD specifications should not be considered as stand-alone entities.
In the environment of acquisition logistics they should be used as a coherent set (suite) offunctional specifications with common data definitions and integrated data exchange. This
integrated concept will ensure that all major functionalities of acquisition logistics are efficiently
covered without overlap. The specifications are internationally accepted and are broadly used in
the aerospace and defence business, but are not limited to these areas.
Of all the ASD specifications, S3000L plays a leading role. It is the principal tool to:−−design the products relevant to maintainability, reliability, testability and to optimize Life
Cycle Cost (LCC).
define all required resources to support the product in its intended use during inservice
operation.

3

Interrelation to S1000D

3.1

Purpose of S1000D
S1000D was produced to establish an international specification for procurement, production
and distribution of technical documentation and learning content. This specification can beapplied to the documentation of any type of equipment including both military and civil products.
Note
Since 2007, ASD, AIA and Air Transport Association of America (ATA) will jointly further
develop, maintain and promote S1000D in the international arena.

3.2

S3000L/S1000D
The task information developed during the LSA process is the baseline for the maintenanceprocedures to be produced in accordance with S1000D. The LSA data is also the input for the
maintenance planning information.

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

The task information includes, for example:−−

Task description
Preliminary requirements••••

Required conditions
Required persons
Required equipment
Safety conditions

This data must be used as a direct input to the corresponding procedure in the maintenancepublications. Depending on the publication production environment, some of this data can bedirectly included in the procedure. During the update of the procedure, the author can be
notified of any changes.
If a full set of maintenance planning data is developed in the LSA process this data can betransferred directly to the maintenance planning publication data modules.
The details of the data set to be exchanged are given in DEX1A&D and DEX3A&D and thespecification S1003X - S1000D and S3000L interface specification.
Note
There is not always a one-to-one relation between a task coming from the LSA process anda procedural data module, since tasks can be grouped into one procedural data module or
split into several reusable procedural data modules.

4Interrelation to S2000M

4.1

Purpose of S2000M
S2000M originally defined the materiel management processes and procedures to be used insupport of aircraft and other aerospace airborne and ground equipment supplied to militarycustomers. S2000M has now been revised to include the business processes and dataapplicable to any military product. Although the S2000M was designed for military productsupport, it may nevertheless be used for the support of any other complex Product.
The processes described within S2000M cover the interfaces between the Contractor and theCustomer, which, when based upon contractual agreements, will provide the typicaldeliverables of the logistic materiel management:
−
−
−
−
−
−
−

4.2

Provisioning
NATO codification (as a special military feature)
Procurement planning
Order administration
Invoicing
Repair administration
S2000M Light

S3000L/S2000M
During the S3000L LSA process, information will be generated that will determine the range anddepth of the maintenance of the product, as well as the required material resources during inservice operation. On the S2000M side, the appropriate functionality for the interface to S3000L
is the provisioning functionality. Provisioning, according to chapter 1 of S2000M, is the processof selecting support items and spares necessary for the support of all categories of products.
The compilation of provisioning data for those items identified as relevant for a customer's
maintenance and support concept is the prime objective of that phase.
Provisioning data is compiled according to compilation rules specified in S2000M. These rules
are normally confirmed or modified/specified during a Guidance Conference (GC). The GC

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

takes place at the start of any project in which the S2000M procedures are to be operated.
During the GC, it will be specified in detail as to what extent LSA data can/shall be used tosupport the provisioning process. Assuming that a full LSA program is authorized for a productthen, as an example, the following S2000M Chapter 1 data elements can be taken/derived from
LSA:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Authorized life
Essentiality code
Integrated logistic support number
maintenance percent
Mean time between failures
Part number
Scrap rate
Shelf life code
Size of packaged unit
Size of unpackaged unit
Source maintenance recoverability code
Special storage
Time between overhauls
Time between scheduled shop visits
Weight of packaged unit
Weight of unpackaged unit

(AUL)
(ESC)
(ILS)
(MAP)
(TBF)
(PNR)
(SRA)
(SLC)
(SPU)
(SUU)
(SMR)
(STR)
(TBO)
(TSV)
(WPU)
(WUU)

Note
The data being derived from LSA need not be limited to the list above. There can be morecommon data between the S2000M and S3000L areas. It should be highlighted that
especially data which are common between S2000M and S3000L (simple example: thename of a part/equipment) should be harmonized as much as possible. The leading
discipline for technical values should be identified during the GC.

5

Interrelation to S4000M

5.1

Purpose of S4000M
S4000M provides a means for developing the scheduled maintenance tasks and intervals which
will be acceptable to operators, manufacturers and regulatory authorities (if applicable). The
scheduled maintenance task and interval details will be developed by coordination withspecialists from operators, manufacturers and the regulatory authority. Specifically, S4000M
outlines the general organization and decision processes for determining scheduled
maintenance requirements initially projected for the life of the product.

5.2

S3000L/S4000M
LSA and SMA are interconnected very closely. Only the common view on unscheduled
maintenance and scheduled or preventive maintenance respectively gives a complete
impression of maintenance activities. The identification of the requirements for any scheduled
task is the same as for the unscheduled tasks. For that reason, the documentation of the tasks
in the LSA database can be done in almost the same way (only the justifying event differs). Also
the packaging of the scheduled maintenance activities can be supported by the use of the LSA
database. The scheduled tasks for each relevant equipment or subsystem can be documented
in the LSA database as well as in the final relevant inspection and overhaul packages.
Additionally, the individual tasks and the packages can be linked together for traceability
purposes, as well as for reporting and evaluation purposes.
The interconnecting data is primarily for the identification of the scheduled task itself (the task
will be documented in the LSA database) and the related interval/threshold. Interval adoption
resulting from the scheduled maintenance packaging requirements will also be documented in
the LSA database.

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

In the following figure, the entire process of identifying SMA tasks within the applied SMA
method to a final harmonization of scheduled maintenance in form of inspection and overhaul
packages.
ASD S4000M - Scheduled Maintenance Analysis
System and Powerplan Analysis

Structure Analysis

Zonal Analysis

identifies
tasks

identifies
tasks

identifies
tasks

applicable and effective
scheduled or preventive
maintenance actions

applicable and effective
scheduled or preventive
maintenance actions

applicable and effective
scheduled or preventive
maintenance actions

Link to LSA

Link to LSA(to task)

Link to LSA

Link to LSA(to task)

Link to LSA(to zone)

Link to LSA(to task)

LSA
Candidate

LSA
Task(s)LSA
Candidate

LSA
Task(s)Zone

LSA
Task(s)Interval Harmonization Process(Packaging of same or similar intervals to harmonized scheduled maintenance packages
 Maintenance Plan)

Non-hardware BC(mainenance package)
LSA Candidate

Maintenance Package
containing a list of
maintenance actions(with interval)

ASD S3000L - Logistic Support Analysis (Logistic database)

ICN-B6865-S3000L0066-001-01
Fig 3 Process overview from SMA tasks via LSA tasks to maintenance packages
Rules for the documentation of scheduled maintenance packages within a LSA database mustbe established and harmonized with the customer during the LSA GC. It is strictly
recommended that the validity of tasks is clarified within the LSA database.
The LSA tasks derived from the original SMA can serve as the documentation of SMA results,
too. It should be possible for a S3000L application to link corresponding SMA documents. Also,
the need for modification of task thresholds or intervals, or even the need for design changes,
can be documented in the LSA as well as the original situation in the SMA tasks. Traceability
should be the main driver for the documentation of SMA within the logisticians’ environment, asshown in Fig 4.

Effectivity: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

Scheduled
Maintenance Analysis(S4000M, MSG-3,
RCM)

identify

Individual maintenancetasks documented in
the LSA database

Scheduledmaintenancepackage

identify

SMA documents(S4000M, MSG-3, RCM)
BEI 010401

S4000M

BEI 070407

S4000M

BEI 111201

S4000M

BEI 111201

S4000M

BEI 111201

S4000M

BEI 111201

S4000M

BEI 111201

S4000M

BEI 111201

S4000M

BEI 111201

S4000M

Example:1000 flight hours
inspection of an aircraft
BEI 010401
BEI 070407
BEI 111201
BEI 111201
BEI 111201
BEI 111201
BEI 111201
BEI 111201
BEI 111201

trace
back

Collection of a numberof Maintenance tasks
having the same orsimilar tasks intervals
near by 1000 flight
hours

trace
back

ICN-B6865-S3000L0067-001-01
Fig 4 Traceability of scheduled maintenance

6Interrelation to S5000F

6.1

Purpose of S5000F
S5000F provides a means for the feed back of inservice information to those functional
domains/activities from which it was originally generated and later transmitted to the customer
to support operations (refer to Fig 2).

6.2

S3000L/S5000F
In-service reality and the maintenance concept/tasks and the logistic support requirements
developed by an S3000L LSA process must be continuously compared to ensure theidentification of required revaluation or adaptation. During operation, it becomes evident
whether the predictions of the logistic analysis processes can bear comparison with the realityof the day-to-day experiences of the system operators. In-service data must be collected
carefully and compared to the existing maintenance situation for permanent optimization oflogistic support.
Specific data elements will be defined during the development of S5000F. At this time only the
information clusters are addressed as they will be covered in S5000F:
−
−
−
−
−
−
−
−

data for the analysis of defects, events and system/component healthdata for usage optimization
data for integrated fleet management
data relevant to consumption
data relevant to Engineering Record Cards,
data to support the management of Performance Based Logistics contracts
data to support LCC considerations
data to support product liability issues

S3000L-A-18-00-0000-00A-040A-A

Effectivity: All

End of data module
DMC-S3000L-A-18-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 18
2010-04-01 Page 8

S3000L-B6568-03000-00

Chapter 19
Data elements
Table of contents

Page

Data elements ................................................................................................................................ 1
References ..................................................................................................................................... 4
1
General ............................................................................................................................ 5
1.1
Introduction ...................................................................................................................... 5
1.2
Objective .......................................................................................................................... 5
1.3
Scope ............................................................................................................................... 5
1.4
Out of scope .................................................................................................................... 5
2
Overview .......................................................................................................................... 5
2.1
Unified modeling language .............................................................................................. 5
2.1.1
UML Class model ............................................................................................................ 6
2.1.2
Special guidance for reading the S3000L data model................................................... 12
2.2
Organization of this chapter ........................................................................................... 13
2.3
S3000L data types ......................................................................................................... 14
2.3.1
Overall description ......................................................................................................... 14
2.3.2
Graphical representation ............................................................................................... 14
2.3.3
Data type Date ............................................................................................................... 15
2.3.4
Data type Id ................................................................................................................... 15
2.3.5
Data type Descr ............................................................................................................. 16
2.3.6
Data type Class ............................................................................................................. 16
2.3.7
Data type Classification ................................................................................................. 17
2.3.8
Data type Prp ................................................................................................................. 17
2.4
Unknown values ............................................................................................................ 19
3
Model overview .............................................................................................................. 19
4
Functional areas ............................................................................................................ 20
4.1
UoF Project .................................................................................................................... 20
4.1.1
Overall description ......................................................................................................... 20
4.1.2
Graphical representation ............................................................................................... 21
4.1.3
UoF Project - New class and interface definitions ......................................................... 21
4.2
UoF Product Usage ....................................................................................................... 24
4.2.1
Overall description ......................................................................................................... 24
4.2.2
Graphical representation ............................................................................................... 25
4.2.3
UoF Product Usage - New class and interface definitions ............................................ 25
4.2.4
UoF Product Usage - Additions to referenced class and interface definitions .............. 27
4.3
UoF Breakdown Structure ............................................................................................. 27
4.3.1
Overall description ......................................................................................................... 27
4.3.2
Graphical representation ............................................................................................... 29
4.3.3
UoF Breakdown Structure - New class and interface definitions .................................. 29
4.3.4
UoF Breakdown Structure - Additions to referenced class and interface definitions .... 32
4.4
UoF Part ........................................................................................................................ 32
4.4.1
Overall description ......................................................................................................... 32
4.4.2
Graphical representation ............................................................................................... 34
4.4.3
UoF Part - New class and interface definitions ............................................................. 34
4.4.4
UoF Part - Additions to referenced class and interface definitions ............................... 40
4.5
UoF Breakdown Element Realization ............................................................................ 40
4.5.1
Overall description ......................................................................................................... 40
4.5.2
Graphical representation ............................................................................................... 41
4.5.3
UoF Breakdown Element Realization - New class and interface definitions ................. 41

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

4.5.4
4.6
4.6.1
4.6.2
4.6.3
4.6.4
4.7
4.7.1
4.7.2
4.7.3
4.8
4.8.1
4.8.2
4.8.3
4.8.4
4.9
4.9.1
4.9.2
4.9.3
4.9.4
4.10
4.10.14.10.24.10.34.10.44.11
4.11.1
4.11.24.11.34.11.44.12
4.12.14.12.24.12.34.12.44.13
4.13.14.13.24.13.34.13.44.14
4.14.14.14.24.14.34.14.44.15
4.15.14.15.24.15.34.15.4
4.16

UoF Breakdown Element Realization - Additions to referenced class and interface
definitions ....................................................................................................................... 44
UoF Breakdown Zone Element ..................................................................................... 44
Overall description ......................................................................................................... 44
Graphical representation ............................................................................................... 45
UoF Breakdown Zone Element - New class and interface definitions .......................... 45
UoF Breakdown Zone Element - Additions to referenced class and interface definitions....................................................................................................................................... 46
UoF Breakdown Aggregated Element ........................................................................... 46
Overall description ......................................................................................................... 46
Graphical representation ............................................................................................... 47
UoF Breakdown Aggregated Element - New class and interface definitions ................ 47
UoF Product Variant Applicability .................................................................................. 48
Overall description ......................................................................................................... 48
Graphical representation ............................................................................................... 49
UoF Product Variant Applicability - New class and interface definitions ....................... 49
UoF Product Variant Applicability - Additions to referenced class and interface
definitions ....................................................................................................................... 52
UoF LSA Candidate ....................................................................................................... 52
Overall description ......................................................................................................... 52
Graphical representation ............................................................................................... 54
UoF LSA Candidate - New class and interface definitions ............................................ 54
UoF LSA Candidate - Additions to referenced class and interface definitions .............. 65
UoF LSA Candidate Analysis Activity ............................................................................ 65
Overall description ......................................................................................................... 65
Graphical representation ............................................................................................... 66
UoF LSA Candidate Analysis Activity - New class and interface definitions ................. 67
UoF LSA Candidate Analysis Activity - Additions to referenced class and interface
definitions ....................................................................................................................... 76
UoF LSA-FMEA and Special Events ............................................................................. 76
Overall description ......................................................................................................... 76
Graphical representation ............................................................................................... 78
UoF LSA-FMEA and Special Events - New class and interface definitions .................. 79
UoF LSA-FMEA and Special Events - Additions to referenced class and interface
definitions ....................................................................................................................... 85
UoF LSA Candidate Task Requirement ........................................................................ 86
Overall description ......................................................................................................... 86
Graphical representation ............................................................................................... 87
UoF LSA Candidate Task Requirement - New class and interface definitions ............. 87
UoF LSA Candidate Task Requirement - Additions to referenced class and interface
definitions ....................................................................................................................... 89
UoF Task ....................................................................................................................... 89
Overall description ......................................................................................................... 89
Graphical representation ............................................................................................... 91
UoF Task - New class and interface definitions ............................................................ 92
UoF Task - Additions to referenced class and interface definitions ............................ 101
UoF Task Resources ................................................................................................... 102
Overall description ....................................................................................................... 102
Graphical representation ............................................................................................. 103
UoF Task Resources - New class and interface definitions ........................................ 103
UoF Task Resources - Additions to referenced class and interface definitions .......... 113
UoF Task Usage (Part 1) ............................................................................................. 114
Overall description ....................................................................................................... 114
Graphical representation ............................................................................................. 115
UoF Task Usage (Part 1) - New class and interface definitions .................................. 116
UoF Task Usage (Part 1) - Additions to referenced class and interface definitions .... 126
UoF Task Usage (Part 2) ............................................................................................. 127

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

4.16.14.16.24.16.34.16.44.17
4.17.1
4.17.24.17.34.17.44.18
4.18.1
4.18.2
4.18.34.18.44.19
4.19.1
4.19.24.19.34.19.44.20
4.20.1
4.20.24.20.34.20.44.21
4.21.1
4.21.24.21.34.21.4Overall description ....................................................................................................... 127
Graphical representation ............................................................................................. 128
UoF Task Usage (Part 2) - New class and interface definitions .................................. 128
UoF Task Usage (Part 2) - Additions to referenced class and interface definitions .... 128
UoF Security Classification .......................................................................................... 129
Overall description ....................................................................................................... 129
Graphical representation ............................................................................................. 129
UoF Security Classification - New class and interface definitions ............................... 129
UoF Security Classification - Additions to referenced class and interface definitions . 130
UoF Organization Assignment..................................................................................... 131
Overall description ....................................................................................................... 131
Graphical representation ............................................................................................. 131
UoF Organization Assignment - New class and interface definitions.......................... 131
UoF Organization Assignment - Additions to referenced class and interface definitions..................................................................................................................................... 133
UoF Document............................................................................................................. 135
Overall description ....................................................................................................... 135
Graphical representation ............................................................................................. 136
UoF Document - New class and interface definitions.................................................. 137
UoF Document - Additions to referenced class and interface definitions .................... 140
UoF Remark ................................................................................................................ 146
Overall description ....................................................................................................... 146
Graphical representation ............................................................................................. 147
UoF Remark - New class and interface definitions ..................................................... 147
UoF Remark - Additions to referenced class and interface definitions ....................... 150
UoF Applicability Statement ........................................................................................ 158
Overall description ....................................................................................................... 158
Graphical representation ............................................................................................. 160
UoF Applicability Statement - New class and interface definitions ............................. 161
UoF Applicability Statement - Additions to referenced class and interface definitions169

List of tables
1
2

References ...................................................................................................................... 4
Association cardinalities used in S3000L ........................................................................ 7

List of figures
1
2
3
4
5
6
7
8
9
10
11
12
13

Example of a class in UML .............................................................................................. 6
Example of relational representation of the UML class given above .............................. 7
Example of an association between classes in UML ...................................................... 7
Example of relational representation of the project and contract association given
above ............................................................................................................................... 8
Example of an association class in UML ......................................................................... 8
Example on relational representation of the association class attributes given above ... 8
Example of a directed association in UML ...................................................................... 9
Example of specialization (inheritance) relationships between classes in UML ........... 10
Example of relational representation of the specializations given above ...................... 10
Example of a composition aggregation in UML ............................................................. 11
Example on relational representation of the composition aggregation given above ..... 11
Example of Interface and Realize relationships in UML ................................................ 12
Example on relational representation of interface definition ......................................... 12

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

S3000L data types - class model .................................................................................. 15
S3000L data model overview ........................................................................................ 20
Project - class model ..................................................................................................... 21
Product Usage - class model ......................................................................................... 25
Breakdown Structure - class model ............................................................................... 29
Part - class model .......................................................................................................... 34
Breakdown Element Realization - class model ............................................................. 41
Breakdown Zone Element - class model ....................................................................... 45
Breakdown Aggregated Element - class model ............................................................ 47
Product Variant Applicability - class model ................................................................... 49
UoF LSA Candidate - class model ................................................................................ 54
LSA Candidate Analysis Activity - class model ............................................................. 66
LSA-FMEA and Special Events - class model .............................................................. 78
LSA Candidate Task Requirement - class model.......................................................... 87
UoF Task - class model ................................................................................................. 91
UoF Task Resources - class model............................................................................. 103
UoF Task Usage (Part 1) - class model ...................................................................... 115
UoF Task Usage (Part 2) - class model ...................................................................... 128
UoF Security Classification - class model ................................................................... 129
UoF Organization Assignment - class model .............................................................. 131
UoF Document - class model ...................................................................................... 136
UoF Remark - class model .......................................................................................... 147
UoF Applicability Statement - class model .................................................................. 160

References
Table 1 References
Chap No./Document No.

Title

Chap 12Maintenance task analysis

Chap 20

Data exchange

Chap 22

Data element list

GEIA-STD-0007

Logistics Product Data

ISO 10303:239 PLCS

Product Life Cycle Support

www.pdm-if.org/pdm_schema

PDM Schema usage guidewww.oasis-open.org

Organization for the Advancement of Structured
Information Standards

www.uml.org

Unified Modeling Language

www.plcs-resources.org

Product Life Cycle Support website

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

1

General1.1

Introduction
This chapter defines a coherent data model for the data that can be exchanged between the
Logistics Support Analysis (LSA) process as defined in S3000L, and related businessprocesses. These related business processes can be either business processes that are
dependent upon data being produced as a result of the LSA, or business processes that provide
input to the LSA process.
The data model is described using the UML (Unified Modeling Language) version 2, classmodel (www.uml.org).
Each attribute defined in the UML class model is defined in Chap 22, Data element list.
The data model has been influenced by ISO 10303-239 Product Life Cycle Support (PLCS), in
order to simplify the use of PLCS Data EXchange specifications (DEX) for actual dataexchanges (refer to Chap 20).
The data model defined in this chapter has been defined during a series of workshops. Some ofthese workshops have focused on data required to support the business process described in
S3000L, whereas other workshops have focused on getting a good integration andharmonization between S3000L and the task related schemas in S1000D.

1.2

Objective
The objective for this chapter is to define a coherent data model for the data that can beexchanged between the LSA process, as defined in S3000L, and related business processes.

1.3

Scope
The following areas are within scope of the data model:
−
−
−
−

1.4

Definition of the LSA project and the products that is to be supported
Support the early phases of the LSA project in terms of selecting the LSA candidate items
as well as selecting analysis activities that is to be performed for each candidate item
Support the LSA FMEA (Failure Mode and Effect Analysis)
Document the results from the maintenance and operational task analysis activities

Out of scope
The data model has been defined to support one project at the time. Any implementation of thedata model in a software package that will support multiple projects needs to define data which
can be reused between projects, and implement an applicability model to support this.
The data model does not provide full support for all the identified candidate item analysis
activities, but focuses on Maintenance Task Analysis (MTA) and LSA FMEA. Results from otheranalysis activities, eg LORA, can be referenced by summarized descriptions or by explicit
document references.
The data model does not cover all data elements supporting the LSA process, but just thosedata elements that typically will be exchanged between a contractor and his subcontractors,
partners and customers.

2

Overview

2.1

Unified modeling language
The Unified Modeling Language™ - UML - is a widely used technique to model not only
application structure, behavior, and architecture, but also business processes and data
structures.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

UML consists of a set of different modeling techniques of which this chapter only uses one,
namely the UML class model. A class model defines a static view of the information (classes,
attributes and relationships) that is needed to support the business processes.
2.1.1

UML Class model
Class models are the most widely used part of UML. Class models shows the things that are to
be represented, and their relationships.
This section gives a short overview of the UML constructs that are used in the S3000L data
model. It is not a complete description of the UML class model concepts. Each UML classmodel concept is also translated into a relational table example. These relational table
examples are provided for those readers that has an understanding of relational databases, but
no previous knowledge of UML. The translations between UML and relational tables shall beseen as examples on how UML class model concepts can be represented using a relational
database.

2.1.1.1

Class
The rectangle in a class diagram is called a classifier. The classifier gives you the name of theclass together with an enumeration of its attributes. Each attribute contains the attribute name,data type and cardinality.
Note
A complete description of a class also includes its behavior (also known as methods), but
this is out of scope of the S3000L data model.
An example of a class is given in the figure below. It shows a project class with two attributes,
Project_identifer and Project_name. Each attribute also shows its data type and cardinality.

ICN-B6865-S3000L0200-001-01
Fig 1 Example of a class in UML
A class can have zero, one or many instances. Example on a project instance is the New
Fighter Aircraft project.
Note
A class in UML can be viewed as a table in a relational database, and an instance of thatclass can be seen as a row within that table. The attributes of a class can be seen as thetable columns.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

PROJECTPROJECT_NAME

PROJECT_IDENTIFIERNew Fighter Aircraft

123

ICN-B6865-S3000L0201-001-01
Fig 2 Example of relational representation of the UML class given above
Note
The relational table column that constitutes its primary key, is emphasized by underlining
the column name(s).
A class can also have relationships to other classes in terms of association, composition,
aggregation, generalization/specialization and realization.
2.1.1.2

Association
Associations represent interdependencies between classes. Associations are often viewed asjust another attribute where the attribute is modeled as a class with a connector between thecontaining class and the class representing the attribute.
An example of an association is shown in the figure below. It shows that a project has at least
one associated contract, and that a contract can be associated with zero, one or many
instances of project. The cardinality for the association is given at the respective end of theassociation.

ICN-B6865-S3000L0202-001-01
Fig 3 Example of an association between classes in UML
Table 2 Association cardinalities used in S3000L
Association

Explanation

1

One (and only one) instance of the associated class must be associated witheach instance of the associating class (a mandatory association)0..*

Zero, one or many instances of the associated class can be associated witheach instance of the associating class (an optional association)

1..*

At least one instance of the associated class must be associated with each
instance of the associating class (a mandatory association)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

Note
An association in UML can be viewed as a relationship table in a relational database, where
the columns in the table represents the primary keys from the respective class, and thetable rows represents references to the associated instances.
PROJECT_CONTRACT_RELATIONSHIPPROJECT_NAME

CONTRACT_IDENTIFIERNew Fighter Aircraft

CCT-2008-011

New Fighter Aircraft

CCT-2008-034

ICN-B6865-S3000L0203-001-01
Fig 4 Example of relational representation of the project and contract association given above
2.1.1.3

Association class
An association may also have an association class. An association class adds information to
the association.
An example of an association class is given in the figure below. It shows that a contract can beassociated with other contracts, and that each association can contain information on the typeof association that is established between the two contracts. This information is defined within
the association class Contract_relationship by using the Contract_relationship_type attribute.

ICN-B6865-S3000L0204-001-01
Fig 5 Example of an association class in UML
Note
An association class in UML can be viewed as adding columns to a relationship table in a
relational database.
CONTRACT_CONTRACT_RELATIONSHIPCONTRACT_ID_1

CONTRACT_ID_2

REL_TYPE

CCT-2008-011

CCT-2008-034

Subcontract

ICN-B6865-S3000L0205-001-01
Fig 6 Example on relational representation of the association class attributes given above
2.1.1.4

Directed association
A directed association has an open arrowhead at the target end of the association. In a directedassociation, two classes are related, but only one class knows that the relationship exists.
An example of a directed association is the possibility to associate an higher failure mode effectwith an LSA candidate that represents the higher level function, including the end item.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

However, there is no requirement for the LSA candidate to be able to navigate to any
associated higher failure mode effects.

ICN-B6865-S3000L0206-002-01
Fig 7 Example of a directed association in UML
Note
A directed association in UML can be viewed as a relationship table in a relational
database, in the same way as described for an association above.
2.1.1.5

Generalization and specialization
Specialization refers to an ‘is-a’ relationship and is modeled by a solid line connector with ahollow triangle at one end. The triangle points to the parent (ie the generalized class).
Specialization is often referred to as inheritance.
The most important aspect of the generalization/specialization relationship is that the child classgets all the features of the parent class, and can then add features of its own, ie a child classinherits all the attributes and relationships defined for its parent class.
Another important aspect of specialization is substitutability. Substitutability means that
wherever a parent class is being used, a child class can be substituted for its parent.
An example of the specialization/generalization association is Part and its specialization into
Hardware_part and Software_part, respectively. In the example given below, the Part class has
the defined attributes Part_identifier and Part_name. This means that both the Hardware_part
and Software_part classes also has the Part_identifier and Part_name attributes, even though
they are not explicitly enumerated in the attribute list for the respective class. The respectiveclass also defines additional attributes which are unique for its respective special
characteristics.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6568-03000-00

ICN-B6865-S3000L0208-001-01
Fig 8 Example of specialization (inheritance) relationships between classes in UML
Note
A special characteristic that can be defined for the parent class is that it can be defined asan ‘abstract’ class. This means that the parent class itself cannot be instantiated, but mustbe substituted by any of its child classes. This is denoted in the model by making the classname (classifier) italic. Part in the example above is defined as an abstract class.
Specialization can be viewed as multiple tables with the same initial set of columns (incl.
the primary key).

ICN-B6865-S3000L0209-002-01
Fig 9 Example of relational representation of the specializations given above
Note
Both the Actual_software_size value and Actual_software_size UoM (Unit of Measure) are
included in the Prp data type.
2.1.1.6

Aggregation
Aggregation defines whole and part relationships, ie it indicates that one class is part of anotherclass. In an aggregation relationship, the child class instance can outlive its parent class.
Note
An example of an aggregation relationship is Car and its Wheels, where the Car represents
the whole class and the Wheels represents parts of the overall Car. However, the Wheel
class instances can live independently of the Car class instance.
Note
Aggregation relationship is currently not used in the S3000L data model, but is describedas background information for the composition aggregation defined in the next paragraph.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6568-03000-00

2.1.1.7

Composition aggregation
Composition aggregation is just another form of aggregation relationship, where the childclass’s instance lifecycle is dependent on the parent class’s instance lifecycle
An example of a composition aggregation is the possibility to define that a Task consists of one
or many Subtasks.

ICN-B6865-S3000L0210-002-01
Fig 10 Example of a composition aggregation in UML
Note
Composition aggregation can be viewed as two relational tables, where the relational tablethat represents the aggregated class has a primary key which initial columns corresponds
to the primary key for the table that represents the composition class.
TASK

SUBTASKTASK_ID

TASK_NAMETASK_ID

SUBTASK_ID

SUBTASK_ROLE

TSK-1112

Remove enginee

TSK-1112

STSK-1

Start-up

TSK-1112

STSK-2Core

ICN-B6865-S3000L0211-001-01
Fig 11 Example on relational representation of the composition aggregation given above
2.1.1.8

Interface and the realize relationship
Interfaces are a way of modeling features that are common for a set of classes.
Any class that realizes (implements) an interface must support the features defined by theinterface. These features include attributes, relationships and behavior.
An example of interface in the S3000L data model is the LSA_candidate interface. This
interface is realized by both Breakdown_element_revision and Part. This means that the
attributes and relationships that are defined for the LSA_candidate interface must be supported
by both Part and Breakdown_element_revision.
Note
Interfaces simplify the data model, eg a similar relationship between one class and a set ofother classes can be directed towards an interface which in turn is implemented by eachclass that can be part of that relationship.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6568-03000-00

The graphical representation for the realization connector is almost identical to thegeneralization connector, except that the connector is a dashed line instead of a solid line.

ICN-B6865-S3000L0212-002-01
Fig 12 Example of Interface and Realize relationships in UML
Note
Interface definition can be viewed as adding columns to existing relational tables (seeexample below) as well as adding relationship tables that will represent the interface
associations.

ICN-B6865-S3000L0259-001-01
Fig 13 Example on relational representation of interface definition
2.1.2
2.1.2.1

Special guidance for reading the S3000L data model
Classes and attributes
The data types that are used in the S3000L class model, are based on basic ISO 10303:239
Product Life Cycle Support constructs, and OASIS usage guidance on how to implement PLCS.
For further information, refer to Para 3, S3000L data types.
Each attribute used in the S3000L data model are defined in Chap 22 Data element list.

2.1.2.2

Graphics
The graphical diagrams contain classes that both filled and not. A filled class represents classes
that are introduced and defined within the Unit of Functionality (UoF) under consideration.
Classes without any fill (ie white) are classes that are defined in another UoF, and arepresented without any of its attributes.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6568-03000-00

2.1.2.3

2.2

Textual descriptions
The use of the terms "specific" and "instance of" in the textual descriptions means the samething, ie it refers to a specific instance of a class. For a description of what is meant by an
instance, refer to Para 2.1.1.1 above.

Organization of this chapter
This chapter is organized into a set of Units of Functionalities (UoF). Each UoF divides theoverall data model into a set of smaller data models, which defines classes and attributes
required to document a specific aspect of the LSA.
Note
The set of UoF does not follow the chapters of S3000L, but is structured in accordance withthe order by which the data typically is created during LSA process.
Each UoF contains:−−−−

An overall description of the UoF
A graphical representation of the class model for the UoF
Definitions of new classes and interfaces identified within the UoF
Additions to classes and interfaces defined within other UoFs

Each class defined in the data model has:−

A short description of its intent−

An enumeration of its attributes, including attribute cardinality
•
•
•
•

−

An enumeration of its associations••−

Associations described as "can be" means that the association is optional
Associations described as "must be" means that the association is mandatory

An enumeration of implemented interfaces•−

Where no cardinality is given, the attribute is mandatory, and only one value can be
given"zero or one", means that the attribute is optional"one or many", means that the attribute is mandatory and that it can have multiple
values"zero, one or many", means that the attribute is optional, but it can also have morethan one value

Implemented interfaces means that the class under consideration must support all theattributes and associations defined by the interface

Special recommendations, eg••

Special recommendations regarding the use of the attribute data types
Special recommendations regarding use of applicability

NoteDefinitions for the attributes used in the data model are provided in Chap 22 Data element
list, and are not repeated in this paragraph.
Note
Any reference to GEIA-STD-0007 is provided for informational purposes only, based on thefact that GEIA-STD-0007 (former DoD-STD-1388-2b) is widely known in the LSA
community.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6568-03000-00

Note
Where no special recommendation is stated for an attribute of type Prp (property), therecommendation is to use the Value_with_unit_property class for the representation of its
value.

2.3

S3000L data types

2.3.1

Overall description
Data types used in the S3000L data model are not the same as usually encountered in data
models, eg integer, real, string. In order to create a richer data model, S3000L has defined a setof data types that are closely related to the basic OASIS PLCS templates (www.oasisopen.org). These templates can be seen as small instantiation patterns, which ensure that eachbasic data element has an associated set of metadata.
For example, consider part identification (part number). In a traditional data model a partnumber would typically be represented as a string value. There is often, for example, noadditional information about the organization that provided the part number.
In the OASIS PLCS template for assigning_identifier, the string value representing the partnumber would always be defined together with the following attributes:−−−

Information about the type of part number that is being represented (eg NATO Stock
Number)Identification of the organization that determined (“owns”) the part number
Information on how the organization is identified (eg NCAGE code).

The following data types have been used throughout the S3000L data model:
−
−
−
−
−
−
2.3.2

Date
Id (Identifier)Descr (Description)
Class
Classification
Prp (Property)

Graphical representation

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6568-03000-00

ICN-B6865-S3000L0213-002-01
Fig 14 S3000L data types - class model
2.3.3

Data type Date
The Date data type is used to represent calendar dates.
Date data type attributes:−−−

Year_component
Month_component
Day_component

Note
All Date attributes are defined as integers. The rules for how to populate the respective
value are defined in the data elements list.
Note
The Date data type does not include any format, eg 23/10/08 or 2008-10-23. Date format is
avoided in order to simplify data exchange.
2.3.4

Data type Id
The Id data type is used to represent any form of identification, including names.
Id data type attributes:−

Identifier

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6568-03000-00−−

Identifier_class
Identifier_set_by_organization (zero or one)The Identifier attribute contains the identifier as such.
The Identifier_class attribute determines the type of identifier that is provided.
The Identifier_set_by_organization identifies the organization that determined (“owns”) the
identifier.
Note
The Identifier_set_by_organization relates to an Organization as the data type. The
Organization class is defined in UoF Project, and contains an Organization_identifier(optional) and an Organization_name, which are both of data type Id. This means that theidentification and/or name of the Organization comes with a classification of what type ofidentification is being used to identify the Organization (eg NCAGE code) and an optional
determination of who determined (“owns”) the Organization identifier.
2.3.5

Data type Descr
The Descr data type is used to represent any form of textual description (free form).
Descr data type attributes.
−−−

Description
Description_provided_by_organization (zero or one)
Description_provided_date (zero or one)The description attribute contains text that provides further information about the subject underconsideration.
Note
The Description attribute must allow for descriptions in an indentured manner.
The Description_provided_by_organization identifies the organization that provided thedescription. The Description_provided_date identifies the date when the description wasprovided.
Note
The Descr attributes Description_provided_by_organization and Description_provided_dateenables multiple descriptions to be provided for different purposes for the same object, andstill be distinguished by organization and date.
2.3.6

Data type Class
The Class data type is used for representing references to terms, which can be used forclassifications. The data model assumes that each term used has a definition in an external
Reference Data Library (RDL). An RDL can be regarded as a glossary containing terms anddefinitions. For more information on the use of an RDL refer to www.plcs-resources.org.
Class data type attributes:−−

Class_name
Class_rdl (zero or one)

The Class_name attribute contains the name of the term being used for classification.
The Class_rdl attribute contains a reference to the source (RDL), where the definition of theterm can be found.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6568-03000-00

2.3.7

Data type Classification
The Classification data type is used for representing dated assignments of classes, ie the datewhen the classification is done is as important as the classification itself.
Classificiation data type attributes:−

Classification_date

The Classification data type has the following associations:−

An association with the Class being used for dated classification

2.3.8

Data type Prp

2.3.8.1

Prp
The Prp data type is used for representing property values.
Note
The property value itself is represented using one of the subclasses of Property_representation.
Prp associations:−

2.3.8.2

An association with one or many instances of Property_representation which contains theactual value(s) for the property.

Property_representation
The Prp class has a one-to-many association with Property_representation. The reason for thisis that the same property may have multiple representations, eg a length property may be
represented in both inches and centimeters.
NoteMultiple representations are not the same as having multiple values for an attribute.
Multiple representations just mean that the same value can be represented in multiple
ways.
Each Property_representation can also include information on how and when a property value
was set. The method by which the value has been determined (eg estimated, calculated) can be
defined using the Propety_determination attribute. When the value was set can be definedusing the Property_creation_date attribute.
Property_representation attributes:−−

Property_determination (zero or one)
Property_creation_date (zero or one)

Property_representation associations−

An association with the Prp for which it represents a value

Note
The Property_representation class is an abstract class, ie any of its subclasses must be
used for the actual representation of the value of a property.
Property_representation subclasses:−−−

Value_with_unit_property (a property with a value and a unit of measure)
Value_with_limit_property (a property with a value and a unit of measure, where the value isdefined as being either a "minimum" or "maximum" value)
Value_with_tolerances_property (a property with a value and unit of measure along withacceptable upper and lower offset values)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6568-03000-00−−

Value_range_property (a property with no fixed value, but defined by upper and lower limits
along with a unit of measure)
Text_property (a property value described as a string, eg "Green")

Note
Where no explicit recommendations have been made for attributes that are of data typePrp, in the S3000L data model below, the default is that they use theValue_with_unit_property representation, ie the property value is provided as a value and aunit of measure.
2.3.8.3

Value_with_unit_property
The Value_with_unit_property class is used to represent a value with its unit of measure.
The Value_with_unit_property class is a specialization of the Property_representation class.
Note
Value_with_unit_property is the default representation for all attributes that are of data type
Prp.
Value_with_unit_property attributes:−−−−

2.3.8.4

Property_determination (inherited from class Property_representation)
Property_creation_date (inherited from class Property_representation)
Value
Unit

Value_with_limit_property
The Value_with_limit_property class is used to represent a value with its unit of measure, wherethe value is defined as being either a "minimum" or "maximum" value.
The Value_with_limit_property class is a specialization of the Value_with_unit_property class.
Value_with_unit_property attributes:
−
−
−
−
−

2.3.8.5

Property_determination (inherited from class Property_representation)
Property_creation_date (inherited from class Property_representation)
Value (inherited from class Value_with_unit_property)
Unit (inherited from class Value_with_unit_property)
Limit_qualifier

Value_with_tolerances_property
The Value_with_tolerances_property class is used to represent a value with its unit of measure,along with acceptable upper and lower offset values.
The Value_with_tolerances_property class is a specialization of the Value_with_unit_property
class.
Value_with_tolerances_property attributes:
−
−
−
−
−
−

2.3.8.6

Property_determination (inherited from class Property_representation)
Property_creation_date (inherited from class Property_representation)
Value (inherited from class Value_with_unit_property)
Unit (inherited from class Value_with_unit_property)
Upper_offset_value
Lower_offset_value

Value_range_property
The Value_range_property class is used to represent a property with a value range in terms ofupper and lower limits along with a unit of measure.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6568-03000-00

The Value_range_property class is a specialization of the Property_representation class.
Value_range_property attributes:
−
−
−
−
−
2.3.8.7

Property_determination (inherited from class Property_representation)
Property_creation_date (inherited from class Property_representation)
Upper_limit_value
Lower_limit_value
Unit

Text_property
The Text_property class is used to represent a property value described as a string value, eg"Green"The Text_property class is a specialization of the Property_representation class.
Text_property attributes:
−
−
−

2.4

Property_determination (inherited from class Property_representation)
Property_creation_date (inherited from class Property_representation)
Text

Unknown values
When no data can be provided, the following convention is recommended to be used:−−

String '/NULL' indicates that data for a mandatory attribute is currently not known.
‘$’ indicates that an optional attribute is not instantiated.

NoteThis guidance has been derived from the "PDM Schema usage guide".

3

Model overview
The S3000L data model is organized into a set of Units of Functionalities (UoF), which splits theoverall data model into a set of smaller data models. The purpose of this is to present small andcoherent portions of the data model, and to gradually give the reader an understanding of thecomplete data model.
The figure below provides an overview of the main UoFs, and how they are interrelated:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6568-03000-00

ICN-B6865-S3000L0214-002-01
Fig 15 S3000L data model overview

4

Functional areas

4.1

UoF Project

4.1.1

Overall description
The first data elements defined during LSA are those required for defining the project (often
referred to as the LSA program) and the product in focus (often referred to as the end item).
A project can be related to one or many contracts, where contracts can be organized into a
chain of associated contracts, eg subcontracts.
Each contract is associated with at least one customer and one contractor. Each contract
includes one or many contracted product variants, where a contracted product variant relates toa specific variant of a generic product.
A contracted product variant may also include information on the quantity of contracted productvariant and/or the serial number range, as known by the customer.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6568-03000-00

4.1.2

Graphical representation

ICN-B6865-S3000L0215-002-01
Fig 16 Project - class model
4.1.3
4.1.3.1

UoF Project - New class and interface definitions
Project
The Project class identifies the overall LSA project (often also known as the LSA program).
Project attributes:−−

Project_identifier (zero or one)
Project_name

Project associations:−4.1.3.2

A project must be associated with at least one contract.

Contract
The Contract class identifies contracts that are associated with the identified project.
Contract attributes:−

Contract_identifier (one or many)

Contract associations:−

Each contract can be associated with zero, one or many projects

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6568-03000-00

−
−
−
−
−
4.1.3.3

Each contract can refer to zero, one or many other contracts (via the associated_contract
association)
Each contract can be referred to from zero, one or many other contracts (via theassociated_contract association)
Each contract must be associated with at least one product variant
Each contract must have at least one customer
Each contract must have at least one contractor

Contract_relationship
The Contract_relationship class is an association class, which adds information to theassociation between two contracts.
Contract_relationship attributes:−

4.1.3.4

Contract_relationship_type

Organization
The Organization class identifies organizations that can be referred to from the LSA project.
Organization attributes:−−

Organization_identifier (zero, one or many)
Organization_name

An Organization class can be specialized into the following classes (also referred to as
subclasses):−−−

Contractor
Customer
User

Each of these specializations has their own characteristics in addition to these that are genericfor an Organization such as having an Organization_identifier and an Organization_name.
4.1.3.5

Contractor
The Contractor class is a specialization of class Organization, and identifies organizations thatare contractors for one or many contracts.
Contractor attributes:−−

Organization_identifier (inherited from class Organization)
Organization_name (inherited from class Organization)

Contractor associations:−4.1.3.6

A contractor can be associated with one or many contracts

Customer
The Customer class is a specialization of class Organization, and identifies organizations thatare customers of one or many contracts.
Customer attributes:−−

Organization_identifier (inherited from class Organization)
Organization_name (inherited from class Organization)

Customer associations:−−

A customer can be associated with one or many contracts
A customer can have zero, one or many user organizations

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6568-03000-00

4.1.3.7

User
The User class is a specialization of class Organization, and identifies organizations that areusers within a specific customer organization.
User attributes:−−

Organization_identifier (inherited from the class Organization)
Organization_name (inherited from the class Organization)

User associations:−−4.1.3.8

A user must be associated with a specific customer
A user can be associated with zero, one or many Contracted_product_variants, which theuser is going to operate

Contracted_product_variant
The Contracted_product_variant class is an association class, which adds information to theassociation between a contract and the product variant that is contracted. A contracted productvariant may be restricted to one or many specific blocks of serialized items, and/or to one or
many specific user organizations.
Contracted_product_variant attributes:−

Quantity_of_contracted_product_variant (zero or one).

Contracted_product_variant associations:−−4.1.3.9

A Contracted_product_variant can be directed towards zero, one or many specific userorganizations
A Contracted_product_variant can be associated with zero, one or many
Block_of_serialized_items

Block_of_serialized_items
The Block_of_serialized_items class defines a block of serialized items by serial numbers. The
identification of a Block_of_serialized_items is always done from a Contracted_product_variant
point of view, ie an instance of the Block_of_serialized_items class doesn’t have any meaningby itself but only in the context of a specific contracted product variant.
Block_of_serialized_items attributes:−−

Serial_number_lower_boundSerial_number_upper_bound (zero or one)Note
The value of the Serial_number_upper_bound attribute need not be specified. If the value
for this attribute is not specified, the interval has no upper bound.
Block_of_serialized_items associations:−4.1.3.10

A Block_of_serialized_items is always defined for a specific Contracted_product_variant.

Product
The Product class identifies a generic product, for which there must be at least one defined
product variant.
Note
An example of generic product is F-15.
Product attributes:−

Product_identifier (one or many)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6568-03000-00−

Product_name (zero, one or many)Note
An example of a type of Product_identifier is the GEIA-STD-0007 End Item Acronym Code.
Product associations:−4.1.3.11

A Product must have at least one defined Product_variant

Product_variant
The Product_variant class identifies a specific variant of a defined generic product.
Note
A Product_variant is also known as a Model in S1000D and S2000M.
Note
Examples of product variants are: F15A and F15B
Product_variant attributes:−−

Product_variant_identifier (one or many)
Product_variant_name (zero, one or many)Note
An example of a type of Product_variant_identifier is the GEIA-STD-0007 System/End Item
Usable On Code.
Product_variant associations:−−

Each Product_variant must be of a defined Product
A Product_variant can be the end item that is identified in zero, one or many contracts

4.2

UoF Product Usage

4.2.1

Overall description
The Product Usage UoF defines the conditions under which the contracted product variant is tobe operated and maintained. This includes eg maintenance levels and operating locations.
Note
The Maintenance_location and Operating_location classes are optional, and need not be
defined within the LSA project.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6568-03000-00

4.2.2

Graphical representation

ICN-B6865-S3000L0216-001-01
Fig 17 Product Usage - class model
4.2.3
4.2.3.1

UoF Product Usage - New class and interface definitions
Operator
The Operator interface must be implemented by those classes that can be used for defining theorganization responsible for operating the contracted product variant. This model allows for bothcustomers and/or users to be defined as Operators.
Classes that implement the Operator interface:−−

CustomerUser

The Operator interface does not define any additional attributes.
Classes that implement the Operator interface must implement the following associations:−−−−An optional association with zero, one or many instances of Operating_location_type
An optional association with zero, one or many instances of Operating_location
An optional association with zero, one or many instances of Maintenance_level_type
An optional association with zero, one or many instances of Maintenance_location

Note
Each Operating_location_type, Operating_location, Maintenance_level_type andMaintenance_location respectively, is uniquely defined for a specific Operator.
4.2.3.2

Maintenance_level_type
Maintenance activities may be structured in maintenance levels according to the customer oruser maintenance policy, and to the customer organization of maintenance means.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6568-03000-00

Maintenance_level_type attributes:−−−

Maintenance_level_type_identifier (zero or one)
Maintenance_level_type_name
Maintenance_level_type_capability_description (zero or one)

Maintenance_level_type associations:−−−4.2.3.3

Each Maintenance_level_type is uniquely defined for a specific Operator
A Maintenance_level_type can be located together with zero, one or many
Operating_location_types
Each Maintenance_level_type can be associated with zero, one or many specific
Maintenance_locations

Maintenance_location
The Maintenance_location class identifies actual locations where maintenance activities are to
be carried out.
Maintenance_location attributes:−−−

Maintenance_location_identifier (zero or one)
Maintenance_location_name
Maintenance_location_description (zero or one)

Maintenance_location associations:−−4.2.3.4

Each Maintenance_location is uniquely defined for a specific Operator
Each Maintenance_location belongs to a specific Maintenance_level_type

Operating_location_type
The Operating_location_type class defines types of locations where the contracted productvariant will be operated.
Note
The Operating_location_type can be generic, ie it doesn’t define any specificcharacteristics, but just enables the recording of the number of contracted product variants
and its operating requirements as defined within theContracted_product_variant_in_operating_location_type class.
Operating_location_type attributes:−−−−

Operating_location_type_identifier (zero or one)
Operating_location_type_name
Operating_location_type_description (zero or one)
Number_of_operating_locations (zero or one)

Operating_location_type associations:−−−−4.2.3.5

Each Operating_location_type is uniquely defined for a specific Operator
An Operating_location_type must operate at least one Contracted_product_variant
An Operating_location_type can be located together with zero, one or many
Maintenance_level_types
An Operating_location_type can be associated with zero, one or many specificOperating_locations.

Operating_location
The Operating_location class defines the exact location where the contracted product variant
will be operated.
Operating_location attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 26

S3000L-B6568-03000-00−−−

Operating_location_identifier (zero or one)
Operating_location_name
Operating_location_description (zero or one)

Operating_location associations:−−−4.2.3.6

Each Operating_location is uniquely defined for a specific Operator
A defined Operating_location must operate at least one Contracted_product_variant
An Operating_location can be of a specific Operating_location_type

Contracted_product_variant_in_operating_location_type
The Contracted_product_variant_in_operating_location_type class is an association class,which adds information to the association between a contracted product variant and its
operating location type.
Contracted_product_variant_in_operating_location_type attributes:−−

4.2.3.7

Quantity_of_product_variant_in_operating_location_type (zero or one)
Operating_requirement_in_operating_location_type (zero or one)

Contracted_product_variant_in_operating_location
The Contracted_product_variant_in_operating_location class is an association class, whichadds information to the association between a contracted product variant and its operating
location.
Contracted_product_variant_in_operating_location attributes:
−
−

4.2.4
4.2.4.1

UoF Product Usage - Additions to referenced class and interface definitions
Contracted_product_variant
The Contracted_product_variant class defined in UoF Project, must also implement thefollowing additional associations:−−4.2.4.2

An association with one or many instances of Operating_location_type, where theContracted_product_variant is to be operated
An optional association with zero, one or many instances of Operating_location, where theContracted_product_variant can be operated

Customer
The Customer class defined in UoF Project, must also implement the following additional
interface:−

4.2.4.3

Quantity_of_product_variant_in_operating_location (zero or one)
Operating_requirement_in_operating_location (zero or one)

OperatorUser
The user class defined in UoF Project, must also implement the following additional interface:−

Operator

4.3

UoF Breakdown Structure

4.3.1

Overall description
The Breakdown Structure UoF can be used to define one or many types of breakdowns for a
specific Product. A breakdown can be eg functional, physical, system, zonal, or hybrid (ie amixture of breakdown types).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 27

S3000L-B6568-03000-00

Note
Existing breakdown structures are often hybrids consisting of both functional, physical andsystem elements.
Each breakdown may have one or many breakdown revisions (design iterations), where eachbreakdown revision references the breakdown element revisions that are included in thespecific revision of the breakdown. These references are done using the
Breakdown_element_usage_in_breakdown class. These references to the breakdown elements(revisions) are then organized hierarchically using the Breakdown_element_structure class.
Note
Having organized the breakdown element usages hierarchically by the use of
Breakdown_element_structure, there needs to be one, and only one, instance ofBreakdown_element_usage_in_breakdown that has no parent element, This
Breakdown_element_usage_in_breakdown is often referred to as the root node.
This construct allows for a defined breakdown element (revision) to be part of many
breakdowns and revisions thereof. A breakdown element (revision) can then be positioned
differently in the respective breakdown and revision thereof. For example, a breakdown element(revision) can be used in both a functional and a physical breakdown.
Note
Each instance of Breakdown_element_usage_in_breakdown andBreakdown_element_structure is unique for a specific breakdown revision.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 28

S3000L-B6568-03000-00

4.3.2

Graphical representation

ICN-B6865-S3000L0217-002-01
Fig 18 Breakdown Structure - class model
4.3.3
4.3.3.1

UoF Breakdown Structure - New class and interface definitions
Breakdown
The breakdown class identifies a partitioning of a Product into a set of related elements so as toform explicit, parent-child relationships that comprise the breakdown.
Examples of breakdowns are:
−
−
−
−
−

Functional
Physical
System
Zonal
Hybrid, ie a mixture of the above

Breakdown attributes:−

Breakdown_type.

Note
One example of a Breakdown_type is the GEIA-STD-0007 functional breakdown.
Breakdown associations:−

An association with the Product for which the breakdown is defined

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 29

S3000L-B6568-03000-00−

4.3.3.2

An association with one or many Breakdown_revisions (design iterations) of the defined
breakdown

Breakdown_revision
The Breakdown_revision class defines an explicit revision (design iteration) of a breakdown for
a Product.
Note:
Breakdown_element_revisions used in a breakdown are related to a Breakdown_revisionand not to the Breakdown.
Breakdown_revision attributes:−−−

Breakdown_revision_identifier
Breakdown_revision_creation_date (zero or one)
Breakdown_revision_status (zero or one)

Breakdown_revision associations:−−4.3.3.3

A Breakdown_revision is always associated with one and only one breakdown of a Product
A Breakdown_revision is related to one or many Breakdown_element_revisions which areused in the breakdown revision, via the Breakdown_element_usage_in_breakdown class.

Breakdown_element_usage_in_breakdown
The Breakdown_element_usage_in_breakdown class defines a relationship between a revisionof a breakdown element and a revision of a breakdown in which the revision of the breakdown
element is being used.
Note
Each instance of Breakdown_element_usage_in_breakdown is uniquely defined for one
combination of Breakdown_element_revision and Breakdown_revision. An instance of the
Breakdown_element_usage_in_breakdown class doesn’t have any meaning by itself but
only in the context of a Breakdown_revision.
Breakdown_element_usage_in_breakdown associations:−−−−

An association with the Breakdown_revision in which the associatedBreakdown_element_revision is being used
An association with the Breakdown_element_revision that is being used in the associatedBreakdown_revision
An optional parent-of association with zero, one or many Breakdown_element_revisions
included in the Breakdown_revision, via the Breakdown_element_structure
An optional child-of association with zero or one Breakdown_element_revision included in
the same Breakdown_revision, via the Breakdown_element_structure class

Note
An instance of Breakdown_element_usage_in_breakdown can be the parent of many
instances of Breakdown_element_usage_in_breakdown (ie Breakdown_element_revisions)defined for the same Breakdown_revision.
Note
There is one instance of Breakdown_element_structure class per parent-child relationship,
and there is no explicit ordering in between the parent-child relationships defined for a
specific Breakdown_element_usage_in_breakdown (ie ordering of child elements for a
specific parent element).
4.3.3.4

Breakdown_element_structure
The Breakdown_element_structure class is being used to hierarchically organize
Breakdown_element_revisions within a specific Breakdown_revision.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 30

S3000L-B6568-03000-00

Note
The breakdown structure is accomplished by organizing the usages of the
Breakdown_element_revisions, ie by organizing the instances ofBreakdown_element_usage_in_breakdown instead of the organizing the
Breakdown_element_revisions themselves.
Note
The breakdown structure can also be derived from the values given as
Breakdown_element_identifiers. The breakdown structure is then implicit, rather than
explicit and do not require the usage of Breakdown_element_structure class. This approach
can be used if the Breakdown_element_identifier follows the logic defined in eg GEIA-STD0007 Logistics Control Number (LCN), A discussion on the advantages/disadvantages of
the respective approach is given in Chap 3 LSA Business Process.
Breakdown_element_structure attributes:−−

Quantity_of_child_elements (zero or one)
Installation_description (zero or one)

Breakdown_element_structure associations:−−4.3.3.5

A parent association with an instance of Breakdown_element_usage_in_breakdown,
representing the Breakdown_element_revision that is defined as the parent element in theassociated Breakdown_revision
A child association with an instance of Breakdown_element_usage_in_breakdown,
representing the Breakdown_element_revision that is defined as the child element in theassociated Breakdown_revision

Breakdown_element
The Breakdown_element class is used to represent eg a system, subsystem, function, zone,
hardware item, software item, etc, that is part of one or many Breakdowns and revisions
thereof.
Note
Breakdown_element is defined as an abstract class, ie this class will never be instantiated,but any of its subclasses will. Subclasses of Breakdown_element are:••••Hardware_element (defined in UoF Breakdown Element Realization below)
Software_element (defined in UoF Breakdown Element Realization below)
Zone_element (defined in UoF Breakdown Zone Element below)
Aggregated_element (defined in UoF Breakdown Aggregated Element below)

Breakdown_element attributes:−−

Breakdown_element_identifier (one or many)
Breakdown_element_name (zero , one or many)

Breakdown_element associations:−−−4.3.3.6

An association with the different Breakdown_element_revisions (design iterations) of the
Breakdown_element
A Breakdown_element can relate to one or many other Breakdown_elements via the
Breakdown_element_relationship association
A Breakdown_element can be related to from one or many other Breakdown_elements via
the Breakdown_element_relationship association

Breakdown_element_revision
The Breakdown_element_revision class defines a revision (design iteration) of a breakdown
element.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 31

S3000L-B6568-03000-00

Note
Revisions of Breakdown_elements are often defined during product design.
Note
Breakdown_element_revision is defined as an abstract class, ie this class will never be
instantiated but any of its subclasses will. Subclasses of Breakdown_element_revison are:••••Hardware_element_revision (defined in UoF Breakdown Element Realization below)
Software_element_revision (defined in UoF Breakdown Element Realization below)
Zone_element_revision (defined in UoF Breakdown Zone Element below)
Aggregated_element_revision (defined in UoF Breakdown Aggregated Element below)

Breakdown_element_revision attributes:−−−−

Breakdown_element_revision_identifier
Breakdown_element_revision_creation_date (zero or one)
Breakdown_element_revision_status (zero or one)
Maintenance_significant_or_relevant_indicator

Breakdown_element_revision associations:−−

An association with the Breakdown_element of which the Breakdown_element_revision is arevision
Associations with one or many Breakdown_element_usage_in_breakdown, ie usages of the
Breakdown_element_revision in one or many Breakdown_revisions of a ProductNote
A revision of a breakdown element can be used in one or many breakdowns via the
Breakdown_revision and Breakdown_element_usage_in_breakdown. This means that thesame Breakdown_element_revision may be re-used in between different types ofbreakdowns for a single Product, as well as be re-used in between Products.
4.3.3.7

Breakdown_element_relationship
The Breakdown_element_relationship class is an association class, which adds information to adefined relationship between two Breakdown_elements.
Note
Breakdown_element_relationship can be used to represent the functional/physicalbreakdown element relationship as defined in GEIA-STD-0007.
Note
Breakdown_element_relationship can be used to represent, eg the use of software in
hardware.
Breakdown_element_relationship attributes:−

4.3.4
4.3.4.1

Breakdown_element_relationship_type

UoF Breakdown Structure - Additions to referenced class and interface definitions
Product
The Product class defined in UoF Project, must also implement the following additional
association:−

An association with one or many Breakdowns

4.4

UoF Part

4.4.1

Overall description
The UoF Part is used to represent hardware items as well as software.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 32

S3000L-B6568-03000-00

Part in S3000L represents an abstract class, and an instance of a part must be either a
Hardware_part or a Software_part.
Parts can be used to realize breakdown elements in a breakdown of a product, as well as play
the role of a resource in a maintenance task.
A part can have one or more alternate parts. The alternate part is interchangeable with the base
part in any/all uses.
Parts can be organized into Bill-Of-Materials (BOM), ie parts can consist of other parts.
A part used in a Bill-Of-Material (BOM) can have one or many substitute parts. As opposed tothe alternate part, which is context free, this substitute part is context dependent. The substitutepart is only valid in the context of its usage as a component within the specified BOM.
Materials (often hazardous) are defined separately, and are then associated with the parts inwhich they are being used.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 33

S3000L-B6568-03000-00

4.4.2

Graphical representation

ICN-B6865-S3000L0218-002-01
Fig 19 Part - class model
4.4.3
4.4.3.1

UoF Part - New class and interface definitions
Part
Part is a discrete object that may come into existence as a consequence of a manufacturing
process (Source: ISO 10303:239 Product Life Cycle Support).
A part can be at any indenture level in a part structure, ie a part can be an assembly as well as
an equipment, component or software package.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 34

S3000L-B6568-03000-00

NotePart is an abstract class, ie an instantiation of Part needs to be either a Hardware_part or a
Software_part.
Part attributes:
−
−
−
−
−
−

Part_identifier (one or many)
Part_name (one or many)
Part_special_handling (zero or one)
Part_maturity (zero, one or many)
Part_obsolescence_risk_assessment (zero, one or many)
Part_demilitarization_class (zero or one)

Note
Examples of different Part_identifiers are; Original Equipment Manufacturer (OEM) partnumbers, Supplier part numbers etc.
Note
A part can have more than one Part_maturity classification. This will most likely reflectchanges in part maturity over time. If the Date attribute included in the Classification data
type is not enough to determine the validity of the respective Part_maturity value, thenApplicability_statement (refer to UoF Applicability statement) can be used to further
determine the applicability of the respective value.
Note
A part can have more than one Part_obsolescence_risk_assessment description. This will
most likely reflect changes in part obsolescence risk assessment over time. If the Dateattribute included in the Classification data type is not enough to determine the validity of
the respective Part_obsolescence_risk_assessment value, then Applicability_statement(refer to UoF Applicability statement) can be used to further determine the applicability of
the respective value.
Part associations:−−−−4.4.3.2

A part can be associated with zero, one or many other parts, which the part underconsideration consists of (via the parent association with the Parts_list_entry class)
A part can be associated with zero, one or many other parts, which the part underconsideration is part of (via the child association with the Parts_list_entry class)
A part can refer to zero, one or many alternate parts (via the base association with the
Alternate_part_relationship class)
A part can be an alternate part for one or many other parts (defined via the alternate
association with the Alternate_part_relationship class)

Alternate_part_relationship
The Alternate_part_relationship class is used to define alternate parts. An alternate part isinterchangeable with the base part in all its usages. The alternate part is a context independent
alternate that is form, fit, and function equivalent in any use (Source: ISO 10303:239 Product
Life Cycle Support).
Note
Alternate_part_relationship defines one alternate Part at the time, and applies both toHardware_parts and Software_parts.
Note
Each instance of Alternate_part_relationship may have an associated Applicability
statement (refer to UoF Applicability Statement).
Alternate_part_relationship associations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 35

S3000L-B6568-03000-00−−
4.4.3.3

An association with the base (primary) Part for which an alternate is specified
An association with the Part that may replace the base Part in all its usages.

Parts_list_entry
The Parts_list_enty class is being used to hierarchically organize Bill-of-Materiels (BOM) for a
Part.
Note
Parts_list_entry defines one “row” at the time in a Bill-of-Material, ie there is one instance ofParts_list_entry per contained part. There is no explicit class in the data model that
represents a complete Bill-of-Material.
Note
The Parts_list_entry applies both to Hardware_parts and Software_parts, and a Bill-ofMaterial may consist of both Hardware_parts and Software_parts.
Parts_list_entry attributes:−−−−

Parts_list_entry_identifier (zero, one or many)
Quantity_of_child_elements
Physical_replaceability
Replaceability_strategy (zero, one or many)

Note
Physical_replaceability and Replaceability_strategy in the context of a Parts_list_entry areused to define if the child part can be replaced in its parent part, and if so at what
maintenance level.
Parts_list_entry associations:−−−−

An association with an instance of Part that is the parent part in the Bill-of-Material
relationshipAn association with an instance of Part that is the child part in the Bill-of-Material
relationshipAn association with zero, one or many Parts_list_entries that specifies substitute Parts for a
specific Parts_list_entry (defined using the base_parts_list_entry association with theSubstitute_part_relationship class)An association with zero or one base Parts_list_entry, for which the Parts_list_entry underconsideration may be used in place of (defined using the substitute_part_list_entry
association with the Substitute_part_relationship class)Parts_list_entry special recommendations:−4.4.3.4

A Part included in another Part can have multiple Replaceability_strategies (ie values of theattribute Replaceability_strategy). Each Replaceability_strategy value (ie instance of data
type Class) must have an associated Applicability_statement, as defined in the UoF
Applicability Statement, in order to define when the respective Replaceability_strategy isapplicable. The applicability statement will in most cases include Operator as one of theparameters to be evaluated.

Substitute_part_relationship
The Substitute_part_relationship class is used to define substitute Parts. As opposed to thealternate part, which is context free, substitute part is context dependent , ie theSubstitute_part_relationship is a relationship that indicates that one Parts_list_entry instancecan be substituted by another instance of Parts_list_entry, where both instances ofParts_list_entry refers to the same parent Part, (Source: ISO 10303:239 Product Life Cycle
Support).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 36

S3000L-B6568-03000-00

Note
Substitute_part_relationship defines one substitute Part at the time, and applies both toHardware_parts and Software_parts.
Substitute_part_relationship attributes:−

Parts_list_entry_substitute_identifier

Substitute_part_relationship associations:−−4.4.3.5

An association with the base Parts_list_entry for which a substitute is specified
An association with the substitute Parts_list_entry which may replace the baseParts_list_entry.

Hardware_part
The Hardware_part class is a specialization of class Part, and represents those parts that are
realized as physical items (hardware).
Hardware_part attributes:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Part_identifier (inherited from class Part)
Part_name (inherited from class Part)
Part_special_handling (inherited from class Part)
Part_maturity (inherited from class Part)
Part_obsolescence_risk_assessment (inherited from class Part)
Part_demilitarization_class (inherited from class Part)
Hardware_part_logistics_category
Repairability
Repairability_strategy (zero, one or many)
Hardware_part_maintenance_start (zero or one)
Hardware_part_material_hazardous_class (zero, one or many)
Hardware_part_waste_products_in_use_disposal_description (zero, one or many)
Hardware_part_waste_products_planned_disposal_description (zero, one or many)
Hardware_part_environmental_aspect_class_in_use (zero, one or many)
Hardware_part_environmental_aspect_class_planned_disposal (zero, one or many)
Hardware_part_scrap_rate (zero or one)Note
A part can have more than one
Hardware_part_waste_products_in_use_disposal_description and/or
Hardware_part_waste_products_planned_disposal_description. This will most likely reflectchanges in part waste products disposal descriptions over time.
Note
A part can have more than one Hardware_part_environmental_aspect_class_in_use and/or
Hardware_part_environmental_aspect_class_planned_disposal classification. This will
most likely reflect changes in hardware part environmental aspects over time.
Hardware_part associations:−−−

A Hardware_part can be associated with zero, one or many other parts (Hardware_parts
and/or Software_parts), which the Hardware_part under consideration consists of (inheritedfrom class Part)A Hardware_part can be associated with zero, one or many other parts (Hardware_parts
and/or Software_parts), which the Hardware_part under consideration is part of (inheritedfrom class Part)A Hardware_part can refer to zero, one or many alternate Hardware_parts (inherited fromPart class)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 37

S3000L-B6568-03000-00−−−

A Hardware_part can be an alternate Hardware_part for one or many other Hardware_parts(inherited from Part class)
A Hardware_part can have zero, one or many defined operational authorized lifes, as
defined by the Hardware_part_operational_authorized_life class
A Hardware_part can have zero, one or many associated Materials, included in the
Hardware_part

Hardware_part special recommendations:−4.4.3.6

A Hardware_part can have multiple Repairability_strategies (ie values for
Repairability_strategy). Each Repairability_strategy value (ie instance of the Class datatype) must have an associated Applicability_statement, as defined in the UoF Applicability
Statement, in order to define when respective Repairability_strategy is applicable. The
applicability statement will in most cases include Operator as one of the parameters to beevaluated.

Hardware_part_operational_authorized_life
Operational authorized life consists of the value pair for operational authorized life and theauthorizing organization.
Note
The same authorizing organization can be related to one or more operational authorized life
values for a Hardware_part since the Hardware_part_operational_authorized_life attribute
can have more than one value (ie instances of the Prp class).
Note
An instance of class Hardware_part_operational_authorized_life has no meaning by itself,
but only in the context of a specific Hardware_part.
Hardware_part_operational_authorized_life attributes:−

Hardware_part_operational_authorized_life (one or many)

Hardware_part_operational_authorized_life associations:−−

An instance of Hardware_part_operational_authorized_life is always associated with one
authorizing Organization
An instance of Hardware_part_operational_authorized_life is always associated with a
specific Hardware_part

Hardware_part_operational_authorized_life special recommendations:−−4.4.3.7

Representations of the value for the Hardware_part_operational_authorized_life attributeare recommended to use the Value_with_limit_property representation, where
Limit_qualifier is set to "maximum". There can also be cases where use ofValue_with_tolerances_property or Value_range_property is valid.
Where a Hardware_part has different operational authorized lives depending on, forexample, operational environments, these can be represented as a set of values of the
Hardware_part_operational_authorized_life attribute, but be distinguished by theassignment of an Applicability_statement to the respective instance of class Prp that
represents the individual value (also refer to Para 4.21, UoF Applicability Statement).

Material
The Material class deals with substances (mainly hazardous) that are used in one or many
Hardware_parts.
Material attributes:−−

Material_identifier (one or many)
Material_name (zero or one)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 38

S3000L-B6568-03000-00

−
−
−
−
−

Material_description (zero or one)
Material_substance_usage_category
Material_risk_description (one or many)
Material_risk_factor (zero or one)
Material_characteristics_recording_date

Material associations:−4.4.3.8

A Material can have zero, one or many associations with Hardware_parts in which theMaterial is being used.

Hardware_part_material_usage
The Hardware_part_material_usage class is an association class, which adds information to adefined relationship between a Material and the Hardware_part in which the Material is being
used. It can also record the quantity of the Material being used in the Hardware_part, and thejustification for its usage.
Hardware_part_material_usage attributes:−−

Quantity_of_material_included_in_hardware_part
Material_usage_justification_description (zero or one)

Note
There is one instance of Hardware_part_material_usage per relevant combination ofMaterial and Hardware_part.
4.4.3.9

Software_part
Software_part is a specialization of class Part, and represents those parts that are realized as
executable software or as data files (eg maps).
Software_part attributes:
−
−
−
−
−
−
−
−
−
−
−
−

Part_identifier (inherited from class Part)
Part_name (inherited from class Part)
Part_special_handling (inherited from class Part)
Part_maturity (inherited from class Part)
Part_obsolescence_risk_assessment (inherited from class Part)
Part_demilitarization_class (inherited from class Part)
Software_type
Software_release
Actual_software_size (zero or one)
Actual_number_of_lines_of_code (zero or one)
Actual_software_complexity_code (zero or one)
Software_technology (zero or one)

Software_part associations:−−−−

A Software_part can be associated with zero, one or many other parts (Hardware_parts
and/or Software_parts), which the Software_part under consideration consists of (inheritedfrom class Part)A Software_part can be associated with zero, one or many other parts (Hardware_parts
and/or Software_parts), which the Software_part under consideration is part of (inheritedfrom class Part)A Software_part can refer to zero, one or many alternate Software_parts (inherited fromclass Part)A Software_part can be an alternate Software_part for one or many other Software_parts(inherited from class Part)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 39

S3000L-B6568-03000-00

4.4.4
4.4.4.1

UoF Part - Additions to referenced class and interface definitions
Organization
The Organization class defined in UoF Project, must also implement the following additional
association:−

An optional association with zero, one or many instances of
Hardware_part_operational_authorized_life, in the role of authorizing_organization

4.5

UoF Breakdown Element Realization

4.5.1

Overall description
The Breakdown Element Realization UoF is used to:−−

Define hardware and software breakdown elements along with their realizations in terms ofhardware and software parts, respectively
Distinguish hardware and software breakdown elements from other types of breakdown
elements such as systems, zones

Note
The Hardware_element and Software_element classes are both specializations of the class
Breakdown_element which means that, wherever the class Breakdown_element is being
used in the data model, Hardware_element or Software_element can be used instead (therule of substitutability).
The Hardware_element_revision and Software_element_revision classes are both
specializations of the class Breakdown_element_revision which means that, wherever theclass Breakdown_element_revision is being used in the data model,
Hardware_element_revision or Software_element_revision can be used instead (the rule ofsubstitutability).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 40

S3000L-B6568-03000-00

4.5.2

Graphical representation

ICN-B6865-S3000L0219-002-01
Fig 20 Breakdown Element Realization - class model
4.5.3
4.5.3.1

UoF Breakdown Element Realization - New class and interface definitions
Hardware_element
The Hardware_element class is a specialization of Breakdown_element, and is used torepresent physical breakdown elements that are to be realized as hardware parts (often referred
to as equipments).
Hardware_element attributes:−−−

Breakdown_element_identifier (inherited from class Breakdown_element)
Breakdown_element_name (inherited from class Breakdown_element)
Hardware_element_type (zero or one)

Hardware_element associations:−

An association with the different Hardware_element_revisions (design iterations) of the
Hardware_element

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 41

S3000L-B6568-03000-00−−

4.5.3.2

A Hardware_element can relate to one or many other Breakdown_elements via the
Breakdown_element_relationship (inherited from class Breakdown_element)
A Hardware_element can be related to from one or many other Breakdown_elements via
the Breakdown_element_relationship (inherited from class Breakdown_element)

Hardware_element_revision
The Hardware_element_revision class is a specialization of Breakdown_element_revision, andis used to represent revisions of physical breakdown elements that are to be realized as
Hardware_parts.
Hardware_element_revision attributes:
−
−
−
−
−
−
−
−
−

Breakdown_element_revision_identifier (inherited from class Breakdown_element_revision)
Breakdown_element_revision_creation_date (inherited from class
Breakdown_element_revision)
Breakdown_element_revision_status (inherited from class Breakdown_element_revision)
Maintenance_significant_or_relevant_indicator (inherited from class
Breakdown_element_revision)
Structural_indicator
Functional_replaceability
Replaceability_strategy (zero, one or many)
Repairability
Repairability_strategy (zero, one or many)

Hardware_element_revision associations:−−−

An association with the Hardware_element of which the Hardware_element_revision is arevision
Associations with one or many Breakdown_element_usage_in_breakdown, ie usages of the
Hardware_element_revision in one or many Breakdown_revisions of a Product (inheritedfrom class Breakdown_element_revision)
An optional association with zero, one or many Hardware_parts that can be used to realize
the defined Hardware_element_revision, via the Hardware_element_realization class

Hardware_element_revision special recommendations:−−4.5.3.3

A Hardware_element_revision can have multiple Replaceability_strategies (ie values of theattribute Replaceability_strategy). Each Replaceability_strategy value (ie instance of Class)must have an associated Applicability_statement, as defined in the UoF Applicability
Statement, in order to define when the respective Replaceability_strategy is applicable. The
applicability statement will in most cases include Operator as one of the parameters to beevaluated.
A Hardware_element_revision can have multiple Repairability_strategies (ie values for
Repairability_strategy). Each Repairability_strategy value (ie instance of Class) must havean associated Applicability_statement, as defined in UoF Applicability Statement, in order todefine when respective Repairability_strategy is applicable. The applicability statement willin most cases include Operator as one of the parameters to be evaluated.

Hardware_element_realization
The Hardware_element_realization class defines an association between an instance ofHardware_element_revision and its Hardware_part realization.
Hardware_element_realization associations:−−

An association with the instance of Hardware_element_revision that has a Hardware_part
realization
An association with the instance of Hardware_part that is the realization of the
Hardware_element_revision

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 42

S3000L-B6568-03000-00

Note
There is one instance of Hardware_element_realization per relevant combination of
Hardware_element_revision and Hardware_part.
Hardware_element_realization special recommendations:−4.5.3.4

Where an instance of Hardware_element_realization is dependent upon Product_variant or
Product_variant_realization, it must be distinguished by the assignment of a
Product_variant_realization_applicability to the instance of Hardware_element_realization(refer to Para 4.8, UoF Product variant applicability).

Software_element
The Software_element class is a specialization of Breakdown_element, and is used torepresent breakdown elements that are to be realized in terms of software.
Software_element attributes:−−−

Breakdown_element_identifier (inherited from class Breakdown_element)
Breakdown_element_name (inherited from class Breakdown_element)
Software_element_type (zero or one)

Software_element associations:−−−4.5.3.5

An association with the different Software_element_revisions (design iterations) of the
Software_element
A Software_element can relate to one or many other Breakdown_elements via the
Breakdown_element_relationship (inherited from class Breakdown_element)
A Software_element can be related to from one or many other Breakdown_elements via the
Breakdown_element_relationship (inherited from class Breakdown_element)

Software_element_revision
The Software_element_revision class is a specialization of Breakdown_element_revision, and isused to represent revisions (design iterations) of breakdown elements that are to be realized asa Software_parts.
Software_element_revision attributes:
−
−
−
−
−
−
−
−

Breakdown_element_revision_identifier (inherited from class Breakdown_element_revision)
Breakdown_element_revision_creation_date (inherited from class
Breakdown_element_revision)
Breakdown_element_revision_status (inherited from class Breakdown_element_revision)
Maintenance_significant_or_relevant_indicator (inherited from class
Breakdown_element_revision)
Estimated_software_size (zero or one)
Estimated_number_of_lines_of_code (zero or one)
Estimated_software_complexity_code (zero or one)
Estimated_software_modification_frequency (zero or one)

Software_element_revision associations:−−−

An association with the Software_element of which the Software_element_revision is arevision
Associations with one or many Breakdown_element_usage_in_breakdown, ie usages of the
Software_element_revision in one or many Breakdown_revisions of a Product (inheritedfrom class Breakdown_element_revision)
An optional association with zero, one or many Software_parts that can be used to realize
the defined Software_element_revision, via the Software_element_realization class

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 43

S3000L-B6568-03000-00

4.5.3.6

Software_element_realization
The Software_element_realization class defines an association between an instance ofSoftware_element_revision and its Software_part realization.
Software_element_realization associations:−−

An association with the instance of Software_element_revision that has a Software_part
realization
An association with the instance of Software_part that is the realization of the
Software_element_revision

Note
There is one instance of Software_element_realization per relevant combination ofSoftware_element_revision and Software_part.
Software_element_realization special recommendations:−

4.5.4
4.5.4.1

UoF Breakdown Element Realization - Additions to referenced class and interface
definitions
Hardware_part
The Hardware_part class defined in UoF Part, must also implement the following additional
association:−

4.5.4.2

Where an instance of Software_element_realization is dependent upon Product_variant or
Product_variant_realization, it must be distinguished by the assignment of a
Product_variant_realization_applicability to the instance of Software_element_realization(refer to Para 4.8, UoF Product Variant Applicability).

An optional association with zero, one or many instances of Hardware_element_realization

Software_part
The Software_part class defined in UoF Part, must also implement the following additional
association:−

An optional association with zero, one or many instances of Software_element_realization

4.6

UoF Breakdown Zone Element

4.6.1

Overall description
The Breakdown Zone Element UoF is used to distinguish between zonal breakdown elements
and other types of breakdown elements (eg hardware, software).
Note
Zone elements can be used to define eg zones within a product, as well as generic work
areas, eg a mechanical workshop.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 44

S3000L-B6568-03000-00

4.6.2

Graphical representation

ICN-B6865-S3000L0220-002-01
Fig 21 Breakdown Zone Element - class model
4.6.3
4.6.3.1

UoF Breakdown Zone Element - New class and interface definitions
Zone_element
The Zone_element class is a specialization of Breakdown_element, and is used to represent
breakdown elements that are defined in terms of zones within a product, or work areas such asa mechanical workshop.
Note
Wherever the Breakdown_element class is used in the data model, Zone_element can beused instead (the rule of substitutability).
Zone_element attributes:−−−

Breakdown_element_identifier (inherited from class Breakdown_element)
Breakdown_element_name (inherited from class Breakdown_element)
Zone_element_type (zero or one)

Zone_element associations:−−−4.6.3.2

An association with the different Zone_element_revisions (design iterations) of the
Zone_element
A Zone_element can relate to one or many other Breakdown_elements via the
Breakdown_element_relationship (inherited from class Breakdown_element)
A Zone_element can be related to from one or many other Breakdown_elements via the
Breakdown_element_relationship (inherited from class Breakdown_element)

Zone_element_revision
The Zone_element_revision class is a specialization of Breakdown_element_revision, and isused to represent revisions of zone elements.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 45

S3000L-B6568-03000-00

Note
Wherever the Breakdown_element_revision class is used in the data model,
Zone_element_revision can be used instead (the rule of substitutability). For example, an
instance of Zone_element_revision can be used in one or many types of breakdowns andrevisions thereof.
Zone_element_revision attributes:
−
−
−
−
−

Breakdown_element_revision_identifier (inherited from class Breakdown_element_revision)
Breakdown_element_revision_creation_date (inherited from class
Breakdown_element_revision)
Breakdown_element_revision_status (inherited from class Breakdown_element_revision)
Maintenance_significant_or_relevant_indicator (inherited from class
Breakdown_element_revision)
Zone_element_description (zero or one)

Zone_element_revision associations:−−−4.6.3.3

An association with the Zone_element of which the Zone_element_revision is a revision
Associations with one or many Breakdown_element_usage_in_breakdown, ie usages of the
Zone_element_revision in one or many Breakdown_revisions of a Product (inherited fromclass Breakdown_element_revision).
Associations with zero, one or many instances of Hardware_element_revision that arelocated in the zone, via the Hardware_element_in_zone_relationship class.

Hardware_element_in_zone_relationship
The Hardware_element_in_zone_relationship class defines an association between an instanceof Hardware_element_revision and its zonal location.
Hardware_element_in_zone_relationship associations:−−

An association with the instance of Hardware_element_revision that has a zonal location
An association with the instance of Zone_element_revision in which the hardware element
is located

Note
There is one instance of Hardware_element_in_zone_relationship per relevant combinationof Hardware_element_revision and Zone_element_revision.
Hardware_element_in_zone_relationship special recommendations:−

4.6.4
4.6.4.1

Where a Hardware_element_in_zone_relationship is dependent upon a Product_variant, it
must be distinguished by assigning a Product_variant_applicability to the
Hardware_element_in_zone_relationship (refer to Para 4.8, UoF Product Variant
Applicability).

UoF Breakdown Zone Element - Additions to referenced class and interface definitions
Hardware_element_revision
The Hardware_element_revision class defined in UoF Breakdown Element Realization, mustalso implement the following additional association:−

An optional association with zero, one or many Hardware_element_in_zone_relationship

4.7

UoF Breakdown Aggregated Element

4.7.1

Overall description
The Breakdown Aggregated Element UoF is used to distinguish between aggregated (orabstract) breakdown elements (systems, functions, slots etc) and other types of breakdown
elements (eg hardware, software).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 46

S3000L-B6568-03000-00

Note
Aggregated breakdown elements of type ‘System’ and ‘Function’ can have a set of childbreakdown elements (refer to Para 4.3 UoF Breakdown Structure). These child elements
are to be seen as a whole-parts relationship, ie all children must exist in order for the parent
system or function to be complete (exception if there is any defined
Product_variant_applicability statement as defined in Para 4.8 UoF Product Variant
Applicability). However aggregated breakdown elements of type ‘Slot’ indicates that all childelements are alternativ breakdown elements which can be used in the defined slot location.
4.7.2

Graphical representation

ICN-B6865-S3000L0221-001-01
Fig 22 Breakdown Aggregated Element - class model
4.7.3
4.7.3.1

UoF Breakdown Aggregated Element - New class and interface definitions
Aggregated_element
The Aggregated_element class is a specialization of Breakdown_element, and is used for
representing abstract breakdown elements, eg a system, function or a slot.
Note
Wherever the Breakdown_element class is used in the data model, Aggregated_element
can be used instead (the rule of substitutability).
Aggregated_element attributes:−−−

Breakdown_element_identifier (inherited from class Breakdown_element)
Breakdown_element_name (inherited from class Breakdown_element)
Aggregated_element_type (zero or one)

Aggregated_element associations:−−−4.7.3.2

An association with the different Aggregated_element_revisions (design iterations) of theAggregated_element
An Aggregated_element can relate to one or many other Breakdown_elements via the
Breakdown_element_relationship (inherited from class Breakdown_element)
An Aggregated_element can be related to from one or many other Breakdown_elements via
the Breakdown_element_relationship (inherited from class Breakdown_element)

Aggregated_element_revision
The Aggregated_element_revision class is a specialization of Breakdown_element_revision,and is used to represent revisions of Aggregated_element.
Note
Wherever Breakdown_element_revision is used in the data model,
Aggregated_element_revision can be used instead (the rule of substitutability). Eg an
instance of Aggregated_element_revision can be used in one or many types of breakdowns(and revisions thereof).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 47

S3000L-B6568-03000-00

Aggregated_element_revision attributes:
−
−
−
−
−

Breakdown_element_revision_identifier (inherited from class Breakdown_element_revision)
Breakdown_element_revision_creation_date (inherited from class
Breakdown_element_revision)
Breakdown_element_revision_status (inherited from class Breakdown_element_revision)
Maintenance_significant_or_relevant_indicator (inherited from class
Breakdown_element_revision)
Aggregated_element_description (zero or one)

Aggregated_element_revision associations:−−

An association with the Aggregated_element of which the Aggregated_element_revision isa revision
Associations with one or many Breakdown_element_usage_in_breakdown, ie usages of theAggregated_element_revision in one or many Breakdown_revisions of a Product (inheritedfrom class Breakdown_element_revision)

4.8

UoF Product Variant Applicability

4.8.1

Overall description
The Product Variant Applicability UoF enables the definition of product models which areavailable or delivered to the customer in different configurations or variations. A variation orconfiguration of a product is defined by applying restrictions to the generic product breakdown
and its breakdown elements realizations, respectively.
Note
Product data standards such as ISO 10303, often use the term effectivity to describe
product design related restrictions, where the restriction defines the planned usage ofcomponents in the context of a particular product configuration.
The Product Variant Applicability UoF enables specification of valid use of:−−Breakdown elements in the context of a Breakdown_revisionParts in the context of a particular Product_variant_realization (also often referred to as a
Product configuration)

This UoF defines two types of product design related applicability’s:−

Product_variant_applicability••−

Constrains the usage of a Breakdown_element_revision within a Breakdown_revision
to a specific Product_variant (also known in GEIA-STD-0007 as System/End Item
Usable On Code).
Constrains the zonal location (Zone_element_revision) for a
Hardware_element_revision to a specific Product_variant.

Product_variant_realization_applicability•

Constrains a Hardware_element_realization, Software_element_realization and/orParts_list_entry to a specific realization (configuration) of a Breakdown_revision.

Note
Information regarding Product_variant_applicability's, andProduct_variant_realization_applicability's, is often received from the design department as
part of the product definition. This information often originates from of some kind of PDMsystem.
Note
The use of Product_variant_applicability's, and Product_variant_realization_applicability's,
enable reuse of product breakdowns between different Product_variants and realizations
thereof.
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 48

S3000L-B6568-03000-00

Note
If Product_variant_applicability’s, and Product_variant_realization_applicability’s are used
to restrict the applicability of elements within breakdown, then it needs to be explicitly
defined for each Breakdown_revision.
Note
Product_variant_applicability’s and Product_variant_realization_applicability’s helps the
LSA analyst to filter out the Breakdown_elements and/or Parts that are within scope of a
specific Product_variant, and realization thereof.
Note
Product_variant_applicability and Product_variant_realization_applicability are used todefine restrictions for a given product design (product definition), whereas
Applicability_statement (refer to Para 4.21, UoF Applicability Statement) is used to define
usage related restrictions.
4.8.2

Graphical representation

ICN-B6865-S3000L0222-002-01
Fig 23 Product Variant Applicability - class model
4.8.3
4.8.3.1

UoF Product Variant Applicability - New class and interface definitions
Product_variant_applicability
The Product_variant_applicability class defines that the usage of a
Breakdown_element_revision, or a zonal location for a Hardware_element_revision,(applicability_target) is limited to a specific Product_variant.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 49

S3000L-B6568-03000-00

Note
Product_variant_applicability can be used for representing GEIA-STD-0007 System/End
Item Usable On Codes.
Note
Instances of Breakdown_element_usage_in_breakdown andHardware_element_in_zone_relationship without any associatedProduct_variant_applicability, means that the respective usage and zonal location of theassociated Breakdown_element_revision, is valid for all Product_variants
Note.
An instances of Breakdown_element_usage_in_breakdown andHardware_element_in_zone_relationship that has an associatedProduct_variant_applicability, needs one instance of Product_variant_applicability per
Product_variant for which the respective instance ofBreakdown_element_usage_in_breakdown or Hardware_element_in_zone_relationship isapplicable.
Product_variant_applicability associations:−−

An association with the Product_variant for which the applicability_target is valid.
An association with the applicability_target (ie an instance of any class that implements the
Product_variant_applicability_interface), which is valid in the resolved Product_variant.

Note
There is one instance of Product_variant_applicability per relevant combination of
Product_variant and applicability_target (ie instance of either a
Breakdown_element_usage_in_breakdown or Hardware_element_in_zone_relationship).
4.8.3.2

Product_variant_applicability_interface
The Product_variant_applicability_interface is implemented by classes that can be the target for
an instance of Product_variant_applicability.
Classes that implement the Product_variant_applicability_interface interface:−−

Breakdown_element_usage_in_breakdown
Hardware_element_in_zone_relationshipClasses that implement the Product_variant_applicability_interface must also implement thefollowing associations:−An optional association with zero, one or many instances of Product_variant_applicability.

Note
An instance of the class that is the applicability_target can have more than one associatedProduct_variant_applicability, ie the instance being the applicability_target is applicablewithin more than one Product_variant.
4.8.3.3

Product_variant_realization
Product_variant_realization defines an approved realization of a Breakdown_revision, andcontrols which parts are allowed to realize the respective Hardware_element_revision,
Software_element_revision, and Parts_list_entry which are part of the defined
Breakdown_revision, for a particular Product_variant. This is managed through the usage of the
Product_variant_realization_applicability class.
Note
Product data standards such as ISO 10303 often use the term product configuration todescribe the planned usage of components in the context of a particular productconfiguration.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 50

S3000L-B6568-03000-00

Product_variant_realization attributes:−−−

Product_variant_realization_identifier
Product_variant_realization_revision_identifier
Product_variant_realization_revision_creation_date (zero or one)

Product_variant_realization associations:−−

4.8.3.4

An association with the Breakdown_revision for which the Product_variant_realization isdefined.
Associations with the Hardware_element_realizations, Software_element_realizations
and/or Parts_list_entries that is applicable for the Product_variant_realization underconsideration (via Product_variant_realization_applicability).

Product_variant_realization_applicability
The Product_variant_realization_applicability class defines an association between the resolved
Product_variant_realization and the elements (applicability_targets) which are applicable within
the Product_variant_realization under consideration.
Product_variant_realization_applicability associations:−−

An association with the Product_variant_realization for which the applicability_target isvalid.
An association with the applicability_target (ie an instance of any class that implements the
Product_variant_realization_applicability_interface, ie an instance of either
Hardware_element_realization, Software_element_realization or Parts_list_entry) which isvalid in the resolved Product_variant_realization.

Note
There is one instance of Product_variant_realization_applicability per relevant combinationof Product_variant_realization and applicability_target.
Note
An instance of Hardware_element_realization, Software_element_realization orParts_list_entry that does not have an associated Product_variant_realization_applicability
means that the instance is valid for all Product_variants and realizations thereof.
Note
An instances of Hardware_element_realization, Software_element_realization orParts_list_entry that has an assigned Product_variant_realization_applicability, need an
instance of Product_variant_realization_applicability per Product_variant_realization forwhich the Hardware_element_realization, Software_element_realization or Parts_list_entry
is applicable.
4.8.3.5

Product_variant_realization_applicability_interface
The Product_variant_realization_applicability_interface is implemented by classes that can be
the target for a Product_variant_realization_applicability.
Classes that implement the Product_variant_realization_applicability_interface interface:−−−

Hardware_element_realization
Software_element_realization
Parts_list_entry

Classes that implement the Product_variant_realization_applicability_interface must also
implement the following association:−

An optional association with zero, one or many instances of
Product_variant_realization_applicability

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 51

S3000L-B6568-03000-00

Note
An instance of the class that is the applicability_target can have more than one associatedProduct_variant_realization_applicability, ie the instance being the applicability_target isapplicable within more than one Product_variant_realization.
4.8.4
4.8.4.1

UoF Product Variant Applicability - Additions to referenced class and interface
definitions
Product_variant
The Product_variant class defined in UoF Project, must also implement the following additional
association:−

4.8.4.2

Breakdown_revision
The Breakdown_revision class defined in UoF Breakdown Structure must also implement thefollowing additional association:−

4.8.4.3

Product_variant_realization_applicability_interface

Software_element_realization
The Software_element_realization class defined in UoF Breakdown Element Realization, mustalso implement the following additional interface:−

4.8.4.7

Product_variant_applicability_interface

Hardware_element_realization
The Hardware_element_realization class defined in UoF Breakdown Element Realization, mustalso implement the following additional interface:−

4.8.4.6

Product_variant_applicability_interface

Hardware_element_in_zone_relationship
The Hardware_element_in_zone_relationship class defined in UoF Breakdown Zone Element,
must also implement the following additional interface:−

4.8.4.5

An optional association with zero, one or many instances of Product_variant_realization

Breakdown_element_usage_in_breakdown
The Breakdown_element_usage_in_breakdown class defined in UoF Breakdown Structure,must also implement the following additional interface:−

4.8.4.4

An optional association with zero, one or many instances of Product_variant_applicability

Product_variant_realization_applicability_interface

Parts_list_entry
The Parts_list_entry class defined in UoF Part, must also implement the following additional
interface:−

Product_variant_realization_applicability_interface

4.9

UoF LSA Candidate

4.9.1

Overall description
The LSA Candidate UoF supports the selection of LSA candidates and the definition of the key
performance indicators per selected LSA candidate.
Note
The recommendation is to select the LSA Candidates from a top-down perspective, ie
starting with the root Breakdown Element node for a given Product_variant and thenApplicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 52

S3000L-B6568-03000-00

traverse through the Breakdown Structure and its part realizations (includingParts_list_entries).
Note
Key performance indicators define the requirements for the project, and are often defined
during the early stages of the LSA project (program).
Note
The process of distributing a key performance indicator between sub elements using eg
fractions is not explicitly supported in the data model. However, the data model supports
the recording of the resulting values against the respective sub element. Key performanceparameters that are the result of a distribution process, eg by fraction, are recommended to
set the value of the Key_performance_indicator_type attribute to “Distributed”.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 53

S3000L-B6568-03000-00

4.9.2

Graphical representation

ICN-B6865-S3000L0223-002-01
Fig 24 UoF LSA Candidate - class model
4.9.3
4.9.3.1

UoF LSA Candidate - New class and interface definitions
LSA_candidate
The LSA_candidate interface is implemented by classes that can be selected as LSA
Candidates.
Classes that implement the LSA_candidate interface:−−

Breakdown_element_revisionPart

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 54

S3000L-B6568-03000-00

Note
Since the LSA_candidate interface is implemented by Breakdown_element_revision andPart respectively, it means that instances of the following classes can be selected as LSA
Candidates; Hardware_element_revision, Software_element_revision,
Aggregated_element_revision, Zone_element_revision, Hardware_part and Software_part.
Classes that implement the LSA_candidate interface must implement the following attributes:−−−−

LSA_candidate_indicator
LSA_candidate_rationale
LSA_candidate_maintenance_concept (zero or one)
LSA_candidate_maintenance_solution (zero or one)Classes that implement the LSA_candidate interface must implement the following association:−

An optional association with zero, one or many instances of Key_performance_indicator

Note
The associated Key_performance_indicators may be of any its specializations (egMean_time_between_failure, Down_time etc), as well as any number of eachspecialization.
4.9.3.2

Key_performance_indicator
The Key_performance_indicator class defines customer or user specific values per
LSA_candidate. The respective value can be eg specified, contracted, allocated, distributed or
actual.
Note
Requirements are often stated as product design and performance data in the contract.
Note
Key performance indicators can be defined for LSA Candidates at any level of indenture.
Note
An instance of class Key_performance_indicator has no meaning by itself, but only in thecontext of a specific LSA_candidate.
Note
Key_performance_indicator is an abstract class, ie an instantiation of
Key_performance_indicator needs to be either:
•
•
•
•
•
•
•
•
•
•
•
•
•

Product_service_life
Scheduled_maintenance_interval
Maintenance_free_operating_period
Down_time
Maintenance_man_hours_per_operating_hour
Mean_time_between_unscheduled_removal
Mean_time_to_repair
Direct_maintenance_cost
Shop_processing_time
Failures_per_operating_hour
Replacement_time
Mean_time_between_failure
Failure_rate

Key_performance_indicator attributes:−−

Key_performance_indicator_type
Key_performance_indicator_method (zero or one)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 55

S3000L-B6568-03000-00−−

Key_performance_indicator_status
Key_performance_indicator_percintile (zero or one)Note
The Key_performance_indicator class does not contain any key performance indicatorvalues. These are contained within the respective subclass of Key_performance_indicator,eg Product_service_life.
Key_performance_indicator associations:−−

An instance of Key_performance_indicator is always defined for a specific LSA_candidate
An association with zero, one or many Operators (ie customers or users) that approved the
Key_performance_indicator

Key_performance_indicator special recommendations:−

Where an instance of Key_performance_indicator is dependent upon eg operational
environment, it must be distinguished by the assignment of an Applicability_statement to the
Key_performance_indicator instance (also refer to Para 4.21, UoF Applicability Statement).

Note
An LSA Candidate can have more than one instance of the same
Key_performance_indicator (eg Mean_time_between_failure). These values can be defined
during different stages of the LSA candidate life cycle, eg one and the same LSA candidate
can have one ‘specified’ mean time between failure value, and one ‘actual’ mean time
between failure value.
4.9.3.3

Product_service_life
The Product_service_life class is a specialization of Key_performance_indicator, andrepresents the number of years the LSA Candidate is expected to be in service.
Product_service_life attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Product_service_life (the value itself)

Product_service_life associations:−−

An instance of Product_service_life is always defined for a specific LSA_candidate(inherited from class Key_performance_indicator).
An association with zero, one or many Operators (ie customers or users) that approved theProduct_service_life value (inherited from class Key_performance_indicator).

Product_service_life special recommendations:−−

An LSA_candidate can have multiple defined Product_service_life's depending on
operational environment, etc. If multiple Product_service_life’s are defined for the same
type of key performance indicator (eg ‘contracted’), these must be distinguished by theassignment of Applicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Product_service_life attribute are recommended to use the Value_with_limit_property
representation, where Limit_qualifier is set to ‘minimum’. However, there can also be cases
where the use of Value_with_tolerances_property or Value_range_property is valid.
Representation of actual values for Product_service_life is recommended to use theValue_with_unit representation.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 56

S3000L-B6568-03000-00

4.9.3.4

Scheduled_maintenance_interval
The Scheduled_maintenance_interval class is a specialization of Key_performance_indicator,
and represents the (minimum) number of operational units (eg rounds, miles, hours) between
scheduled maintenance.
Scheduled_maintenance_interval attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Scheduled_maintenance_interval (the value itself)

Scheduled_maintenance_interval associations:−−

An instance of Scheduled_maintenance_interval is always defined for a specific
LSA_candidate (inherited from class Key_performance_indicator)
An association with zero, one or many Operators (ie customers or users) that approved the
Scheduled_maintenance_interval value (inherited from class Key_performance_indicator)

Scheduled_maintenance_interval special recommendations:−−4.9.3.5

An LSA_candidate can have multiple defined Scheduled_maintenance_intervals dependingon operational environment, etc. If multiple Scheduled_maintenance_intervals are definedfor the same type of key performance indicator (eg "contracted"), these must be
distinguished by the assignment of Applicability_statement as defined in UoF Applicability
Statement.
Representations of specified, allocated, distributed and contracted values for the
Scheduled_maintenance_interval attribute are recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to "minimum".
However, there can also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid. Representation of actual values for
Scheduled_maintenance_interval is recommended to use the Value_with_unit
representation.

Maintenance_free_operating_period
The Maintenance_free_operating_period class is a specialization of
Key_performance_indicator, and represents the acceptable (minimum) maintenance free
operating period, where maintenance free operating period is the interval in which no
maintenance actions occur.
Maintenance_free_operating_period attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Maintenance_free_operating_period (the value itself)

Maintenance_free_operating_period associations:−−

An instance of Maintenance_free_operating_period is always defined for a specific
LSA_candidate (inherited from class Key_performance_indicator).
An association with zero, one or many Operators (ie customers or users) that approved theMaintenance_free_operating_period value (inherited from class
Key_performance_indicator).

Maintenance_free_operating_period special recommendations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 57

S3000L-B6568-03000-00−−

4.9.3.6

An LSA_candidate can have multiple defined Maintenance_free_operating_periods
depending on operational environment, etc. If multiple Maintenance_free_operating_periods
are defined for the same type of key performance indicator (eg ‘contracted’), these must be
distinguished by the assignment of Applicability_statement as defined in UoF Applicability
Statement.
Representations of specified, allocated, distributed, and contracted values for the
Maintenance_free_operating_period attribute are recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to ‘minimum’.
However, there can also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid. Representation of actual values for
Maintenance_free_operating_period is recommended to use the Value_with_unit
representation.

Down_time
The Down_time class is a specialization of Key_performance_indicator, and represents theacceptable (maximum) down time (MDT), where MDT is the time where an item is nonoperational.
Down_time attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Down_time (the value itself)

Down_time associations:−−

An instance of Down_time is always defined for a specific LSA_candidate (inherited fromclass Key_performance_indicator).
An association with zero, one or many Operators (ie customers or users) that approved the
Down_time value (inherited from class Key_performance_indicator).

Down_time special recommendations:−−4.9.3.7

An LSA_candidate can have multiple defined Down_times depending on operational
environment, etc. If multiple Down_times are defined for the same type of key performanceindicator (eg ‘contracted’), these must be distinguished by the assignment ofApplicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Down_time attribute are recommended to use the Value_with_limit_property representation,
where Limit_qualifier is set to ‘maximum’. However, there can also be cases where the useof Value_with_tolerances_property or Value_range_property is valid. Representation of
actual values for Down_time is recommended to use the Value_with_unit representation.

Maintenance_man_hours_per_operating_hour
The Maintenance_man_hours_per_operating_hour class is a specialization of
Key_performance_indicator, and represents the (maximum) acceptable maintenance man
hours per operating hour, where maintenance man hours per operating hour is the ratio of
maintenance man-hours expended to the operating interval (as defined by the measurementbase) of the system/equipment.
Maintenance_man_hours_per_operating_hour attributes:−−−−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 58

S3000L-B6568-03000-00−

Maintenance_man_hours_per_operating_hour (the value itself)

Maintenance_man_hours_per_operating_hour associations:−−

An instance of Maintenance_man_hours_per_operating_hour is always defined for a
specific LSA_candidate (inherited from class Key_performance_indicator)
An association with zero, one or many Operators (ie customers or users) that approved theMaintenance_man_hours_per_operating_hour value (inherited from class
Key_performance_indicator).

Maintenance_man_hours_per_operating_hour special recommendations:−−4.9.3.8

An LSA_candidate can have multiple defined
Maintenance_man_hours_per_operating_hours depending on operational environment, etc.
If multiple Maintenance_man_hours_per_operating_hours are defined for the same type of
key performance indicator (eg ‘contracted’), these must be distinguished by the assignmentof Applicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Maintenance_man_hours_per_operating_hour attribute are recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to ‘maximum’.
However, there can also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid. Representation of actual values for
Maintenance_man_hours_per_operating_hour is recommended to use the Value_with_unit
representation.

Mean_time_between_unscheduled_removal
The Mean_time_between_unscheduled_removal class is a specialization of
Key_performance_indicator, and represents the total number of operational units (eg, miles,
rounds, hours) divided by the total number of items removed from that system during a statedperiod of time. This term is defined to exclude removals as either being scheduled or performed
in order to facilitate other maintenance and removals for product improvement.
Mean_time_between_unscheduled_removal attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Mean_time_between_unscheduled_removal (the value itself)

Mean_time_between_unscheduled_removal associations:−−

An instance of Mean_time_between_unscheduled_removal is always defined for a specific
LSA_candidate (inherited from class Key_performance_indicator).
An association with zero, one or many Operators (ie customers or users) that approved the
Mean_time_between_unscheduled_removal value (inherited from class
Key_performance_indicator).

Mean_time_between_unscheduled_removal special recommendations:−−

An LSA_candidate can have multiple defined Mean_time_between_unscheduled_removals
depending on operational environment, etc. If multiple
Mean_time_between_unscheduled_removals are defined for the same type of key
performance indicator (eg ‘contracted’), these must be distinguished by the assignment ofApplicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Mean_time_between_unscheduled_removal attribute are recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to ‘minimum’.
However, there can also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid. Representation of actual values forApplicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 59

S3000L-B6568-03000-00

Mean_time_between_unscheduled_removal is recommended to use the Value_with_unit
representation.
4.9.3.9

Mean_time_to_repair
The Mean_time_to_repair class is a specialization of Key_performance_indicator, andrepresents the total elapsed time for corrective maintenance divided by the total number ofcorrective maintenance actions during a given period of time.
Mean_time_to_repair attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Mean_time_to_repair (the value itself)

Mean_time_to_repair associations:−−

An instance of Mean_time_to_repair is always defined for a specific LSA_candidate(inherited from class Key_performance_indicator).
An association with zero, one or many Operators (ie customers or users) that approved the
Mean_time_to_repair value (inherited from class Key_performance_indicator).

Mean_time_to_repair special recommendations:−−4.9.3.10

An LSA_candidate can have multiple defined Mean_time_to_repair values depending on
operational environment, etc. If multiple Mean_time_to_repair values are defined for thesame type of key performance indicator (eg ‘contracted’), these must be distinguished by
the assignment of Applicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Mean_time_to_repair attribute are recommended to use the Value_with_limit_property
representation, where Limit_qualifier is set to ‘maximum’. However, there can also be cases
where the use of Value_with_tolerances_property or Value_range_property is valid.
Representation of actual values for Mean_time_to_repair is recommended to use theValue_with_unit representation.

Direct_maintenance_cost
The Direct_maintenance_cost class is a specialization of Key_performance_indicator, andrepresents costs which include the shop maintenance man-hours, shop test man-hours, repair
cost (incl. required material). Statistical values which represent the occurrence rate like
MTBF(Mean Time Between Failure) and MTBUR (Mean Time Between Unscheduled Removal)
must be considered for that cost element.
Direct_maintenance_cost attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Direct_maintenance_cost (the value itself)

Direct_maintenance_cost associations:−−

An instance of Direct_maintenance_cost is always defined for a specific LSA_candidate(inherited from class Key_performance_indicator).
An association with zero, one or many Operators (ie customers or users) that approved the
Direct_maintenance_cost value (inherited from class Key_performance_indicator).

Mean_time_to_repair special recommendations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 60

S3000L-B6568-03000-00−−

4.9.3.11

An LSA_candidate can have multiple defined Direct_maintenance_costs depending on
operational environment, etc. If multiple Direct_maintenance_costs are defined for the same
type of key performance indicator (eg ‘contracted’), these must be distinguished by theassignment of Applicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Direct_maintenance_cost attribute are recommended to use the Value_with_limit_property
representation, where Limit_qualifier is set to ‘maximum’. However, there can also be cases
where the use of Value_with_tolerances_property or Value_range_property is valid.
Representation of actual values for Direct_maintenance_cost is recommended to use theValue_with_unit representation.

Shop_processing_time
The Shop_processing_time class is a specialization of Key_performance_indicator, andrepresents the duration from the start of the repair activities in the repair shop until the closing of
the repair procedure without considering any shipping and delay times.
Shop_processing_time attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Shop_processing_time (the value itself)

Shop_processing_time associations:−−

An instance of Shop_processing_time is always defined for a specific LSA_candidate(inherited from class Key_performance_indicator)
An association with zero, one or many operators (ie customers or users) that approved the
Shop_processing_time value (inherited from class Key_performance_indicator).

Shop_processing_time special recommendations:−−4.9.3.12

An LSA_candidate can have multiple defined Shop_processing_times depending on
operational environment, etc. If multiple Shop_processing_times are defined for the same
type of key performance indicator (eg "contracted"), these must be distinguished by theassignment of Applicability_statement as defined in UoF Applicability statement.
Representations of specified, allocated, distributed and contracted values for the
Shop_processing_time attribute are recommended to use the Value_with_limit_property
representation, where Limit_qualifier is set to "maximum". However, there can also becases where the use of Value_with_tolerances_property or Value_range_property is valid.
Representation of actual values for Shop_processing_time is recommended to use theValue_with_unit representation.

Failures_per_operating_hour
The Failures_per_operating_hour class is a specialization of Key_performance_indicator, andrepresents the failure rate, expressed in failures per operating hour.
The Failures_per_operating_hour defines a specified value which will be the maximum
acceptable failure behavior of a component..
Failures_per_operating_hour attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Failures_per_operating_hour (the value itself)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 61

S3000L-B6568-03000-00

Failures_per_operating_hour associations:−−

An instance of Failures_per_operating_hour is always defined for a specific LSA_candidate(inherited from class Key_performance_indicator)
An association with zero, one or many operators (ie customers or users) that approved the
Failures_per_operating_hour value (inherited from class Key_performance_indicator).

Failures_per_operating_hour special recommendations:−−4.9.3.13

An LSA_candidate can have multiple defined Failures_per_operating_hour depending on
operational environment, etc. If multiple Failures_per_operating_hour are defined for thesame type of key performance indicator (eg "contracted"), these must be distinguished by
the assignment of Applicability_statement as defined in UoF Applicability statement.
Representations of specified, allocated, distributed and contracted values for the
Failures_per_operating_hour attribute are recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to "maximum".
However, there can also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid. Representation of actual values for
Failures_per_operating_hour is recommended to use the Value_with_unit representation.

Replacement_time
The Replacement_time class is a specialization of Key_performance_indicator, and represents
the duration of the replacement of a (eg faulty) component within any technical system byanother (eg new) component.
Note
The contracted/allocated/specified Replacement_time defines a specified value which willbe the maximum acceptable duration for component replacement. In practice, this value
can be used to document eg a customer's requirement to be able to perform 98% of all
replacement tasks below a specified value of two hours (= maximum replacement time).
Replacement_time attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Replacement_time (the value itself)

Replacement_time associations:−−

An instance of Replacement_time is always defined for a specific LSA_candidate (inheritedfrom class Key_performance_indicator)
An association with zero, one or many operators (ie customers or users) that approved theReplacement_time value (inherited from class Key_performance_indicator).

Replacement_time special recommendations:−−

An LSA_candidate can have multiple defined Replacement_times depending on operational
environment, etc. If multiple Replacement_times are defined for the same type of key
performance indicator (eg "contracted"), these must be distinguished by the assignment ofApplicability_statement as defined in UoF Applicability statement.
Representations of specified, allocated, distributed and contracted values for the
Replacement_time attribute are recommended to use the Value_with_limit_property
representation, where Limit_qualifier is set to "maximum". However, there can also becases where the use of Value_with_tolerances_property or Value_range_property is valid.
Representation of actual values for Replacement_time is recommended to use theValue_with_unit representation.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 62

S3000L-B6568-03000-00

4.9.3.14

Mean_time_between_failure
The Mean_time_between_failure (MTBF) class is a specialization of
Key_performance_indicator, where the MTBF is the total operational life of a population of an
LSA Candidate divided by the total number of failures within the population during a particularmeasurement interval. The definition holds for time, rounds, miles, events, or other measure oflife units.
Mean_time_between_failure attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Mean_time_between_failure (the value itself)

Mean_time_between_failure associations:−−−

An instance of Mean_time_between_failure is always defined for a specific LSA_candidate(inherited from class Key_performance_indicator)
An association with zero, one or many operators (ie customers or users) that approved the
Mean_time_between_failure value (inherited from class Key_performance_indicator)
An optional association with zero, one or many instances of
Mean_time_between_failure_correction.

Mean_time_between_failure special recommendations:−−4.9.3.15

An LSA_candidate can have multiple defined Mean_time_between_failures depending on
operational environment, etc. If multiple Mean_time_between_failures are defined for thesame type of key performance indicator (eg "contracted"), these must be distinguished by
the assignment of Applicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Mean_time_between_failure attribute are recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to ‘minimum’.
However, there can also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid. Representation of actual values for
Mean_time_between_failure is recommended to use the Value_with_unit representation.

Mean_time_between_failure_correction
The Mean_time_between_failure_correction class defines correction factors for an associatedmean time between failure value. Mean_time_between_failure_correction can be defined fromeg the following perspectives:−−

Usage of the associated LSA_candidate under specific conditions, eg environment whichcauses additional stress to the system (sand, extreme temperatures, salty environment)
Usage of a Part at a specific location in a Product Breakdown.

Mean_time_between_failure_correction attributes:−−−

Mean_time_between_failure_correction_factor
Mean_time_between_failure_correction_justification
Mean_time_between_failure_correction_date

The Mean_time_between_failure_correction class must implement the following interfaces:−

Applicability_assignment (Refer to UoF Applicability Statement).

Mean_time_between_failure_correction association:−

An instance of Mean_time_between_failure_correction is always associated with a specificinstance of Mean_time_between_failure.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 63

S3000L-B6568-03000-00

Mean_time_between_failure_correction special recommendations:−4.9.3.16

The Mean_time_between_failure_correction is dependent upon eg operational environment,
its location within a Product etc. This condition must be made explicit by the assignment of
an Applicability_statement, as defined in UoF Applicability Statement.

Failure_rate
The Failure_rate class is a specialization of Key_performance_indicator, where the failure rateis the total number of failures within a population of an LSA_candidate item divided by the total
functional life of the population during the measurement interval. The definition holds for time,rounds, miles, cycles or other measures of life units..
Failure_rate attributes:
−
−
−
−
−

Key_performance_indicator_type (inherited from class Key_performance_indicator)
Key_performance_indicator_method (inherited from class Key_performance_indicator)
Key_performance_indicator_status (inherited from class Key_performance_indicator)
Key_performance_indicator_percintile (inherited from class Key_performance_indicator)
Failure_rate (the value itself)

Failure_rate associations:−−−

An instance of Failure_rate is always defined for a specific LSA_candidate (inherited fromclass Key_performance_indicator)
An association with zero, one or many operators (ie customers or users) that approved the
Failure_rate value (inherited from class Key_performance_indicator)
An optional association with zero, one or many instances of Failure_rate_correction.

Failure_rate special recommendations:−−4.9.3.17

An LSA_candidate can have multiple defined Failure_rates depending on operational
environment, etc. If multiple Failure_rates are defined for the same type of key performanceindicator (eg "contracted"), these must be distinguished by the assignment ofApplicability_statement as defined in UoF Applicability Statement.
Representations of specified, allocated, distributed and contracted values for the
Failure_rate attribute are recommended to use the Value_with_unit representation.
However, there can also be cases where the use of Value_with_limit_property,
Value_with_tolerances_property or Value_range_property is valid. Representation of actual
values for Failure_rate is recommended to use the Value_with_unit representation.

Failure_rate_correction
The Failure_rate_correction class defines correction factors for an associated failure rate value.
Failure_rate_correction can be defined from eg the following perspectives:−−

Usage of the associated LSA_candidate under specific conditions, eg environment whichcauses additional stress to the system (sand, extreme temperatures, salty environment)
Usage of a Part at a specific location in a Product Breakdown.

Failure_rate_correction attributes:−

Failure_rate_correction_factor

The Failure_rate_correction class must implement the following interfaces:−

Applicability_assignment (Refer to UoF Applicability Statement).

Failure_rate_correction associations:−

An instance of Failure_rate_correction is always associated with a specific instance ofFailure_rate.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 64

S3000L-B6568-03000-00

Failure_rate_correction special recommendations:−

4.9.4
4.9.4.1

UoF LSA Candidate - Additions to referenced class and interface definitionsPart
The Part class defined in UoF Part, must also implement the following additional interface:−

4.9.4.2

LSA_candidate

Breakdown_element_revision
The Breakdown_element_revision class defined in UoF Breakdown Structure, must also
implement the following additional interface:−

4.9.4.3

The Failure_rate_correction is dependent upon eg operational environment, its location
within a Product etc. This condition must be made explicit by the assignment of an
Applicability_statement, as defined in UoF Applicability Statement.

LSA_candidate

Operator
The operator interface defined in UoF Project, must also implement the following additional
association:−

An optional association with zero, one or many instances of Key_performance_indicators

4.10

UoF LSA Candidate Analysis Activity

4.10.1

Overall description
The LSA Candidate Analysis Activity UoF supports the selection and justification of Logistics
Support Analysis (LSA) activities to be performed for the respective LSA Candidate.
Note
LSA Candidate analysis activities are only to be documented for those parts andBreakdown_element_revisions that are identified as being LSA Candidates.
Note
There is no requirement that all types of LSA activities must be performed for every single
LSA Candidate, but there is a requirement to document the decision made for eachcombination of LSA Candidate and LSA activity.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 65

S3000L-B6568-03000-00

4.10.2Graphical representation

ICN-B6865-S3000L0224-002-01
Fig 25 LSA Candidate Analysis Activity - class model
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 66

S3000L-B6568-03000-00

4.10.34.10.3.1

UoF LSA Candidate Analysis Activity - New class and interface definitions
Candidate_item_analysis_activity
The Candidate_item_analysis_activity class identifies the LSA activities that are to be
performed for the respective LSA Candidate, the rationale behind it, and the recorded status forthe respective analysis activity.
Each identified LSA activity can also be associated with zero, one or many documents, eg
documents containing the results from the LSA activity.
Note
LSA activities are often selected during the LSA guidance conference.
Note
LSA activities can be defined for LSA Candidates at any level of indenture.
Note
The Candidate_item_analysis_activity class is an abstract class, ie the class itself will never
be instantiated but any of its subclasses can be. Subclasses of
Candidate_item_analysis_activity are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

LSA_candidate_comparative_analysis_activity
LSA_candidate_human_factor_analysis_activity
LSA_candidate_reliability_analysis_activity
LSA_candidate_maintainability_analysis_activity
LSA_candidate_testability_analysis_activity
LSA_candidate_failure_mode_and_effect_analysis_activity
LSA_candidate_damage_analysis_activity
LSA_candidate_special_event_analysis_activity
LSA_candidate_scheduled_maintenance_analysis_activity
LSA_candidate_level_of_repair_analysis_activity
LSA_candidate_mainenance_task_analysis_activity
LSA_candidate_software_data_loading_analysis_activity
LSA_candidate_software_support_analysis_activity
LSA_candidate_operational_analysis_activity
LSA_candidate_simulation_operational_scenarios_analysis_activity
LSA_candidate_training_needs_analysis_activity
LSA_candidate_other_analysis_activity

Candidate_item_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator
Candidate_item_analysis_activity_rationale
Candidate_item_analysis_activity_status
Candidate_item_analysis_activity_date

Any subclass of Candidate_item_analysis_activity class must also implement the followinginterface:−
4.10.3.2

Document_assignment_interface

LSA_candidate_comparative_analysis_activity
The LSA_candidate_comparative_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding comparative
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_comparative_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 67

S3000L-B6568-03000-00

LSA_candidate_comparative_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_comparative_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_comparative_analysis_activity is being performed.

The LSA_candidate_comparative_ analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.3

Document_assignment_interface.

LSA_candidate_human_factor_analysis_activity
The LSA_candidate_human_factor_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding human factor
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_human_factor_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.
LSA_candidate_human_factor_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_human_factor_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_human_factor_analysis_activity is being performed

The LSA_candidate_human_factor_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.4

Document_assignment_interface.

LSA_candidate_reliability_analysis_activity
The LSA_candidate_reliability_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding reliability analysis
for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_reliability_analysis_activity has no meaning by itself,
but only in the context of a specific LSA_candidate.
LSA_candidate_reliability_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 68

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_reliability_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_reliability_analysis_activity is being performed

The LSA_candidate_reliability_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.5

Document_assignment_interface.

LSA_candidate_maintainability_analysis_activity
The LSA_candidate_maintainability_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding maintainability
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_maintainability_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.
LSA_candidate_maintainability_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_maintainability_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_maintainability_analysis_activity is being performed

The LSA_candidate_maintainability_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.6

Document_assignment_interface.

LSA_candidate_testability_analysis_activity
The LSA_candidate_testability_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding testability analysis
for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_testability_analysis_activity has no meaning by itself,
but only in the context of a specific LSA_candidate.
LSA_candidate_testability_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 69

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_testability_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_testability_analysis_activity is being performed

The LSA_candidate_testability_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.7

Document_assignment_interface.

LSA_candidate_failure_mode_and_effect_analysis_activity
The LSA_candidate_failure_mode_and_effect_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding failure mode andeffect analysis (LSA-FMEA) for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_failure_mode_and_effect_analysis_activity has no
meaning by itself, but only in the context of a specific LSA_candidate.
LSA_candidate_failure_mode_and_effect_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_failure_mode_and_effect_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_failure_mode_and_effect_analysis_activity is being performed

The LSA_candidate_failure_mode_and_effect_analysis_activity class must also implement thefollowing interface (inherited from class Candidate_item_analysis_activity):−
4.10.3.8

Document_assignment_interface.

LSA_candidate_damage_analysis_activity
The LSA_candidate_damage_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding damage analysis
for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_damage_analysis_activity has no meaning by itself,
but only in the context of a specific LSA_candidate.
LSA_candidate_damage_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 70

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_damage_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_damage_analysis_activity is being performed

The LSA_candidate_damage_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.9

Document_assignment_interface.

LSA_candidate_special_event_analysis_activity
The LSA_candidate_special_event_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding special events
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_special_event_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.
LSA_candidate_special_event_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_special_event_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_special_event_analysis_activity is being performed

The LSA_candidate_special_event_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.10

Document_assignment_interface.

LSA_candidate_scheduled_maintenance_analysis_activity
The LSA_candidate_scheduled_maintenance_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding scheduled
maintenance analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_scheduled_maintenance_analysis_activity has no
meaning by itself, but only in the context of a specific LSA_candidate.
LSA_candidate_scheduled_maintenance_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 71

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_scheduled_maintenance_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_scheduled_maintenance_analysis_activity is being performed

The LSA_candidate_scheduled_maintenance_analysis_activity class must also implement thefollowing interface (inherited from class Candidate_item_analysis_activity):−
4.10.3.11

Document_assignment_interface.

LSA_candidate_level_of_repair_analysis_activity
The LSA_candidate_level_of_repair_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding level of repair
analysis (LORA) for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_level_of_repair_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.
LSA_candidate_level_of_repair_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_level_of_repair_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_level_of_repair_analysis_activity is being performed

The LSA_candidate_level_of_repair_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.12

Document_assignment_interface.

LSA_candidate_mainenance_task_analysis_activity
The LSA_candidate_mainenance_task_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding maintenance task
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_mainenance_task_analysis_activity has no meaningby itself, but only in the context of a specific LSA_candidate.
LSA_candidate_mainenance_task_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 72

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_mainenance_task_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_mainenance_task_analysis_activity is being performed

The LSA_candidate_mainenance_task_analysis_activity class must also implement thefollowing interface (inherited from class Candidate_item_analysis_activity):−
4.10.3.13

Document_assignment_interface.

LSA_candidate_software_data_loading_analysis_activity
The LSA_candidate_software_data_loading_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding software dataloading analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_software_data_loading_analysis_activity has no
meaning by itself, but only in the context of a specific LSA_candidate.
LSA_candidate_software_data_loading_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_software_data_loading_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_software_data_loading_analysis_activity is being performed

The LSA_candidate_software_data_loading_analysis_activity class must also implement thefollowing interface (inherited from class Candidate_item_analysis_activity):−
4.10.3.14

Document_assignment_interface.

LSA_candidate_software_support_analysis_activity
The LSA_candidate_software_support_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding software support
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_software_support_analysis_activity has no meaningby itself, but only in the context of a specific LSA_candidate.
LSA_candidate_software_support_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 73

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_software_support_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_software_support_analysis_activity is being performed

The LSA_candidate_software_support_analysis_activity class must also implement thefollowing interface (inherited from class Candidate_item_analysis_activity):−
4.10.3.15

Document_assignment_interface.

LSA_candidate_operational_analysis_activity
The LSA_candidate_operational_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding operational
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_operational_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.
LSA_candidate_operational_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_operational_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_operational_analysis_activity is being performed

The LSA_candidate_operational_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.16

Document_assignment_interface.

LSA_candidate_simulation_operational_scenarios_analysis_activity
The LSA_candidate_simulation_operational_scenarios_analysis_activity class is a
specialization of Candidate_item_analysis_activity, and records the decision made regarding
simulation of operational scenarios for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_simulation_operational_scenarios_analysis_activity
has no meaning by itself, but only in the context of a specific LSA_candidate.
LSA_candidate_simulation_operational_scenarios_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 74

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_simulation_operational_scenarios_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_simulation_operational_scenarios_analysis_activity is being performed

The LSA_candidate_simulation_operational_scenarios_analysis_activity class must also
implement the following interface (inherited from class Candidate_item_analysis_activity):−
4.10.3.17

Document_assignment_interface.

LSA_candidate_training_needs_analysis_activity
The LSA_candidate_training_needs_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding training needs
analysis for the LSA Candidate under consideration.
Note
An instance of class LSA_candidate_training_needs_analysis_activity has no meaning byitself, but only in the context of a specific LSA_candidate.
LSA_candidate_training_needs_analysis_activity attributes:−−−−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_training_needs_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_training_needs_analysis_activity is being performed

The LSA_candidate_training_needs_analysis_activity class must also implement the followinginterface (inherited from class Candidate_item_analysis_activity):−
4.10.3.18

Document_assignment_interface.

LSA_candidate_other_analysis_activity
The LSA_candidate_other_analysis_activity class is a specialization of
Candidate_item_analysis_activity, and records the decision made regarding additional types ofanalysis activities that needs to be performed for the LSA Candidate under consideration, apartfrom those enumerated above.
Note
An instance of class LSA_candidate_other_analysis_activity has no meaning by itself, but
only in the context of a specific LSA_candidate.
LSA_candidate_other_analysis_activity attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 75

S3000L-B6568-03000-00

−
−
−
−

Candidate_item_analysis_activity_indicator (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_rationale (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_status (inherited from class
Candidate_item_analysis_activity)
Candidate_item_analysis_activity_date (inherited from class
Candidate_item_analysis_activity)

LSA_candidate_other_analysis_activity associations:−

An association with the LSA_candidate for which the
LSA_candidate_other_analysis_activity is being performed

The LSA_candidate_other_analysis_activity class must also implement the following interface(inherited from class Candidate_item_analysis_activity):−
4.10.44.10.4.1

Document_assignment_interface.

UoF LSA Candidate Analysis Activity - Additions to referenced class and interface
definitions
LSA Candidate
Any class that implements the LSA_candidate interface defined in UoF LSA Candidate mustalso implement the following additional associations:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

An association with LSA_candidate_comparative_analysis_activity
An association with LSA_candidate_human_factor_analysis_activity
An association with LSA_candidate_reliability_analysis_activity
An association with LSA_candidate_maintainability_analysis_activity
An association with LSA_candidate_testability_analysis_activity
An association with LSA_candidate_failure_mode_and_effect_analysis_activity
An association with LSA_candidate_damage_analysis_activity
An association with LSA_candidate_special_event_analysis_activity
An association with LSA_candidate_scheduled_maintenance_analysis_activity
An association with LSA_candidate_level_of_repair_analysis_activity
An association with LSA_candidate_mainenance_task_analysis_activity
An association with LSA_candidate_software_data_loading_analysis_activity
An association with LSA_candidate_software_support_analysis_activity
An association with LSA_candidate_operational_analysis_activity
An association with LSA_candidate_simulation_operational_scenarios_analysis_activity
An association with LSA_candidate_training_needs_analysis_activity
An association with LSA_candidate_other_analysis_activity

Note
Only those instances of Breakdown_element_revision and Part (ie those classes that
implement the LSA_candidate interface) that are selected as LSA Candidates must identify
which analysis activities are to be performed.

4.11

UoF LSA-FMEA and Special Events

4.11.1

Overall description
The LSA-FMEA and Special Events UoF supports the recording of portions of the results fromthe following LSA analysis activities:−−−−

LSA-FMEA (Failure Mode and Effect Analysis),
Damage analysis
Special event analysis
Testability analysis

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 76

S3000L-B6568-03000-00

4.11.1.1

LSA-FMEA
The starting point for the LSA-FMEA are the physical items that has been identified as being
LSA candidates. Physical items can be Hardware_element_revisions, as well as
Hardware_parts, and each specific physical item can have a set of identified failure modes.
All identified failure modes causing one and the same maintenance procedure will be grouped
into a single LSA failure mode. Each LSA failure mode will be associated with the hardware
element or part for which there will be a defined task requirement, where the task requirement
represents the need for the identified maintenance procedure. This hardware element or partneed not be the same hardware element or part as for which the original failure mode(s) was
identified.
While grouping, failure rates for the item under analysis is distributed to the respective LSA
failure mode. The distributed failure rate can be defined either by ratio, or by qualitative
measures (rating).
Each possible failure mode can be detected by, either an automatic detection mean, BIT (BuiltIn-Test), or by other functional/physical symptoms. The failure mode effects defined in thetechnical FME(C)A can be considered as a guideline. The ability to localize the unit that has
failed (without ambiguity) can be rated using qualitative measures.
The requirement for a troubleshooting task can be recorded against the original failure mode.

4.11.1.2

Damage and special events
Special events can be due to external or internal causes, eg natural phenomenon or unusual
use. The probability of an event occurring is related to the usage phase of the product, eg
operation, maintenance etc.
Each possible event can affect one or many LSA candidates and result in one or many failuremodes. Identification of potential damages can also include a special analysis for each affected
LSA candidate with respect to the knowledge of the technology used. This is referred to as
technology behavior rating.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 77

S3000L-B6568-03000-00

4.11.2Graphical representation

ICN-B6865-S3000L0225-002-01
Fig 26 LSA-FMEA and Special Events - class model
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 78

S3000L-B6568-03000-00

4.11.3

UoF LSA-FMEA and Special Events - New class and interface definitions

4.11.3.1

Physical_item
The Physical_item interface is implemented by classes that represent hardware items.
Classes that implement the Physical_item interface:−−

Hardware_element_revision
Hardware_part

Classes that implement the Physical_item interface must implement the following associations:−−4.11.3.2

An optional association with one or many instances of Failure_mode
An optional association with one or many instances of LSA_failure_mode

Failure_mode
The Failure_mode class supports the definition of possible failure modes for a specificPhysical_item.
Note
An instance of class Failure_mode has no meaning by itself, but only in the context of a
Physical_item.
Note
Failure mode is also known as damage for failure modes caused by special events.
Failure_mode attributes:
−
−
−
−
−
−

Failure_mode_identifier (zero or one)
Failure_mode_description
Failure_mode_detection_ability_rating (zero or one)
Failure_mode_detection_ability_description (zero or one)
Failure_mode_localization_ability_rating (zero or one)
Failure_mode_localization_ability_description (zero or one)

Note
Failure_mode_detection_ability_rating and Failure_mode_localization_ability_rating areboth of data type Classification, ie both ratings must have an associated date representing
the date when the rating was performed.
LSA_candidate_failure_mode associations:
−
−
−
−
−
−
4.11.3.3

An association with the Physical_item for which the failure mode has been identified
An association with one or many instances of Failure_mode_effect
An optional association with one or many Special_events that can cause the identified
failure mode (via the Special_event_effects class)
An optional association with one or many Detection_means that can be used to detect the
failure mode
An optional association with one LSA_failure_mode (grouping of failure modes)
An optional association with a troubleshooting Task_requirement

LSA_failure_mode
The LSA_failure_mode class supports the grouping of identified failure modes which leads tothe same maintenance procedure.
Note
The LSA_failure_mode class is an abstract class, ie an instantiation of LSA_failure_mode
needs to be either:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 79

S3000L-B6568-03000-00••

Distributed_LSA_failure_mode_with_ratio
Distributed_LSA_failure_mode_with_rating

Making the LSA_failure_mode an abstract class, mandates the distribution of failure rates
between the different instances of LSA_failure_mode that has been identified for the same
Physical_item.
LSA_failure_mode attributes:−−

LSA_failure_mode_identifier
LSA_failure_mode_description (zero or one)

LSA_failure_mode associations:−−−4.11.3.4

An association with the Physical_item for which the LSA_failure_mode has been identified
An association with one or many instances of Failure_mode which are grouped into the
LSA_failure_mode
An association with the Task_requirement that describes the identified maintenanceprocedure

Distributed_LSA_failure_mode_with_ratio
The Distributed_LSA_failure_mode_with_ratio class is a specialization of LSA_failure_mode,and records the probability for an individual LSA_failure_mode to occur in relation to the entire
population of LSA_failure_modes identified for the related Physical_item.
Note
An instance of class Distributed_LSA_failure_mode_with_ratio has no meaning by itself,
but only in the context of a specific Physical_item.
Distributed_LSA_failure_mode_with_ratio attributes:−−−

LSA_failure_mode_identifier (inherited from class LSA_failure_mode)
LSA_failure_mode_description (inherited from class LSA_failure_mode)
LSA_failure_mode_distribution_ratio (one or many)

Distributed_LSA_failure_mode_with_ratio associations:−−−

An association with the Physical_item for which theDistributed_LSA_failure_mode_with_ratio has been identified (inherited from class
LSA_failure_mode)
An association with one or many instances of Failure_mode which are grouped into theDistributed_LSA_failure_mode_with_ratio (inherited from class LSA_failure_mode)
An association with the Task_requirement that describes the identified maintenanceprocedure (inherited from class LSA_failure_mode)

Distributed_LSA_failure_mode_with_ratio special recommendations:−4.11.3.5

A Distributed_LSA_failure_mode_with_ratio can have multiple failure mode distribution
values, eg depending on operational environment. Each instance of
LSA_failure_mode_distribution_ratio is then recommended have an associatedApplicability_statement, as defined in the UoF Applicability Statement, in order to define
when the respective ratio value is applicable.

Distributed_LSA_failure_mode_with_rating
The Distributed_LSA_failure_mode_with_rating class is a specialization of LSA_failure_mode,and records the rating for the occurrence of an individual LSA failure mode in comparison to theentire population of LSA failure modes identified for the related Physical_item.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 80

S3000L-B6568-03000-00

Note
An instance of class Distributed_LSA_failure_mode_with_rating has no meaning by itself,
but only in the context of a specific Physical_item.
Distributed_LSA_failure_mode_with_rating attributes:−−−

LSA_failure_mode_identifier (inherited from class LSA_failure_mode)
LSA_failure_mode_description (inherited from class LSA_failure_mode)
LSA_failure_mode_distribution_occurrence_rating (one or many)

Distributed_LSA_failure_mode_with_rating associations:−−−

An association with the Physical_item for which theDistributed_LSA_failure_mode_with_rating has been identified (inherited from class
LSA_failure_mode)
An association with one or many Instances of Failure_mode which are grouped into theDistributed_LSA_failure_mode_with_rating (inherited from class LSA_failure_mode)
An association with the Task_requirement that describes the identified maintenanceprocedure (inherited from class LSA_failure_mode)

Distributed_LSA_failure_mode_with_rating special recommendations:−4.11.3.6

A Distributed_LSA_failure_mode_with_rating can have multiple failure mode distribution
ratings, eg depending on operational environment. Each instance ofDistributed_LSA_failure_mode_with_rating is then recommended have an associatedApplicability_statement, as defined in the UoF Applicability Statement, in order to define
when the respective rating is applicable.

Failure_mode_effect
The Failure_mode_effect class defines the consequences of an identified failure mode and its
effect on the local/next higher/end item operation, function, or status.
Note
An instance of class Failure_mode_effect has no meaning by itself, but only in the context
of an identified Failure_mode.
Note
The Failure_mode_effect class is an abstract class, ie an instantiation of
Failure_mode_effect must to be either:••

Local_failure_mode_effectHigher_failure_mode_effectFailure_mode_effect attributes:−

Failure_mode_effectFailure_mode_effect associations:−4.11.3.7

An association with the Failure_mode that causes the identified Failure_mode_effectLocal_failure_mode_effect
The Local_failure_mode_effect class is a specialization of Failure_mode_effect, and identifies
the consequences of each postulated failure/damage mode affecting the Physical_item underanalysis. It is possible for the ”local effect” to be the failure/damage mode itself.
Note
An instance of class Local_failure_mode_effect has no meaning by itself, but only in thecontext of an identified Failure_mode.
Local_failure_mode_effect attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 81

S3000L-B6568-03000-00−

Failure_mode_effect (inherited from class Failure_mode_effect)

Local_failure_mode_effect associations:−4.11.3.8

An association with the Failure_mode that causes the identified Local_failure_mode_effect(inherited from class Failure_mode_effect)

Higher_failure_mode_effect
The Higher_failure_mode_effect class is a specialization of Failure_mode_effect, and identifies
the consequences of each failure/damage mode affecting the next higher indenture level, or the
essential functions(s) affecting system/equipment operating capability and mission completion
capability.
Note
An instance of class Higher_failure_mode_effect has no meaning by itself, but only in thecontext of an identified Failure_mode.
Higher_failure_mode_effect attributes:−−

Failure_mode_effect (inherited from class Failure_mode_effect)
Failure_mode_effect_level

Higher_failure_mode_effect associations:−−4.11.3.9

An association with one or many Instances of Failure_mode that causes the identified
Higher_failure_mode_effect (inherited from class Failure_mode_effect)
An association with the LSA_candidate that represents the higher indenture level

Detection_mean
The Detection_mean interface is implemented by those classes whose instances can be used
for detection and/or localization of one or many failure modes.
Classes that implement the Detection_mean interface:−−

Hardware_element_revision
Hardware_part

Detection_mean attributes:−−−

Detection_mean_description
Detection_mean_false_alarm_rate
Detection_mean_type

Detection_mean associations:−4.11.3.10

An association with one or many Failure_modes that can be detected/localized using the
Detection_mean

Detectability
The Detectability class is an association class, which adds information to a defined relationshipbetween a Detection_mean and an identified Failure_mode which can be detected and/or
localized, using the detection mean.
Detectability attributes:−−

4.11.3.11

Failure_mode_detection_rate (zero or one)
Failure_mode_isolation_rate (zero or one)Special_event
The Special_event class identifies special events that can occur, and which can lead to one or
many failure modes for one or many affected LSA_candidates.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 82

S3000L-B6568-03000-00

Special_event attributes:−−−

Special_event_title
Special_event_description (zero or one)Special_event_group

Special_event associations:−−4.11.3.12

An optional association with one or many instances of LSA_candidate which can beaffected by the special event
An association with one or many instances of Special_event_occurrence_definition, which
defines the probability for the special event to occur during a specific product usage phase.

Special_event_occurrence_definition
The Special_event_occurrence_definition class defines the probability for a special event tooccur during a specific product usage phase.
Note
The Special_event_occurrence_definition class is an abstract class, ie an instantiation ofSpecial_event_occurrence_definition must be either:••

Rated_special_event_occurrence_definition
Quantified_special_event_occurrence_definition

Note
An instance of class Special_event_occurrence_definition has no meaning by itself, but
only in the context of an identified Special_event.
Special_event_occurrence_definition associations:−−

An association with one or many defined Product_usage_phases during which theSpecial_event can occur
An association with the Special_event that can occur during the specified product usage
phase

Special_event_occurrence_definition special recommendations:−4.11.3.13

A Special_event_occurrence_definition can be dependent upon eg operational
environment. Each instance of Special_event_occurrence_definition is then recommended
have an associated Applicability_statement, as defined in the UoF Applicability Statement,in order to define when the respective Special_event_occurrence_definition is applicable.

Product_usage_phase
The Product_usage_phase class defines usage phases of interest for the Product in scope of
the LSA project.
Product_usage_phase attributes:−

Product_usage_phase

Product_usage_phase associations:−4.11.3.14

An optional association with one or many Special_events that can occur during thespecified Product_usage_phase (via Special_event_occurrence_definition)

Rated_special_event_occurrence_definition
The Rated_special_event_occurrence_definition class is a specialization of theSpecial_event_occurrence_definition class.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 83

S3000L-B6568-03000-00

Note
Rated_special_event_occurrence_definition and
Quantified_special_event_occurrence_definition respectively, mandate the recording of thefrequency for which the associated Special_event is expected to occur during a specificproduct usage phase, either by rating or by ratio.
Note
An instance of class Rated_special_event_occurrence_definition has no meaning by itself,
but only in the context of an identified Special_event.
Rated_special_event_occurrence_definition attributes:−

Special_event_occurrence_rating

Rated_special_event_occurrence_definition associations:−−

An association with one or many defined Product_usage_phases during which theSpecial_event can occur (inherited from class Special_event_occurrence_definition)
An association with the Special_event that can occur during the specified product usage
phase (inherited from class Special_event_occurrence_definition)

Rated_special_event_occurrence_definition special recommendations:−4.11.3.15

A Rated_special_event_occurrence_definition can be dependent upon eg operational
environment. Each instance of Rated_special_event_occurrence_definition is thenrecommended have an associated Applicability_statement, as defined in the UoF
Applicability Statement, in order to define when the respective
Rated_special_event_occurrence_definition is applicable.

Quantified_special_event_occurrence_definition
The Quantified_special_event_occurrence_definition class is a specialization of theSpecial_event_occurrence_definition class.
NoteRated_special_event_occurrence_definition and
Quantified_special_event_occurrence_definition respectively, mandate the recording of thefrequency for which the associated Special_event is expected to occur during a specificproduct usage phase, either by rating or by ratio.
Note
An instance of class Quantified_special_event_occurrence_definition has no meaning byitself, but only in the context of an identified Special_event.
Quantified_special_event_occurrence_definition attributes:−

Special_event_occurrence_rate

Quantified_special_event_occurrence_definition associations:−−

An association with one or many defined Product_usage_phases during which theSpecial_event can occur (inherited from class Special_event_occurrence_definition)
An association with the Special_event that can occur during the specified product usage
phase (inherited from class Special_event_occurrence_definition)

Quantified_special_event_occurrence_definition special recommendations:−

A Quantified_special_event_occurrence_definition can be dependent upon eg operational
environment. Each instance of Quantified_special_event_occurrence_definition is thenrecommended have an associated Applicability_statement, as defined in the UoF
Applicability Statement, in order to define when the respective
Quantified_special_event_occurrence_definition is applicable.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 84

S3000L-B6568-03000-00

4.11.3.16

Special_event_effects
The Special_event_effects class is an association class, which adds information to a defined
relationship between a Special_event and an affected LSA_candidate.
Special_event_effects associations:−An optional association with one or many identified Failure_modes that can occur as aconsequence of the related Special_event.

Note
The probability for each associated Failure_mode to occur, is defined using the association
class Special_event_effect_probability.
4.11.3.17

Special_event_effect_probability
The Special_event_effect_probability class is an association class, which adds information to adefined relationship between a Special_events_effects and an associated Failure_mode.
Special_event_effect_probability attributes:−

4.11.3.18

Special_event_effect_probability_ratio (zero or one)

LSA_candidate_technology_behavior_rating
The LSA_candidate_technology_behavior_rating class identifies technologies used anddescribes its characteristics regarding knowledge of its behavior. Experience shows thattechnologies used can be more or less sensitive to damage.
Note
An LSA Candidate can have zero, one or many technology behavior ratings over time.
Note
An instance of class LSA_candidate_technology_behavior_rating has no meaning by itself,
but only in the context of an LSA_candidate.
LSA_candidate_technology_behavior_rating attributes:−−

Technology_behavior_knowledge_rating (one or many)
Technology_sensitivity_rating (one or many)

LSA_candidate_technology_behavior_rating association:−

4.11.44.11.4.1

UoF LSA-FMEA and Special Events - Additions to referenced class and interface
definitions
Hardware_part
The Hardware_part class defined in UoF Part, must also implement the following additional
interfaces:−−

4.11.4.2

Physical_item
Detection_mean

Hardware_element_revision
The Hardware_element_revision class defined in UoF Breakdown Element Realization mustalso implement the following additional interfaces:−−

4.11.4.3

An association with the LSA_candidate for which the technology behavior rating is being
performed

Physical_item
Detection_mean

LSA_candidate
The LSA_candidate interface defined in UoF LSA Candidate, must also implement the following
additional associations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 85

S3000L-B6568-03000-00−−−
4.11.4.4

An optional association with one or many instances of Higher_failure_mode_effect
An optional association with one or many instances of Special_event that can affect the
LSA_candidate
An optional association with an instance of LSA_candidate_technology_behavior_rating

Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement, must also
implement the following additional associations:−−An optional association with an instance of LSA_failure_mode, defining a need for a
rectifying maintenance procedure
An optional association with one or many instances of Failure_mode, defining a need for atroubleshooting procedure

4.12

UoF LSA Candidate Task Requirement

4.12.1

Overall description
The LSA Candidate Task Requirement UoF supports early recordings of task requirements,
which will be refined during the detailed maintenance task analysis, software and data loading
analysis etc.
Objectives for documenting task requirements are, eg to:−−

Produce input to the LSA review, and together with the customer define maintenanceconcepts for the respective LSA Candidate before any detailed task analysis is being
carried out.
Identify product design changes that will result in increased maintainability, testability, etc.

A task requirement can also be associated with the source for the requirement, ie the driver forthe task. The requirement for a task may be derived from any type of LSA activity (Para 4.10).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 86

S3000L-B6568-03000-00

4.12.2Graphical representation

ICN-B6865-S3000L0226-002-01
Fig 27 LSA Candidate Task Requirement - class model
4.12.34.12.3.1

UoF LSA Candidate Task Requirement - New class and interface definitions
Task_requirement
The Task_requirement class supports the specification of task requirements prior to any
detailed task analysis.
Task_requirement attributes:
−
−
−
−
−
−

Task_requirement_identifier
Task_requirement_revision_identifier
Task_requirement_date
Task_requirement_description
Task_requirement_decisionTask_requirement_special_resource (zero or one)

Task_requirement associations:−−−−

An association with one or many LSA_candidates for which the task is required (via
Task_requirement_target)
An optional association with one or many succeeding revisions of the Task_requirement
An optional association with one or many preceding revisions of the Task_requirement
An optional association with one or many Candidate_item_analysis_activities, from which
the Task_requirement is derived

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 87

S3000L-B6568-03000-00−

4.12.3.2

An optional association with one or many product design Change_requests, which arerequired in order to be able to carry out the required task in the specified way

Task_requirement_change
The Task_requirement_change class is an association class, which adds information to theassociation between two successive revisions of Task_requirement.
Task_requirement_change attribute:−

4.12.3.3

Task_requirement_change_description (zero or one)

Authority_driven_task_requirement
The Authority_driven_task_requirement class is a specialization of class Task_requirement, andis to be used to record task requirements which are derived from regulations and/or otherauthoritative sources.
Authority_driven_task_requirement attributes:
−
−
−
−
−
−
−

Task_requirement_identifier (inherited from class Task_requirement)
Task_requirement_revision_identifier (inherited from class Task_requirement)
Task_requirement_date (inherited from class Task_requirement)
Task_requirement_description (inherited from class Task_requirement)
Task_requirement_decision (inherited from class Task_requirement)
Task_requirement_special_resource (inherited from class Task_requirement)
Task_requirement_authority_source_type (zero or one)The Authority_driven_task_requirement class must also implement the following interface:−Document_assignment (Refer to UoF Document)

Authority_driven_task_requirement associations:−−−−

An association with one or many LSA_candidates for which the task is required (inheritedfrom class Task_requirement)
An optional association with one or many Candidate_item_analysis_activities, from which
the task requirement is derived (inherited from class Task_requirement)
An optional association with one or many product design Change_requests, which arerequired in order to be able to carry out the required task in the specified way (inheritedfrom class Task_requirement)
An association with the authority Organization.

Authority_driven_task_requirement special recommendations:−4.12.3.4

Each instance of Authority_driven_task_requirement should have at least one document
reference from which the task requirement is derived, using the Document_assignment
capability defined in UoF document (refer to Para 4.19).

Task_requirement_target
The Task_requirement_target class defines a relationship between a specific Task_requirement
and the LSA_candidate for which the task is required.
Note
There is one instance of Task_requirement_target per relevant combination of
Task_requirement and LSA_candidate.
Task_requirement_target associations:−−

An association with the Task_requirement which is required for the LSA Candidate
An association with the LSA_candidate for which the task is required

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 88

S3000L-B6568-03000-00−

An optional association with one or many Task_limits defining, eg a task limit as required byan authority

Note
The Task_limit class is defined in UoF Task Usage Part 1. Refer to Para 4.15.
4.12.3.5

Change_request
The Change_request class supports the recording of desired product design changes.
Change_request attributes:−−

Change_request_identifier (zero or one)
Change_request_description

Change_request associations:−−4.12.44.12.4.1

UoF LSA Candidate Task Requirement - Additions to referenced class and interface
definitions
LSA_candidate
The LSA_candidate interface defined in UoF LSA Candidate, must also implement the following
additional associations:−−4.12.4.2

An optional association with one or many Task_requirements, which refer to the
Candidate_item_analysis_activity as its justification

Organization
The Organization class defined in UoF Project, must also implement the following additional
association:−

4.12.4.4

An optional association with one or many Task_requirements (via Task_requirement_target)
An optional association with one or many Change_requests

Candidate_item_analysis_activity
The Candidate_item_analysis_activity class defined in UoF LSA Candidate Analysis Activity,
must also implement the following additional association:−

4.12.4.3

An association with one or many instances of Task_requirement from which the designchange request has been derived
An association with the LSA_candidate for which the design change request is defined

An optional association with one or many instances of Authority_driven_task_requirement,in the role of authority organization.

Task_limit
The Task_limit class defined in UoF Task Usage (Part 1), must also implement the following
additional association:−

An association with an instance of Task_requirement_target, for which the Task_limit canbe defined.

4.13

UoF Task

4.13.1

Overall description
The Task UoF supports a detailed definition of a task, both maintenance task and operationaltask.
The Task procedure is described using a set of Subtasks. A Subtask can either be defined anddescribed within the Task under consideration, or make reference to another Task.
Note
A Subtask that is defined and described within a Task cannot be referenced by any other
Task.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 89

S3000L-B6568-03000-00

There is also the possibility to define a time line (schedule) for the Subtasks contained within a
Task. This can be used for the purpose of optimizing resource requirements and/or be the basis
for creating job cards, eg in a fleet management system.
Note
The Task UoF has been designed to support an easy to use integration between S3000L
and the S1000D procedure and schedule schemes, respectively.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 90

S3000L-B6568-03000-00

4.13.2Graphical representation

ICN-B6865-S3000L0227-002-01
Fig 28 UoF Task - class model

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 91

S3000L-B6568-03000-00

4.13.34.13.3.1

UoF Task - New class and interface definitions
Task
The Task class supports the detailed specification of a task, both maintenance tasks andoperational tasks.
Note
Task is an abstract class, ie an instantiation of Task must be either, a Rectifying_task,
Operational_task or a Supporting_task. (Refer to Chap 12 for definitions and usages of therespective task type).
Note
A detailed procedure for performing the task can be documented in zero, one or many
S1000D data modules. The Task UoF supports cross references between tasks being
defined in S3000L and data modules being produced in accordance with the S1000D
procedure and schedule schemes, respectively.
Note
Task includes its revision identification.
Task attributes:
−
−
−
−
−
−
−
−
−
−

Task_identifier (one or many)
Task_revision_identifier
Task_name (one or many)
Task_revision_status (zero or one)
Information_code
Task_criticality_code (zero or one)
Task_operability_code
Task_duration (zero, one or many)
Task_total_labour_time (zero, one or many)
S1000D_task_type (zero or one)

Task associations:
−
−
−
−
−
−
−
−

An optional association with zero, one or many succeeding revisions of the Task
An optional association with zero, one or many preceding revisions of the Task
An optional association with zero or one Organization that is responsible for the task
definition (can be used if the task definition is imported from a eg a subcontractor)
An optional association with zero, one or many Warning_caution_or_notes (via
Task_warning_caution_or_note)
An optional association with zero, one or many S1000D data modules, which contains thedetailed procedures for performing the task
An optional association with zero, one or many Task_requirements which forms thejustification for the task
An association with one or many Subtasks which contains the details for the task
An optional association with zero, one or many instances of Subtask_by_reference, ie
Subtasks that reference the Task under consideration as a Subtask

Note
The association between Task and S1000D_data_module classes enables the definition ofcross references between the tasks that are defined in S3000L, and the corresponding
S1000D data modules.
A Task in S3000L can be split into many S1000D data modules. One S1000D data module
can cover many S3000L tasks. However, projects are strongly recommended to aim for a
one to one correspondence.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 92

S3000L-B6568-03000-00

Where the concept of master data modules is used in the S1000D CSDB (Common Source
DataBase), it is recommended to just keep the cross references between the S3000L tasks
and the master data modules in the CSDB.
Task special recommendations:−

The value for the Task_duration and Task_total_labour_time attributes can berecommended to use either of the following representations:
•
•
•
•

−

4.13.3.2

Value_with_unit_property
Value_with_limit_property, where Limit_qualifier is set to "maximum".
Value_with_tolerances_property
Value_range_property

Where a Task has different Task_durations and/or Task_total_labour_times depending on,eg maintenance level, these must be represented as a set of values (Prp instances) for therespective attribute, but be distinguished by assigning Applicability_statement to therespective Prp instance representing the individual value (also refer to Para 4.21, UoF
Applicability Statement).

Task_change
The Task_change class is an association class which adds information to the association
between two successive revisions of a Task.
Task_change attributes:−

4.13.3.3

Task_revision_change_description (zero or one)

Task_distribution
The Task_distribution class is an association class which adds information to the association
between a Task_requirement and a Task. Task_distribution records the probability of one Task
to be performed, when there are multiple Tasks that can resolve the same Task_requirement.
Task_distribution attributes:−

4.13.3.4

Task_distribution_ratio

Rectifying_task
The Rectifying_task class is a specialization of class Task.
Note
Each maintenance activity is driven by an event. This event can be a failure, damage,special event or a time limit (interval). All these events require a maintenance action that
resolves the event. Each task that is able to resolve an event must be defined as arectifying task.
Rectifying_task attributes:
−
−
−
−
−
−
−
−
−
−

Task_identifier (inherited from class Task)
Task_revision_identifier (inherited from class Task)
Task_name (inherited from class Task)
Task_revision_status (inherited from class Task)
Information_code (inherited from class Task)
Task_criticality_code (inherited from class Task)
Task_operability_code (inherited from class Task)
Task_duration (inherited from class Task)
Task_total_labour_time (inherited from class Task)
S1000D_task_type (inherited from class Task)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 93

S3000L-B6568-03000-00

Rectifying_task associations:
−
−
−
−
−
−
−
−

An optional association with zero, one or many succeeding revisions of the Rectifying_task(inherited from class Task)
An optional association with zero, one or many preceding revisions of the Rectifying_task(inherited from class Task)
An optional association with zero or one Organization that is responsible for the task
definition (inherited from class Task)
An optional association with zero, one or many Warning_caution_or_notes (via
Task_warning_caution_or_note) (inherited from class Task)
An optional association with zero, one or many S1000D data modules, which contains thedetailed procedures for performing the Rectifying_task (inherited from class Task)
An optional association with zero, one or many Task_requirements which forms thejustification for the Rectifying_task (inherited from class Task)
An association with one or many Subtasks which contains the details for the Rectifying_task(inherited from class Task)
An optional association with zero, one or many instances of Subtask_by_reference, ie
Subtasks that uses the Rectifying_task under consideration as a subtask (inherited fromclass Task).

Rectifying_task special recommendations:−4.13.3.5

See special recommendations described under Task

Supporting_task
The Supporting_task class is a specialization of class Task.
Note
A supporting task does not "solve" any event, but can be used as a subtask within one or
many rectifying tasks. An example of a supporting task is open hatch, or jack a car.
Supporting_task attributes:
−
−
−
−
−
−
−
−
−
−

Task_identifier (inherited from class Task)
Task_revision_identifier (inherited from class Task)
Task_name (inherited from class Task)
Task_revision_status (inherited from class Task)
Information_code (inherited from class Task)
Task_criticality_code (inherited from class Task)
Task_operability_code (inherited from class Task)
Task_duration (inherited from class Task)
Task_total_labour_time (inherited from class Task)
S1000D_task_type (inherited from class Task)

Supporting_task associations:
−
−
−
−
−
−

An optional association with zero, one or many succeeding revisions of the Supporting_task(inherited from class Task)
An optional association with zero, one or many preceding revisions of the Supporting_task(inherited from class Task)
An optional association with zero or one Organization that is responsible for the task
definition (inherited from class Task)
An optional association with zero, one or many Warning_caution_or_notes (via
Task_warning_caution_or_note) (inherited from class Task)
An optional association with zero, one or many S1000D data modules, which contains thedetailed procedures for performing the Supporting_task (inherited from class Task)
An optional association with zero, one or many Task_requirements which forms thejustification for the Supporting_task (inherited from class Task)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 94

S3000L-B6568-03000-00−−

An association with one or many Subtasks which contains the details for the
Supporting_task (inherited from class Task)
An optional association with zero, one or many instances of Subtask_by_reference, ie
Subtasks that uses the Supporting_task under consideration as a subtask (inherited fromclass Task)

Supporting_task special recommendations:−4.13.3.6

See special recommendations described under Task

Operational_task
The Operational_task class is a specialization of class Task.
Note
Operational tasks are tasks that are required for operational purposes, eg fueling. An
operational task may also be used as a subtask within one or many rectifying tasks.
Operational_task attributes:
−
−
−
−
−
−
−
−
−
−

Task_identifier (inherited from class Task)
Task_revision_identifier (inherited from class Task)
Task_name (inherited from class Task)
Task_revision_status (inherited from class Task)
Information_code (inherited from class Task)
Task_criticality_code (inherited from class Task)
Task_operability_code (inherited from class Task)
Task_duration (inherited from class Task)
Task_total_labour_time (inherited from class Task)
S1000D_task_type (inherited from class Task)

Operational_task associations:
−
−
−
−
−
−
−
−

An optional association with zero, one or many succeeding revisions of the
Operational_task (inherited from class Task)
An optional association with zero, one or many preceding revisions of the Operational_task(inherited from class Task)
An optional association with zero or one Organization that is responsible for the task
definition (inherited from class Task)
An optional association with zero, one or many Warning_caution_or_notes (via
Task_warning_caution_or_note) (inherited from class Task)
An optional association with zero, one or many S1000D data modules, which contains thedetailed procedures for performing the Operational_task (inherited from class Task)
An optional association with zero, one or many Task_requirements which forms thejustification for the Operational_task (inherited from class Task)
An aggregate association with one or many Subtasks which contains the details for the
Operational_task (inherited from class Task) An optional association with zero, one or many instances of Subtask_by_reference, ie
Subtasks that uses the Operational_task under consideration as a subtask (inherited fromclass Task)

Operational_task special recommendations:−4.13.3.7

See special recommendations described under Task

SubtaskThe Subtask class defines steps to be performed within a Task. Subtasks are used to provide
detailed information about the Task.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 95

S3000L-B6568-03000-00

Note
Subtask is an abstract class, ie an instantiation of Subtask needs to be either, aSubtask_by_definition, a Subtask_by_reference, or a Subtask_by_external_reference.
Note
Subtasks within a Task can be time lined (scheduled) using the Subtask_timeline class.
Subtask attributes:−−

Subtask_identifier
Subtask_role (zero or one)

Subtask associations:−−−

An association with the Task to which the Subtask belongs
An optional association with zero or one related Subtask, of which the starting point for the
Subtask under consideration is dependent (used for time lining of the overall Task eg
preceding subtask in a GANTT-schema)
An optional association with zero, one or many Subtasks, whose starting points are
dependent upon the Subtask under consideration (used for time lining of the overall Task,
eg succeeding subtasks in a GANTT-schema)

Subtask special recommendations:−

Where a Subtask is dependent upon, eg maintenance level, it must be distinguished by theassignment of an Applicability_statement to the Subtask (refer to Para 4.21, UoF
Applicability Statement)

Note
There can be alternative subtasks within a Task. These are also distinguished by theassignment of Applicability_statement.
4.13.3.8

Subtask_timeline
The Subtask_timeline class is association class which adds information to the timeline
association between two Subtasks. The timeline association enables the definition of timedependencies between two Subtasks in a Task.
The Subtask_timeline class defines the event to which relating subtask refers (start or end of
the related Subtask). It also defines a possible lag, ie duration from the time the related event
occurs and the time when the relating Subtask can be initiated (started).
Note
Subtasks that don’t relate to any other Subtask, via the Subtask_timeline association, are to
be regarded as starting at the beginning of the associated Task.
Note
This class supports the creation of a GANTT-schema for a Task.
Subtask_timeline attributes:−−

4.13.3.9

Subtask_timeline_event
Subtask_timeline_lag

Subtask_by_reference
The Subtask_by_reference class is a specialization of Subtask. Subtask_by_reference is to be
used wherever the Subtask is defined as a Task in its own right.
Note
Subtask_by_reference is the only mechanism in S3000L that supports reuse of task steps
and/or task procedures in between Tasks.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 96

S3000L-B6568-03000-00

Subtask_by_reference attributes:−−

Subtask_identifier (inherited from class Subtask)
Subtask_role (inherited from class Subtask)

Subtask_by_reference associations:−−−−

An association with the Task to which the Subtask_by_reference belongs (inherited fromclass Subtask)
An optional association with zero or one related Subtask, of which the starting point for the
Subtask_by_reference under consideration is dependent (inherited from class Subtask)
An optional association with zero, one or many Subtasks, for which the respective starting
point is dependent upon the Subtask_by_reference under consideration (inherited fromclass Subtask)
An association with the specific Task being referenced as a Subtask

Subtask_by_reference special recommendations:−4.13.3.10

See special recommendations for Subtask above

Subtask_by_external_reference
The Subtask_by_external_reference class is a specialization of Subtask.
Subtask_by_external_reference is to be used wherever the complete description of the Subtask
is being described in an external source, ie outside the scope of S3000L and S1000D.
Subtask_by_external_reference attributes:−−

Subtask_identifier (inherited from class Subtask)
Subtask_role (inherited from class Subtask)

Subtask_by_external_reference associations:
−
−
−
−
−

An association with the Task to which the Subtask_by_external_reference belongs(inherited from class Subtask)
An optional association with zero or one related Subtask, of which the starting point for the
Subtask_by_external_reference under consideration is dependent (inherited from class
Subtask)
An optional association with zero, one or many Subtasks, for which the respective starting
point is dependent upon the Subtask_by_external_reference under consideration (inheritedfrom class Subtask)
An optional association with zero, one or many instances of External_document (source)
containing the detailed description for the subtask to be performed
An optional association with zero, one or many instances of S1000D_publication_module(source) containing the detailed description for the subtask to be performed

Subtask_by_external_reference special recommendations:−−4.13.3.11

Where a Subtask_by_external_reference is dependent upon, eg maintenance level, it must
be distinguished by the assignment of an Applicability_statement to the
Subtask_by_external_reference (refer to Para 4.21, UoF Applicability Statement)
An instance of Subtask_by_external_reference must be associated with at least one
instance of External_document or S1000D_publication_module

Subtask_by_definition
The Subtask_by_definition class is a specialization of Subtask. A Subtask_by_definition
provides a detailed characterization of the subtask to be included in the overall Task. A
Subtask_by_definition cannot be referenced from any other Task.
Subtask_by_definition attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 97

S3000L-B6568-03000-00

−
−
−
−
−
−
−

Subtask_identifier (inherited from class Subtask)
Subtask_role (inherited from class Subtask)
Subtask_name
Information_code (zero or one)
Subtask_description (zero or one)
Subtask_duration (one or many)
Maintenance_location_code (zero or one)

Subtask_by_definition associations:
−
−
−
−
−
−
−
−

An association with the Task to which the Subtask_by_definition belongs (inherited fromclass Subtask)
An optional association with zero or one related Subtask, of which the starting point for the
Subtask_by_definition under consideration is dependent (inherited from class Subtask)
An optional association with zero, one or many Subtasks, for which the respective starting
point is dependent upon the Subtask_by_definition under consideration (inherited fromclass Subtask)
An optional association with a zonal location (Zone_element_revision) in which the subtask
is to be performed (via Subtask_in_zone)
An optional association with zero, one or many Subtask_acceptance_parameters, defining
criteria that need to be fulfilled before the subtask can be closed
An optional association with zero, one or many Breakdown_elements and/or parts which
are the objects on which the subtask is being performed
An optional association with zero, one or many Subtask_objective_states that defines thestates that must be obtained before the subtask can be closed
An optional association with zero, one or many Warning_caution_or_notes (via
Subtask_warning_caution_or_note)

Subtask_by_definition special recommendations:−−−4.13.3.12

The value for the Subtask_duration attribute can use either of the following representations:•
Value_with_unit_property•
Value_with_limit_property, where Limit_qualifier is set to "maximum".
•
Value_with_tolerances_property•
Value_range_property
Where the Subtask_durations depends on, eg maintenance level, these are represented as
different values (instances of Prp) for the attribute but must be distinguished by assigning
Applicability_statement to the respective Prp instance representing the individual value
See also special recommendations for Subtask above

Subtask_in_zone
The Subtask_in_zone class defines a relationship between an instance ofSubtask_by_definition and a zonal location (Zone_element_revision) in which the subtask is tobe performed.
Note
There is one instance of Subtask_in_zone per relevant combination of
Subtask_by_definition and zonal location (Zone_element_revision).
Subtask_in_zone associations:−−

An association with the specific Subtask_by_definition that is to be performed
An association with the Zone_element_revision that represents the zonal location in which
the subtask is to be performed

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 98

S3000L-B6568-03000-00

4.13.3.13

Subtask_acceptance_parameter
The Subtask_acceptance_parameter class defines criteria’s that needs to be fulfilled before thesubtask can be closed.
Note
An instance of class Subtask_acceptance_parameter has no meaning by itself, but only inthe context of a specific instance of Subtask_by_definition.
Subtask_acceptance_parameter attributes:−−

Subtask_acceptance_parameter_description
Subtask_acceptance_parameter_value (one or many)

Subtask_acceptance_parameter associations:−

An association with the specific instance of Subtask_by_definition for which theSubtask_acceptance_parameter has been defined

Subtask_acceptance_parameter special recommendations:−

The value for the Subtask_acceptance_parameter_value attribute can use either of thefollowing representations:
•
•
•
•

−

4.13.3.14

Value_with_unit_property
Value_with_limit_property, where Limit_qualifier is set to ‘maximum’, or ‘minimum’.
Value_with_tolerances_property
Value_range_property

Where the Subtask_acceptance_parameter depends on, eg operational environment, these
are represented as different instances of Subtask_acceptance_parameter. The respective
instance must be distinguished by the assignment of an Applicability_statement to therespective instance of Subtask_acceptance_parameter (also refer to Para 4.21, UoF
Applicability Statement).

Subtask_target_item
The Subtask_target_item interface is implemented by classes that can represent the object onwhich a Subtask_by_definition is to be performed.
Classes that implement the Subtask_target_item interface:−−

Breakdown_element_revision
Part

Classes that implement the Subtask_target_item interface must implement the following
association:−
4.13.3.15

An optional association with zero, one or many instances of Subtask_by_definition

Subtask_objective_state
The Subtask_objective_state class defines a state that must be obtained before the subtask can
be closed.
Note
An instance of class Subtask_objective_state has no meaning by itself, but only in thecontext of a specific instance of Subtask_by_definition.
Subtask_objective_state attributes:−

Subtask_objective_state

Subtask_objective_state association:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 99

S3000L-B6568-03000-00−

An association with the specific instance of Subtask_by_definition for which theSubtask_objective_state has been definedNote
If a Subtask_by_definition must obtain more than one state, there needs to be one instanceof Subtask_objective_state per state.
4.13.3.16

Subtask_circuit_breaker_state
The Subtask_circuit_breaker_state class is a specialization of Subtask_objective_state. The
Subtask_circuit_breaker_state class defines a circuit breaker state that must be obtained before
the subtask can be closed. The main difference between the generic Subtask_objective_stateand Subtask_circuit_breaker_state is that the Subtask_circuit_breaker_state identifies theindividual Circuit_breaker that must obtain the state.
Note
An instance of class Subtask_circuit_breaker_state has no meaning by itself, but only in thecontext of a specific instance of Subtask_by_definition.
Subtask_circuit_breaker_state attributes:−

Subtask_objective_state (inherited from class Subtask_objective_state)

Subtask_circuit_breaker_state associations:−−

An association with the specific instance of Subtask_by_definition for which theSubtask_circuit_breaker_state has been defined (inherited from class
Subtask_objective_state)
An association with the individual Circuit_breaker that must obtain the state

Note
If a Subtask_by_definition must obtain more than one circuit breaker state, there needs to
be one instance of Subtask_circuit_breaker_state per circuit breaker.
4.13.3.17

Circuit_breaker
The Circuit_breaker class identifies individual circuit breakers that are installed on the Product.
Circuit_breaker attributes:−−−

Circuit_breaker_identifier
Circuit_breaker_name
Circuit_breaker_type

Circuit_breaker associations:−An optional association with zero, one or many Subtask_circuit_breaker_states, ie statesthat the circuit breaker must be in before a specific instance of Subtask_by_definition can
be closed

Circuit_breaker class must also implements the following interface:−Document_assignment_interface.

Circuit_breaker special recommendations:−4.13.3.18

Circuit breaker location can be defined using the assignment of a Document, where theDocument_assignment_role is set to “Source”, and the Document_portion attributedescribes the location.

Warning_caution_or_note
The Warning_caution_or_note class defines advices concerning safety, legal and healthaspects.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 100

S3000L-B6568-03000-00

Warning_caution_or_note attributes:−−−

Warning_caution_or_note_identifier (zero or one)
Warning_caution_or_note_description
Warning_caution_or_note_type

Warning_caution_or_note associations:−−4.13.3.19

An optional association with zero, one or many Tasks for which theWarning_caution_or_note is valid (via Task_warning_caution_or_note)
An optional association with zero, one or many specific instances of Subtask_by_definition
for which the Warning_caution_or_note is valid (via Subtask_warning_caution_or_note)

Task_warning_caution_or_note
The Task_warning_caution_or_note class defines a relationship between a specific Task andan instance of Warning_caution_or_note.
Task_warning_caution_or_note associations:−−

An association with the specific Task that needs the advice concerning safety, legal andhealth aspects
An association with the instance of Warning_caution_or_note that contains the advice
concerning safety, legal and health aspects

Note
There is one instance of Task_warning_caution_or_note per relevant combination of Task
and Warning_caution_or_note.
Task_warning_caution_or_note special recommendations:−4.13.3.20

Where a Task_warning_caution_or_note is dependent upon eg maintenance level, or
external conditions, it must be distinguished by the assignment of an
Applicability_statement (UoF Applicability Statement) to the Task_warning_caution_or_note
instance.

Subtask_warning_caution_or_note
The Subtask_warning_caution_or_note class defines a relationship between specific instance ofSubtask_by_definition and an instance of Warning_caution_or_note.
Subtask_warning_caution_or_note associations:−−

An association with the specific instance of Subtask_by_definition that needs the advice
concerning safety, legal and health aspects
An association to the instance of Warning_caution_or_note that contains the advice
concerning safety, legal and health aspects

Note
There is one instance of Subtask_warning_caution_or_note per relevant combination of
Subtask_by_definition and Warning_caution_or_note.
Subtask_warning_caution_or_note special recommendations:−4.13.44.13.4.1

Where a Subtask_warning_caution_or_note is dependent upon eg maintenance level, or
external conditions, it must be distinguished by the assignment of an
Applicability_statement (UoF Applicability Statement) to the
Subtask_warning_caution_or_note instance.

UoF Task - Additions to referenced class and interface definitions
Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement, must also
implement the following additional association:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 101

S3000L-B6568-03000-00−
4.13.4.2

S1000D_data_module
The S1000D_data_module class defined in UoF Document must also implement the following
association:−

4.13.4.3

An optional association with zero, one or many instances of Subtask_by_external_reference

Zone_element_revision
The Zone_element_revision class defined in UoF Breakdown Zone Element, must also
implement the following additional association:−

4.13.4.8

An optional association with zero, one or many instances of Subtask_by_external_reference

S1000D_publication_module
The S1000D_publication_module class defined in UoF Document, must also implement thefollowing additional association:−

4.13.4.7

Subtask_target_item

External_document
The External_document class defined in UoF Document, must also implement the following
additional association:−

4.13.4.6

Subtask_target_item

Breakdown_element_revision
The Breakdown_element_revision class defined in UoF Breakdown Structure, must also
implement the following additional interface:−

4.13.4.5

An optional association with zero, one or many Tasks (ie revisions thereof), which aredescribed in the identified issue of the S1000D data module

Part
The Part class defined in UoF Part, must also implement the following additional interface:−

4.13.4.4

An optional association with zero, one or many Tasks which are justified by theTask_requirement.

An optional association with zero, one or many specific instances of Subtask_by_definition(via Subtask_in_zone)

Organization
The Organization class defined in UoF Project must also implement the following additional
association:−

An optional association with zero, one or many instances of Task in the role of responsibleorganization (task origin).

4.14

UoF Task Resources

4.14.1

Overall description
The Task Resources UoF supports a detailed definition of resources needed, either per
subtask, or aggregated per task.
Task Resources can be either:−−−−

Material resources, eg spares, tools, consumables
Facilities, eg hangars, power
Personnel resources, eg skills
Documents

Material and facility resources can be defined both in terms of specifications, and in terms ofactual parts.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 102

S3000L-B6568-03000-00

4.14.2Graphical representation

ICN-B6865-S3000L0228-002-01
Fig 29 UoF Task Resources - class model
4.14.34.14.3.1

UoF Task Resources - New class and interface definitions
Task_resource_assignment
The Task_resource_assignment interface enables resources to be assigned to classes that
implement this interface.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 103

S3000L-B6568-03000-00

Classes that implement the Task_resource_assignment interface:
−
−

Task
Subtask_by_definition

Classes that implement the Task_resource_assignment interface must also implement thefollowing association:−

4.14.3.2

An optional association with zero, one or many Task_resources, ie resources needed for
performing the specific instance of Task or Subtask_by_definition

Task_resource
The Task_resource class supports the identification of resources needed for the performance ofa specific instance of Task or Subtask_by_definition.
Note
Task_resource is an abstract class, ie an instantiation of Task_resource must be either:
•
•
•
•
•
•

Task_material_resource_by_specification
Task_materiel_resource_by_reference
Task_facility_resource_by_specification
Task_facility_resource_by_reference
Task_personnel_resource
Task_document.

Note
Each instance of Task_resource is uniquely defined for a specific instance of Task or
Subtask_by_definition. Reuse of resource definitions is enabled through the use of
Resource_specifications, Parts, Skills, Trades and Documents.
Task_resource attributes:−−

Fixed_resource_marker
Task_resource_duration

Task_resource associations:−−−

An association with a specific instance of Task or Subtask_by_definition, for which theassociated resource is needed (via Task_resource_assignment interface)
An optional association where an instance of Task_resource can relate to other instances of
Task_resource, eg “person A uses tool B”
An optional association where an instance of Task_resource can be related to from otherinstances of Task_resource, eg “tool B is used by person A”

Task_resource special recommendations:−−4.14.3.3

Where a Task_resource is dependent upon eg, maintenance level, external conditions, etc,
it must be distinguished by the assignment of an Applicability_statement (UoF Applicability
Statement) to the Task_resource instance
Where a Task_resource_duration is depending on eg maintenance level, external
conditions etc, these must be represented as a set of values (Prp instances), but be
distinguished by the assignment of Applicability_statement to the respective Prp instancethat represents the individual values.

Task_resource_relationship
The Task_resource_relationship class is an association class which adds information to theTask_resource_relationship association between two instances of Task_resource. The
Task_resource_relationship association defines dependencies between two Task_resources ina Task or in Subtask_by_definition, eg person A "uses" tool B.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 104

S3000L-B6568-03000-00

Task_resource_relationship attributes:−
4.14.3.4

Task_resource_relationship_category

Task_material_resource
The Task_material_resource class is a specialization of the Task_resource class, and identifies
material resources needed for the performance of a specific instance of Task or
Subtask_by_definition.
Note
Task_material_resource is an abstract class, ie an instantiation of Task_material_resourcemust be either:••

Task_material_resource_by_specification
Task_materiel_resource_by_reference

Note
Each instance of Task_material_resource is uniquely defined for a specific instance of Task
or Subtask_by_definition. Reuse of material resource definitions is enabled through the useof Resource_specifications and Parts.
Task_material_resource attributes:−−−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_material_resource_quantity
Task_material_resource_category (zero or one)

Task_material_resource associations:−−−

An association with a specific instance of Task or Subtask_by_definition for which theassociated resource is needed (inherited from class Task_resource)
An optional association where an instance of Task_material_resource can relate to otherinstances of Task_resource, eg “equipment A calibrates tool B” (inherited from class
Task_resource)
An optional association where an instance of Task_material_resource can be related tofrom other instances of Task_resource, eg ”tool B is calibrated by equipment A”. (inheritedfrom class Task_resource)

Task_material_resource special recommendations:−

See Task_resource special recommendations

Note
For a Task/Subtask_by_definition it’s recommended to define every item that is affected by
the task/subtask as a Task material resource. The consumption rate then can be calculated
based on the scrap rate defined for the Hardware_part, eg if four screws are removed inorder to open a hatch, these will be recorded as task material resources, and theconsumption will be calculated based on Task_material_resource_quantity andHardware_part_scrap_rate.
4.14.3.5

Task_material_resource_by_reference
The Task_material_resource_by_reference class is a specialization of theTask_material_resource class, and identifies a specific Part (by Part_identifier) as the resource
needed for the performance of a specific Task or Subtask_by_definition.
Note
Each instance of Task_material_resource_by_reference is uniquely defined for a specificinstance of Task or Subtask_by_definition. Reuse is enabled through the use of Parts.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 105

S3000L-B6568-03000-00

Task_material_resource_by_reference attributes:−−−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_material_resource_quantity (inherited from class Task_material_resource)
Task_material_resource_category (inherited from class Task_material_resource)

Task_material_resource_by_reference associations:−−−−

An association with a specific instance of Task or Subtask_by_definition for which theassociated resource is needed (inherited from class Task_resource)
An optional association where an instance of Task_material_resource_by_reference canrelate to other instances of Task_resource, eg “equipment A calibrates tool B” (inheritedfrom class Task_resource)
An optional association where an instance of Task_material_resource_by_reference can be
related to from other instances of Task_resource, eg ”tool B is calibrated by person A”(inherited from class Task_resource)
An association with the Part that plays the role of a Task_material_resource

Task_material_resource_by_reference special recommendations:−

See Task_resource special recommendations

Note− For a Task/Subtask_by_definition it’s recommended to define every item that is affected by
the task/subtask as a Task material resource. The consumption rate then can be calculated
based on the scrap rate defined for the Hardware_part, eg if four screws are removed inorder to open a hatch, these will be recorded as task material resources, and theconsumption will be calculated based on Task_material_resource_quantity andHardware_part_scrap_rate.
4.14.3.6

Task_material_resource_by_specification
The Task_material_resource_by_specification class is a specialization of theTask_material_resource class, and identifies material resources needed to perform a specific
Task or Subtask_by_definition, through a Resource_specification.
Note
Each instance of Task_material_resource_by_specification is uniquely defined for a specificinstance of Task or Subtask_by_definition. Reuse of material resource specifications isenabled through the use of Resource_specification.
Task_material_resource_by_specification attributes:−−−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_material_resource_quantity (inherited from class Task_material_resource)
Task_material_resource_category (inherited from class Task_material_resource)

Task_material_resource_by_specification associations:−−−

An association with a specific instance of Task or Subtask_by_definition, for which theassociated resource is needed (inherited from class Task_resource)
An optional association where an instance of Task_material_resource_by_specification canrelate to other instances of Task_resource, eg “equipment A calibrates tool B” (inheritedfrom class Task_resource)
An optional association where an instance of Task_material_resource_by_specification canbe related to from other instances of Task_resource, eg ”tool B is calibrated by person A”(inherited from class Task_resource)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 106

S3000L-B6568-03000-00−

An association with an instance of Material_resource_specification that plays the role of a
Task_material_resource

Task_material_resource_by_specification special recommendations:−

See Task_resource special recommendations

Note
For a Task/Subtask_by_definition it’s recommended to define every item that is affected by
the task/subtask as a Task material resource. The consumption rate then can be calculated
based on the scrap rate defined for the Hardware_part, eg if four screws are removed inorder to open a hatch, these will be recorded as task material resources, and theconsumption will be calculated based on Task_material_resource_quantity andHardware_part_scrap_rate.
4.14.3.7

Resource_specification
The Resource_specification class identifies specifications of resources which can be realized by
one or many Parts.
Note
Use of Resource_specifications allows for more generic task/subtask definitions, ie thetask/subtask does not need to be changed based on customer specific tool sets etc.
Note
Resource_specification is an abstract class, ie an instantiation of Resource_specificationmust be either a Facility_resource_specification or a Material_resource_specification.
Resource_specification attributes:−−−

Resource_specification_identifier
Resource_specification_name
Resource_specification_description

Resource_specification associations:−4.14.3.8

An optional association with zero, one or many Parts that realizes the
Resource_specification, ie actual tools, equipment, spares, that can be used when the task
is to be performed (via an instance of the Resource_realization class)

Resource_realization
The Resource_realization class defines a relationship between a specificResource_specification and a Part that fulfills that specification.
Resource_realization associations:−−

An association with a specific Resource_specification which has a Part realization
An association with a specific Part that fulfills the resource specification (realizes the
specification)

Note
There is one instance of Resource_realization per relevant combination of
Resource_specification and Part.
Resource_realization special recommendations:−

Where a Resource_realization is dependent upon eg, customer, maintenance level orexternal conditions, it must be distinguished by the assignment of an
Applicability_statement to the Resource_realization instance (UoF Applicability Statement)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 107

S3000L-B6568-03000-00

4.14.3.9

Material_resource_specification
The Material_resource_specification class is a specialization of the Resource_specification
class, and identifies specifications of material resources (spares, consumables, tools, etc.)
which can be realized by one or many Parts.
Note
Use of Material_resource_specifications allows for more generic task/subtask definitions, ie
the task/subtask does not need to be changed based on customer specific tool sets.
Material_resource_specification attributes:−−−

Resource_specification_identifier (inherited from class Resource_specification)
Resource_specification_name (inherited from class Resource_specification)
Resource_specification_description (inherited from class Resource_specification)

Material_resource_specification associations:−−An optional association with zero, one or many Parts that realizes theMaterial_resource_specification, ie actual tools, equipments, spares, that can be used when
the task is to be performed (inherited from class Resource_specification)
An optional association with zero, one or many instances of
Task_material_resource_by_specification, ie individual usages of the specified material
resource in a specific Task or Subtask_by_definition

Material_resource_specification special recommendations:−4.14.3.10

See Resource_specification special recommendations.

Task_facility_resource
The Task_facility_resource class is a specialization of the Task_resource class, and identifies
facility resources needed for the performance of a specific instance of Task or
Subtask_by_definition.
Note
Task_facility_resource is an abstract class, ie an instantiation of Task_facility_resourcemust be either:••

Task_facility_resource_by_specification
Task_facility_resource_by_reference

Note
Each instance of Task_facility_resource is uniquely defined for a specific instance of Task
or Subtask_by_definition. Reuse of facility resource definitions is enabled through the useof Resource_specifications and Parts.
Task_facility_resource attributes:−−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_facility_resource_quantity (zero or one)

Task_facility_resource associations:−−

An association with a specific instance of Task or Subtask_by_definition for which theassociated resource is needed (inherited from class Task_resource)
An optional association where an instance of Task_facility_resource can relate to otherinstances of Task_resource, eg “power utility A powers equipment B” (inherited from class
Task_resource)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 108

S3000L-B6568-03000-00−

An optional association where an instance of Task_facility_resource can be related to fromother instances of Task_resource, eg ”equipment B is powered by power utility A” (inheritedfrom class Task_resource)

Task_material_resource special recommendations:−4.14.3.11

See Task_resource special recommendations

Task_facility_resource_by_reference
The Task_facility_resource_by_reference class is a specialization of the Task_facility_resourceclass, and identifies a specific Part (by Part_identifier) as the resource needed for the
performance of a specific Task or Subtask_by_definition.
Note
Each instance of Task_facility_resource_by_reference is uniquely defined for a specificinstance of Task or Subtask_by_definition. Reuse is enabled through the use of Parts.
Task_facility_resource_by_reference attributes:−−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_facility_resource_quantity (zero or one, inherited from class Task_facility_resource)

Task_facility_resource_by_reference associations:−−−−

An association with a specific instance of Task or Subtask_by_definition for which theassociated resource is needed (inherited from class Task_resource)
An optional association where an instance of Task_facility_resource_by_reference canrelate to other instances of Task_resource, eg “power utility A powers equipment B”(inherited from class Task_resource)
An optional association where an instance of Task_facility_resource_by_reference can be
related to from other instances of Task_resource, eg ”equipment B is powered by power
utility A” (inherited from class Task_resource)
An association with the Part that plays the role of a Task_facility_resource

Task_facility_resource_by_reference special recommendations:−4.14.3.12

See Task_resource special recommendations

Task_facility_resource_by_specification
The Task_facility_resource_by_specification class is a specialization of theTask_facility_resource class, and identifies facility resource needed to perform a specific Task
or Subtask_by_definition through a Resource_specification.
Note
Each instance of Task_facility_resource_by_specification is uniquely defined for a specificinstance of Task or Subtask_by_definition. Reuse of facility resource specifications isenabled through the use of Resource_specification.
Task_facility_resource_by_specification attributes:−−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_facility_resource_quantity (inherited from class Task_facility_resource)

Task_facility_resource_by_specification associations:−

An association with a specific instance of Task or Subtask_by_definition for which theassociated resource is needed (inherited from class Task_resource)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 109

S3000L-B6568-03000-00−−−

An optional association where an instance of Task_facility_resource_by_specification canrelate to other instances of Task_resource, eg “power utility A powers equipment B”(inherited from class Task_resource)
An optional association where an instance of Task_facility_resource_by_specification canbe related to from other instances of Task_resource, eg ”equipment B is powered by power
utility A” (inherited from class Task_resource)
An association with an instance of Facility_resource_specification that plays the role of a
Task_facility_resource

Task_facility_resource_by_specification special recommendations:−4.14.3.13

See Task_resource special recommendations

Facility_resource_specification
The Facility_resource_specification class is a specialization of the Resource_specification
class, and identifies specifications of facility resources (power, internet, hangar, dock etc) which
can be realized by one or many Parts.
Note
Use of Facility_resource_specifications allows for more generic task/subtask definitions, ie
the task/subtask does not need to be changed based on customer specific realizations offacilities etc.
Facility_resource_specification attributes:−−−

Resource_specification_identifier (inherited from class Resource_specification)
Resource_specification_name (inherited from class Resource_specification)
Resource_specification_description (inherited from class Resource_specification)

Facility_resource_specification associations:−−An optional association with zero, one or many Parts that realizes the
Facility_resource_specification, ie actual equipment etc, that can be used when the task is
to be performed (inherited from class Resource_specification)
An optional association with zero, one or many Task_facility_resource_by_specifications, ie
individual usages of the specified facility resource in a specific Task or
Subtask_by_definition

Facility_resource_specification special recommendations:−4.14.3.14

See Resource_specification special recommendations.

Task_personnel_resource
The Task_personnel_resource class is a specialization of the Task_resource class, andidentifies personnel resources needed for the performance of a specific instance of Task or
Subtask_by_definition.
Note
Each instance of Task_personnel_resource is uniquely defined for a specific instance ofTask or Subtask_by_definition. Reuse of personnel resource definitions is enabled throughthe use of Trades and Skills.
Task_personnel_resource attributes:
−
−
−
−
−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)
Task_personnel_resource_role
Task_number_of_personnel_resource (zero, one or many)
Task_personnel_resource_labour_time (zero, one or many)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 110

S3000L-B6568-03000-00

Task_personnel_resource associations:−−−−

An association with a specific instance of Task or Subtask_by_definition for which theassociated resource is needed (inherited from class Task_resource).
An optional association where an instance of Task_personnel_resource can relate to otherinstances of Task_resource, eg "person A uses equipment B" (inherited from class
Task_resource).
An optional association where an instance of Task_personnel_resource can be related tofrom other instances of Task_resource, eg "equipment B is used by person A" (inheritedfrom class Task_resource).
An optional association with zero, one or many Competences (Trades or Skills) that canperform as the needed Task_personnel_resource (via
Task_personnel_resource_competence).

Task_material_resource special recommendations:−−4.14.3.15

Where a Task_personnel_resource is dependent upon eg maintenance level, external
conditions, etc, it must be distinguished by assigning an Applicability_statement (UoF
Applicability) to the Task_personnel_resource instance.
Where a Task_personnel_resource has different Task_resource_duration,
Task_number_of_personnel_resource, and/or Task_personnel_resource_labour_time
depending on eg maintenance level, these must be represented as a set of values (Prpinstances) for the respective attribute, but be distinguished by the assignment ofApplicability_statement to the respective Prp instance representing the individual values.

Competence
The Competence interface enables Skills and Trades to be associated with personnel resource
requirements, needed to perform a Task or a Subtask_by_definition.
Classes that implement the Competence interface:
−
−

Trade
Skill

Classes that implement the Competence interface must also implement the following
association:−

4.14.3.16

An optional association with zero, one or many instances of Task_personnel_resource, ie
personnel needed for the performance of a specific instance of Task or
Subtask_by_definition (via Task_personnel_resource_competence).

Trade
The Trade class defines types of occupations.
Trade attributes:−

Trade_name

Trade associations:−An optional association with zero, one or many Skills defined for the Trade

Trade interfaces:−
4.14.3.17

The Trade class implements the Competence interface

Skill
The Skill class defines specific combinations of Trade and Skill_level.
Skill attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 111

S3000L-B6568-03000-00−

Skill_code

Skill associations:−An optional association with zero or one Trade for which the Skill is defined

Trade interfaces:−
4.14.3.18

The Trade class implements the Competence interface

Skill_level
The Skill_level class is an association class which adds information to the association between
a Skill and a Trade.
Skill_level attributes:−

4.14.3.19

Skill_level_name (zero or one)

Task_personnel_resource_competence
The Task_personnel_resource_competence class defines a relationship between an instance of
Task_personnel_resource (ie a needed type of personnel) and a specific Competence (ie an
instance of Skill or Trade) that fulfills that need.
Task_personnel_resource_competence associations:−−−

An association with an instance of Task_personnel_resource which defines the need of apersonnel resource for a specific instance of Task or Subtask_by_definition
An association with a specific Competence that has the required qualifications for
performing the defined task
An optional association with zero, one or many Special_training_requirements which aredefined in order for the defined Competence to be able to perform the defined task

Note
There is one instance of Task_personnel_resource_competence per relevant combinationof Task_personnel_resource and Competence (ie Trade or Skill).
Task_personnel_resource_competence special recommendations:−4.14.3.20

Where a specified Task_personnel_resource_competence is dependent upon eg customer,
maintenance level, or external conditions, it must be distinguished by the assignment of an
Applicability_statement to the Task_personnel_resource_competence instance (refer toPara 4.21, UoF Applicability statement)

Special_training_requirement
The Special_training_requirement class identifies additional training required for the given
Competence, in order for the defined Competence to be qualified to perform the defined task.
Note
An instance of class Special_training_requirement has no meaning by itself, but only in thecontext of an association between a specific required personnel resource, and a definedCompetence (ie in association with an instance of Task_personnel_resource_competence).
Special_training_requirement attributes:−−

Special_training_requirement_description
Training_method (zero or one)Special_training_requirement associations:−

An instance of Special_training_requirement is always associated with a specific instance of
Task_personnel_resource_competence (ie the association between a needed personnel

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 112

S3000L-B6568-03000-00

resource, and a defined competence), for which the Special_training_requirement has been
identified
4.14.3.21

Task_document
The Task_document class is a specialization of the Task_resource class, and identifies
Documents needed for the performance of a specific Task or Subtask_by_definition.
Note
Each instance of Task_document is uniquely defined for a specific instance of Task or
Subtask_by_definition. Reuse of document resource definitions is enabled through the useof Documents.
Task_document attributes:−−

Fixed_resource_marker (inherited from class Task_resource)
Task_resource_duration (inherited from class Task_resource)

Task_document associations:−−−−

An association with a specific instance of Task or Subtask_by_definition for which theassociated Task_document resource is needed (inherited from class Task_resource)
An optional association where an instance of Task_document can relate to other instancesof Task_resource (inherited from class Task_resource)
An optional association where an instance of Task_document can be related to from otherinstances of Task_resource (inherited from class Task_resource)
An association with the specific Document that is to be used in the role of a task resource

Task_material_resource special recommendations:−4.14.44.14.4.1

UoF Task Resources - Additions to referenced class and interface definitions
Task
The Task class defined in UoF Task, must also implement the following additional interface:−

4.14.4.2

Task_resource_assignment

Document
The Document class defined in UoF document, must also implement the following additional
association:−

4.14.4.4

Task_resource_assignment

Subtask_by_definition
The Subtask_by_definition class defined in UoF task, must also implement the following
additional interface:−

4.14.4.3

See Task_resource special recommendations

An optional association with zero, one or many instances of Task_document, ie situations
where the Document is to be used as resource in a taskPart
The Part class defined in UoF part, must also implement the following additional associations:−−An optional association with zero, one or many instances of Resource_realization, ie areas
where the Part meets the requirements in a Resource_specification, and hence can beused as a resource in one or many tasks
An optional association with zero, one or many instances of
Task_material_resource_by_reference, ie instances where the Part has been identified as
the material resource to be used in a task

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 113

S3000L-B6568-03000-00−

An optional association with zero, one or many instances of
Task_facility_resource_by_reference, ie instances where the Part has been identified as thefacility resource to be used in a task

4.15

UoF Task Usage (Part 1)

4.15.1

Overall description
The Task Usage (Part 1) UoF supports detailed definitions for:−−−Identifying the breakdown element or part on which an operational or rectifying task is to be
performed
Thresholds and triggers defining the conditions that initiates an operational or rectifying task
Where the operational or rectifying task is to be performed

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 114

S3000L-B6568-03000-00

4.15.2Graphical representation

ICN-B6865-S3000L0229-002-01
Fig 30 UoF Task Usage (Part 1) - class model
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 115

S3000L-B6568-03000-00

4.15.34.15.3.1

UoF Task Usage (Part 1) - New class and interface definitions
Task_target_item
The Task_target_item interface is implemented by classes on which a Task can be performed.
Classes that implement the Task_target_item interface:−−

Breakdown_element_revision
Part

Classes that implement the Task_target_item interface must implement the following
associations:−An optional association with zero, one or many instances of Task_usage

Note
Since the Task_target_item interface is implemented by Breakdown_element_revision andPart, it means that instances of the following classes can be selected asTask_target_items; Hardware_element_revision, Software_element_revision,
Aggregated_element_revision, Zone_element_revision, Hardware_part and Software_part
respectively.
4.15.3.2

Task_usage
The Task_usage class (specifically its subclasses) identifies the Task that is to be performed on
a Breakdown_element_revision or Part (ie the Task_target_item).
Note
Task_usage is an abstract class, ie an instantiation of Task_usage needs to be either aPlanned_task_usage or Supporting_task_usage (refer to Para 4.16, UoF Task Usage (Part2)).
Task_usage associations:−−4.15.3.3

An association with the Task_target_item (instance of Breakdown_element_revision or Part)
on which the associated task is to be performed
An optional association with zero, one or many instances of Task_frequency

Task_frequency
The Task_frequency class defines the frequency of performance or occurrence for the
associated Task.
Note
An instance of class Task_frequency has no meaning by itself, but only in the context of a
specific Task_usage.
Task_frequency attributes:−−

Task_frequency
Task_frequency_calculation_method (zero or one)

Task_frequency associations:−

An instance of Task_frequency is always associated with a specific instance of
Task_usage, ie a specific combination of Task and the Task_target_item on which the task
is to be performed.

Task_frequency special recommendations:−

Where a Task_frequency is dependent upon eg external conditions, customer, etc, it must
be distinguished by the assignment of an Applicability_statement to the Task_frequency
instance (also refer to Para 4.21, UoF Applicability Statement).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 116

S3000L-B6568-03000-00

4.15.3.4

Planned_task_item
The Planned_task_item interface is implemented by classes that can be associated with aPlanned_task_usage, ie be associated with task limits and preferred locations for task
execution.
Classes that implement the Planned_task_item interface:−−

Rectifying_task
Operational_task

Classes that implement the Planned_task_item interface must also implement the following
associations:−4.15.3.5

An association with one or many instances of Planned_task_usage

Planned_task_usage
The Planned_task_usage class is a specialization of the Task_usage class, and adds
information in terms of task limits and preferred locations for Task execution.
Note
There is one instance of Planned_task_usage per relevant combination ofPlanned_task_item and Breakdown_element_revision or Part.
Note
The Planned_task_usage class must be used to associate a Rectifying_task or an
Operational_task with the item on which the Task is to be performed.
Planned_task_usage associations:
−
−
−
−
−

An association with the item (instance of Breakdown_element_revision or Part via theTask_target_item interface) on which the associated Planned_task_item is to be performed(inherited from class Task_usage).
An optional association with zero, one or many instances of Task_frequency (inherited fromclass Task_usage).
An association with the Planned_task_item (instance of Rectifying_task or
Operational_task) which is to be performed on the Task_target_item (instance ofBreakdown_element_revision or Part).
An association with at least one instance of Maintenance_level_allocation, ie location where
the associated Planned_task_item is to be performed.
An optional association with zero, one or many instances of Task_limit, ie thresholds(intervals) defining when the associated Planned_task_item is to be performed.

Planned_task_usage recommendations:−

Where an instance of Planned_task_usage is dependent upon eg external conditions,customer, etc, it must be distinguished by the assignment of an Applicability_statement(also refer to Para 4.21, UoF Applicability Statement).

Note
Associating a Planned_task_usage with a specific maintenance level, by default means thatany maintenance level above can carry out the same Task.
4.15.3.6

Maintenance_level_allocation
The Maintenance_level_allocation class defines a relationship between an instance ofPlanned_task_usage and an identified support organization where the associatedPlanned_task_item is to be carried out.
Note
An instance of class Maintenance_level_allocation has no meaning by itself, but only in thecontext of a Planned_task_usage.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 117

S3000L-B6568-03000-00

Maintenance_level_allocation associations:−−

An instance of Maintenance_level_allocation is always associated with an instance ofPlanned_task_usage, ie specific combination of a Rectifying_task or Operational_task andBreakdown_element_revision or Part.
An association with the Maintenance_level_type, Maintenance_location,
Operating_location_type, or Operating_location that is identified as the organization thatmust have the capability to perform the associated task (via theMaintenance_level_allocation_interface).

Note
There is one instance of Maintenance_level_allocation per relevant combination ofPlanned_task_usage and support organization.
Maintenance_level_allocation special recommendations:−4.15.3.7

Where a Maintenance_level_allocation is dependent upon eg operational scenario etc, it
must be distinguished by the assignment of an Applicability_statement to the instance ofMaintenance_level_allocation (also refer to Para 4.21, UoF Applicability Statement)

Maintenance_level_allocation_interface
The Maintenance_level_allocation_interface is implemented by classes that can represent
support organizations where a Planned_task_item can be performed.
Classes that implement the Maintenance_level_allocation_interface interface:−−−−

Maintenance_level_type
Maintenance_location
Operating_location_type
Operating_location

Classes that implement the Maintenance_level_allocation_interface must also implement thefollowing association:−
4.15.3.8

An optional association with zero, one or many instances of Maintenance_level_allocation

Task_limit
The Task_limit class identifies thresholds (intervals) which defines when the associatedPlanned_task_item is to be performed on the identified Breakdown_element_revision or Part.
Note
An instance of class Task_limit has no meaning by itself, but only in the context of a
specific Planned_task_usage or Task_requirement_target (UoF LSA Candidate Task
Requirement).
Note
Task_limit is an abstract class, ie an instantiation of Task_limit needs to be either a
Discrete_task_limit or a Periodic_task_limit.
Task_limit attributes:−−

Task_limit_harmonization_indicator
Task_limit_description (zero or one)

Task_limit associations:−

An instance of Task_limit is always associated with a specific instance ofPlanned_task_usage or Task_requirement (Refer to UoF LSA Candidate Task
Requirement)

Task_limit special recommendations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 118

S3000L-B6568-03000-00−

4.15.3.9

Where an instance of Task_limit is dependent upon eg external conditions, customer, etc, it
must be distinguished by the assignment of an Applicability_statement (also refer to Para
4.21 UoF Applicability Statement)

Sampling
The Sampling class identifies the method to be used for selecting a limited set of manufactured
products, on which the task is to be performed.
Note
An instance of class Sampling has no meaning by itself, but only in the context of a specific
Discrete_task_limit, Initial_task_limit or Repeat_task_limit.
Note
An instance of Sampling can be (but must not be) specialized into either Sampling_by_ratio
or Sampling_by_value.
Sampling attributes:−

Sampling_method_description

Sampling associations:−4.15.3.10

An instance of Sampling must always be associated with a specific instance of a class that
implements the Sampling_interface.

Sampling_by_ratio
The Sampling_by_ratio class is a specialization of the Sampling class, and identifies that themethod used for selecting products on which the rectifying task is to be performed is done byratio.
Note
An instance of class Sampling_by_ratio has no meaning by itself, but only in the context ofa specific Discrete_task_limit, Initial_task_limit or Repeat_task_limit.
Sampling_by_ratio attributes:−−

Sampling_method_description (inherited from class Sampling)
Sampling_method_ratio

Sampling_by_ratio associations:−4.15.3.11

An instance of Sampling_by_ratio must always be associated with a specific instance of aclass that implements the Sampling_interface (inherited from class Sampling)

Sampling_by_value
The Sampling_by_value class is a specialization of the Sampling class, and identifies that themethod used for selecting products on which the rectifying task is to be performed is done byvalue.
Note
An instance of class Sampling_by_value has no meaning by itself, but only in the context ofa specific Discrete_task_limit, Initial_task_limit or Repeat_task_limit.
Sampling_by_value attributes:−−

Sampling_method_description (inherited from class Sampling)
Sampling_method_value

Sampling_by_value associations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 119

S3000L-B6568-03000-00−

4.15.3.12

An instance of Sampling_by_value must always be associated with a specific instance of aclass that implements the Sampling_interface (inherited from class Sampling)

Sampling_interface
The Sampling_interface is implemented by classes that can be associated with a definedsampling.
Classes that implement the Sampling_interface:−−−

Discrete_task_limit
Initial_task_limit
Repeat_task_limit

Classes that implement the Sampling_interface must implement the following associations:−4.15.3.13

An optional association with zero or one instance of Sampling (and subclasses thereof)

Discrete_task_limit
The Discrete_task_limit class is a specialization of the Task_limit class, and is used to identify
task limits that are distinct from each other, ie there is no scheduled next occurrence for the
associated task.
Note
An instance of class Discrete_task_limit has no meaning by itself, but only in the context ofa specific instance of Planned_task_usage.
Note
Discrete_task_limit must not contain a computable expression, ie it can just contain a
Task_limit_description without any computable triggers or thresholds.
Discrete_task_limit attributes:−−

Task_limit_harmonization_indicator (inherited from class Task_limit)
Task_limit_description (inherited from class Task_limit)

The Discrete_task_limit class must implement the following interfaces:−

Sampling_interface

Discrete_task_limit associations:−−−

An instance of Discrete_task_limit is always associated with a specific instance ofPlanned_task_usage or Task_requirement (inherited from class Task_limit)
An optional trigger association with zero, one or many instances of Threshold_definition
An optional threshold association with zero, one or many instances of Threshold_definition

Note
The threshold association defines a specified interval, from a defined event, to the next
required performance of the Planned_task_item. The defined event is identified by thetrigger association.
Note
The trigger association describes the event to which the threshold is related, eg bird strikeor engine replacement. If the Discrete_task_limit does not define any trigger association, it
is to be assumed that the trigger event equals the Hardware_part_maintenance_startdefined for Hardware_part in UoF Part. The trigger activates the threshold.
NoteMultiple instances of Threshold_definitions for both the trigger and the thresholdassociation mean ‘whichever comes first’.
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 120

S3000L-B6568-03000-00

Discrete_task_limit special recommendations:−

Where an instance of Discrete_task_limit is dependent upon eg external conditions,customer, etc, it must be distinguished by the assignment of an Applicability_statement(also refer to Para 4.21, UoF Applicability Statement)

Note
The Discrete_task_limit can be used to define "Perform once" and "On condition" task limits
as defined in S1000D.
4.15.3.14

Periodic_task_limit
The Periodic_task_limit class is a specialization of the Task_limit class, and is used to identify
task limits that are repeated with a specific interval, ie there is a next scheduled occurrence forthe associated task.
Note
An instance of class Periodic_task_limit has no meaning by itself, but only in the context ofa specific instance of Planned_task_usage plan.
Note
Periodic_task_limit must contain a computable expression.
Periodic_task_limit attributes:−−

Task_limit_harmonization_indicator (inherited from class Task_limit)
Task_limit_description (inherited from class Task_limit)

Periodic_task_limit associations:−−−

An instance of Periodic_task_limit is always associated with a specific instance ofPlanned_task_usage or Task_requirement (inherited from class Task_limit)
An optional initial threshold association with an instance of Initial_task_limit
An association with one or many instances of Repeat_task_limit

Note
The Initial_task_limit association defines a specified interval for the first required
performance of the Planned_task_item (ie Rectifying_task or Operational_task). Theinterval is to be assumed to be triggered by the condition that is defined as the
Hardware_part_maintenance_start for Hardware_part in UoF Part.
Note
Multiple instances of Repeat_task_limits for the repeat association require that each
instance of Repeat_task_limits is ordered using the Subsequent_repeat_relationship class.
Periodic_task_limit special recommendations:−

Where an instance of Periodic_task_limit is dependent upon eg external conditions,customer, etc, it must be distinguished by the assignment of an Applicability_statement(also refer to Para 4.21, UoF Applicability Statement)

Note
The Periodic_task_limit class can be used to define explicit combinations of "Perform once"and "Perform periodically" task limits as defined in S1000D.
4.15.3.15

Initial_task_limit
The Initial_task_limit class defines a specific interval for the first scheduled performance of aperiodic task.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 121

S3000L-B6568-03000-00

Note
An instance of class Initial_task_limit has no meaning by itself, but only in the context of a
specific Periodic_task_limit.
The Initial_task_limit class must implement the following interfaces:−

Sampling_interface

Initial_task_limit associations:−−

An instance of Initial_task_limit is always associated with a specific instance of
Periodic_task_limit
A threshold association with one or many instances of Threshold_definition

Note
The threshold association defines a specified interval for the first performance of the
Planned_task_item (ie Rectifying_task or Operational_task).
Note
Multiple instances of Threshold_definition for the threshold association mean “whichevercomes first”.
4.15.3.16

Repeat_task_limit
The Repeat_task_limit class defines task limits that are repeated with a specific interval.
Note
An instance of class Repeat_task_limit has no meaning by itself, but only in the context of a
specific Periodic_task_limit.
Note
Repeat_task_limit must contain a computable expression.
The Repeat_task_limit class must implement the following interfaces:−

Sampling_interface

Repeat_task_limit associations:−−−−

An instance of Repeat_task_limit is always associated with a specific instance of
Periodic_task_limit
A threshold association with one or many instances of Threshold_definition
An optional association with zero or one succeeding instance of Repeat_task_limit, via theSubsequent_repeat_relationship
An optional association with zero or one preceding instance of Repeat_task_limit, via theSubsequent_repeat_relationshipNote
The threshold association defines a specified interval for the repeated performance of the
Planned_task_item (ie the associated Rectifying_task or Operational_task).
Note
Multiple instances of Threshold_definition for the threshold association mean ‘whichevercomes first’.
Note
The Repeat_task_limit class can be used to define "Perform periodically" task limits as
defined in S1000D Issue 3.0.
4.15.3.17

Subsequent_repeat_relationship
The Subsequent_repeat_relationship class defines a subsequent relationship between two
instances of Repeat_task_limit.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 122

S3000L-B6568-03000-00

Note
The definition of when an instance of Repeat_task_limit is to be succeeded by anotherinstance (ie replaced by another instance) is determined by the instance ofThreshold_definition defined via the Subsequent_repeat_relationship trigger association.
Subsequent_repeat_relationship associations:−−−

A preceding association with an instance of Repeat_task_limit
An succeeding association with an instance of Repeat_task_limit
A trigger association with one or many instances of Threshold_definition

Note
The trigger association describes the event when the instance of Repeat_task_limit
identified by the succeeding association will replace the instance of Repeat_task_limit
identified by the preceding association.
Note
Multiple instances of Threshold_definition for the trigger association mean "whichevercomes first".
4.15.3.18

Threshold_definition
The Threshold_definition class defines the value or event that constitutes a threshold or trigger.
Note
An instance of class Threshold_definition has no meaning by itself, but only in the context
of a specific instance of either:
•
•
•
•
•

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

Note
Threshold_definition is an abstract class, ie an instantiation of Threshold_definition needs
to be either a Parameter_threshold or an Event_threshold.
Threshold_definition associations:−

An instance of Threshold_definition can only be associated with one specific instance of
one of the following:
•
•
•
•
•

4.15.3.19

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

Parameter_threshold
The Parameter_threshold class is a specialization of class Threshold_definition and is used torepresent a value that constitutes the threshold or trigger.
Note
An instance of class Parameter_threshold has no meaning by itself, but only in the context
of a specific instance of either:•••

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 123

S3000L-B6568-03000-00••

Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger.

Note
An example of Parameter_threshold is 1000 flight hours. This value can either be a trigger
or a threshold depending on how it is being referenced.
Parameter_threshold attributes:−

Threshold_value

Parameter_threshold associations:−

An instance of Parameter_threshold is always associated with a specific instance of one of
the following:
•
•
•
•
•

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

Parameter_threshold special recommendations:−4.15.3.20

A representation of the Threshold_value attribute is recommended to use theValue_with_limit_property representation, where Limit_qualifier is set to ‘maximum’. Therecan also be cases where the use of Value_with_tolerances_property or
Value_range_property is valid

Event_threshold
The Event_threshold class is a specialization of class Threshold_definition and is used torepresent the number of occurrences of an explicit event that constitutes the threshold or
trigger.
Note
An instance of class Event_threshold has no meaning by itself, but only in the context of a
specific instance of either:
•
•
•
•
•

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold.
Subsequent_repeat_relationship, as a trigger

Note
Event_threshold is an abstract class, ie an instantiation of Event_threshold needs to beeither, an LSA_failure_mode_related_threshold, a Special_event_related_threshold or a
Task_related_threshold.
Event_threshold attributes:−

Event_threshold_number_of_event_occurrences

Event_threshold associations:−

An instance of Event_threshold is always associated with a specific instance of one of the of
the following:•••

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 124

S3000L-B6568-03000-00••
4.15.3.21

Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

LSA_failure_mode_related_threshold
The LSA_failure_mode_related_threshold class is a specialization of class Event_threshold.
LSA_failure_mode_related_threshold is used to represent the number of occurrences of a
specific LSA_failure_mode that constitutes the threshold or trigger.
Note
An instance of class LSA_failure_mode_related_threshold has no meaning by itself, but
only in the context of a specific instance of either:
•
•
•
•
•

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

LSA_failure_mode_related_threshold attributes:−

Event_threshold_number_of_event_occurrences (inherited from class Event_threshold)

LSA_failure_mode_related_threshold associations:−

An instance of LSA_failure_mode_related_threshold is always associated with a specificinstance of one of the following:
•
•
•
•
•

−
4.15.3.22

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

An association with an instance of LSA_failure_mode

Special_event_related_threshold
The Special_event_related_threshold class is a specialization of class Event_threshold.
Special_event_related_threshold is used to represent the number of occurrences of a specific
Special_event that constitutes the threshold or trigger.
Note
An instance of class Special_event_related_threshold has no meaning by itself, but only inthe context of a specific instance of either:
•
•
•
•
•

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

Special_event_related_threshold attributes:−

Event_threshold_number_of_event_occurrences (inherited from class Event_threshold)Special_event_related_threshold associations:−

An instance of Special_event_related_threshold is always associated with a specificinstance of one of the following:••

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 125

S3000L-B6568-03000-00•••−
4.15.3.23

Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

An association with an instance of Special_event

Task_related_threshold
The Task_related_threshold class is a specialization of class Event_threshold.
Task_related_threshold is used to represent the number of occurrences of a specific Task that
constitutes the threshold or trigger.
Note
An instance of class Task_related_threshold has no meaning by itself, but only in thecontext of a specific instance of either:
•
•
•
•
•

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Initial_task_limit, as an initial threshold
Repeat_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

Task_related_threshold attributes:−

Event_threshold_number_of_event_occurrences (inherited from class Event_threshold)Task_related_threshold associations:−

An instance of Task_related_threshold is always associated with a specific instance of oneof the following:
•
•
•
•
•

−
4.15.44.15.4.1

Task_target_item

Rectifying_task
The Rectifying_task class defined in UoF Task, must also implement the following additional
interface:−

4.15.4.4

Task_target_item

Breakdown_element_revision
The Breakdown_element_revision class defined in UoF Breakdown Structure, must also
implement the following additional interface:−

4.15.4.3

An association with an instance of Task

UoF Task Usage (Part 1) - Additions to referenced class and interface definitionsPart
The Part class defined in UoF Part, must also implement the following additional interface:−

4.15.4.2

Discrete_task_limit, as a trigger
Discrete_task_limit, as a threshold
Periodic_task_limit, as an initial threshold
Initial_task_limit, as a threshold
Subsequent_repeat_relationship, as a trigger

Planned_task_item

Operational_task
The Operational_task class defined in UoF Task, must also implement the following additional
interface:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 126

S3000L-B6568-03000-00−
4.15.4.5

Maintenance_level_type
The Maintenance_level_type class defined in UoF Product Usage, must also implement thefollowing additional interface:−

4.15.4.6

An optional association with zero, one or many instances ofSpecial_event_related_threshold

LSA_failure_mode
The LSA_failure_mode class defined in UoF LSA-FMEA and Special Events, must also
implement the following additional association:−

4.15.4.11

Maintenance_level_allocation_interface

Special_event
The Special_event class defined in UoF LSA-FMEA and Special Events, must also implement
the following additional association:−

4.15.4.10

Maintenance_level_allocation_interface

Operating_location
The Operating_location class defined in UoF Product Usage, must also implement the following
additional interface:−

4.15.4.9

Maintenance_level_allocation_interface

Operating_location_type
The Operating_location_type class defined in UoF Product Usage, must also implement thefollowing additional interface:−

4.15.4.8

Maintenance_level_allocation_interface

Maintenance_location
The Maintenance_location class defined in UoF Product Usage, must also implement thefollowing additional interface:−

4.15.4.7

Planned_task_item

An optional association with zero, one or many instances of
LSA_failure_mode_related_threshold

Task
The Task class defined in UoF Task, must also implement the following additional association:−

An optional association with zero, one or many instances of Task_related_threshold

4.16

UoF Task Usage (Part 2)

4.16.1

Overall description
The Task Usage (Part 2) UoF supports the creation of associations between supporting tasks
and the objects on which the supporting task is to be performed.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 127

S3000L-B6568-03000-00

4.16.2Graphical representation

ICN-B6865-S3000L0230-001-01
Fig 31 UoF Task Usage (Part 2) - class model
4.16.34.16.3.1

UoF Task Usage (Part 2) - New class and interface definitions
Supporting_task_usage
The Supporting_task_usage class is a specialization of the Task_usage class, and supports thecreation of associations between instances of Supporting_task and specific Task_target_items(ie Breakdown_element_revision or Part) on which the Supporting_task is to be performed.
Note
There is one instance of Supporting_task_usage per relevant combination of
Supporting_task and Breakdown_element_revision and Part.
Note
The class Supporting_task_usage must be used to associate a Supporting_task with theitem on which the Supporting_task is to be performed.
Supporting_task_usage associations:−−−4.16.44.16.4.1

An association with the specific item (ie instance of Breakdown_element_revision or Part)
on which the associated Supporting_task is to be performed (inherited from class
Task_usage)
An optional association with zero, one or many instances of Task_frequency (inherited fromclass Task_usage)
An association with the specific Supporting_task which is to be performed on theTask_target_item

UoF Task Usage (Part 2) - Additions to referenced class and interface definitions
Supporting_task
The Supporting_task class defined in UoF Task, must also implement the following additional
association:−

An association with one or many instances of Supporting_task_usage in order to identify theitem(s) on which the Supporting_task is to be performed

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 128

S3000L-B6568-03000-00

4.17

UoF Security Classification

4.17.1

Overall description
The Security Classification UoF supports the assignment of security classes to objects thatneed special handling with respect to, availability, distribution, presentation etc.

4.17.2Graphical representation

ICN-B6865-S3000L0231-002-01
Fig 32 UoF Security Classification - class model
4.17.34.17.3.1

UoF Security Classification - New class and interface definitions
Security_class
The Security_class class identifies security classes that can be assigned to objects within an
LSA database.
Security_class attributes:−

Security_class

Security_class associations:−An optional association with zero, one or many instances of Breakdown_element, Part,
Task, Subtask and/or Task_requirement (ie classes that implement the
Security_classification_interface)

Note
Security classification system to be used, is determined by the project.
4.17.3.2

Security_classification_interface
The Security_classification_interface is implemented by classes that can be candidates forsecurity classification.
Classes that implement the Security_classification_interface:−

Breakdown_element

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 129

S3000L-B6568-03000-00

−
−
−
−

Part
Task
SubtaskTask_requirement

Classes that implement the Security_classification_interface must implement the following
association:−

4.17.3.3

An optional association with zero, one or many instances of Security_class (via the
Security_classification class)

Security_classification
The Security_classification class defines a relationship between an instance of Security_classand an instance of a class that implements the Security_classification_interface.
Security_classification associations:−−

An association with the specific Security_class being applied
An association with the instance to which the Security_class is applied (an instance of any
class that implements the Security_classification_interface)

Note
There is one instance of Security_classification per relevant combination of Security_classand instance to which the Security_class is applied (ie relevant instances ofBreakdown_element_revision, Part, Task, Subtask or Task_requirement).
Security_classification special recommendations−

4.17.44.17.4.1

UoF Security Classification - Additions to referenced class and interface definitions
Breakdown_element
The Breakdown_element class defined in UoF Breakdown Structure, must also implement thefollowing additional interface:−

4.17.4.2

Security_classification_interface

SubtaskThe Subtask class defined in UoF Task, must also implement the following additional interface:−

4.17.4.5

Security_classification_interface

Task
The Task class defined in UoF Task, must also implement the following additional interface:−

4.17.4.4

Security_classification_interface

Part
The Part class defined in UoF Part, must also implement the following additional interface:−

4.17.4.3

Where an instance of Security_classification is dependent upon eg external conditions,customer, etc, it must be distinguished by the assignment of an Applicability_statement(also refer to Para 4.21, UoF Applicability Statement)

Security_classification_interface

Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement, must also
implement the following additional interface:−

Security_classification_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 130

S3000L-B6568-03000-00

4.18

UoF Organization Assignment

4.18.1

Overall description
The Organization Assignment UoF supports a flexible way of assigning different types oforganizational information to different types of objects in the data model.
Note
There are some previously proposed (even mandatory) associations with the Organization
class in the data model. This UoF adds the ability to define any type of additionalorganizational information which is of relevance for an instance of classes that implement
the Organization_assignment_interface. An example of additional organizational
information can be ‘design_responsible_organization’ for a specific part. This is not
explicitly defined in the data model but can be added using this UoF, by defining theOrganization_assignment_role of class Organization_assignment as‘Design_responsibility’.

4.18.2Graphical representation

ICN-B6865-S3000L0232-002-01
Fig 33 UoF Organization Assignment - class model
4.18.34.18.3.1

UoF Organization Assignment - New class and interface definitions
Organization_assignment_interface
The Organization_assignment_interface is implemented by classes that can be associated with
optional organizational information.
Classes that implement the Organization_assignment_interface:−−−

Project
Contract
Product

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 131

S3000L-B6568-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Product_variant
Breakdown
Breakdown_element
Part
Material
Product_variant_realization
Key_performance_indicator
Candidate_item_analysis_activity
Failure_mode
Change_request
Task_requirement
Task
Resource_specification
Trade
Skill
Task_usage
Task_limit
Security_class
Security_classification
Document
Property_representation

Note
Organizations can also be assigned to any class that is a subclass of the classes
enumerated above, eg to a Rectifying_task which is a subclass of Task (the rule ofsubstitutability).
Classes that implement the Organization_assignment_interface must implement the following
association:−

4.18.3.2

An optional association with zero, one or many instances of Organization (via theOrganization_assignment class)

Organization_assignment
The Organization_assignment class defines a relationship between a specific Organization andan instance of any class that implements the Organization_assignment_interface.
Note
The role of the Organization being assigned is determined by
Organization_assignment_role attribute.
Organization_assignment attributes:−

Organization_assignment_role

Organization_assignment associations:−−

An association with the specific Organization being assigned
An association with the object to which the Organization is assigned (an instance of any
class that implements the Organization_assignment_interface)

Note
There is one instance of Organization_assignment per relevant combination ofOrganization and instance to which the Organization is being assigned (ie relevant instanceof any class that implements the Organization_assignment_interface).
Organization_assignment special recommendations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 132

S3000L-B6568-03000-00−

4.18.44.18.4.1

UoF Organization Assignment - Additions to referenced class and interface definitions
Project
The Project class defined in UoF Project, must also implement the following additional interface:−

4.18.4.2

Organization_assignment_interface

Product_variant_realization
The Product_variant_realization class defined in UoF Product Variant Applicability, must also
implement the following additional interface:−

4.18.4.10

Organization_assignment_interface

Material
The Material class defined in UoF Part, must also implement the following additional interface:−

4.18.4.9

Organization_assignment_interface

Part
The Part class defined in UoF Part, must also implement the following additional interface:−

4.18.4.8

Organization_assignment_interface

Breakdown_element
The Breakdown_element class defined in UoF Breakdown Structure, must also implement thefollowing additional interface:−

4.18.4.7

Organization_assignment_interface

Breakdown
The Breakdown class defined in UoF Breakdown Structure, must also implement the following
additional interface:−

4.18.4.6

Organization_assignment_interface

Product_variant
The Product_variant class defined in UoF Project, must also implement the following additional
interface:−

4.18.4.5

Organization_assignment_interface

Product
The Product class defined in UoF Project, must also implement the following additional
interface:−

4.18.4.4

Organization_assignment_interface

Contract
The Contract class defined in UoF Project, must also implement the following additional
interface:−

4.18.4.3

Where an instance of Organization_assignment is dependent upon eg customer, etc, it
must be distinguished by the assignment of an Applicability_statement (also refer to Para
4.21, UoF Applicability Statement)

Organization_assignment_interface

Key_performance_indicator
The Key_performance_indicator class defined in UoF LSA Candidate, must also implement thefollowing additional interface:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 133

S3000L-B6568-03000-00−
4.18.4.11

Candidate_item_analysis_activity
The Candidate_item_analysis_activity class defined in UoF LSA Candidate Analysis Activity,
must also implement the following additional interface:−

4.18.4.12

Organization_assignment_interface

Task_usage
The Task_usage class defined in UoF Task Usage (Part 1), must also implement the following
additional interface:−

4.18.4.20

Organization_assignment_interface

Skill
The Skill class defined in UoF Task Resources, must also implement the following additional
interface:−

4.18.4.19

Organization_assignment_interface

Trade
The Trade class defined in UoF Task Resources, must also implement the following additional
interface:−

4.18.4.18

Organization_assignment_interface

Resource_specification
The Resource_specification class defined in UoF Task Resources, must also implement thefollowing additional interface:−

4.18.4.17

Organization_assignment_interface

Task
The Task class defined in UoF Task, must also implement the following additional interface:−

4.18.4.16

Organization_assignment_interface

Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement, must also
implement the following additional interface:−

4.18.4.15

Organization_assignment_interface

Change_request
The Change_request class defined in UoF LSA Candidate Task Requirement, must also
implement the following additional interface:−

4.18.4.14

Organization_assignment_interface

Failure_mode
The Failure_mode class defined in UoF LSA-FMEA and Special Events, must also implement
the following additional interface:−

4.18.4.13

Organization_assignment_interface

Organization_assignment_interface

Task_limit
The Task_limit class defined in UoF Task Usage (Part 1), must also implement the following
additional interface:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 134

S3000L-B6568-03000-00−
4.18.4.21

Security_class
The Security_class class defined in UoF Security Classification, must also implement thefollowing additional interface:−

4.18.4.22

Organization_assignment_interface

Document
The Document class defined in UoF Document, must also implement the following additional
interface:−

4.18.4.24

Organization_assignment_interface

Security_classification
The Security_classification class defined in UoF Security Classification, must also implement
the following additional interface:−

4.18.4.23

Organization_assignment_interface

Organization_assignment_interface

Property_representation
The Property_representation class defined in UoF Data Types, must also implement thefollowing additional interface:−

Organization_assignment_interface

Note
The assignment of an Organization to a Property_representation enables the recording oforganizational information for any property value in the LSA database, eg in order to
identify the Organization that recorded the property value.

4.19

UoF Document

4.19.1

Overall description
The Document UoF supports a flexible way of assigning documents to different types of objects
in the data model.
Note
There are some previously proposed (even mandatory) associations with the Documentclass in the data model. This UoF adds the ability to define any type of additional document
information which is of relevance for an instance of classes that implement theDocument_assignment_interface. An example of additional document information can be a‘design document’ for a Part. This is not explicit in the data model but can be added using
this UoF, by defining the Document_assignment_role of class Document_assignment as‘Design_document’.
Note
The S3000L data model defines three specializations of document:••

S1000D data modules and S1000D publication modules, which just contains
information that identifies the respective document
External documents, which contains more meta information about the document itself

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 135

S3000L-B6568-03000-00

4.19.2Graphical representation

ICN-B6865-S3000L0233-002-01
Fig 34 UoF Document - class model

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 136

S3000L-B6568-03000-00

4.19.34.19.3.1

UoF Document - New class and interface definitions
Document
The Document class represents documents which are of relevance for the LSA program.
Note
Document is an abstract class, ie an instantiation of Document must either be; an
S1000D_data_module, an S1000D_publication_module, or an External_document.
Document associations:−4.19.3.2

An optional association with zero, one or many instances of any class that implements theDocument_assignment_interface (via Document_assignment)

S1000D_data_module
The S1000D_data_module class is a specialization of class Document.
The S1000D_data_module class enables the cross references in between the Tasks being
defined in S3000L, and its corresponding S1000D data modules, as defined in UoF Task.
However, a document that is of type S1000D_data_module can also be assigned to zero, one
or many instances of classes that implement the Document_assignment_interface, for the same
reason as any other type of document.
S1000D_data_module attributes:−−−

Data_module_code
Data_module_issue_number (zero or one)
Data_module_infoname (zero or one)

S1000D_data_module association:−

4.19.3.3

An optional association with zero, one or many instances of any class that implements theDocument_assignment_interface (inherited from class Document)

S1000D_publication_module
The S1000D_publication_module class is a specialization of class Document.
The S1000D_publication_module class enables references from Subtasks to S1000D
publication modules, as defined in UoF Task. However, a document that is of type
S1000D_pubication_module can also be assigned to zero, one or many instances of classes
that implement the Document_assignment_interface, for the same reason as any other type of
document.
S1000D_publication_module attributes:−−−

Publication_module_code
Publication_module_issue_number (zero or one)
Publication_module_title (zero or one)

S1000D_publication_module association:−

4.19.3.4

An optional association with zero, one or many instances of any class that implements theDocument_assignment_interface (inherited from class Document)

External_document
The External_document class is a specialization of class Document, and represents all
documents that are not identified and produced in accordance with S1000D.
External_document attributes:−−

Document_identifier (one or many)
Document_title

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 137

S3000L-B6568-03000-00

−
−
−
−

Document_issue_identifier (zero or one)
Document_issue_date (zero or one)
Document_type (zero or one)
Document_location (zero or one)

External_document associations:−4.19.3.5

An optional association with zero, one or many instances of any class that implements theDocument_assignment_interface (inherited from class Document)

Document_assignment_interface
The Document_assignment_interface is implemented by classes that can be associated with
optional document information.
Classes that implement the Document_assignment_interface:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Project
Contracted_product_variant
Contract
Product
Product_variant
Organization
Operating_location
Maintenance_location
Operating_location_type
Maintenance_level_type
Breakdown
Breakdown_revision
Breakdown_element
Breakdown_element_revisionPart
Material
Hardware_part_operational_authorized_life
Alternate_part_relationshipParts_list_entry
Hardware_element_realization
Software_element_realization
Hardware_element_in_zone_relationship
Product_variant_realization
Key_performance_indicator
Mean_time_between_failure_correction
Failure_rate_correction
Candidate_item_analysis_activity
LSA_candidate_technology_behavior_rating
LSA_failure_mode
Failure_mode
Failure_mode_effectSpecial_event
Product_usage_phase
Detectability
Task_requirement
Change_request
Task
Warning_caution_or_note
Task_change

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 138

S3000L-B6568-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Subtask
Subtask_timeline
Subtask_acceptance_parameter
Circuit_breaker
Task_resource
Skill
Trade
Special_training_requirement
Resource_specification
Resource_realization
Task_usage
Task_frequency
Task_limit
Security_class
Security_classification
Organization_assignment
RemarkApplicability_statement
Condition_by_identifier
Condition_type
Class
Prp

Note
Documents can also be assigned to any class that is a subclass of the classes enumerated
above, eg to a Rectifying_task which is a subclass of Task (the rule of substitutability).
Classes that implement the Document_assignment_interface must implement the following
association:−

4.19.3.6

An optional association with zero, one or many instances of Documents (via theDocument_assignment class)

Document_assignment
The Document_assignment class defines a relationship between a specific Document and an
instance of any class that implements the Document_assignment_interface.
Note
The role of the document being assigned is determined by Document_assignment_role
attribute.
Note
The Document_portion attribute identifies a defined portion of a document which is ofinterest in a specific usage.
Document_assignment attributes:−−

Document_assignment_role
Document_portion (zero or one)

Document associations:−−

An association with the specific Document being assigned
An association with the object to which the instance of Document is being assigned (ie an
instance of any class that implements the Document_assignment_interface)

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 139

S3000L-B6568-03000-00

Note
There is one instance of Document_assignment per relevant combination of Document
instance and instance to which the Document is assigned (ie instance of any class that
implements the Document_assignment_interface).
Document_assignment special recommendations:−4.19.44.19.4.1

UoF Document - Additions to referenced class and interface definitions
Project
The Project class defined in UoF Project must also implement the following additional interface:−

4.19.4.2

Document_assignment_interface.

Operating_location
The Operating_location class defined in UoF Product Usage must also implement the following
additional interface:−

4.19.4.8

Document_assignment_interface

Organization
The Organization class defined in UoF Project must also implement the following additional
interface:−

4.19.4.7

Document_assignment_interface

Product_variant
The Product_variant class defined in UoF Project must also implement the following additional
interface:−

4.19.4.6

Document_assignment_interface

Product
The Product class defined in UoF Project must also implement the following additional interface:−

4.19.4.5

Document_assignment_interface

Contract
The Contract class defined in UoF Project must also implement the following additional
interface:−

4.19.4.4

Document_assignment_interface

Contracted_product_variant
The Contracted_product_variant class defined in UoF Project must also implement the following
additional interface:−

4.19.4.3

Where an instance of Document_assignment is dependent upon eg customer, etc, it must
be distinguished by the assignment of an Applicability_statement (also refer to Para 4.21,
UoF Applicability Statement)

Document_assignment_interface

Maintenance_location
The Maintenance_location class defined in UoF Product Usage must also implement thefollowing additional interface:−Document_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 140

S3000L-B6568-03000-00

4.19.4.9

Maintenance_level_type
The Maintenance_level_type class defined in UoF Product Usage must also implement thefollowing additional interface:−

4.19.4.10

Operating_location_type
The Operating_location_type class defined in UoF Product Usage must also implement thefollowing additional interface:−

4.19.4.11

Document_assignment_interface

Hardware_part_operational_authorized_life
The Hardware_part_operational_authorized_life class defined in UoF Part must also implement
the following additional interface:−

4.19.4.18

Document_assignment_interface

Material
The Material class defined in UoF Part must also implement the following additional interface:−

4.19.4.17

Document_assignment_interface

Part
The Part class defined in UoF Part must also implement the following additional interface:−

4.19.4.16

Document_assignment_interface

Breakdown_element_revision
The Breakdown_element_revision class defined in UoF Breakdown Structure must also
implement the following additional interface:−

4.19.4.15

Document_assignment_interface

Breakdown_element
The Breakdown_element class defined in UoF Breakdown Structure must also implement thefollowing additional interface:−

4.19.4.14

Document_assignment_interface

Breakdown_revision
The Breakdown_revision class defined in UoF Breakdown Structure must also implement thefollowing additional interface:−

4.19.4.13

Document_assignment_interface

Breakdown
The Breakdown class defined in UoF Breakdown Structure must also implement the following
additional interface:−

4.19.4.12

Document_assignment_interface

Document_assignment_interface

Alternate_part_relationship
The Alternate_part_relationship class defined in UoF Part must also implement the following
additional interface:−Document_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 141

S3000L-B6568-03000-00

4.19.4.19

Parts_list_entry
The Parts_list_entry class defined in UoF Part must also implement the following additional
interface:−

4.19.4.20

Hardware_element_realization
The Hardware_element_realization class defined in UoF Breakdown Element Realization mustalso implement the following additional interface:−

4.19.4.21

Document_assignment_interface

Candidate_item_analysis_activity
The Candidate_item_analysis_activity class defined in UoF LSA Candidate Analysis Activity
must also implement the following additional interface:−

4.19.4.28

Document_assignment_interface

Failure_rate_correction
The Failure_rate_correction class defined in UoF LSA Candidate must also implement thefollowing additional interface:−

4.19.4.27

Document_assignment_interface

Mean_time_between_failure_correction
The Mean_time_between_failure_correction class defined in UoF LSA Candidate must also
implement the following additional interface:−

4.19.4.26

Document_assignment_interface

Key_performance_indicator
The Key_performance_indicator class defined in UoF LSA Candidate must also implement thefollowing additional interface:−

4.19.4.25

Document_assignment_interface

Product_variant_realization
The Product_variant_realization class defined in UoF Product Variant Applicability must also
implement the following additional interface:−

4.19.4.24

Document_assignment_interface

Hardware_element_in_zone_relationship
The Hardware_element_in_zone_relationship class defined in UoF Breakdown Zone Element
must also implement the following additional interface:−

4.19.4.23

Document_assignment_interface

Software_element_realization
The Software_element_realization class defined in UoF Breakdown Element Realization mustalso implement the following additional interface:−

4.19.4.22

Document_assignment_interface

Document_assignment_interface

LSA_candidate_technology_behavior_rating
The LSA_candidate_technology_behavior_rating class defined in UoF LSA-FMEA and Special
Events must also implement the following additional interface:−Document_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 142

S3000L-B6568-03000-00

4.19.4.29

LSA_failure_mode
The LSA_failure_mode class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.19.4.30

Failure_mode
The Failure_mode class defined in UoF LSA-FMEA and Special Events must also implement
the following additional interface:−

4.19.4.31

Document_assignment_interface

Task
The Task class defined in UoF Task must also implement the following additional interface:−

4.19.4.38

Document_assignment_interface

Change_request
The Change_request class defined in UoF LSA Candidate Task Requirement must also
implement the following additional interface:−

4.19.4.37

Document_assignment_interface

Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement must also
implement the following additional interface:−

4.19.4.36

Document_assignment_interface

Detectability
The Detectability class defined in UoF LSA-FMEA and Special Events must also implement thefollowing additional interface:−

4.19.4.35

Document_assignment_interface

Product_usage_phase
The Product_usage_phase class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.19.4.34

Document_assignment_interface

Special_event
The Special_event class defined in UoF LSA-FMEA and Special Events must also implement
the following additional interface:−

4.19.4.33

Document_assignment_interface

Failure_mode_effect
The Failure_mode_effect class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.19.4.32

Document_assignment_interface

Document_assignment_interface

Warning_caution_or_note
The Warning_caution_or_note class defined in UoF Task must also implement the following
additional interface:−Document_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 143

S3000L-B6568-03000-00

4.19.4.39

Task_change
The Task_change class defined in UoF Task must also implement the following additional
interface:−

4.19.4.40

SubtaskThe Subtask class defined in UoF Task must also implement the following additional interface:−

4.19.4.41

Document_assignment_interface

Special_training_requirement
The Special_training_requirement class defined in UoF Task Resources must also implement
the following additional interface:−

4.19.4.48

Document_assignment_interface

Trade
The Trade class defined in UoF Task Resources must also implement the following additional
interface:−

4.19.4.47

Document_assignment_interface

Skill
The Skill class defined in UoF Task Resources must also implement the following additional
interface:−

4.19.4.46

Document_assignment_interface

Task_resource
The Task_resource class defined in UoF Task Resources must also implement the following
additional interface:−

4.19.4.45

Document_assignment_interface

Circuit_breaker
The Circuit_breaker class defined in UoF Task must also implement the following additional
interface:−

4.19.4.44

Document_assignment_interface

Subtask_acceptance_parameter
The Subtask_acceptance_parameter class defined in UoF Task must also implement thefollowing additional interface:−

4.19.4.43

Document_assignment_interface

Subtask_timeline
The Subtask_timeline class defined in UoF Task must also implement the following additional
interface:−

4.19.4.42

Document_assignment_interface

Document_assignment_interface

Resource_specification
The Resource_specification class defined in UoF Task Resources must also implement thefollowing additional interface:−Document_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 144

S3000L-B6568-03000-00

4.19.4.49

Resource_realization
The Resource_realization class defined in UoF Task Resources must also implement thefollowing additional interface:−

4.19.4.50

Task_usage
The Task_usage class defined in UoF Task Usage (Part 1) must also implement the following
additional interface:−

4.19.4.51

Document_assignment_interface

Applicability_statement
The Applicability_statement class defined in UoF Applicability Statement must also implement
the following additional interface:−

4.19.4.58

Document_assignment_interface

RemarkThe Remark class defined in UoF Remark must also implement the following additional
interface:−

4.19.4.57

Document_assignment_interface

Organization_assignment
The Organization_assignment class defined in UoF Organization Assignment must also
implement the following additional interface:−

4.19.4.56

Document_assignment_interface

Security_classification
The Security_classification class defined in UoF Security Classification must also implement thefollowing additional interface:−

4.19.4.55

Document_assignment_interface

Security_class
The Security_class class defined in UoF Security Classification must also implement thefollowing additional interface:−

4.19.4.54

Document_assignment_interface

Task_limit
The Task_limit class defined in UoF Task Usage (Part 1) must also implement the following
additional interface:−

4.19.4.53

Document_assignment_interface

Task_frequency
The Task_frequency class defined in UoF Task Usage (Part 1) must also implement thefollowing additional interface:−

4.19.4.52

Document_assignment_interface

Document_assignment_interface

Condition_by_identifier
The Condition_by_identifier class defined in UoF Applicability Statement must also implement
the following additional interface:−Document_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 145

S3000L-B6568-03000-00

4.19.4.59

Condition_type
The Condition_type class defined in UoF Applicability Statement must also implement thefollowing additional interface:−

4.19.4.60

Class
The Class class defined in UoF Data Types must also implement the following additional
interface:−

4.19.4.61

Document_assignment_interface

Document_assignment_interface

Prp
The Prp class defined in UoF Data Types must also implement the following additional
interface:−Document_assignment_interface

4.20

UoF Remark

4.20.1

Overall description
The Remark UoF supports a flexible way of assigning remarks to instances of almost any classin the data model.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 146

S3000L-B6568-03000-00

4.20.2Graphical representation

ICN-B6865-S3000L0234-002-01
Fig 35 UoF Remark - class model
4.20.34.20.3.1

UoF Remark - New class and interface definitions
RemarkThe Remark class represents remarks of any kind, which anyone working within the LSA
Program would like to put against an object of interest.
Remark attributes:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 147

S3000L-B6568-03000-00−−

Remark_text
Remark_type (zero or one)

Note
Since the Remark_text is of data type Descr, all remarks also identify the organization thatprovided the remark, and the date when it was recorded.
Remark associations:−4.20.3.2

An association with one or many instances of any class that implements the
Remark_assignment_interface

Remark_assignment_interface
The Remark_assignment_interface is implemented by classes that can be associated with
optional remarks.
Classes that must implement the Remark_assignment_interface:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Project
Contract
Product
Product_variant
Contracted_product_variant
Organization
Contracted_product_variant_in_operating_location
Contracted_product_variant_in_operating_location_type
Maintenance_level_type
Operating_location
Operating_location_type
Maintenance_location
Breakdown
Breakdown_revision
Breakdown_element
Breakdown_element_revision
Breakdown_element_relationship
Part
Parts_list_entry
Hardware_part_operational_authorized_life
Material
Hardware_part_material_usage
Alternate_part_relationship
Substitute_part_relationship
Hardware_element_realization
Software_element_realization
Hardware_element_in_zone_relationship
Product_variant_realization
Product_variant_applicability
Product_variant_realization_applicability
Key_performance_indicator
Failure_rate_correction
Mean_time_between_failure_correction
Candidate_item_analysis_activity
Failure_mode
LSA_failure_mode
Special_event
Failure_mode_effectApplicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 148

S3000L-B6568-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

LSA_candidate_technology_behavior_rating
Special_event_occurrence_definition
Product_usage_phase
Special_event_effects
Detectability
Task_requirement
Task_requirement_change
Change_request
Task
Task_distribution
Warning_caution_or_note
Task_change
Subtask
Subtask_timeline
Subtask_in_zone
Subtask_acceptance_parameter
Subtask_objective_state
Circuit_breaker
Task_resource
Task_resource_relationshipResource_specification
Resource_realization
Special_training_requirement
Skill
Trade
Task_usage
Task_frequency
Maintenance_level_allocation
Task_limit
Sampling
Security_class
Security_classification
Document
Document_assignment
Organization_assignment
Applicability_statement
Condition_by_identifier
Condition_type
Condition_statement
Serial_number_range
Class
Classification
Prp
Property_representation

Note
Remarks can also be assigned to any class that is a subclass of the classes enumerated
above, eg to a Rectifying_task which is a subclass of Task (the rule of substitutability).
Classes that implement the Remark_assignment_interface must implement the following
association:−

An optional association with zero, one or many remarks

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 149

S3000L-B6568-03000-00

4.20.44.20.4.1

UoF Remark - Additions to referenced class and interface definitions
Project
The Project class defined in UoF Project must also implement the following additional interface:−

4.20.4.2

Contract
The Contract class defined in UoF Project must also implement the following additional
interface:−

4.20.4.3

Remark_assignment_interface

Maintenance_level_type
The Maintenance_level_type class defined in UoF Product Usage must also implement thefollowing additional interface:−

4.20.4.10

Remark_assignment_interface

Contracted_product_variant_in_operating_location_type
The Contracted_product_variant_in_operating_location_type class defined in UoF Product
Usage must also implement the following additional interface:−

4.20.4.9

Remark_assignment_interface

Contracted_product_variant_in_operating_location
The Contracted_product_variant_in_operating_location class defined in UoF Product Usage
must also implement the following additional interface:−

4.20.4.8

Remark_assignment_interface

Organization
The Organization class defined in UoF Project must also implement the following additional
interface:−

4.20.4.7

Remark_assignment_interface

Contracted_product_variant
The Contracted_product_variant class defined in UoF Project must also implement the following
additional interface:−

4.20.4.6

Remark_assignment_interface

Product_variant
The Product_variant class defined in UoF Project must also implement the following additional
interface:−

4.20.4.5

Remark_assignment_interface

Product
The Product class defined in UoF Project must also implement the following additional interface:−

4.20.4.4

Remark_assignment_interface

Remark_assignment_interface

Operating_location
The Operating_location class defined in UoF Product Usage must also implement the following
additional interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 150

S3000L-B6568-03000-00

4.20.4.11

Operating_location_type
The Operating_location_type class defined in UoF Product Usage must also implement thefollowing additional interface:−

4.20.4.12

Maintenance_location
The Maintenance_location class defined in UoF Product Usage must also implement thefollowing additional interface:−

4.20.4.13

Remark_assignment_interface

Parts_list_entry
The Parts_list_entry class defined in UoF Part must also implement the following additional
interface:−

4.20.4.20

Remark_assignment_interface

Part
The Part class defined in UoF Part must also implement the following additional interface:−

4.20.4.19

Remark_assignment_interface

Breakdown_element_relationship
The Breakdown_element_relationship class defined in UoF Breakdown Structure must also
implement the following additional interface:−

4.20.4.18

Remark_assignment_interface

Breakdown_element_revision
The Breakdown_element_revision class defined in UoF Breakdown Structure must also
implement the following additional interface:−

4.20.4.17

Remark_assignment_interface

Breakdown_element
The Breakdown_element class defined in UoF Breakdown Structure must also implement thefollowing additional interface:−

4.20.4.16

Remark_assignment_interface

Breakdown_revision
The Breakdown_revision class defined in UoF Breakdown Structure must also implement thefollowing additional interface:−

4.20.4.15

Remark_assignment_interface

Breakdown
The Breakdown class defined in UoF Breakdown Structure must also implement the following
additional interface:−

4.20.4.14

Remark_assignment_interface

Remark_assignment_interface

Hardware_part_operational_authorized_life
The Hardware_part_operational_authorized_life class defined in UoF Part must also implement
the following additional interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 151

S3000L-B6568-03000-00

4.20.4.21

Material
The Material class defined in UoF Part must also implement the following additional interface:−

4.20.4.22

Hardware_part_material_usage
The Hardware_part_material_usage class defined in UoF Part must also implement thefollowing additional interface:−

4.20.4.23

Remark_assignment_interface

Product_variant_applicability
The Product_variant_applicability class defined in UoF Product Variant Applicability must also
implement the following additional interface:−

4.20.4.30

Remark_assignment_interface

Product_variant_realization
The Product_variant_realization class defined in UoF Product Variant Applicability must also
implement the following additional interface:−

4.20.4.29

Remark_assignment_interface

Hardware_element_in_zone_relationship
The Hardware_element_in_zone_relationship class defined in UoF Breakdown Zone Element
must also implement the following additional interface:−

4.20.4.28

Remark_assignment_interface

Software_element_realization
The Software_element_realization class defined in UoF Breakdown Element Realization mustalso implement the following additional interface:−

4.20.4.27

Remark_assignment_interface

Hardware_element_realization
The Hardware_element_realization class defined in UoF Breakdown Element Realization mustalso implement the following additional interface:−

4.20.4.26

Remark_assignment_interface

Substitute_part_relationship
The Substitute_part_relationship class defined in UoF Part must also implement the following
additional interface:−

4.20.4.25

Remark_assignment_interface

Alternate_part_relationship
The Alternate_part_relationship class defined in UoF Part must also implement the following
additional interface:−

4.20.4.24

Remark_assignment_interface

Remark_assignment_interface

Product_variant_realization_applicability
The Product_variant_realization_applicability class defined in UoF Product Variant Applicability
must also implement the following additional interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 152

S3000L-B6568-03000-00

4.20.4.31

Key_performance_indicator
The Key_performance_indicator class defined in UoF LSA Candidate must also implement thefollowing additional interface:−

4.20.4.32

Failure_rate_correction
The Failure_rate_correction class defined in UoF LSA Candidate must also implement thefollowing additional interface:−

4.20.4.33

Remark_assignment_interface

LSA_candidate_technology_behavior_rating
The LSA_candidate_technology_behavior_rating class defined in UoF LSA-FMEA and Special
Events must also implement the following additional interface:−

4.20.4.40

Remark_assignment_interface

Failure_mode_effect
The Failure_mode_effect class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.20.4.39

Remark_assignment_interface

Special_event
The Special_event class defined in UoF LSA-FMEA and Special Events must also implement
the following additional interface:−

4.20.4.38

Remark_assignment_interface

LSA_failure_mode
The LSA_failure_mode class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.20.4.37

Remark_assignment_interface

Failure_mode
The Failure_mode class defined in UoF LSA-FMEA and Special Events must also implement
the following additional interface:−

4.20.4.36

Remark_assignment_interface

Candidate_item_analysis_activity
The Candidate_item_analysis_activity class defined in UoF LSA Candidate Analysis Activity
must also implement the following additional interface:−

4.20.4.35

Remark_assignment_interface

Mean_time_between_failure_correction
The Mean_time_between_failure_correction class defined in UoF LSA Candidate must also
implement the following additional interface:−

4.20.4.34

Remark_assignment_interface

Remark_assignment_interface

Special_event_occurrence_definition
The Special_event_occurrence_definition class defined in UoF LSA-FMEA and Special Events
must also implement the following additional interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 153

S3000L-B6568-03000-00

4.20.4.41

Product_usage_phase
The Product_usage_phase class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.20.4.42

Special_event_effects
The Special_event_effects class defined in UoF LSA-FMEA and Special Events must also
implement the following additional interface:−

4.20.4.43

Remark_assignment_interface

Warning_caution_or_note
The Warning_caution_or_note class defined in UoF Task must also implement the following
additional interface:−

4.20.4.50

Remark_assignment_interface

Task_distribution
The Task_distribution class defined in UoF Task must also implement the following additional
interface:−

4.20.4.49

Remark_assignment_interface

Task
The Task class defined in UoF Task must also implement the following additional interface:−

4.20.4.48

Remark_assignment_interface

Change_request
The Change_request class defined in UoF LSA Candidate Task Requirement must also
implement the following additional interface:−

4.20.4.47

Remark_assignment_interface

Task_requirement_change
The Task_requirement_change class defined in UoF LSA Candidate Task Requirement mustalso implement the following additional interface:−

4.20.4.46

Remark_assignment_interface

Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement must also
implement the following additional interface:−

4.20.4.45

Remark_assignment_interface

Detectability
The Detectability class defined in UoF LSA-FMEA and Special Events must also implement thefollowing additional interface:−

4.20.4.44

Remark_assignment_interface

Remark_assignment_interface

Task_change
The Task_change class defined in UoF Task must also implement the following additional
interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 154

S3000L-B6568-03000-00

4.20.4.51

SubtaskThe Subtask class defined in UoF Task must also implement the following additional interface:−

4.20.4.52

Subtask_timeline
The Subtask_timeline class defined in UoF Task must also implement the following additional
interface:−

4.20.4.53

Remark_assignment_interface

Resource_specification
The Resource_specification class defined in UoF Task Resources must also implement thefollowing additional interface:−

4.20.4.60

Remark_assignment_interface

Task_resource_relationship
The Task_resource_relationship class defined in UoF Task Resources must also implement thefollowing additional interface:−

4.20.4.59

Remark_assignment_interface

Task_resource
The Task_resource class defined in UoF Task Resources must also implement the following
additional interface:−

4.20.4.58

Remark_assignment_interface

Circuit_breaker
The Circuit_breaker class defined in UoF Task must also implement the following additional
interface:−

4.20.4.57

Remark_assignment_interface

Subtask_objective_state
The Subtask_objective_state class defined in UoF Task must also implement the following
additional interface:−

4.20.4.56

Remark_assignment_interface

Subtask_acceptance_parameter
The Subtask_acceptance_parameter class defined in UoF Task must also implement thefollowing additional interface:−

4.20.4.55

Remark_assignment_interface

Subtask_in_zone
The Subtask_in_zone class defined in UoF Task must also implement the following additional
interface:−

4.20.4.54

Remark_assignment_interface

Remark_assignment_interface

Resource_realization
The Resource_realization class defined in UoF Task Resources must also implement thefollowing additional interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 155

S3000L-B6568-03000-00

4.20.4.61

Special_training_requirement
The Special_training_requirement class defined in UoF Task Resources must also implement
the following additional interface:−

4.20.4.62

Skill
The Skill class defined in UoF Task Resources must also implement the following additional
interface:−

4.20.4.63

Remark_assignment_interface

Security_class
The Security_class class defined in UoF Security Classification must also implement thefollowing additional interface:−

4.20.4.70

Remark_assignment_interface

Sampling
The Sampling class defined in UoF Task Usage (Part 1) must also implement the following
additional interface:−

4.20.4.69

Remark_assignment_interface

Task_limit
The Task_limit class defined in UoF Task Usage (Part 1) must also implement the following
additional interface:−

4.20.4.68

Remark_assignment_interface

Maintenance_level_allocation
The Maintenance_level_allocation class defined in UoF Task Usage (Part 1) must also
implement the following additional interface:−

4.20.4.67

Remark_assignment_interface

Task_frequency
The Task_frequency class defined in UoF Task Usage (Part 1) must also implement thefollowing additional interface:−

4.20.4.66

Remark_assignment_interface

Task_usage
The Task_usage class defined in UoF Task Usage (Part 1) must also implement the following
additional interface:−

4.20.4.65

Remark_assignment_interface

Trade
The Trade class defined in UoF Task Resources must also implement the following additional
interface:−

4.20.4.64

Remark_assignment_interface

Remark_assignment_interface

Security_classification
The Security_classification class defined in UoF Security Classification must also implement thefollowing additional interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 156

S3000L-B6568-03000-00

4.20.4.71

Document
The Document class defined in UoF Document must also implement the following additional
interface:−

4.20.4.72

Document_assignment
The Document_assignment class defined in UoF Document must also implement the following
additional interface:−

4.20.4.73

Remark_assignment_interfaceClass
The Class class defined in UoF Data Types must also implement the following additional
interface:−

4.20.4.80

Remark_assignment_interface

Serial_number_range
The Serial_number_range class defined in UoF Applicability Statement must also implement thefollowing additional interface:−

4.20.4.79

Remark_assignment_interface

Condition_statement
The Condition_statement class defined in UoF Applicability Statement must also implement thefollowing additional interface:−

4.20.4.78

Remark_assignment_interface

Condition_type
The Condition_type class defined in UoF Applicability Statement must also implement thefollowing additional interface:−

4.20.4.77

Remark_assignment_interface

Condition_by_identifier
The Condition_by_identifier class defined in UoF Applicability Statement must also implement
the following additional interface:−

4.20.4.76

Remark_assignment_interface.

Applicability_statement
The Applicability_statement class defined in UoF Applicability Statement must also implement
the following additional interface:−

4.20.4.75

Remark_assignment_interface

Organization_assignment
The Organization_assignment class defined in UoF Organization Assignment must also
implement the following additional interface:−

4.20.4.74

Remark_assignment_interface

Remark_assignment_interface

Classification
The Classification class defined in UoF Data Types must also implement the following additional
interface:−

Remark_assignment_interface

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 157

S3000L-B6568-03000-00

4.20.4.81

Prp
The Prp class defined in UoF Data Types must also implement the following additional
interface:−

4.20.4.82

Remark_assignment_interface

Property_representation
The Property_representation class defined in UoF Data Types must also implement thefollowing additional interface:−

Remark_assignment_interface

4.21

UoF Applicability Statement

4.21.1

Overall description
The Applicability Statement UoF defines a flexible way of assigning applicability statements to
instances of relevant classes in the data model. This UoF supports simple to highly complex
definitions of applicability statements.
Note
The S3000L applicability statement class model is based on the applicability model definedin S1000D.
The Applicability Statement class model supports:−−−

Identification of parameters that can affect the applicability of LSA data (eg parameters suchas "model A", "tail number 15", "arctic", "desert", "land-based", "sea-based", etc)
Creation of computable logical expressions which can be evaluated, using the identified
parameters
Enumeration of the S3000L classes that can have an associated applicability statement

The definition of an applicability statement is based upon the following constructs:−−

Applicability assignment, which identifies classes to which an applicability statement can be
assigned
Applicability evaluation, which defines the expression to be evaluated in order for the target
item to be applicable

The applicability expression to be evaluated can be either a logical expression, or a value to beasserted. Any use of a logical expression will in turn relate to one or many values which are to
be asserted.
Note
S1000D defines two separate types of parameters which can affect the applicability of techdata. Firstly, product attributes and secondly, conditions. Product attributes are propertiesof the product that are typically set at the time of manufacture of a product instance and will
not change throughout the service life of a product instance. Examples of product attributes
given in S1000D are ‘serial number’ or ‘model’. Conditions may be technical, operational,
environmental or any other type that can change throughout the service life of a productinstance. Examples of conditions given in S1000D are location of maintenance,
temperature, wind speed and sandy conditions. However, there is no hard and fast rule in
S1000D for distinguishing between product attributes and conditions, which is why S3000L
does not implement this distinction in the data model. Mapping in between S3000L
parameters and S1000D product attributes and conditions needs to be done on a per
project basis.
The Applicability Cross Reference (ACT) and Condition Cross Reference (CCT) data
modules in S1000D can be generated from the defined Conditions in S3000L, and/or fromthe instances that defined for classes that implements the Applicability_assert_interface.
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 158

S3000L-B6568-03000-00

Note
Applicability statements in S1000D (<applic>) can be generated from Applicability
statements defined in S3000L. Basic rules are:•••

The S1000D <applic> element can be derived from the Applicability statement sectionof the S3000L data model, which includes Applicability_statement,
Dated_applicability_statement and the Applicability_assignment interface
The content of the S1000D <evaluate> element within the <applic> element can bederived from the Applicability evaluation section of the S3000L data model, which
includes:− Applicability_evaluation_by_logical_operator− Logical_operator specializations And, Or, XOR and NOT
The content of the S1000D <assert> element within the <applic>/<evaluate> elements
can be derived from:−
Applicability_evaluation_by_assertion_of_class_instance together with instancesof classes that implements the Applicability_assert_interface− Applicability_evaluation_by_assertion_of_condition together with
Condition_statement which relates to a defined Condition_definition and a
Condition_type_value− Applicability_evaluation_by_applicability_statement_reference which relates to apreviously defined Applicability_statement.

Note
Applicability_statement is used to define usage related restrictions, whereas
Product_variant_applicability and Product_variant_realization_applicability (UoF Product
Variant Applicability) are used to define restrictions for a given product design (productdefinition).

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 159

S3000L-B6568-03000-00

4.21.2Graphical representation

ICN-B6865-S3000L0235-002-01
Fig 36 UoF Applicability Statement - class model
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 160

S3000L-B6568-03000-00

4.21.34.21.3.1

UoF Applicability Statement - New class and interface definitions
Condition_type
The Condition_type class defines types of conditions to be used in applicability statements,
where the specific type of condition cannot be derived from any other class that is defined within
the S3000L data model.
Note
Examples of condition types that cannot be derived from the use of any other class in the
S3000L data model, and therefore needs to be defined as instances of Condition_type, are:
−
−
−
−
−
−

Service bulletin
Operational environment
Wind speed
Ashore/Afloat
Operational scenario
Operational state

Note
An example of a class in the data model which can be used to define an
Applicability_evaluation_by_assertion expression is the Customer class. The values thatcan be used in the Applicability_evaluation_by_assertion_of_class_instance are theidentifier values for the instances of the Customer class, ie the values already exist in the
LSA database.
Condition_type attributes:−−

Condition_type_name
Condition_type_definition (zero or one)

The Condition_type class must implement the following interface:−

Condition_definition

Condition_type associations:−−

An association with one or many Condition_type_values
An optional association with zero, one or many instances of Condition_by_identifier, where
the Condition_by_identifier is an instantiation of the Condition_type

Note
An example on Condition_type and Condition_by_identifier is ‘Service Bulletin’ (as an
instance of Condition_type) and ‘Service bulletin S001 - Chain guard’ (as an instance ofCondition_by_identifier)Note
The following rules can be applied to populate an S1000D Condition Cross-reference Table(CCT):••

4.21.3.2

The value of Condition_type_name can populate the <conditiontype id> attribute and<conditiontype><name> element, respectively
The value of Condition_type_definition can be left empty if the definition of the termstated as the Condition_type_name is defined in a Reference Data Library (RDL).
Depending on where the definition of the Condition_type resides, the S1000D<conditiontype><description> element can be populated either by the value given in
Condition_type_definition or the value available in the referenced RDL

Condition_type_value
The Condition_type_value class defines valid values for a specific Condition_type.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 161

S3000L-B6568-03000-00

Note
The Condition_type_value class is an abstract class, ie any of its subclasses must be used
for the actual representation of the expression to be evaluated or asserted.
•

Condition_type_value subclasses:−−

Condition_type_class_value
Condition_type_property_value

Note
Instances of the Condition_type_value have no meaning by itself, but only in the context ofa specific Condition_type, or a specific Condition_statement.
Condition_type_value associations:−4.21.3.3

An instance of Condition_type_value is always associated with either an instance ofCondition_type, or an instance of Condition_statement

Condition_type_class_value
Instances of Condition_type_class_value must refer to valid Reference Data Library classes.
Note
Examples on valid class names that can be used are:••‘Pre’/’Post’ defined as valid values for eg the ‘Service_bulletin’ Condition_type‘Desert’/’’Arctic’ defined as valid values for ‘Operational_environment’ Condition_type

Note
Instances of the Condition_type_class_value have no meaning by itself, but only in thecontext of a specific Condition_type, or a specific Condition_statement.
Condition_type_class_value attributes:−

Condition_type_class_value

Condition_type_class_value associations:−

An instance of Condition_type_class_value is always associated with either an instance ofCondition_type, or an instance of Condition_statement (inherited from class
Condition_type_value)

Note
The following rules can be applied to populate an S1000D Condition Cross-reference Table(CCT):•

4.21.3.4

The value of Condition_type_class_value can populate the <conditiontype><enum>
element for the associated Condition_type

Condition_type_property_value
The Condition_type_property_value class defines valid values, value ranges etc, which can beused for a specific Condition_type.
Note
Valid values can be of any kind of Property_representation, ie it can be a
Value_with_unit_property, Value_with_tolerances_property, Value_range_property or a
Value_with_limit_property.
Note
Examples on valid property values are ‘0-15’, ‘15-30’ and ‘30-45’ defined for Condition_type‘Wind_speed’.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 162

S3000L-B6568-03000-00

Note
Instances of the Condition_type_property_value have no meaning by itself, but only in thecontext of a specific Condition_type, or a specific Condition_statement.
Condition_type_property_value attributes:−

Condition_type_property_value

Condition_type_property_value associations:−

An instance of Condition_type_property_value is always associated with either an instanceof Condition_type, or an instance of Condition_statement (inherited from class
Condition_type_value)

Note
The following rules can be applied to populate an S1000D Condition Cross-reference Table(CCT):•

4.21.3.5

The value of Condition_type_property_value can populate the <conditiontype><enum>
element for the associated Condition_type

Condition_definition
The Condition_definition interface is implemented by the condition classes that can be asserted
in order to determine the applicability of the data being defined during LSA.
Classes that implement the Condition_definition interface:−−

Condition_type
Condition_by_identifier

Classes that implement the Condition_definition interface must implement the following
associations:−4.21.3.6

An optional association with one or many instances of Condition_statement

Condition_by_identifier
The Condition_by_identifier class identifies specific instances of a condition type that can beused as conditions in one or many applicability statements.
Note:
An example of an identified condition is:•

Service bulletin S001 - Chain guard (an identified instance of the service bulletin
Condition_type)

Condition_by_identifier attributes:−−−

Condition_identifier
Condition_name
Condition_description (zero or one)

The Condition_by_identifier class must implement the following interface:−

Condition_definition

Condition_by_identifier associations:−

An instance of Condition_by_identifier is always associated with a specific Condition_type

Note
The following rules can be applied to populate an S1000D Condition Cross-reference Table(CCT):
Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 163

S3000L-B6568-03000-00•••

4.21.3.7

The value of Condition_identifier can populate the <condition id> attribute
The value of Condition_description can populate the <condition><description> element
The value of Condition_name can populate the <condition><name>and<condition><displayname> elements, respectively

Applicability_statement
The Applicability_statement class defines explicit applicability statements to be applied against
instances in the LSA database.
Note
An Applicability_statement can be evaluated in a maintenance execution environment, eg
using an Interactive Electronic Technical Publishing (IETP).
Applicability_statement attributes:−−

Applicability_statement_identifier (zero or one)
Applicability_statement_description (zero or one)

Applicability_statement associations:−−−An optional association with zero or one computer interpretable expression, ie an instanceof Applicability_evaluation
An association with one or many objects for which the Applicability_statement is valid, ie
instances of any class that implements the Applicability_assignment interface
An optional association with zero, one or many instances ofApplicability_evaluation_by_applicability_statement_reference, in which theApplicability_statement can be asserted as part of another Applicability_evaluation.

Note
The Applicability_statement class can be specialized into a Dated_applicability_statement.
4.21.3.8

Dated_applicability_statement
The Dated_applicability_statement class is a specialization of Applicability_statement, anddefines explicit applicability statements to be used against instances in the LSA database,where the applicability is not just defined by the expression to be evaluated, but is also limited intime.
Dated_applicability_statement attributes:−−−−

Applicability_statement_identifier (inherited from class Applicability_statement)
Applicability_statement_description (inherited from class Applicability_statement)
Applicability_start_date
Applicability_end_date (zero or one)

Dated_applicability_statement associations:−−−4.21.3.9

An optional association with zero or one computer interpretable expression, ie an instanceof Applicability_evaluation (inherited from class Applicability_statement)
An association with one or many objects for which the Applicability_statement is valid, ie
instances of any class that implements the Applicability_assignment interface (inheritedfrom class Applicability_statement)
An optional association with zero, one or many instances ofApplicability_evaluation_by_applicability_statement_reference, in which theApplicability_statement can be asserted as part of another Applicability_evaluation(inherited from class Applicability_statement)

Applicability_assignment
The Applicability_assignment interface is implemented by classes that can be associated with
optional applicability statements.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 164

S3000L-B6568-03000-00

Classes that must implement the Applicability_assignment interface:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

Substitute_part_relationship
Alternate_part_relationship
Hardware_part_operational_authorized_life
Parts_list_entry
Key_performance_indicator
Failure_rate_correction
Mean_time_between_failure_correction
LSA_failure_mode
Failure_mode
Special_event_occurrence_definition
Failure_mode_effectSpecial_event_effects
Task_requirement
Task
Subtask
Subtask_timeline
Subtask_in_zone
Task_warning_caution_or_note
Subtask_warning_caution_or_note
Subtask_acceptance_parameter
Subtask_objective_state
Task_resource
Task_resource_relationshipResource_realization
Task_personnel_resource_competence
Task_usage
Task_frequency
Maintenance_level_allocation
Task_limit
Threshold_definition
Security_classification
Document_assignment
Organization_assignment
Classification
Class
Descr
Prp

Note
Applicability_assignment can also be assigned to any class that is a subclass of the classes
enumerated above, eg Rectifying_task which is a subclass of Task (rule of substitutability).
Classes that implement the Applicability_assignment interface must implement the following
association:−

4.21.3.10

An optional association with one instance of Applicability_statement per instance of therespective class

Applicability_evaluation
The Applicability_evaluation class identifies an expression against which an applicability
statement can be evaluated or asserted.
The expression to be evaluated is either a logical expression, or a value to be asserted. These
are defined as separate subclasses of Applicability_evaluation.

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 165

S3000L-B6568-03000-00

Note
The Applicability_evaluation class is an abstract class, ie any of its subclasses must be
used for the actual representation of the expression to be evaluated or asserted.
Note
Instances of Applicability_evaluation don’t have any meaning outside the context of the
Applicability_statement or the Logical_operator in which it is being used.
Applicability_evaluation associations:−4.21.3.11

An instance of Applicability_evaluation is always associated with an instance ofApplicability_statement, either directly or as a logical operator operand (ie as part of anAND, OR, XOR or NOT expression)

Applicability_evaluation_by_logical_operator
The Applicability_evaluation_by_logical_operator class is a specialization ofApplicability_evaluation, and defines a logical expression against which an applicability
statement can be evaluated.
Note
All Logical_operators that are part of a Applicability_evaluation_by_logical_operator refers
to other instances of Applicability_evaluation, which in turn can be either a logicalexpression or a value to be asserted, and so on.
Note
Instances of Applicability_evaluation_by_logical_operator don’t have any meaning outside
the context of the Applicability_statement or Logical_operator, in which it is being defined.
Applicability_evaluation_by_logical_operator associations:−−4.21.3.12

An instance of Applicability_evaluation_by_logical_operator is always associated with a
specific Applicability_statement, either directly, or as a logical operator operand (ie as partof an AND, OR, XOR or NOT expression)
An instance of Applicability_evaluation_by_logical_operator must be associated with an
instance of a Logical_operator which in turn refers to other instances ofApplicability_evaluation to be evaluated or asserted

Logical_operator
The Logical_operator class defines the logical expression to be evaluated.
Note
Logical_operator is an abstract class, ie any instantiation of Logical_operator must be an
instance of either AND, OR, XOR or NOT.
Logical_operator associations:−4.21.3.13

An instance of Logical_operator is always associated with a specific instance ofApplicability_evaluation_by_logical_operator.

AND
The AND class is a specialization of Logical_operator, and defines a list ofApplicability_evaluations that all need to be TRUE in order for the overall
Applicability_statement to be TRUE.
Note
S1000D uses AND statements in the definition of an <applic> element.
AND associations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 166

S3000L-B6568-03000-00−−

4.21.3.14

An instance of AND is always associated with a specific instance ofApplicability_evaluation_by_logical_operator (inherited from class Logical_operator)
An instance of AND relates to two or more instances of Applicability_evaluation as its
operandsOR
The OR class is a specialization of Logical_operator, and defines a list ofApplicability_evaluations where at least one needs to be TRUE in order for the overall
Applicability_statement to be TRUE.
Note
S1000D does not use OR statements in the definition of an <applic> element.
OR associations:−−4.21.3.15

An instance of OR is always associated with a specific instance ofApplicability_evaluation_by_logical_operator (inherited from class Logical_operator)
An instance of OR relates to two or more instances of Applicability_evaluation as its
operandsXOR
The XOR class is a specialization of Logical_operator, and defines a list ofApplicability_evaluations where exactly one can be TRUE in order for the overall
Applicability_statement to be TRUE.
Note
S1000D does not use XOR statements in the definition of an <applic> element.
XOR associations:−−4.21.3.16

An instance of XOR is always associated with a specific instance ofApplicability_evaluation_by_logical_operator (inherited from class Logical_operator)
An instance of XOR relates to two or more instances of Applicability_evaluation as its
operands

NOTThe NOT class is a specialization of Logical_operator, and defines an Applicability_evaluations
that needs to be FALSE in order for the overall Applicability_statement to be TRUE.
Note
S1000D does not make explicit use of NOT statements in the definition of an <applic>element.
NOT associations:−−4.21.3.17

An instance of NOT is always associated with a specific instance ofApplicability_evaluation_by_logical_operator (inherited from class Logical_operator)
An instance of NOT relates to one instance of Applicability_evaluation as its operandApplicability_evaluation_by_applicability_statement_reference
The Applicability_evaluation_by_applicability_statement_reference class is a specialization ofApplicability_evaluation, and makes a reference another Applicability_statement that is to beasserted as part of the Applicability_evaluation. This class enables the definition of nested
applicability statements.
Applicability_evaluation_by_applicability_statement_reference associations:Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 167

S3000L-B6568-03000-00−−

4.21.3.18

An instance of Applicability_evaluation_by_applicability_statement_reference is always
associated with a specific Applicability_statement for which the nested
Applicability_statement is asserted (inherited from class Applicability_evaluation)
An instance of Applicability_evaluation_by_applicability_statement_reference is always
associated with another instance of Applicability_statement which is to be asserted as partof an overall Applicability_statement.

Applicability_evaluation_by_assertion
The Applicability_evaluation_by_assertion class is a specialization of Applicability_evaluation,and identifies a value against which an applicability statement is to be asserted.
Note
The Applicability_evaluation_by_assertion class is an abstract class, ie any of its
subclasses must be used for the actual representation of the value to be asserted.
Applicability_evaluation_by_assertion subclasses:−−

Applicability_evaluation_by_assertion_of_condition
Applicability_evaluation_by_assertion_of_class_instance

Applicability_evaluation_by_assertion associations:−4.21.3.19

An instance of Applicability_evaluation_by_assertion is always associated with a specific
Applicability_statement (inherited from class Applicability_evaluation).

Applicability_evaluation_by_assertion_of_condition
The Applicability_evaluation_by_assertion_of_condition class is a specialization ofApplicability_evaluation_by_assertion, and identifies the condition against which an applicability
statement is to be asserted.
Note
Instances of Applicability_evaluation_by_assertion_of_condition don’t have any meaningoutside the context of the Applicability_statement in which it is being defined.
Applicability_evaluation_by_assertion_of_condition associations:−−4.21.3.20

An instance of Applicability_evaluation_by_assertion is always associated with a specific
Applicability_statement (inherited from class Applicability_evaluation)
An instance of Applicability_evaluation_by_assertion always refers to a value of a
Condition_statement against which the applicability statement is to be asserted

Condition_statement
The Condition_statement class defines the combination of Condition_definition and a value,
which needs to be true in order for the Applicability_evaluation_by_assertion_of_condition
expression to be true.
Note
An instance of Condition_statement has no meaning by itself, but only in the context of an
instance of Applicability_evaluation_by_assertion_of_condition.
Condition_statement association:−−−

An instance of Condition_statement is always related to an instance ofApplicability_evaluation_by_assertion_of_condition
An association with an instance of either Condition type or Condition_by_identifier (via theCondition_definition interface) for which a value is to be asserted
An association with an instance of Condition_type_value that needs to be asserted, in orderfor the Applicability_evaluation_by_assertion_of_condition expression to be true

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 168

S3000L-B6568-03000-00

4.21.3.21

Applicability_evaluation_by_assertion_of_class_instance
The Applicability_evaluation_by_assertion_of_class_instance class is a specialization ofApplicability_evaluation_by_assertion, and identifies a class instance against which an
applicability statement is to be asserted.
Note
Instances of Applicability_evaluation_by_assertion_of_class_instance don’t have any
meaning outside the context of the Applicability_statement in which it is being defined.
Applicability_evaluation_by_assertion_of_class_instance associations:−−4.21.3.22

An instance of Applicability_evaluation_by_assertion_of_class_instance is always
associated with a specific Applicability_statement (inherited from class
Applicability_evaluation)
An instance of Applicability_evaluation_by_assertion_of_class_instance is always
associated with an instance of a class, against which the applicability statementis to beasserted (via the Applicability_assert_interface)

Applicability_assert_interface
The Applicability_assert_interface is implemented by classes that have instances (values) thatcan be used for defining applicability statements.
Classes and interfaces that implement the Applicability_assert_interface:
−
−
−
−
−
−
−
−
−
−
−
−

Customer
User
Contract
Product_variant
Contracted_product_variant
Breakdown_element
Part
Hardware_element_realization
Software_element_realizaiton
Product_usage_phase
Product_variant_realization
Maintenance_level_allocation_interface

Classes that implement the Applicability_assert_interface must implement the following
association:−

4.21.3.23

An optional association with zero, one or many instances ofApplicability_evaluation_by_assertion_of_class_instance.

Serialized_item
The Serialized_item interface is implemented by classes that can be manufactured.
Classes and interfaces that must implement the Serialized_item interface:−−

Product_variant
Part

Classes that implement the Serialized_item interface must implement the following association:−
4.21.44.21.4.1

An association with one or many instances of Block_of_serialized_items

UoF Applicability Statement - Additions to referenced class and interface definitions
Customer
The customer class defined in UoF Project must also implement the following additional
interface:

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 169

S3000L-B6568-03000-00−
4.21.4.2

User
The User class defined in UoF Project must also implement the following additional interface:−

4.21.4.3

Applicability_assert_interface

Software_element_realization
The Software_element_realization class defined in UoF Breakdown Element Realization mustalso implement the following additional interface:−

4.21.4.10

Applicability_assert_interface
Serialized_item

Hardware_element_realization
The Hardware_element_realization class defined in UoF Breakdown Element Realization mustalso implement the following additional interface:−

4.21.4.9

Applicability_assert_interface

Part
The Part class defined in UoF Part must also implement the following additional interface:−−

4.21.4.8

Applicability_assert_interface

Breakdown_element
The Breakdown_element class defined in UoF Breakdown Structure must also implement thefollowing additional interface:−

4.21.4.7

Applicability_assert_interface
Serialized_item

Contracted_product_variant
The Contracted_product_variant class defined in UoF Project must also implement the following
additional interface:−

4.21.4.6

Applicability_assert_interface

Product_variant
The Product_variant class defined in UoF Project must also implement the following additional
interface:−−

4.21.4.5

Applicability_assert_interface

Contract
The Contract class defined in UoF Project must also implement the following additional
interface:−

4.21.4.4

Applicability_assert_interface

Applicability_assert_interface

Block_of_serialized_items
The Block_of_serialized_items class defined in UoF Project must also implement the following
additional association:−

An optional association with an instance of Serialized_item

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 170

S3000L-B6568-03000-00

4.21.4.11

Product_variant_realization
The Product_variant_realization class defined in UoF Product Variant Applicability, must also
implement the following additional interface:−

4.21.4.12

Maintenance_level_allocation_interface
Classes that implement the Maintenance_level_allocation_interface defined in UoF Task Usage(Part 1), must also implement the following additional interface:−

4.21.4.13

Applicability_assignment

Mean_time_between_failure_correction
The Mean_time_between_failure_correction class defined in UoF LSA Candidate, must also
implement the following additional interface:−

4.21.4.20

Applicability_assignment

Failure_rate_correction
The Failure_rate_correction class defined in UoF LSA Candidate, must also implement thefollowing additional interface:−

4.21.4.19

Applicability_assignment

Key_performance_indicator
The Key_performance_indicator class defined in UoF LSA Candidate, must also implement thefollowing additional interface:−

4.21.4.18

Applicability_assignment

Parts_list_entry
The Parts_list_entry class defined in UoF Part, must also implement the following additional
interface:−

4.21.4.17

Applicability_assignment

Hardware_part_operational_authorized_life
The Hardware_part_operational_authorized_life class defined in UoF Part, must also implement
the following additional interface:−

4.21.4.16

Applicability_assignment

Alternate _part_relationship
The Alternate _part_relationship class defined in UoF Part, must also implement the following
additional interface:−

4.21.4.15

Applicability_assert_interface

Substitute_part_relationship
The Substitute_part_relationship class defined in UoF Part, must also implement the following
additional interface:−

4.21.4.14

Applicability_assert_interface

Applicability_assignment

LSA_failure_mode
The LSA_failure_mode class defined in UoF LSA-FMEA and Special Events, must also
implement the following additional interface:−

Applicability_assignment

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 171

S3000L-B6568-03000-00

4.21.4.21

Failure_mode
The Failure_mode class defined in UoF LSA-FMEA and Special Events, must also implement
the following additional interface:−

4.21.4.22

Special_event_occurrence_definition
The Special_event_occurrence_definition class defined in UoF LSA-FMEA and Special Events,
must also implement the following additional interface:−

4.21.4.23

Applicability_assignment

Subtask_in_zone
The Subtask_in_zone class defined in UoF Task, must also implement the following additional
interface:−

4.21.4.30

Applicability_assignment

Subtask_timeline
The Subtask_timeline class defined in UoF Task, must also implement the following additional
interface:−

4.21.4.29

Applicability_assignment

SubtaskThe Subtask class defined in UoF Task, must also implement the following additional interface:−

4.21.4.28

Applicability_assignment

Task
The Task class defined in UoF Task, must also implement the following additional interface:−

4.21.4.27

Applicability_assignment

Task_requirement
The Task_requirement class defined in UoF LSA Candidate Task Requirement, must also
implement the following additional interface:−

4.21.4.26

Applicability_assignment

Special_event_effects
The Special_event_effects class defined in UoF LSA-FMEA and Special Events, must also
implement the following additional interface:−

4.21.4.25

Applicability_assignment

Failure_mode_effect
The Failure_mode_effect class defined in UoF LSA-FMEA and Special Events, must also
implement the following additional interface:−

4.21.4.24

Applicability_assignment

Applicability_assignment

Task_warning_caution_or_note
The Task_warning_caution_or_note class defined in UoF Task, must also implement thefollowing additional interface:−

Applicability_assignment

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 172

S3000L-B6568-03000-00

4.21.4.31

Subtask_warning_caution_or_note
The Subtask_warning_caution_or_note class defined in UoF Task, must also implement thefollowing additional interface:−

4.21.4.32

Subtask_acceptance_parameter
The Subtask_acceptance_parameter class defined in UoF Task, must also implement thefollowing additional interface:−

4.21.4.33

Applicability_assignment

Task_frequency
The Task_frequency class defined in UoF Task Usage (Part 1), must also implement thefollowing additional interface:−

4.21.4.40

Applicability_assignment

Task_usage
The Task_usage class defined in UoF Task Usage (Part 1), must also implement the following
additional interface:−

4.21.4.39

Applicability_assignment

Task_personnel_resource_competence
The Task_personnel_resource_competence class defined in UoF Task Resources, must also
implement the following additional interface:−

4.21.4.38

Applicability_assignment

Resource_realization
The Resource_realization class defined in UoF Task Resources, must also implement thefollowing additional interface:−

4.21.4.37

Applicability_assignment

Task_resource_relationship
The Task_resource_relationship class defined in UoF Task Resources, must also implement
the following additional interface:−

4.21.4.36

Applicability_assignment

Task_resource
The Task_resource class defined in UoF Task Resources, must also implement the following
additional interface:−

4.21.4.35

Applicability_assignment

Subtask_objective_state
The Subtask_objective_state class defined in UoF Task, must also implement the following
additional interface:−

4.21.4.34

Applicability_assignment

Applicability_assignment

Maintenance_level_allocation
The Maintenance_level_allocation class defined in UoF Task Usage (Part 1), must also
implement the following additional interface:−

Applicability_assignment

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 173

S3000L-B6568-03000-00

4.21.4.41

Task_limit
The Task_limit class defined in UoF Task Usage (Part 1), must also implement the following
additional interface:−

Applicability_assignment

4.21.4.42

Threshold_definition
The Threshold_definition class defined in UoF Task Usage (Part 1), must also implement thefollowing additional interface:

4.21.4.43

Applicability_assignmentSecurity_classification
The Security_classification class defined in UoF Security Classification, must also implement
the following additional interface:−

4.21.4.44

Document_assignment
The Document_assignment class defined in UoF Document, must also implement the following
additional interface:−

4.21.4.45

Applicability_assignment

Organization_assignment
The Organization_assignment class defined in UoF Organization Assignment, must also
implement the following additional interface:−

4.21.4.46

Applicability_assignment

Applicability_assignment

Classification
The Classification class defined in UoF Data Types, must also implement the following
additional interface:−

Applicability_assignment

Note
By giving the possibility to assign an Applicability_statement to an instance ofClassification, there is a possibility to distinguish between different values for attributes inthe data model where multiple values are allowed.
4.21.4.47

Class
The Class class defined in UoF Data Types, must also implement the following additional
interface:−

Applicability_assignment

Note
By giving the possibility to assign an Applicability_statement to an instance of Class, there
is a possibility to distinguish between different values for attributes in the data model wheremultiple values are allowed.
4.21.4.48

Descr
The Descr class defined in UoF Data Types, must also implement the following additional
interface:−

Applicability_assignment

Applicable to: All

S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 174

S3000L-B6568-03000-00

Note
By giving the possibility to assign an Applicability_statement to an instance of Descr, there
is a possibility to distinguish between different values for attributes in the data model wheremultiple values are allowed.
4.21.4.49

Prp
The Prp class defined in UoF Data Types, must also implement the following additional
interface:−

Applicability_assignment

Note
By giving the possibility to assign an Applicability_statement to an instance of Prp, there isa possibility to distinguish between different values for attributes in the data model wheremultiple values are allowed.

S3000L-A-19-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-19-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 192010-04-01 Page 175

S3000L-B6568-03000-00

Chapter 20
Data exchange
Table of contents

Page

Data exchange ............................................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
1.4
Out of scope .................................................................................................................... 42
Overview .......................................................................................................................... 4
2.1
S3000L Data exchanges ................................................................................................. 4
3
Data exchange specifications .......................................................................................... 5
3.1
DEX1A&D Aerospace and defense business DEX for exchange of product breakdown
for support........................................................................................................................ 5
3.1.1
UoF Project in DEX1AD .................................................................................................. 6
3.1.2
UoF Breakdown Structure in DEX1AD ............................................................................ 7
3.1.3
UoF Part in DEX1AD ....................................................................................................... 7
3.1.4
UoF Breakdown Element Realization in DEX1AD .......................................................... 8
3.1.5
UoF Breakdown Aggregated Element in DEX1AD.......................................................... 9
3.1.6
UoF Breakdown Zone Element in DEX1AD .................................................................. 10
3.1.7
UoF Product Variant Applicability in DEX1AD ............................................................... 10
3.1.8
UoF LSA Candidate ....................................................................................................... 11
3.1.9
UoF Security Classification in DEX1AD ........................................................................ 12
3.1.10 UoF Organization Assignment in DEX1AD ................................................................... 13
3.1.11 UoF Document in DEX1AD ........................................................................................... 14
3.1.12 UoF Remark in DEX1AD ............................................................................................... 14
3.1.13 UoF Applicability Statement in DEX1AD ....................................................................... 15
3.2
DEX3AD Aerospace and Defense task set ................................................................... 17
3.2.1
UoF LSA Candidate Task Requirement in DEX3AD ..................................................... 17
3.2.2
UoF Task in DEX3AD .................................................................................................... 18
3.2.3
UoF Task Resources in DEX3AD.................................................................................. 20
3.2.4
UoF Task Usage Part 1 in DEX3AD .............................................................................. 22
3.2.5
UoF Task Usage Part 2 in DEX3AD .............................................................................. 24
3.2.6
UoF Security Classification in DEX3AD ........................................................................ 24
3.2.7
UoF Organization Assignment in DEX3AD ................................................................... 25
3.2.8
UoF Document in DEX3AD ........................................................................................... 26
3.2.9
UoF Remark in DEX3AD ............................................................................................... 26
3.2.10 UoF Applicability Statement in DEX3AD ....................................................................... 27

List of tables
1

References ...................................................................................................................... 2

List of figures1
2
3

S3000L data exchanges .................................................................................................. 4
UoF Project supported by DEX1AD ................................................................................ 6
UoF Breakdown Structure supported by DEX1AD .......................................................... 7

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

UoF Part supported by DEX1AD ..................................................................................... 8
UoF Breakdown Element Realization supported by DEX1AD ........................................ 9
UoF Breakdown Aggregated Element supported by DEX1AD ..................................... 10
UoF Breakdown Zone Element supported by DEX1AD ................................................ 10
UoF Product Variant Applicability supported by DEX1AD ............................................ 11
UoF LSA Candidate supported by the DEX1AD ........................................................... 12
UoF Security Classification supported by DEX1AD ...................................................... 13
UoF Organization Assignment supported by DEX1AD ................................................. 13
UoF Document supported by DEX1AD ......................................................................... 14
UoF Remark supported by DEX1AD ............................................................................. 15
UoF Applicability Statement supported by DEX1AD ..................................................... 16
UoF LSA Candidate Task Requirement supported by DEX3AD ................................... 18
UoF Task supported by DEX3AD .................................................................................. 19
UoF Task Resources supported by DEX3AD ............................................................... 21
UoF Task Usage Part 1 supported by DEX3AD ............................................................ 23
UoF Task Usage Part 2 supported by DEX3AD ............................................................ 24
UoF Security Classification supported by DEX3AD ...................................................... 25
UoF Organization Assignment supported by DEX3AD ................................................. 25
UoF Document supported by DEX3AD ......................................................................... 26
UoF Remark supported by DEX3AD ............................................................................. 27
UoF Applicability Statement supported by DEX3AD ..................................................... 28

References
Table 1 References
Chap No./Document No.

Title

Chap 19

Data elements

ISO 10303 239 PLCS

Product Life Cycle Support (PLCS)

DEX1AD

DEX1A&D - Aerospace and defense business DEX for
exchange of product breakdown for support (Aerospaceand defense product breakdown)

DEX3AD

DEX3A&D - Aerospace and defense business DEX for
exchange of a task specification (Aerospace and defense
task set)www.oasis-open.org

1

General1.1

Introduction
This paragraph gives an overview of aerospace and defense data exchange specifications that
supports the S3000L business process.
The Aerospace and Defense Data Exchange Specifications (AD DEX) are defined inaccordance with the OASIS PLCS Data Exchange Specifications (DEX), ie each DEX has thefollowing content:−

Terms, provides a definition of terms used in the DEX

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

−
−
−
−
−
−
−
−
−
−
−

Scope, outlines the scope of the information covered by the DEX
239 AAM, uses the ISO 10303-239 Application activity model to illustrate the businessactivities that are supported by the DEX
Business overview, provides a high level overview of the business process/application thatthe DEX is intended to support
Business information overview, provides a high level overview of the business informationthat can be represented by the DEX
Business information requirements, provides a more detailed overview of the informationthat the business process/application described in business overview requires
239 representation, provides technical details of how the business information requirements
identified in business information requirements are represented using ISO 10303 239 PLCS
Capabilities, lists all the capabilities that provide usage guidance for the DEX
Templates, lists all the templates that are used in the definition of the DEX
Schemas, identifies the information models that define the DEX
Reference data, lists the reference data classes used by this DEX
Conformance, defines the requirements for applications to conform to this DEX

The OASIS (www.oasis-open.org) PLCS DEXs are developed on sourceforge.net(www.sourceforge.net) under the DEXlib project. Sourceforge.net is a free open source
software and standards development website. The content on DEXlib can also be viewed using
any internet browser on www.plcs-resources.org/plcs/dexlib/dex_index.htm.
Any baseline revision of a DEX is published separately from the sourceforge.net website. The
Aerospace and Defense DEXs will be published via ASD.
This chapter contains the DEX information that would normally go into the following sections of
the DEX, but to minimize duplication of information it is only given here in S3000L:−−−

Business overview
Business information overview
Business information requirements

However, the following sections are developed on DEXlib, and are therefore also publishedfrom DEXlib:
−
−
−
−
−
−

ISO10303-239 representation
Capabilities
Templates
SchemasReference data
Conformance

The aerospace and defense DEX sections developed on DEXlib, and that goes along with thisissue of S3000L, are published separately as:−−

DEX1AD_001_00.zip
DEX3AD_001_00.zip

The aerospace and defense data exchange specifications defined in this chapter are derived
from the S3000L data model, and from the S1000D and S3000L interface specification definedby the S1000D Maintenance Task Data Task Team (MTDTT).

1.2

Objective
The objective for this chapter is to define a coherent set of AD DEX that supports the S3000L
LSA process and its interaction with other business processes.

1.3

Scope
The following data exchanges are in scope of this document:

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

−
−

1.4

Exchange of the Product data needed for the performance of an LSA (DEX1A&D Aerospace and defense business DEX for exchange of product breakdown for support)
Exchange of task set data needed by eg technical publications and maintenancemanagement (DEX3A&D - Aerospace and defense business DEX for exchange of a task
specification)

Out of scope
The current set of aerospace and defense data exchange specification does not support theexchange of:−−

LSA analysis activities selection
LSA Failure Mode Effect Analysis (LSA-FMEA)

2

Overview

2.1

S3000L Data exchanges
The data exchanges that are to be supported by the current set of aerospace and defense dataexchange specifications is summarized in the figure below:
Product
development(SX000I)

Material
management(S2000M)

External
partners

Product
breakdown
DEX1 AD
Entiredataset
DEX1 AD
DEX3 ADPart
data
DEX1 AD

LSA
candidatelist

Product
development(SX000I)

FMECA

SMA
(S4000M)
Scheduledmaintenance

Customer(SX000I)

S3000L
Product
usage
data

Technical
publication(S1000D)

Publishingdata
DEX3 AD

Inservicesupport(S5000F)

LSA
FMEA

Logistic
SupportAnalysisdatabase

Customer(SX000I)

Technical
publication(S1000D)
Task
requirements
DEX3 AD

Task
data
DEX3 AD

Training(S6000T)

Material
management(S2000M)
Inservicesupport(S5000F)

Feedback

ICN-B6865-S3000L0236-001-01
Fig 1 S3000L data exchanges
The identified data exchange basically contains the following information:−

Product breakdown from Product development to LSA, includes information on:••

The product to be supported,
One or many product variants

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

•
•
•
•
−

Part data from material management to LSA, includes information on eg:
•
•
•

−
−

Part identifiers (eg part numbers)Part nameOperational authorized life

Publishing data from technical publication to LSA, includes cross reference data between
S3000L tasks and S1000D data module codes in which the respective S3000L task is
documented
Task requirement from LSA to customers and Product Development, includes information
on eg:•••−

One or many breakdowns of the product, including its breakdown elements (iesystems, functions, hardware, software, zones)
Possible breakdown element realizations in terms of hardware or software parts
Product variant applicability, and specific product variant realizations
Key performance indicators for each LSA candidate

Task requirement specification
Task requirement authority
Task limit requirements

Task data from LSA to customers, technical publication, materiel support, etc, includes
information on eg:••••

Task identification
Task justification
Subtasks
Task resources

Identified data exchanges are grouped into two different aerospace and defense data exchange
specifications that can be used to support one or many actual data exchanges.
The two aerospace and defense data exchange specifications that are defined in this chapter
are:
−
−

DEX1AD - DEX1A&D - Aerospace and defense business DEX for exchange of productbreakdown for support
DEX3AD - DEX3A&D - Aerospace and defense business DEX for exchange of a task
specification

The content for each of those two AD DEXs are based on the unit of functionalities defined in
Chap 19, Data definition.

3

Data exchange specifications

3.1

DEX1A&D Aerospace and defense business DEX for exchange of productbreakdown for support
DEX1A&D - Aerospace and defense business DEX for exchange of product breakdown forsupport supports the following data exchanges described in Para 2:−−−−

Product breakdown, from Product development to LSAPart data, from material management to LSA
Subset of entire dataset, from external partners to LSA
Subset of entire dataset, from LSA to external partners

The DEX1A&D basically supports the exchange of data defined in the following Unit of
Functionalities (UoF) (refer to Chap 19):−−

UoF Project
UoF Breakdown Structure

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

−
−
−
−
−
−
−
−
−
−
−

UoF Part
UoF Breakdown Element Realization
UoF Breakdown Zone Element
UoF Breakdown Aggregated Element
UoF Product Variant Applicability
UoF LSA Candidate
UoF Security Classification (relevant subsection of)
UoF Organization Assignment (relevant subsection of)
UoF Document (relevant subsection of)
UoF Remark (relevant subsection of)
UoF Applicability Statement (relevant subsection of)

A more detailed definition on the exact content in the respective unit of functionality that is
supported by DEX1AD, the Aerospace and defense business DEX for exchange of productbreakdown for support, is given under the respective unit of functionality figure below.
3.1.1

UoF Project in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Project, refer to Chap 19.

ICN-B6865-S3000L0237-002-01
Fig 2 UoF Project supported by DEX1AD
Note
The complete content of UoF Project can be exchanged using DEX1AD Aerospace anddefense product breakdown for support.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

3.1.2

UoF Breakdown Structure in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Breakdown Structure, refer to Chap 19.

ICN-B6865-S3000L0238-002-01
Fig 3 UoF Breakdown Structure supported by DEX1AD
Note
The complete content of UoF Breakdown Structure can be exchanged using DEX1AD
Aerospace and defense product breakdown for support.
3.1.3

UoF Part in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF Part,
refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

ICN-B6865-S3000L0239-002-01
Fig 4 UoF Part supported by DEX1AD
Note
The complete content of UoF Part can be exchanged using DEX1AD Aerospace anddefense product breakdown for support.
3.1.4

UoF Breakdown Element Realization in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Breakdown Element Realization, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

ICN-B6865-S3000L0240-002-01
Fig 5 UoF Breakdown Element Realization supported by DEX1AD
Note
The complete content of UoF Breakdown Element Realization can be exchanged using
DEX1AD Aerospace and defense product breakdown for support.
3.1.5

UoF Breakdown Aggregated Element in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Breakdown Aggregated Element, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6568-03000-00

ICN-B6865-S3000L0241-001-01
Fig 6 UoF Breakdown Aggregated Element supported by DEX1AD
Note
The complete content of UoF Breakdown Aggregated Element can be exchanged using
DEX1AD Aerospace and defense product breakdown for support.
3.1.6

UoF Breakdown Zone Element in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Breakdown Zone Element, refer to Chap 19.

ICN-B6865-S3000L0242-002-01
Fig 7 UoF Breakdown Zone Element supported by DEX1AD
Note
The complete content of UoF Breakdown Zone Element can be exchanged using DEX1AD
Aerospace and defense product breakdown for support.
3.1.7

UoF Product Variant Applicability in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Product Variant Applicability, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6568-03000-00

ICN-B6865-S3000L0243-002-01
Fig 8 UoF Product Variant Applicability supported by DEX1AD
Note
The complete content of UoF Product Variant Applicability can be exchanged using
DEX1AD Aerospace and defense product breakdown for support.
3.1.8

UoF LSA Candidate
For a a more detailed description on the classes, attributes and associations defined in UoF
LSA Candidate, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6568-03000-00

ICN-B6865-S3000L0260-002-01
Fig 9 UoF LSA Candidate supported by the DEX1AD
Note
The complete content of UoF LSA Candidate can be exchanged using DEX1AD Aerospaceand defense product breakdown for support.
3.1.9

UoF Security Classification in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Security Classification, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6568-03000-00

ICN-B6865-S3000L0244-00201
Fig 10 UoF Security Classification supported by DEX1AD
Note
Only those security classifications that are relevant for Product breakdown can beexchanged using DEX1AD Aerospace and defense product breakdown for support.
3.1.10UoF Organization Assignment in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Organization Assignment, refer to Chap 19.

ICN-B6865-S3000L0245-002-01
Fig 11 UoF Organization Assignment supported by DEX1AD
Note
Only those organization assignments that are relevant for Product breakdown can beexchanged using DEX1AD Aerospace and defense product breakdown for support.
Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6568-03000-00

3.1.11

UoF Document in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Document, refer to Chap 19.

ICN-B6865-S3000L0246-002-01
Fig 12 UoF Document supported by DEX1AD
Note•

3.1.12

Only those document assignments that are relevant for Product breakdown can beexchanged using DEX1AD Aerospace and defense product breakdown for support.

UoF Remark in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Remark, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6568-03000-00

ICN-B6865-S3000L0247-002-01
Fig 13 UoF Remark supported by DEX1AD
Note
Only those remark assignments that are relevant for Product breakdown can be exchanged
using DEX1AD Aerospace and defense product breakdown for support.
3.1.13UoF Applicability Statement in DEX1AD
For a more detailed description on the classes, attributes and associations defined in UoF
Applicability Statement, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6568-03000-00

ICN-B6865-S3000L0248-002-01
Fig 14 UoF Applicability Statement supported by DEX1AD
Note
Only those applicability statement assignments that are relevant for Product breakdown canbe exchanged using DEX1AD Aerospace and defense product breakdown for support.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6568-03000-00

3.2

DEX3AD Aerospace and Defense task set
The use of DEX3AD assumes that all necessary product data is exchanged through the usageof DEX1AD. The DEX3AD then adds information to the already known product with respect to
how the product is to be maintained.
DEX3AD Aerospace and Defense task set supports the following data exchanges described in
section 20.2:
−
−
−
−
−

Publishing data, from technical publications to LSA
Task Requirement, from LSA to customer and Product development, respectively
Task data, from LSA to technical publications, in-service support, material management,
Training and LORA, respectively
Subset of entire dataset, from external partners to LSA
Subset of entire dataset, from LSA to external partners

The DEX1AD DEX3AD Aerospace and Defense task set basically supports the exchange ofdata defined in the following units of functionality (refer to Chap 19):
−
−
−
−
−
−
−
−
−
3.2.1

UoF LSA Candidate Task Requirement
UoF Task
UoF Task Resources
UoF Task Usage (Part 1 and Part2)
UoF Security Classification (relevant subsection of)
UoF Organization Assignment (relevant subsection of)
UoF Document (relevant subsection of)
UoF Remark (relevant subsection of)
UoF Applicability Statement (relevant subsection of)

UoF LSA Candidate Task Requirement in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF LSA
Candidate Task Requirement refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6568-03000-00

ICN-B6865-S3000L0249-002-01
Fig 15 UoF LSA Candidate Task Requirement supported by DEX3AD
Note
Only those classes in the UoF LSA Task Requirement that are relevant for a Task can beexchanged using DEX3AD Aerospace and Defense task set.
Note
Detailed information about the classes shown in the shaded grey area, marked DEX1AD, isexchanged using the DEX1AD Aerospace and defense product breakdown for support.
Only the attributes required for identification of the respective class are exchanged through
DEX3AD.
3.2.2

UoF Task in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF Task,
refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6568-03000-00

ICN-B6865-S3000L0250-002-01
Fig 16 UoF Task supported by DEX3AD
Note
Detailed information about the classes shown in the shaded grey area, marked DEX1AD, isexchanged using the DEX1AD Aerospace and defense product breakdown for support.
Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6568-03000-00

Only the attributes required for identification of the respective class are exchanged through
DEX3AD. These attributes are shown in UoF section 3.2.1 LSA Candidate Task
Requirement in DEX3AD, above.
3.2.3

UoF Task Resources in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF Task
Resources, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6568-03000-00

ICN-B6865-S3000L0251-002-01
Fig 17 UoF Task Resources supported by DEX3AD
Note
Detailed information about the class in the shaded grey area, marked DEX1AD, isexchanged using the DEX1AD Aerospace and defense product breakdown for support.
Only the attributes required for identification of the class is exchanged through DEX3AD.
These attributes are shown in UoF section 3.2.1 LSA Candidate Task Requirement in
DEX3AD, above.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6568-03000-00

3.2.4

UoF Task Usage Part 1 in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF Task
Usage Part 1, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6568-03000-00

ICN-B6865-S3000L0252-002-01
Fig 18 UoF Task Usage Part 1 supported by DEX3AD

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6568-03000-00

Note
Detailed information about the classes in the shaded grey area, marked DEX1AD, isexchanged using the DEX1AD Aerospace and defense product breakdown for support.
Only the attributes required for identification of the respective class are exchanged through
DEX3AD. These attributes are shown in UoF section 3.2.1 LSA Candidate Task
Requirement in DEX3AD, above.
3.2.5

UoF Task Usage Part 2 in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF Task
Usage Part 2, refer to Chap 19.

ICN-B6865-S3000L0253-002-01
Fig 19 UoF Task Usage Part 2 supported by DEX3AD
Note
Detailed information about the classes in the shaded grey area, marked DEX1AD, isexchanged using the DEX1AD Aerospace and defense product breakdown for support.
Only the attributes required for identification of the respective class are exchanged through
DEX3AD. These attributes are shown in UoF section 3.2.1 LSA Candidate Task
Requirement in DEX3AD, above.
3.2.6

UoF Security Classification in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF
Security Classification, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6568-03000-00

ICN-B6865-S3000L0254-001-01
Fig 20 UoF Security Classification supported by DEX3AD
Note
Only those security classifications that are relevant for task set can be exchanged using
DEX3AD Aerospace and Defense task set. There are more classes in the UoF Security
Classification that implements the Security_classification_interface, but these are out of
scope for DEX3AD.
3.2.7

UoF Organization Assignment in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF
Organization Assignment, refer to Chap 19.

ICN-B6865-S3000L0255-002-01
Fig 21 UoF Organization Assignment supported by DEX3AD
Note
Only those organization assignments that are relevant for task set can be exchanged using
DEX3AD Aerospace and defense task set. There are more classes in the UoF Organization
Assignment that implements the Organization_assignment_interface, but these are out of
scope for DEX3AD.
Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6568-03000-00

3.2.8

UoF Document in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF
Document, refer to Chap 19.

ICN-B6865-S3000L0256-002-01
Fig 22 UoF Document supported by DEX3AD
Note
Only those document assignments that are relevant for task set can be exchanged using
DEX3AD Aerospace and Defense task set. There are more classes in the UoF Documentthat implements the Organization_assignment_interface, but these are out of scope for
DEX3AD.
3.2.9

UoF Remark in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF
Remark, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 26

S3000L-B6568-03000-00

ICN-B6865-S3000L0257-002-01
Fig 23 UoF Remark supported by DEX3AD
Note
Only those remark assignments that are relevant for task set can be exchanged using
DEX3AD Aerospace and Defense task set. There are more classes in the UoF Remark that
implements the Remark_assignment_interface, but these are out of scope for DEX3AD.
3.2.10UoF Applicability Statement in DEX3AD
For a more detailed description on the classes, attributes and associations defined in UoF
Applicability Statement, refer to Chap 19.

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 27

S3000L-B6568-03000-00

ICN-B6865-S3000L0258-002-01
Fig 24 UoF Applicability Statement supported by DEX3AD

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 28

S3000L-B6568-03000-00

Note
Detailed information about the classes in the shaded grey area, marked DEX1AD, isexchanged using the DEX1AD Aerospace and defense product breakdown for support.
Only the attributes required for identification of the respective class are exchanged through
DEX3AD.
Note
Only those applicability assignments that are relevant for task set can be exchanged using
DEX3AD Aerospace and Defense task set. There are more classes in the UoF Applicability
Statement that implements the Applicability_assignment interface andApplicability_assert_interface, but these are out of scope for DEX3AD.

S3000L-A-20-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-20-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 20
2010-04-01 Page 29

S3000L-B6865-03000-00

Chapter 21
Terms, abbreviations and acronyms
Table of content

Document

Chap 21Chap 21.1

Terms, abbreviations and acronyms .................. S3000L-A-01-00-0000-00A-040A-A
Terms, abbreviations and acronyms - Introduction............................................................................ S3000L-A-01-01-0000-00A-040A-A
Terms, abbreviations and acronyms - Glossary of terms........................................................................... S3000L-A-01-02-0000-00A-040A-A
Terms, abbreviations and acronyms - Abbreviations and acronyms............................................................................ S3000L-A-01-03-0000-00A-040A-A

Chap 21.2
Chap 21.3

S3000L-A-21-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-21-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 212010-04-01 Page 1

S3000L-B6865-03000-00

Chapter 21.1
Terms, abbreviations and acronyms - Introduction
Table of contents

Page

Terms, abbreviations and acronyms - Introduction........................................................................ 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
2
Content ............................................................................................................................ 1

List of tables
Table 1 References……………………………………………………………………………………...1

References
Table 1 References
Chap No./Document No.

Title

Chap 21.2

Terms, abbreviations and acronyms - Glossary of terms

Chap 21.3

Terms, abbreviations and acronyms - Abbreviations andacronyms

1

GeneralThis chapter gives a brief description of the main chapters that deal with information generation.

2

Content

A comprehensive terminology dictionary for terms used in this specification is given in Chap 21.2.
A dictionary of abbreviations and acronyms used in this specification is presented in Chap 21.3. These
include all specific S3000L definitions, abbreviations and some basic abbreviations to be used whencompleting Logistic Support Analysis.

S3000L-A-21-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-21-01-0000-00A-040A-A_001_00_EN-US.doc

Chap 21.1
2010-04-01 Page 1

S3000L-B6568-03000-00

Chapter 21.2
Terms, abbreviations and acronyms – Glossary of terms
Table of contents

Page

Terms, abbreviations and acronyms – Glossary of terms ............................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
2
Glossary of terms............................................................................................................. 1

List of tables
1
2

References ...................................................................................................................... 1
Glossary of terms............................................................................................................. 1

References
Table 1 References
Chap No./Document No.

Title

None

1

GeneralWhen there is doubt whether an abbreviation or acronym will be understood or whenever there
is ample space to write in full, the term must be written out rather than abbreviated.

2

Glossary of terms
Table 2 Glossary of terms
Term

Definition

availability

Availability is the measure of the degree to which an item is in an
operable and ready-for-use state at the start of a mission oroperation, when the mission or operation is called for at an
unknown time. This is sometimes called operational readiness.

Breakdown Element
Identifier

The Breakdown Element Identifier (BEI) is a code that identifies thebreakdown structure of all system items within the LSA. The
breakdown can include software items.

Breakdown Element
Revision

The Breakdown Element Revision (BER) is a code which indicatesthat an alternative equipment or component occupies the same
position in the breakdown and, therefore, the same installation
position.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

Term

Definition

Built In Test

Built-In tests (BIT) are implemented on items to enable them tocarry out some self-testing up to a given degree.
Usually, three types of built-in tests are implemented:−

power-on built-in tests (P-BIT) executed at start-up of the item−

continuous built-in tests (C-BIT) periodically and automatically
executed during the operation of the item, without any
intervention from the operating crew−

initiated built-in tests (I-BIT) executed upon order from theoperator or from the maintenance team

Each of these types of tests detects specific categories of failures.
They are characterized by:−a detection rate that gives the percentage of functions or items
whose failure is detected−

a localization or isolation rate that gives the percentage of
detected failures that are associated without ambiguity to thefailure of an identified replaceable unit−

a false alarm rate

Built-in tests are likely to:−detect failures−

localize failed replaceable units

Localization may be:−

ambiguous, which means that the failure has been localized
within a group of replaceable parts, not on a single replaceable
part−

non-ambiguous, which means that the failed item has been
identified and localized with an acceptable degree of certainty

Lifting the ambiguity is the goal of troubleshooting analysis.
In terms of warning and signals, BIT results may be signaled to theoperator through a warning or alarm (which is usually the case for
critical failures).
candidate item

An item which was identified to be analyzed within the LSA
process.

candidate item list

List of all Candidate Items, which documents the items that are to
be analyzed (documentation of the selection of analysis tasks).

chemical abstract
substance
identification number

Unique international identifier for a given substance.

commercial off-theshelf

Software or hardware, generally technology products, that is readymade and available for sale, lease, or license to the general public.

common cause

Some failures may lead to several malfunctions. For instance, thefailure of a power supply leads to malfunction of all its supplied
items. This type of failure with multiple impacts is called a common
cause.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

Term

Definition

corrective
maintenanceAll maintenance activities, which are carried out to reset a faulty
item to full functionality.

customerrequirements
document

A document containing all the logistic requirements coming from
customer. This document should be available for the Guidance
Conference.

damageA loss or reduction of functionality, excluding inherent failure(intrinsic reliabilities). Normally a maintenance task will be required.
Damages can be grouped into "damage families", eg concerning
structures; typical damage can be identified like scratches, dents or
cracks. These damage families are typical candidates for astandard repair procedure.

dangerous/toxic
substance

Substance which harms human beings and environment (animals,
plants, etc).

data element list

List of selected data elements or an output of a data element
tailoring process. This list can contain additional data elements
required for a special project, which are not predefined in any
standard.

defectAny non-conformance of an item with its specified requirements is
a defect. Note that a defect does not necessarily result in a failureof the item.

definition files

Definition files, such as technical descriptions, interface definitions,wiring diagrams, description of sockets bounding, etc. may be
useful if localization remains ambiguous after all simple means oftroubleshooting have been used and when it becomes necessary
to make functional or electrical tests to help localize the failed item.

demilitarization

Operation which makes a defense Product unavailable for its
intended military use.

detection

Failure detection warns the operator that a failure has occurred

direct replaceable

Item that is directly replaceable on the product.

deviation

Authorized approval to depart from a particular requirement of a
products/equipment approved configuration documentation for a
specified period of time. This allows the acceptance of anequipment/product which departs from the particular requirement,
but is considered as suitable for use ‘as is’ or after repair by anapproved method.

disposal phase

Last phase of a Product Life Cycle, where the product is phasedout of use.

disposal process

Set of tasks to be performed on a product at the end of its intended
use

external cause

A cause is said to be external when an event independent of
product usage occurs eg bird-strike.

failureUnacceptable reduction of functionality of an item where the item
cannot continue in its intended use. The failure occurs inherently
during proper usage of the item.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

Term

Definition

failure cause

A failure cause is any circumstance during design, manufacture or
use which led to the failure.

failure mode

A failure mode is a predicted or observed physical, mechanical,
thermal or other process which leads to a failure. The result of thisprocess is stated in relation to the operating conditions at the timeof the failure.

Failure rate

The failure rate is the probability of failure per unit of time of items
in operation

Failure Modes andEffects Analysis(FMEA)A Failure Modes and Effects Analysis (FMEA) is a procedure foranalysis of potential failure modes within a system for classification
by severity or determination of the effect of failures on the system.

Failure Mode, Effects,
and Criticality
Analysis (FMECA)

Failure Mode, Effects, and Criticality Analysis (FMECA) is anextension of Failure Mode and Effects Analysis (FMEA). In addition
to the basic FMEA, it includes a criticality analysis, which is used tochart the probability of failure modes against the severity of theirconsequences. The result highlights failure modes with relatively
high probability and severity of consequences, allowing remedial
effort to be directed where it will produce the greatest value.

field loadable software

Software that can be installed to one or several equipments on asystem/product without need to dismount the target from its
installation location.

firmware

Software that can be loaded into a LRU or SRU but requires thetarget to be dismounted from its installation on the operational
system and requiring the replacement of a component.

Fit form and function

Where the physical interface, physical parameters that uniquely
characterize or the actions of a product/equipment remainunchanged.

function breakdown

A simple functional breakdown can start on top level of the productas the root of the breakdown tree. The different functions of the
product should be documented from the main functions down to
the sub-functions, etc, to the required depth. Within the purefunctional breakdown, no hardware elements should be found.

functionality analysis

Functional analysis describes and links functions performed by thesystem.
Each function of the system may be characterized by the flows orparameters:−

it takes as inputs−

it requires as part of operating context−

it provides as outputs

The providing of the output flows justifies the presence of the items
on board. Failure prevention, detection and correction all aim to thecontinuity or the restoration of these functions. Each function may
also be associated with a list of the physical items which realize thefunction or contribute to it. This helps in identifying the functions
impacted by failure of given equipment.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

Term

Definition

functional symptom

A functional symptom characterizes a failure detected by functional
check and/or by loss or degradation of an operational function. It is
detectable when the system is currently operated or checked via afunctional check.

guidance conference

Conference to establish the LSA business process (breath anddepth of analysis) with contractor and customer members, where
the basic and binding methods and procedures should be agreed.

guidance conference
document

A document with contractual character, where agreements
between the customer and the contractor are documented andwhich is signed by both sides. This document is an output of the
Guidance Conference.

integrated logistic
support

The management process which facilitates development andintegration between individual logistic support elements to specify,
design, develop, acquire, test, field, and support technical systems.

internal cause

A cause is said internal when it comes from product usage by itself
eg excessive vibration.

labor time

Summarized duration of personnel work. The duration should be
addressed against the subtasks. If more than one person is
working parallel on a subtask, the Labor time for each different skill
level must be summarized.

Level Of Repair
Analysis

Level Of Repair Analysis (LORA) is a prescribed procedure forlogistics planning. LORA is performed to determine the best, mostefficient location where an item can be repaired.

localization

Failure localization indicates which item or group of items has
failed. This localization is generally a complement to failure
detection

Logistic Support
Analysis (LSA)

The selective application of scientific and engineering efforts
undertaken during the development process and continuing
throughout the complete life cycle, as part of the systemengineering and design process, to assist in complying withsupportability and other Integrated Logistic Support activities.

LSA database

A database, where the relevant logistic data is collected. Other
terms can be LSA Record (LSAR) or support engineering
database.

life cycle

Total product lifespan since its initial feasibility phase, until its
service withdrawal and total dismantling of the park.

Life Cycle Costs

Life Cycle Cost (LCC) is the cumulative cost of a product over its
life cycle from entry into service to disposal as determined by aprocess of economic analysis that allows for the assessment of thetotal cost of acquisition, ownership and disposal of the product.

maintainability

The measure of the ability of an item to be retained in or restored
to a specified condition, when maintenance is performed bypersonnel having specified skill levels, using prescribed
procedures and resources, at each prescribed level ofmaintenance and repair.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6568-03000-00

Term

Definition

Maintenance Concept

A statement of maintenance considerations, constraints andstrategy for the operational support that governs the maintenancelevels and type of maintenance activities to be carried out for thesystem/equipment under analysis.

Maintenance Plan

The purpose of the maintenance plan is to ensure that theequipment/product can be maintained effectively and economicallyat the desired level of readiness after it is placed in operational use.
The Maintenance plan specifies when, where, and how
maintenance tasks will be performed on the equipment/product,
including both:••

Preventive maintenance
Corrective maintenance

The plan ensures that all required maintenance resources are inplace to support deployment of the equipment/product.
maintenance task
analysis

The Maintenance Task Analysis is a detailed analysis performed
for each of the logistic related operational or maintenance tasks
and will identify the support resources required to implement
effective corrective and preventative maintenance tasks for asystem and/ or equipment. These maintenance tasks are identified
in the LSA process.

maintenance relevant
item

A Maintenance Relevant Item is an item that can be repaired or
replaced in case of a failure or damage. Normally this item is
automatically a potential LSA candidate, but not automatically an
MSI.

Maintenance SteeringGroup 3 (MSG-3)

A designation for an established procedure of scheduled
maintenance analysis. The ATA MSG-3 publication outlines adecision-logic process for determining initial scheduled
maintenance requirements for new aircraft and/or power plants.
This document presents a means for developing maintenancetasks and intervals acceptable to regulatory authorities, operatorsand manufacturers.

maintenancesignificant item

A Maintenance Significant Item (MSI) is an item that was identified
by any selection process as the result of a Scheduled MaintenanceAnalysis procedure such as S4000M, MSG-3 or RCM. For this
item, a Scheduled Maintenance Analysis (SMA) will be performed(eg a system and power plant analysis as described in S4000M). A
Maintenance Significant Item can become a LSA candidate if the
SMA identifies a scheduled task. This task will be documented in
the LSA database.

malfunction analysis

Malfunctioning analysis aims to define what to do when things gowrong. It may cover two types of corrective actions:−actions to be taken by the operating crew when a failure occurs
during operation,−actions to be taken as part of the corrective maintenance.

Only the second type of actions falls into the scope of thisspecification.
Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6568-03000-00

Term

Definition

mean elapsed time

Duration of the entire task. The duration should be addressedagainst the subtasks. The duration of the whole task can becalculated as the sum of times coming from the subtasks and fromthe referenced supporting tasks.

Mean time between
failures

Mean time between failure is the predicted elapsed time between
inherent failures of a system during operation. MTBF can becalculated as the arithmetic mean (average) time between failuresof a system. The MTBF is typically part of a model that assumes
the failed system is immediately repaired (zero elapsed time), as apart of a renewal process. This is in contrast to the Mean Time To
Failure (MTTF), which measures average time between failure withthe modeling assumption that the failed system is not repaired

Model Identifier

The Model Identifier is a code, which uniquely identifies the productvariant. It is recommended to use the model identifier in
conjunction with other identifiers within the entire ILS process.

operational
requirements
document

Document which defines the operational requirements and needs
in a qualitative way for the end item platform. This document
should be available for the Guidance Conference.

physical breakdown

A top down representation of hardware and software of a productbased on the engineering design model/drawings.

physical symptom

A physical symptom characterizes a failure detected by visualinspection, measurement of a wear-out parameter, material
degradation. It is detectable or measurable when the system iscurrently operated or if it is undergoing inspection or maintenance.

preventive
maintenance

Maintenance activities to prevent the occurrence of critical failures
or damages in conjunction with safety, economical or ecologicalaspects. The Preventive Maintenance also includes activities after
special events where these events, chronological intervals or otherregular threshold cannot be defined.

product

The Product is a final combination of systems, subsystems,
component parts/materials, etc. such as an aircraft, a ship, vehicle,
or a complex technical system. The product always represents the
top level of any hierarchical breakdown.

rectifying task

A maintenance activity, which resolves an event such as failures,
damages, special events or thresholds. A rectifying task contains
subtasks in terms of referenced supporting tasks and/or definite
working steps.

reliability

The duration or probability of failure free performance of a productor system under stated conditions, or the probability that an item
can perform its intended function for a specified interval understated conditions, is a prime driver of support resources.

reliability centered
maintenanceA disciplined logic or methodology used to identify scheduled
maintenance tasks to maintain the inherent reliability of equipment
at a minimum expenditure of resources.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6568-03000-00

Term

Definitionscheduledmaintenance

Maintenance activities to prevent the occurrence of critical failures
or damages in conjunction with safety, economical or ecologicalaspects. These maintenance tasks are defined with acorresponding interval or threshold eg after certain time, cycles,
rounds, distance. Scheduled maintenance is a subset of thepreventive maintenance.

SMA Candidate

Element of the breakdown, which is identified as a potential
candidate for which a scheduled or preventive maintenance task
could be necessary.

Scheduled
Maintenance Analysis(SMA)

The analysis task for the identification of preventive and scheduled
maintenance. Different methods are available to perform thisanalysis task such as S4000M, MSG-3 or RCM)

Shop Loadable
Software

Software that can be loaded into a LRU but that requires the target
LRU to be dismounted from its installation in the system where it islocated.

Shop Replaceable
Unit (SRU)

An item, which can only be changed at shop/rear level (cannot be
removed and installed at the organizational maintenance area).

signature

A list of physical symptoms, functional symptoms and BIT resultsthat help detect and localize the failure.

Software Support
Analysis (SSA)

Methodology to analyze software with the purpose to supply thecustomer with all necessary information to establish a costeffective SSC. This includes all equipment, tools, personnel,
documentation, infrastructure and required skill and training
respectively.

special event

A special event is something that may occur during the life of the
product but cannot be considered as a normal way of operation. It
can be due either to external causes, eg meteorologicalphenomenon for example or to out of bound use such as over G
maneuver.

specific test
equipment

Whenever built-in-tests are unable to detect or localize failures,some specific test equipment may be required. This specific test
equipment may be:−

external measurement or test items−

external means used to simulate a function of the operating
systemstructural detail

A specific area of the Structure Significant Item which was
identified by any selection process from a SMA procedure such as
S4000M or MSG-3. For this detail, a SMA will be performed.

structural item

A Structural Item is a part of the system bodywork. It can be an
LSA candidate as well as a Structure Significant Item.

structure significant
item

An item which is identified by the selection process from a
Scheduled Maintenance Analysis procedure such as S4000M or
MSG-3.

substances
cartography

Characterization (identification, risk, quantity etc) and location of all
the tracked substances within a Product.

Applicable to: All

S3000L-A-21-02-0000-00A-040A-A
Chap 21.2

DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6568-03000-00

Term

Definition

Supply Chain

A supply chain consists of all organizations involved, directly or
indirectly, in fulfilling a customer support requirements.

supply chain
management

The process of planning, implementing and controlling theoperations of the supply chain as efficiently as possible.

supporting task

A supporting task is a part of a complete maintenance activity. As astandalone task it cannot rectify an event like failures, damages,
special events or thresholds. A supporting task contains subtasks
in terms of working steps.

testability

Performances of Built-in-Tests (BIT) developed on some items of
the system are often assessed using FMEA terms and results, but
this is not mandatory, especially if the item has been previously
developed for another program. Whatever their elaboration
method, BIT may be characterized by:−−−−a list of functions or sub-functions that are tested
a detection rate that gives the percentage of functions or items
whose failure is detected
a localization or isolation rate that gives the percentage of
detected failures that are associated without ambiguousness tothe failure of an identified item or component
a false alarm rate

These analyses and their justification should be used formalfunctioning analysis and for LSA FMEA, especially because
they provide:−a list of failure reports (from BIT) giving failure codes or any
other message that indicates which item or group of items isliable to have failed, therefore restraining greatly the number of
items to be investigated as part of the troubleshooting process

Warnings sent to the operating crew or to the maintenance team toindicate detected failures. These warnings should be used as firsthand symptoms rather than any other clue on the item itself
Training Needs
Analysis (TNA)

Analysis task to identify the requirements for training concerning
the operational and maintenance activities.

troubleshooting

Troubleshooting consists of localizing failed replaceable units when
this is not obvious or previously done by other means eg built-in
test. Troubleshooting is carried out after a failure has been
detected.

unified identifier

Designation for an identifier (ID), which can be used across all
logistic disciplines in the ILS process for a definite identification of
any item.

Usable on Code
(UoC)

A model identifier that indicates the configuration of a product onwhich the item under analysis is used.

S3000L-A-21-02-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-21-02-0000-00A-040A-A_001_00_EN-US.doc

Chap 21.2
2010-04-01 Page 9

S3000L-B6568-03000-00

Chapter 21.3
Terms, abbreviations and acronyms - Abbreviations and acronyms
Table of contents

Page

Terms, abbreviations and acronyms - Abbreviations and acronyms ............................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
2
Word combination - Acronym .......................................................................................... 1
3
Tense and number .......................................................................................................... 1
4
Abbreviation and acronym list ......................................................................................... 2

List of tables
1
2

References ...................................................................................................................... 1
Abbreviations and acronyms ........................................................................................... 2

References
Table 1 References
Chap No./Document No.

Title

None

1

GeneralWhen there is doubt that an abbreviation or acronym will be understood or whenever there is
ample space to write in full, the term must be written out rather than abbreviated. Abbreviations
and acronyms listed in Table 2 reflect their use in S3000L and not in other documents.

2

Word combination - Acronym
Abbreviations for word combinations, acronyms, must be used as such and not separated foruse singly, unless authorized singly.
Single abbreviations can be combined when necessary if there is no abbreviation listed for the
combination.

3

Tense and number
The same abbreviation must be used for all tenses, possessive cases, singular and plural formsof a given word.

Applicable to: All

S3000L-A-21-03-0000-00A-040A-A
Chap 21.3

DMC-S3000L-A-21-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6568-03000-00

4Abbreviation and acronym list
Table 2 Abbreviations and acronyms
Abbreviation/Acronym

Definition

AIA

Aerospace Industries Association of America

AOR

Annual Operating Rate

ASD

AeroSpace and Defense Industries Association of Europe

ATA

Air Transport Association of America

BE

Breakdown Element

BEI

Breakdown Element Identifier

BER

Breakdown Element Revision

BIT

Built in Test

BITE

Built in Test Equipment

CBS

Cost Breakdown Structure

CE

Communauté Européenne

CEE

Communauté Economique Européenne

Chap

ChapterCI

Candidate Item

CIL

Candidate Item List

CM

Configuration Management

COTS

Commercial Off The ShelfCP

Change Proposal

CRD

Customer Requirements Document

DA

Design Authority

DEL

Data Element List

Descr

Description

DEX

Data Exchange Specification

DM

Data Module

DMC

Data Module Codeeg

for example

ELORA

Economical Level of Repair Analysis

Fig

FigureFLS

Field Loadable Software

Applicable to: All

S3000L-A-21-03-0000-00A-040A-A
Chap 21.3

DMC-S3000L-A-21-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6568-03000-00

Abbreviation/Acronym

Definition

FMEA

Failure Mode and Effects Analysis

FMECA

Failure Mode and Effects Criticality Analysis

FMR

Failure Mode Ratio

FSN

Fleet Serial Number

GC

Guidance Conference

GCD

Guidance Conference Document

GEIA

Government Electronic and Information Technology Association

ICN

Information Control Number

ID

Identifier

iethat isILS

Integrated Logistic Support

ISO

International Standards Organization

IT

Information Technology

IUA

Item under Analysiskg

kilogram

lb

pound

LCC

Life Cycle Costs

LCMP

LSA Configuration Management Plan

LCN

Logistic Control Number

LORA

Level of Repair Analysis

LRU

Line Replaceable Unit

LSA

Logistic Support Analysis

LSA RC

Logistic Support Analysis Review ConferenceM

Mean active maintenance action timeMC

Maintenance Concept

MDT

Maintenance Down Time

MET

Mean Elapsed Time

MIL-STD

Military Standard (US DoD)ML

Maintenance Level

MoD

Ministry of Defence

MSDS

Material Safety Data Sheet

Applicable to: All

S3000L-A-21-03-0000-00A-040A-A
Chap 21.3

DMC-S3000L-A-21-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6568-03000-00

Abbreviation/Acronym

Definition

MSG

Maintenance Steering GroupMSI

Maintenance Significant Item

MSN

Manufacturer Serial Number

MTA

Maintenance Task Analysis

MTBF

Mean Time Between Failures

MTBM

Mean Time Between Maintenance

NATO

North Atlantic Treaty Organization

O&S

Operating and Support

OASIS

Organisation for the Advancement of Structural Information StandardsOEM

Original Equipment Manufacturer

OM

Obsolescence management

ORD

Operational Requirements Document

para

paragraph

PBS

Product Breakdown Structure

PDF

Product Disposal File

PDM

Product Data Management

PE

Periodical

PHST

Packaging, Handling, Storage and Transportation

PLCS

Product Life Cycle Support

P/N

Part number

PNR

Part number

PO

Perform once

PP

Program Plan

RCM

Reliability Centered Maintenance

RDL

Reference Data Library

RFC

Request for clarification

SB

Service Bulletin

SI

Structural Item

SMA

Scheduled Maintenance Analysis

SRU

Shop Replaceable Unit

SSA

Software Support Analysis

SSC

Software Support Concept

Applicable to: All

S3000L-A-21-03-0000-00A-040A-A
Chap 21.3

DMC-S3000L-A-21-03-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6568-03000-00

Abbreviation/Acronym

Definition

ST

SubTaskSW

SoftwareTNA

Training Needs Analysis

UML

Unified Modeling Language™

UoF

Unit of Functionality

WBS

Work Breakdown Structure

S3000L-A-21-03-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-21-03-0000-00A-040A-A_001_00_EN-US.doc

Chap 21.3
2010-04-01 Page 5

S3000L-B6865-03000-00

Chapter 22
Data element list
Table of contents

Page

Data element list ............................................................................................................................ 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1

List of tables
1
2
3

References ...................................................................................................................... 1
Data elements in alphabetical order ................................................................................ 2
Attributes of the S3000L data types .............................................................................. 55

References
Table 1 References
Chap No./Document No.

Title

Chap 19

Data elements

Chap 20

Data exchange

S1000DInternational specification for technical publications using
a common source database

S2000M

International specification for material management

S4000M

International procedure handbook for the development ofscheduled maintenance programs for military aircrafts

1

GeneralThis chapter defines all the data elements that are used as attributes in the S3000L data model(Chap 19), and in the S3000L data exchange specifications (Chap 20).
The data element list in Table 2 defines all business related data elements. The table isorganized alphabetically by the data element name, and contains:
−
−
−
−
−

Data element name
Data element data type (refer to Chap 19 on more details on data types used in S3000L)
Data element definition, contains a textual definition and a list of valid values
Class name, identifies Classes in the S3000L data model where the data element is used
as an attribute (Chap 19)
Unit of Functionality, identifies the section in Chap 19 where the Class is defined

The attribute list in Table 3 defines all the data elements that are used to define the S3000L
data types.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 1

S3000L-B6865-03000-00

Table 2 Data elements in alphabetical order

Data element

Type

Definition

Class/Interface

UoF

Actual_number_of_lines_of_code

Prp

Actual number of lines of executable code in a software part.

Software_part

Part

Software_part

Part

Software_part

Part

Aggregated_element_revision

Breakdown AggregatedElement

The following Unit of Measures is recommended to be used to enable
integration with other ASD specifications:- 'Lines_of_software_code'
Actual_software_complexity_code

Class

Code for describing software part complexity.
Valid classes are to be determined by the project.

Actual_software_size

PrpActual size of a software part.
The following Unit of Measures is recommended to be used to enable
integration with other ASD specifications:- 'Kilobyte'- 'Megabyte'- 'Gigabyte'- 'Terabyte'

Aggregated_element_description

Descr

Description of an aggregated breakdown element.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 2

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Aggregated_element_type

Class

Indicates further specialization of an aggregated breakdown element.

Aggregated_element

Breakdown AggregatedElement

The following classes is recommended to be used to enable
integration with other ASD specifications:- 'System_breakdown_element'- 'Functional_breakdown_element'- 'Family_breakdown_element'- ‘Slot_breakdown_element’
Applicability_end_date

Date

The date that defines the upper bound of the interval for a dated
applicability.

Dated_applicability_statement

Applicability Statement

Applicability_start_date

Date

The date that defines the lower bound of the interval for a dated
applicability.

Dated_applicability_statement

Applicability Statement

Applicability_statement_description

Descr

Human readable applicability information. Provides a textual
description of an applicability statement and its conditions.

Applicability_statement

Applicability Statement

Applicability_statement_identifier

Id

Identification of an applicability statement.

Applicability_statement

Applicability Statement

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 3

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Breakdown_element_identifier

Id

Identification of an element used within a breakdown of a defined
product.

Breakdown_element

Breakdown Structure

Breakdown_element

Breakdown Structure

Note 1: Used to establish a hierarchical structure of the technicalsystem (known as LCN/ALCN within GEIA-STD-0007).
The following Identifier_class is recommended to be used forBreakdown_element_identifier, to enable integration with other ASD
specifications:- 'ASD_system_or_hardware_identification_code’ (also known as
AECMA-code or SNS in S1000D)
Breakdown_element_nameId

The name by which a breakdown element is known.
The following identifier_class is recommended to be used forBreakdown_element_name, to enable integration with other ASD
specifications:- 'ASD_technical_name’ (‘techname’ in S1000D).

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 4

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Breakdown_element_relationship_type

Class

Definition of the type of relationship that is being established between
two breakdown elements.

Breakdown_element_relationship Breakdown Structure

Note: The related breakdown elements does not need to be used in
the same breakdown, i.e. it can be used to establish the relationshipbetween a breakdown element in a functional breakdown and a
breakdown element in a physical breakdown.
The following classes are recommended to be used to enable
integration with other ASD specifications:- 'Alternative_breakdown_element'- 'Functional_and_physical_breakdown_element_relationship’- ‘Access_point’
Breakdown_element_revision_creation_dat Datee

Date when the breakdown element revision was created.

Breakdown_element_revision

Breakdown Structure

Breakdown_element_revision_identifier

Identification of a specific revision of a breakdown element.

Breakdown_element_revision

Breakdown Structure

Indication of the design progression of a breakdown element used in a Breakdown_element_revision
breakdown of a product.

Breakdown Structure

Id

Note: Revision identifier is used to identify design iterations and notvariants.
Breakdown_element_revision_status

Class

Valid classes are to be determined by the project.
Breakdown_revision_creation_date

Date

Date when the breakdown revision was created.

Applicable to: All

Breakdown_revision

Breakdown Structure

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 5

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Breakdown_revision_identifier

Id

Identification of a specific revision of a breakdown.

Breakdown_revision

Breakdown Structure

Breakdown_revision

Breakdown Structure

Breakdown

Breakdown Structure

Note: Revision identification is used to document design iterations andnot breakdown variants.
Breakdown_revision_status

Class

Indication of the design progression of a complete breakdown of a
product.
Valid classes are to be determined by the project.

Breakdown_type

Class

The type of breakdown being defined.
The following classes are recommended to be used to enable
integration with other ASD specifications:- 'Physical_breakdown'- 'Functional_breakdown'- 'System_breakdown'- 'ASD_system_hardware_breakdown'- 'Zonal_breakdown'- 'Family_tree_breakdown'.

Candidate_item_analysis_activity_date

Date

Candidate_item_analysis_activity_indicator Class

Date for the latest update of the candidate item analysis activity
information.

Candidate_item_analysis_activity LSA Candidate Analysis
Activity

Definition of whether the candidate item analysis activity is selected for Candidate_item_analysis_activity LSA Candidate Analysis
a specific LSA candidate.
Activity
The following classes are recommended to be used:- 'Selected'

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 6

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF- 'Rejected'- 'Open (not decided)'Candidate_item_analysis_activity_rationale Descr

Description of the reason for the selection / non-selection of thecandidate item analysis activity.

Candidate_item_analysis_activity LSA Candidate Analysis
Activity

Candidate_item_analysis_activity_status

Indication of the progression of the candidate item analysis activity.

Candidate_item_analysis_activity LSA Candidate Analysis
ActivityClass

The following classes are recommended to be used:- 'Not_started'- 'Ongoing'- 'Completed'
Change_request_description

Descr

Description of a desired product design change.

Change_request

LSA Candidate Task
Requirement

Change_request_identifier

Id

Identification of a desired product design change, eg due to a task
requirement.

Change_request

LSA Candidate Task
Requirement

Circuit_breaker_identifier

Id

Identification of a circuit breaker that is installed on the end item.

Circuit_breaker

Task

Circuit_breaker_nameId

The name by which a circuit breaker is known.

Circuit_breaker

Task

Circuit_breaker_type

Class

Definition of the type of circuit breaker being identified.

Circuit_breaker

Task

The following classes is recommended to be used to enable
integration with other ASD specifications:- 'Electronic_circuit_breaker' (‘eltro’ in S1000D)- 'Electro_mechanic_circuit_breaker' (‘elmec’ in S1000D)- 'Dummy_circuit_breaker' ('clip’ in S1000D)

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 7

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Condition_description

Descr

Textual description (explanation) of a specific instance of a condition
used in one or many applicability statements.

Condition_by_identifier

Applicability Statement

Condition_identifier

Id

Identification of a specific condition used in one or many applicability
statements.

Condition_by_identifier

Applicability Statement

Condition_nameId

The name (title) by which a specific condition is known.

Condition_by_identifier

Applicability Statement

Condition_type_class_value

Class

Valid classes to be used for a defined condition type.

Condition_type_class_value

Applicability Statement

Condition_type

Applicability Statement

The following classes are examples which can be used to enable
integration with other ASD specifications:- ‘Pre’ / ‘Post’ (Service_bulletin_condtion_type)- ‘Ashore’ / ‘Afloat’ (Ashore_or_afloat_condition_type)- ‘Arctic’ / ‘Dessert’ (Operational_environment_condition_type)- ‘Docked’ / ‘Indoor’ / ‘Outdoor’(Maintenance_environment_condition_type)
Final valid classes are to be determined by the project.
Condition_type_definition

Descr

Textual description of a specific condition type used in one or many
applicability statements.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 8

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Condition_type_name

Class

The name by which the condition type is known.

Condition_type

Applicability Statement

The following classes are examples of classes which can be used toenable integration with other ASD Specifications:- ‘Service_bulletin_condition_type’- ‘Ashore_or_afloat_condition_type’- ‘Operational_environment_condition_type’- ‘Maintenance_environment_condition_type’
Condition_type_property_value

Prp

Valid property value for a defined condition type.

Condition_type_property_value

Applicability Statement

Contract_identifier

Id

Identification of a contract/subcontract established within the defined
LSA project (LSA program).

Contract

Project

Contract_relationship_type

Class

Defines the type of relationship that is established between twocontracts.

Contract_relationship

Project

S1000D_data_module

Document

The following classes are recommended to be used to enable
integration with other ASD specifications:- 'Subcontract'- 'Related_contract'Data_module_code

Id

Identification of a specific data module created in accordance with therules defined in S1000D.
The following Identifier_class must be used for Data_module_code, toenable integration with other ASD specifications:- 'S1000D_data_module_code'

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 9

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

Data_module_infonameId

The name by which a data module is known (S1000D element name = S1000D_data_module
Infoname).

UoF
Document

The following Identifier_class must be used for Data_module_identifier,to enable integration with other ASD specifications:- 'S1000D_data_module_infoname'
Data_module_issue_number

Id

Identification of a specific issue (revision) of a data module.

S1000D_data_module

Document

The following Identifier_class must be used for
Data_module_issue_number, to enable integration with other ASD
specifications:- 'S1000D_data_module_issue_number'
Detection_mean_description

Descr

Description of the mean that warns the user or maintainer that a failure Detection_mean
has occurred.

LSA-FMEA and Special
Events

Detection_mean_false_alarm_rate

Prp

The percent (expressed as a decimal value) of all alarms that indicate
a malfunction that cannot be verified by maintenance personnel
performing follow-on tests.

Detection_mean

LSA-FMEA and Special
Events

Detection_mean_type

Class

Defines if the test that generates the symptom is:1) Power_on_built_in_test (P-BIT) – executed at start-up of the item,
2) Continuous_built_in_test (C-BIT) – periodically and automatically
executed during the operation of the item, without any intervention
from the operating crew,3) Initiated_built_in_test (I-BIT) – executed upon order from theoperator or from the maintenance team,4) Ground_support_equipment.

Detection_mean

LSA-FMEA and Special
EventsApplicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 10

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Direct_maintenance_cost

Prp

For a given LSA candidate, the direct maintenance costs include shop Direct_maintenance_cost
maintenance manhours, shop test manhours, repair cost (incl. requiredmaterial). Statistical values like MTBF and MTBUR are taken into
consideration.

LSA Candidate

The following Unit of Measures must be used to enable integration withother ASD specifications:- Subclass of 'Currency'
Document_assignment_role

Class

Determination of the role of a document being assigned to something.

Document_assignment

Document

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Document_reference’- ‘Drawing_reference’- ‘Design_document_reference’- ‘Directive’- ’Source’- ‘Verification’.
Document_identifier

Id

Identification assigned to a particular document.

External_document

Document

Document_issue_date

Date

Date of issue for a specific issue (revision) of a document.

External_document

Document

Document_issue_identifier

Id

Identification of a specific issue (revision) of a document.

External_document

Document

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 11

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Document_location

Descr

Description where to find a specific document (issue).

External_document

Document

Note: May be a string that contains a hyperlink to the document (orspecific issue of the document).
Document_portion

Descr

Identifies a defined portion of a document which is of interest in a
specific usage.

Document_assignment

Document

Document_title

Id

The title (name) by which a document is known.

External_document

Document

Document_type

Class

Classification of the document in order to indicate the type of
document.

External_document

Document

Down_time

LSA Candidate

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Technical Report’- ‘Standard’- 'Drawing'
Down_time

Prp

The acceptable (maximum) down time (MDT), where down time is theduration where an item is non-operational.
The following Unit of Measures must be used to enable integration withother ASD specifications:- Subclass of 'Time_unit'

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 12

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Estimated_number_of_lines_of_code

Prp

Estimated number of lines of executable code in a software that willrealize the software breakdown element.

Software_element_revision

Breakdown Element
Realization

Software_element_revision

Breakdown Element
Realization

Software_element_revision

Breakdown Element
Realization

Software_element_revision

Breakdown Element
Realization

The following Unit of Measures must be used to enable integration withother ASD specifications:- 'Lines_of_software_code'
Estimated_software_complexity_code

Class

Rough classification of the estimated complexity of the software thatwill realize the software breakdown element.
Valid classes are to be determined by the project.

Estimated_software_modification_frequenc Classy

Estimated frequency of new releases (minor as well as major) for asoftware that will realize the software breakdown element.
The following Unit of Measures must be used to enable integration withother ASD specifications:- Subclass of 'Time_unit'

Estimated_software_size

Prp

Estimated size of a software that will realize the software breakdown
element
The following Unit of Measures is recommended to be used to enable
integration with other ASD specifications:- 'Kilobyte'- 'Megabyte'- 'Gigabyte'- 'Terabyte'

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 13

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Event_threshold_number_of_event_occurre int
nces

The number of event occurrences required to initiate the related
threshold or trigger.

Event_threshold

Task Usage (Part 1)

Failure_mode_description

A description of the manner by which a failure occurs.

Failure_mode

LSA-FMEA and Special
EventsDescription of the ability to detect an identified failure mode. The
description can include eg a summary of the available detectionmeans.

Failure_mode

LSA-FMEA and Special
EventsClassifi Defines the ability to detect an identified failure mode. Qualitative
cation judgment made by the analyst.

Failure_mode

LSA-FMEA and Special
EventsDescr

Failure_mode_detection_ability_description Descr

Failure_mode_detection_ability_rating

The following classes are recommended to be used:- ‘High_likelihood’- ‘Moderately_high_likelihood’- ‘Medium_likelihood’- ‘Moderately_low_likelihood’- ‘Low_likelihood’
Failure_mode_detection_rate

Prp

Defines the percentage of failure modes detected by the defined
detection mean.

Detectability

LSA-FMEA and Special
EventsFailure_mode_effect

Descr

A description of the consequences that a failure mode has on thelocal/next higher/end item operation, function, or status.

Failure_mode_effect

LSA-FMEA and Special
Events‘Local effect’ – The consequences of each postulated failure/damage
mode affecting the LSA candidate must be described along with any
second order effects that result. Potential conditions where thefailure/damage of one item results in a change of the conditional failure

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 14

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Failure_mode_effect

LSA-FMEA and Special
Eventsprobability or effect of a second item must be identified. It is possible
for the ”local effect” to be the failure/damage mode itself.
‘Next higher effect’ – The consequences of each failure/damage mode
affecting the next higher indenture level must be described.
‘End effect’ – The effect of each failure/damage mode upon theessential functions(s) affecting system/equipment operating capability
and mission completion capability must be determined. The end effectdescribed may be the result of a double failure. For example, failure ofa safety device may result in a catastrophic end effect only in the eventthat both the prime function goes beyond the limit for which the safety
device is set, and the safety device fails.
Failure_mode_effect_level

Class

Failure effect level may be defined as either Next higher or End Item.
‘Next higher effect’ – These effects concentrate on the impact a
failure/damage mode has on the operation and function of the items in
the next higher indenture level above the LSA candidate underconsideration.
‘End effect’ – End effects evaluate and define the total effect a
failure/damage mode has on the operation, function, or status of theuppermost system.

Failure_mode_identifier

Id

Identification of a specific failure mode code, typically assigned by thecontractor for an LSA candidate.

Failure_mode

LSA-FMEA and Special
EventsFailure_mode_isolation_rate

Prp

Defines the percentage of detected failures that are associated without Detectability
ambiguity to the failure of an identified item or component.

LSA-FMEA and Special
EventsApplicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 15

S3000L-B6865-03000-00

Data element

Type

Failure_mode_localization_ability_descripti Descron

Definition

Class/Interface

UoF

Description of the ability to localize an identified failure mode. The
description can include a summary of localization means available or
required.

Failure_mode

LSA-FMEA and Special
EventsFailure_mode

LSA-FMEA and Special
EventsNote: Failure mode localization_ability_description is generally acomplement to failure mode detection_ability_description.
Failure_mode_localization_ability_rating

Classifi Defines the ability to localize an identified failure mode. Qualitative
cation judgment made by the analyst.
The following classes are recommended to be used:- ‘High_likelihood’- ‘Moderately_high_likelihood’- ‘Medium_likelihood’- ‘Moderately_low_likelihood’- ‘Low_likelihood’

Failure_rate

Prp

For a particular interval, the total number of failures within a population Failure_rateof an LSA candidate item divided by the total functional life of the
population during the measurement interval. The definition holds fortime, rounds, miles, cycles or other measures of life units.

LSA Candidate

Note: Ref GEIA-0007, failure_rate_type
Failure_rate_correction_factor

Int

Correction factor for the failure rate value. This can either be related to Failure_rate_correction
design or to the usage of the system under specific conditions eg
environment which causes additional stress to the system (sand,extreme temperatures, salty environment).

LSA Candidate

Failures_per_operating_hour

Prp

Failure rate, expressed in failures per operating hour

LSA Candidate

Applicable to: All

Failures_per_operating_hour

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 16

S3000L-B6865-03000-00

Data element

Type

Fixed_resource_marker
Functional_replaceability

Definition

Class/Interface

UoF

boolean Indicates that no other resource than the specified is allowed to be
used in the task/subtask.

Task_resource

Task ResourcesClass

Hardware_element_revision

Breakdown Element Revision

Hardware_element

Breakdown Element
Realization

Classification whether a part is replaceable at its functional location.
This classification is done from a technical standpoint (i.e. avendor/supplier standpoint) and is independent of customer
maintenance concepts.
The following classes are recommended to be used to enable
integration with other ASD specifications:- Replaceable- Not_replaceable- Not_applicable

Hardware_element_type

ClassCan be used to indicate further specialization of a hardware element.
The following classes are recommended to be used to enable
integration with other ASD specifications:- Equipment- Access_point- Door,- Panel,- Electrical_panel

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 17

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Hardware_part_environmental_aspect_clas Classifi Classification of environment aspects which needs to be considered
s_in_use
cation during use of the hardware part.

Hardware_part

Part

Hardware_partPart

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Harmful_to_environment’- ‘Acidification’- ‘Dangerous_for_ozone_layer’- ‘Greenhouse_effect’- ‘Material_waste’- ‘Energy_regaining_by_burning’- ‘Material_recycling’
Hardware_part_environmental_aspect_clas Classifi Classification of environment aspects which needs to considereds_planned_disposal
cation during planned disposal of the hardware part.
The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Harmful_to_environment’- ‘Acidification’- ‘Dangerous_for_ozone_layer’- ‘Greenhouse_effect’- ‘Material_waste’- ‘Energy_regaining_by_burning’- ‘Material_recycling’

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 18

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Hardware_part_logistics_category

Class

Defines the logistics role of a hardware part that is used within one or
many tasks.

Hardware_part

Part

Hardware_partPart

The following classes are recommended to be used to enable
integration with other ASD specifications:- 'Support_equipment’- ‘Common_support_equipment’- ‘Special_support_equipment’- ‘Spare’- ‘Supply’- ‘Consumable’- ‘Expendable’- ‘Material’- ‘Facility’-‘Training_equipment’
Note 1: Equivalent to Item Category Code in GEIA-STD-0007.
Hardware_part_maintenance_startClass

Defines when to initiate maintenance scheduling for a part.
The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Maintenance_start_at_production’- ‘Maintenance_start_at_delivery’- ‘Maintenance_start_at_installation_in_assembly’- ‘Maintenance_start_at_installation_in_end_item’.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 19

S3000L-B6865-03000-00

Data element

Type

Definition

Hardware_part_material_hazardous_classClassifi Identifies articles or substances which are capable of posing acation significant risk to health, safety or property during transportation,
handling or storage.

Class/Interface

UoF

Hardware_part

Part

Source: S2000M
The Substance Identification Numbers listed in Chapter 2 of the United
Nations Recommendations on the Transport of Dangerous Goods
ST/SG/AC.10/1/Rev5, must be used to enable integration with other
ASD specifications.
Hardware_part_operational_authorized_life Prp

Authorized life indicates the maximum installed life for which an item
may be operated. Upon reaching this authorized life, any further life of
the item must be re-authorized.

Hardware_part_operational_autho Part
rized_life

Source: S2000M
Hardware_part_scrap_rate

Prp

Indicates the estimated percentage of normally repairable units which,when removed from service, will be found to be beyond economic
repair and therefore have to be scrapped.

Hardware_part

Part

Hardware_part

Part

Note: The Unit of Measure must always be Percentage.
Source: S2000M
Hardware_part_waste_products_in_use_di Descr
sposal_description

Describes how waste products for an individual part need to be
managed when the part is disposed of according to the procedure
during use or after being used.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 20

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Hardware_part_waste_products_planned_d Descr
isposal_description

Describes how waste products need to be managed when the entire
population of a part is disposed of according to the procedure forplanned disposal.

Hardware_part

Part

Information_code

Information code according to ASD S1000D. Information code is used
for categorizing a task/subtask.

Task /
Subtask_by_definition

Task

Breakdown_element_structure

Breakdown Structure

Class

S1000D information codes must be used to enable integration withother ASD specifications.
Installation_description

Descr

Description of the installation and location(s) for a breakdown element
within a specific breakdown.
Note: May be used to describe multiple installations, if
Quantity_of_child_elements for a breakdown element is greater thanone.

Key_performance_indicator_method

Descr

Describes the method by which the key performance indicator value
has been derived.

Key_performance_indicator

LSA Candidate

Key_performance_indicator_percintile

Prp

The percentage of all occurrences related to a specified key
performance indicator that must be within the limit of the value definedfor the key performance indicator.

Key_performance_indicator

LSA Candidate

Example: A customer requirement is that 98% of all replacement tasks
must be performed below a specified value of two hours (= maximum
replacement time).

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 21

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Key_performance_indicator_status

Class

Status of acceptance of the recorded value for the key performanceindicator.

Key_performance_indicator

LSA Candidate

Key_performance_ndicator

LSA Candidate

The following classes are recommended to be used:- ‘Preliminary’,- ‘Accepted’,- ‘Released’,
Key_performance_indicator_type

Class

Defines the context in which the key performance indicator value isdefined.
The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Specified’ (also known as allocated)- ‘Distributed’- ‘Contracted’- ‘Predicted’- ‘Actual’.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 22

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

LSA_candidate_indicatorClass

Defines the depth of analysis that will be performed on the candidate
item.

LSA_candidate

LSA Candidate

The following classes are recommended to be used:- ‘Full candidate’, provide full scale of selected LSA information
applicable to the related item.
- ‘Partial candidate’, provide a partial scale of selected LSA information
applicable to the related item, eg only remove and install information
because of the need to gain access to other items, but no repair
information required, because the item is a discard able item.
- ‘Non’, no LSA required.
- ‘Open’, not yet decided.
LSA_candidate_maintenance_concept

Descr

A statement of maintenance considerations, constraints and strategy
for the operational support that governs the maintenance levels andtype of maintenance activities to be carried out for the LSA candidate
under analysis.

LSA_candidate

LSA Candidate

LSA_candidate_maintenance_solution

Descr

A statement of maintenance activities and maintenance levels that has LSA_candidate
been decided for the LSA candidate under analysis.

LSA Candidate

LSA_candidate_rationale

Descr

Description of the reason for ’Full’ / ’Partial’ / ’Non’ LSA Candidate
Indicator selection.

LSA_candidate

LSA Candidate

LSA_failure_mode_description

Descr

Description of a generic failure mode which covers a set of individual
failure modes that has been grouped into the LSA failure mode.

LSA_failure_mode

LSA-FMEA and Special
Events

LSA_failure_mode_identifier

Id

Identification of an LSA failure mode.

LSA_failure_mode

LSA-FMEA and Special
EventsApplicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 23

S3000L-B6865-03000-00

Data element

Type

LSA_failure_mode_distribution_occurrence Class_rating

Definition

Class/Interface

UoF

Identifies the rating for the occurrence of an individual LSA failuremode in comparison to the entire population of LSA failure modes
identified for the item under analysis.

Distributed_LSA_failure_mode_wit LSA-FMEA and Special
h_rating
Events

The following classes are recommended to be used:- ‘Moderately_high_likelihood’- ‘Medium_likelihood’- ‘Moderately_low_likelihood’- ‘Low_likelihood’- ‘Very_low_likelihood’
LSA_failure_mode_distribution_ratio

Prp

Identifies the fraction of an individual LSA failure mode f the entire
population of LSA failure modes identified for the item under analysis.

Distributed_LSA_failure_mode_wit LSA-FMEA and Special
h_ratio
Events

Maintenance_free_operating_periodPrp

The acceptable (minimum) maintenance free operating period, where
maintenance free operating period is the interval in which no
maintenance actions occur.

Maintenance_free_operating_peri LSA Candidate
od

Maintenance_level_type_capability_descrip Descr
tion

Description of a maintenance level type. May include textual
Maintenance_level_type
descriptions of defined capabilities in terms of personnel, availability of
special facilities, time limits and the environmental conditions to be
assumed. These capabilities are the basis in determining the functions
to be accomplished at each maintenance level.

Product Usage

Maintenance_level_type_identifier

Identification of a maintenance level authorized to perform a required
maintenance function.

Maintenance_level_type

Product Usage

Maintenance_level_type

Product Usage

Id

Note: Includes software maintenance levels.
Maintenance_level_type_nameId

The name by which a maintenance level type is known.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 24

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Maintenance_location_code

Class

Indicates where the maintenance task will be carried out in terms of a
product (end item or major assembly).

Subtask_by_definition

Task

The following classes must be used to enable integration with other
ASD specifications:“A” – Information related to items installed on the Product“B” – Information related to items installed on amajor assembly removed from the Product“C” – Information related to items on the bench. In this context, it does
not matter, for example, whether an item has been removed fromthe Product.
“D” – Information related to all three locations A, B, and C.
Source; S1000D Item Location Code
Maintenance_location_description

Descr

Description of a specific maintenance location. May include textual
descriptions of actual capabilities in terms of personnel, availability of
special facilities, time limits and the environmental conditions.

Maintenance_location

Product Usage

Maintenance_location_identifier

Id

Identification of a specific maintenance location.

Maintenance_location

Product Usage

Maintenance_location_nameId

The name by which a specific maintenance location is known.

Maintenance_location

Product Usage

Maintenance_man_hours_per_operating_h Prp
our

The (maximum) acceptable maintenance man hours per operating
Maintenance_man_
hour, where maintenance man hours per operating hour is the ratio of ours_per_operating_hour
maintenance man hours expended to the operating interval (as definedby the measurement base) of the system/equipment.

Applicable to: AllLSA Candidate

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 25

S3000L-B6865-03000-00

Data element

Type

Maintenance_significant_or_relevant_indica Class
tor

Definition

Class/Interface

UoF

Indicator, whether a breakdown element is classified as being a
Breakdown_element_revision
Maintenance Significant Item (MSI), Maintenance Relevant Item (MRI),or if the classification is Not Applicable (N/A).

Breakdown Structure

Note 1: An MSI is an item which was identified by any selection
process coming from a Scheduled Maintenance Analysis Procedure
like MSG-3 or ASD/AIA S4000M. For this item, a Scheduled
Maintenance Analysis (SMA) will be performed.
Note 2: An MRI is an item which can be repaired or replaced in case of
failure or damage.
Material_characteristics_recording_date

Date

Date for latest changes of material characteristics data.

Material

Part

Material_description

Descr

Short description of material (substance) used in one or many parts.

Material

Part

Material_identifier

Id

Identification of the material (substance)

MaterialPart

Example: An example of an material identifier is the Chemical Abstract
Substance Registry Number (often referred to as a CAS Number). See
www.cas.org.
Material_nameId

The name by which a material (substance) is known.

Material

Part

Material_risk_description

Descr

Description of risks associated with the material (substance).

Material

Part

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 26

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Material_risk_factor

Class

Classification of risk associated with the material (substance).

Material

Part

Material

Part

Hardware_part_material_usage

Part

Valid classes for material risk factors are to be determined by the
project.
Example: Example of risk factor is the judged risk factor of material in
Shelf Life Analysis (SLA)
Material_substance_usage_categoryClass

The main substances category.
The following classes are recommended to be used:- ‘Forbidden’- ‘Authorized with limitation’- ‘Authorized with no limitation’.

Material_usage_justification_description

Descr

Description of the most important property for the function of the partthat the included material (substance) has.

Mean_time_between_failurePrp

The (minimum) mean time between failure (MTBF), where the MTBF is Mean_time_between_failure
the total operational life of a population of an LSA candidate divided by
the total number of failures within the population during a particularmeasurement interval. The definition holds for time, rounds, miles,
events, or other measure of life units.

Mean_time_between_failure_correction_dat Datee

Date for defining the correction factor.

Applicable to: AllLSA Candidate

Mean_time_between_failure_corr LSA Candidate
ection

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 27

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

Mean_time_between_failure_correction_fac int
tor

Correction factor for the mean time between failure value. This caneither be related to design (effects of eg no failure found, BIT cannot
duplicate or detectability effects can influence the real applicableMTBF) or to the usage of the system under specific conditions eg
environment which causes additional stress to the system (sand,extreme temperatures, salty environment).

Mean_time_between_failure_corr LSA Candidate
ectionMean_time_between_failure_correction_jus Descr
tification

Description of the reason for the introduction of the correction factor.

Mean_time_between_failure_corr LSA Candidate
ectionMean_time_between_unscheduled_remova PrplMinimum mean time between unscheduled removal, where mean time Mean_time_between_unschedule LSA Candidate
between unscheduled removal is the total number of operational units d_removal(eg, miles, rounds, hours) divided by the total number of items
removed from that system during a stated period of time. This term isdefined to exclude removals either being scheduled or performed tofacilitate other maintenance and removals for product improvement.

Mean_time_to_repair

Prp

The (maximum) mean time to repair (MTTR), where MTTR is the total Mean_time_to_repair
elapsed time for corrective maintenance divided by the total number ofcorrective maintenance actions during a given period of time.

LSA Candidate

Number_of_operating_locations

Prp

Number of locations which will receive and operate the contracted
product variant.

Operating_location_type

Product Usage

Operating_location_description

Descr

Description of an actual operating location.

Operating_location

Product Usage

Operating_location_identifier

Id

Identification of an actual operating location.

Operating_location

Product Usage

Operating_location_nameId

The name by which an actual operating location is known.

Operating_location

Product Usage

Applicable to: All

UoF

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 28

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Operating_location_type_description

Descr

Description of an operating location type and its operating andenvironmental conditions to be assumed.

Operating_location_type

Product Usage

Operating_location_type_identifier

Id

Identification of a type of operating location which will receive andoperate the contracted product variant.

Operating_location_type

Product Usage

Operating_location_type_nameId

The name by which an operating location type is known.

Operating_location_type

Product Usage

Operating_requirement_at_operating_locati Prpon

Value of the (annual) operating requirement per operating location and Contracted_product_in_operating Product Usage
contracted product variant.
_location
Note: Annual operating requirements may be measurement based,
generally operating hours, but also other measurement bases can be
possible.

Operating_requirement_at_operating_locati Prp
on_type

Value of the (annual) operating requirement per operating location type Contracted_product_in_operating Product Usageand contracted product.
_location_type
Note: Annual operating requirements may be measurement based,
generally operating hours, but also other measurement bases can be
possible.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 29

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Organization_assignment_role

Class

Determines the role of the organization being assigned to an object in
the LSA database.

Organization_assignment

Organization_assignment

Organization

Project

Organization

Project

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Authorizing_organization’- ‘Design_responsible_organization’- ‘Published_by_organization’
Organization_identifier

Id

Identification of an actual organization.
Examples: NCAGE code, VAT number.

Organization_nameId

The name by which an actual organization is known.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 30

S3000L-B6865-03000-00

Data element

Type

Definition

Part_demilitarization_classClassifi Part demilitarization identifies special measures to be taken when acation part is being disposed of, eg:- render them useless for military purposes- destroy any indications of military purposes or performance
characteristics

Class/Interface

UoF

Part

Part

Source: S2000M
Usage of the following Part demilitarization classes are required toenable integration with other ASD specifications:- ‘Demilitarization not required’- ‘Trade Security Controls (TSC) required at disposal’- ‘Remove and/or demilitarize installed key point(s)’- ‘Demilitarize by mutilation’- ‘Demilitarization to be furnished by the MoD or national
Demilitarization Program Office’- ‘Demilitarization instructions to be furnished by item/technicalmanager’- ‘Demilitarization required prior to transfer of item to national
reutilization and disposition offices’- ‘Security Classified Item’

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 31

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Part_identifier

Id

Any identifier of an item of production (including software). Includes
manufacturer’s part, drawing, model, type, or source controllingnumbers.

Part

Part

Classifi Classification defining the maturity of the part in order to determine the Part
cation certainty by which the parts characteristics can be valued.

Part

Usage of the following Part_identifier classes are recommended toenable integration with other ASD specifications:- 'ASD_system_or_hardware_identification_code’,- ‘Nato_stock_number’,- ‘OEM_part_identification_code’,- ‘Supplier_part_identification_code’,
Part_maturity

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘New_developed’- ‘Major_modification_of_existing_item’- ‘Moderate_modification_of_existing_item’- ‘COTS_item’- ‘GSE/GFE_items’.
Part_nameId

The name by which a part is known.

Part

Part

The following Part_name Identifier_class is recommended to be used
to enable integration with other ASD specifications:- 'Technical name’ (techname in S1000D).

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 32

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Part_obsolescence_risk_assessment

Descr

Describes risk associated with loss of the part in the supply chain due
to factors such as termination of manufacturing, replacement with adifferent model, etc.

Part

Part

Part_special_handling

Descr

Describes any requirements for special handling of the part.

Part

Part

Parts_list_entry_identifier

Id

Any identifier of an entry in a parts list (Bill-Of-Material).

Parts_list_entry

Part

Usage of the following Parts_list_entry_identifier classes are required
to enable integration with other ASD specifications:- ’Catalogue_sequence_number’Parts_list_entry_substitute_identifier

Id

The ‘Parts_list_entry_substitute_identifier’ together with theSubstitute_part_relationship‘Parts_list_entry_identifier’ can provide a unique key for each record ina ‘Parts_list_entry’ (Bill-of-Material).

Part

Usage of the following Parts_list_entry_substitute_identifier class isrecommended to enable integration with other ASD specifications:- ’Item_sequence_number’ ( requires the Parts_list_identifier’ to beclassified as Catalogue_sequence_number’)Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 33

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

Physical_replaceability

Class

Classification of whether a part is interchangeable in a specificParts_list_entry
assembly. This classification is done from a technical standpoint (i.e. avendor/supplier standpoint) and is independent of customer
maintenance concepts.

UoF
Part

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Interchangeable’ (Interchangeable items must be capable of being
readily installed, removed, or replaced without alteration misalignment
or damage to items being installed or to adjoining items or structure)- ‘Replaceable’ (Replaceable items requires alterations of the items in
addition to the normal application and methods of attachment. Suchalterations may include drilling, reaming, cutting, filing, trimming,
bending, shaping, etc)
- ‘Not_applicable’
Source: EIA-836 Configuration Management
Product_identifier

Id

Identification of a product which is the target for the Logistics Support
Analysis Project (Program).

Product

Project

Product

Project

Note 1: Equivalent to End Item Acronym Code in GEIA-STD-0007.
Note 2: May be used to capture ASD S1000D Model Identification
Code, where the Model Identification Code is used for more than one
Product Variant.
Product_nameId

The name by which the Product is known.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 34

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Product_service_life

Prp

The number of years the LSA candidate is expected to be in service.

Product_service_life

LSA Candidate

Product_usage_phase

LSA-FMEA and Special
Events

Product_variant

Project

Product_variant

Project

Note: Other measures than years can be used.
Product_usage_phaseClass

Defined phases during the products in-service phase.
Examples of product usage phases are:- ‘Operation’- ‘Take off’- ‘Flight’- ‘Landing’- ‘Maintenance’- ‘Storage’- ‘Transportation’
Valid classes are to be determined by the project.

Product_variant_identifier

Id

Identification of a specific variant (model) of the contracted productbeing the target for the Logistics Support Analysis Project (Program).
Note 1: Equivalent to System/End Item Usable On Code in GEIA-STD0007.
The following Product_variant_identifier is recommended to be used toenable integration with other ASD specifications:- 'Model_identification_code'.

Product_variant_nameId

The name by which the product variant (model) is known.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 35

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Product_variant_realization_identifier

Id

Identification of a product variant realization (i.e. an allowed physicalconfiguration). A product variant realization identifies the approved
parts and software which are allowed to realize the individual
breakdown elements defined for a product breakdown.

Product_variant_realization

Product Variant Applicability

Product_variant_realization_revision_creati Dateon_dateDate for creation of a revision of a product variant realization (i.e. anallowed physical configuration).

Product_variant_realization

Product Variant Applicability

Product_variant_realization_revision_identif Id
ier

Identification of a specific revision of a product variant realization.

Product_variant_realization

Product Variant Applicability

Note: Revision identifier is used to identify design iterations and notvariants.
Project_identifier

Id

Identification of the project (program) within which the Logistics
Support Analysis (LSA) is being performed.

Project

Project

Project_nameId

The name by which the project (LSA program) is known.

Project

Project

Publication_module_code

Id

Identification of a specific publication module created in accordancewith the rules defined in S1000D.

S1000D_publication_module

Document

Publication_module_issue_number

Id

Identification of a specific issue (revision) of a publication module.

S1000D_publication_module

Document

Publication_module_title

Id

The name by which a publication module is known.

S1000D_publication_module

Document

Quantity_of_child_elements

Prp

The quantity of a child element in the context of its parent element.

Breakdown_element_structure /Part_list_entry

Breakdown Structure /Part

Quantity_of_contracted_product_variant

Prp

Quantity of a product variant included in a contract.

Contracted_product_variant

Project

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 36

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Quantity_of_material_included_in_hardwar Prp
e_partQuantity of a material included in a hardware part.

Hardware_part_material_usage

Part

Quantity_of_product_variant_in_operating_l Prp
ocation

The number of serialized items, of a specific product variant, that is tobe operated at an actual operating location.

Contracted_product_variant_in_op Product Usageerating_location

Quantity_of_product_variant_in_operating_l Prp
ocation_type

The number of serialized items, of a specific product variant, that is tobe operated at a specific operating location type.

Contracted_product_variant_in_op Product Usageerating_location_type

Remark_text

Text that provides the user with information that is helpful but does not Remark
belong to the immediate subject.

Descr

RemarkSource: OASIS PLCS Standard Reference Data Library
Remark_type

Class

Additional characterization of the remark, defining its purpose.

RemarkRemark

The following class can be used to enable integration with other ASD
specifications:- ‘Maintenance_allocation_remark’ (S1000D Maintenance Allocation)

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 37

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Repairability

Class

Classification whether a part is repairable from a technical standpoint(i.e. a vendor/supplier standpoint). This classification is independent
from customer maintenance concepts.

Hardware_part /Hardware_element_revisionPart /Breakdown Element
Realization

Classification of the repairability strategy chosen for a specificHardware_part /customer and maintenance concept. Repairability strategy can include Hardware_element_revision
information on which maintenance level the repair is to be performed.

Part /Breakdown Element
Realization

The following classes must be used to enable integration with other
ASD specifications:- ‘Reapairable’- ‘Partially_repairable’- ‘Discardable’- ‘Not_applicable’.
Repairability_strategy

Class

Valid classes for Repairability_strategy are to be determined by the
project.
Replaceability_strategy

Class

Defines the replaceability strategy chosen for a specific customer andmaintenance concept. Replaceability strategy can include information
about the maintenance level, at which the replacement task is to be
performed.

Parts_list_entry /Hardware_element_revisionPart /Breakdown Element Revision

Valid classes for Replaceability_strategy are to be determined by the
project. Examples on classes that can be used are:- ‘Line_replaceable’,- ‘Shop_replaceable’.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 38

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Replacement_time

Prp

The duration of the replacement of a (eg faulty) component within any
technical system by another (eg new) component.

Replacement_time

LSA Candidate

Resource_specification_description

Descr

Textual specification of a resource needed to perform a task.

Resource_specification

Task Resources

Resource_specification_identifier

Id

Identification of a resource specification.

Resource_specification

Task Resources

Resource_specification_name

Id

Name by which the resource being specified is known.

Resource_specification

Task Resources

S1000D_task_type

Class

Defines how the task corresponds with the schemas defined in
S1000D.

Task

Task

The following S1000D_task_types must be used to enable integration
with other ASD specifications:- 'Procedure',- 'Package'
Sampling_method_description

Descr

Description of sampling method used.

Sampling

Task Usage (Part 1)

Sampling_method_ratio

doubleThe number of samples over the total population expressed as a ratio,eg 0,1 (equals 10%)

Sampling_by_ratio

Task Usage (Part 1)

Task Usage (Part 1)

Note: The value must be represent as decimal, even though it shouldhave been a fraction.
Sampling_method_value

Prp

The number of samples over the total population expressed as avalue, eg ten aircrafts.

Sampling_by_value

Scheduled_maintenance_intervalPrp

The (minimum) number of operational units (eg rounds, miles, hours)
between scheduled maintenance.

Scheduled_maintenance_interval LSA Candidate

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 39

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Security_class

Class

Security class associated with a specific, breakdown element, part,task, subtask or task requirement.

Security_class

Security Classification

Valid classes for Security_class are to be determined by the project.
Serial_number_lower_boundint

The lower bound of a specified range of serialized items, as known by
the customer.

Block_of_serialized_items

Project

Serial_number_upper_boundint

The upper bound of a specified range of serialized items, as known by
the customer.

Block_of_serialized_items

Project

Shop_processing_time

Prp

The duration from the start of the repair activities in the repair shop
until the closing of the repair procedure without considering any
shipping and delay times.

Shop_processing_time

LSA Candidate

Skill_code

Class

Identification of a specific combination of trade and skill level.

Skill

Task Resources

Skill_level

Task Resources

Valid classes for Skill_code are to be determined by the project.
Skill_level_nameClassA defined competency level.
The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Advanced’- ‘Intermediate’- ’Basic’.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 40

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Software_element_type

ClassCan be used to indicate further specialization of a software element.

Software_element

Breakdown Element
Realization

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Loadable’- ‘Embedded’.
Software_release

Id

Identification of a release (revision) of a manufactured software.

Software_part

Part

Software_technology

Descr

Description of technology used for the development or execution of amanufactured software. Used for harmonization purposes, i.e.
harmonizing the software technologies used within a product.

Software_part

Part

Software_type

Class

Classification defining if the software and/or data can beloaded/unloaded to/from the related hardware element (part).

Software_partPart

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Loadable’- ‘Embedded’- ‘Distributed’.
Special_event_description

Descr

Description of a special event that can cause a related failure mode(damage).

Special_event

LSA-FMEA and Special
EventsSpecial_event_effect_probability_ratio

doubleIdentifies the fraction of a specific failure mode (damage) to occur outof the total number of failure modes (damages) that can occur as aconsequence of the special event affecting a specific LSA candidate.

Special_event_effect_probability

LSA-FMEA and Special
EventsApplicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 41

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Special_event_group

Class

Classification used for the grouping of special events.

Special_event

LSA-FMEA and Special
Events

The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘External cause’- ‘Natural phenomenon’- ‘Meteorological’- ‘Animal’- ‘Human impact’- ‘Combat’- ‘Material maneuver’- ‘Internal cause’- ‘Internal dysfunction’- ‘Extensive heat’- ‘Extensive vibration’Special_event_occurrence_rate

Prp

Quantification of how often a specific special event will occur.

Quantified_special_event_occurre LSA-FMEA and Special
nce_definition
EventsSpecial_event_occurrence_rating

Class

Qualification of how often a specific special event will occur.

Rated_special_event_occurrence LSA-FMEA and Special_definition
Events

The following classes is proposed to be used to enable integration withother ASD specifications:- 'Extremely_unlikely'- ‘Remote_likelihood’- 'Occasional'- 'Reasonably_probable'- 'Frequent'Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 42

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Special_event_title

Class

Title (name) by which a special event is known.

Special_event

LSA-FMEA and Special
EventsSpecial_training_requirement_description

Descr

Description of additional training required for the given competence(trade or skill).

Special_training_requirement

Task Resources

Structural_indicatorClass

Indicator, whether a hardware breakdown element is classified as
being a Structural Significant Item (SI), Structural Item (SI), Structural
Detail (SD), or if the classification is Not Applicable (N/A).

Hardware_breakdown_element

Breakdown Element
Realization

Note 1: A Structure Significant Item (SSI) is an item which was
identified by any selection process coming from a Scheduled
Maintenance Analysis Procedure like MSG-3 or ASD/AIA S4000M. For
this item, a Scheduled Maintenance Analysis (SMA) will be performed.
Note 2: A Structural Item (SI) is part of the systems bodywork.
Note 3: A Structural Detail (SD), also named Significant Detail in the
ASD S4000M, is a limited area of an SSI or a local spot being also partof the whole SSI. In contrast to an SSI, the SD isn´t identified by an
own identifier (eg an own part number). Therefore these SD's must be
defined and documented on the respective SSI drawing.
For identification within any breakdown structure, an additional artificial
breakdown element identifier can be addressed.
Subtask_acceptance_parameter_descriptio Descr
nDescription of criteria that determines whether a subtask is completed. Subtask_acceptance_parameter

Task

Subtask_acceptance_parameter_value

Prp

Value (criteria) that must be fulfilled in order to complete the subtask.

Subtask_acceptance_parameter

Task

Subtask_description

Descr

Detailed description of the subtask procedure.

Subtask_by_definition

Task

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 43

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Subtask_duration

Prp

The average time expended, regardless of the number of personnel
working simultaneously, required for the performance of the subtask.
This does not include time spent awaiting spares, support equipment,
facilities or personnel (logistics delay time).

Subtask_by_definition

Task

Subtask_identifier

Id

Identification of a subtask.

Subtask

Task

Subtask_by_definition

Task

Note: A subtask is identified within the context of a task.
Subtask_nameId

The name (title) by which a subtask is known.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 44

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Subtask_objective_stateClass

Defines the new state that will exist due to the accomplishment of thesubtask.

Subtask_objective_state

Task

The following classes must be used to enable integration with other
ASD specifications:- ‘Task_checked’- ‘Jacked’ / ‘Unjacked’- ‘Safety_device_established’- ‘Elecrical_power_established’ /‘Elecrical_power_from_engine_established’ /‘Elecrical_power_from_apu_established’ /‘External_elecrical_power_established’ /‘Internal_elecrical_power_established’- ‘Hydraulic_power_established’- ‘Air_supply_established’- ‘Fueled’ / ‘Defueled’- ‘Water_supply_established’- ‘Controls_status_established’- ‘Open’ / ‘Close’ / ‘Verify_open’ / ‘Verify_close’ (forSubtask_circuit_breaker_state)

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 45

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Subtask_role

Class

Defines if the subtask is required for preparation, core, or close-up
purposes.

Subtask

Task

Subtask_timeline

Task

Subtask_timeline

Task

The following classes must be used to enable integration with other
ASD specifications:- ‘Startup’- ‘Core’- ‘Core_no_required_conditions’- ‘Closeup’.
Subtask_timeline_event

Class

Defining the starting point for subtask under consideration, in relation
to the start or end point of the subtask playing the role of its
predecessor.
The following classes are recommended to be used to enable
integration with other ASD specifications:- ‘Start’- ‘End’Subtask_timeline_lag

PrpTime between the related subtask timeline event (start / end) and thestart point for the subtask under consideration.
Note: Time lining just using references to the start point for the entire
task, can use the lag attribute to indicate the time relative to thestarting point of the first subtask and set Subtask_timeline_event =‘Start’.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 46

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Task_criticality_code

Class

Indicates whether or not the task is critical. A task is critical if failure toaccomplish it would result in adverse effects on system reliability,
efficiency, effectiveness, safety, or cost. A task will also be designatedas critical whenever system design characteristics approach human
limitations, and thereby, significantly increase the likelihood of
degraded, delayed, or otherwise impaired mission performance.

Task

Task

Task_distribution

Task

Valid classes for Task_criticality_code are to be determined by the
project.
Note: GEIA-STD-0007 uses the values 'Yes' / 'No'
Task_distribution_ratio

doubleThe probability of a specific task to be performed, when there are
multiple Tasks that can resolve the same task requirement

Task_duration

Prp

The average time expended, regardless of the number of personnel
Task
working simultaneously, required for the performance of a task,scheduled or unscheduled. This does not include time spent awaiting
spares, support equipment, facilities or personnel (logistics delay time).

Task

Note: May be calculated from the subtask durations.
Task_facility_resource_quantity

Prp

Quantity of a specific facility resource required by a subtask, oraggregated per task.

Task_frequencyPrp

The frequency of performance or occurrence of the task, expressed as Task_frequency
the number of annual occurrences.

Task Usage (Part 1)

Task_frequency_calculation_method

Descr

Description of the method used for calculating the task frequency.

Task Usage (Part 1)

Applicable to: All

Task_facility_resource

Task_frequency

Task Resources

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 47

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Task_identifier

Id

Identification of a task.

Task

Task

Note: If the Task_identifier is being used in conjunction with S1000D it
must follow the rules of XML identifier datatypes (start with an alphacharacter)
Task_limit_description

Descr

Textual description of the limit (threshold and triggers) for performing a Task_limit
defined task.

Task Usage (Part 1)

Task_limit_harmonization_indicatorboolean Marker for task limit, which is the result from a task limit harmonization Task_limit
and packaging procedure. Such tasks are in general inspection or/and
overhaul packages, documented against non physical breakdown
elements.

Task Usage (Part 1)

Task_material_resource_categoryClass

Task_material_resource

Task Resources

Task_material_resource

Task Resources

Classification of the needed material resource as being eg spare part,
supply, or support equipment in the context of the task/subtask.
The following classes must be used to enable integration with other
ASD specifications:- ‘Support_equipment’- ‘Safety_related_support_equipment’- ‘Spare’- ‘Supply’.

Task_material_resource_quantity

Prp

Quantity of the material resource needed by a subtask, or aggregated
per task.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 48

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Task_nameId

The name (title) by which a task is known.

Task

Task

The following rule must be followed to enable integration with other
ASD specifications:- Task_name must use the information code name for the
Information_code that is associated with the task
- Additional qualifiers can be added to establish a unique Task_name if
multiple tasks with the same Information_code is associated with one
and the same breakdown element or part.
Task_number_of_personnel_resource

Prp

Number of persons with the same role and skill code needed within
one task/subtask.

Task_personnel_resource

Task Resources

Task_operability_code

Class

A code used to indicate the operational status and mission readinessof the end item during the maintenance task.

Task

Task

Task_personnel_resource

Task Resources

The following classes must be used to enable integration with other
ASD specifications:“A” – System Inoperable during Equipment Maintenance,“B” – System Operable during Equipment Maintenance,“C” – Full Mission Capable,“D” – Partial Mission Capable,“E” – Not Mission Capable,“F” – Turnaround
Note: Ref GEIA-0007, except code = G.
Task_personnel_resource_labour_time

Prp

Time expended within a task/subtask per needed human resource.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 49

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Task_personnel_resource_role

Class

Role of a specific instance of a personnel resource needed within atask/subtask.

Task_personnel_resource

Task Resources

The following classes must be used to enable integration with other
ASD specifications:- ‘Man A’ / ‘Man B’ etc- ‘Performer’- ‘Supervisor’- ‘Quality_assurance’
Task_requirement_authority_source_type

Class

Indicates the source of an authority driven task requirement.

Authority_driven_task_requiremen LSA Candidate Taskt
Requirement

The following classes must be used to enable integration with other
ASD specifications:- ‘MSG3’- ‘CMR’- ‘AD’
Task_requirement_change_description

Descr

Description of the changes introduced between two revisions of a task
requirement.

Task_requirement_change

LSA Candidate Task
Requirement

Task_requirement_date

Date

The date when the task requirement was created.

Task_requirement

LSA Candidate Task
Requirement

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 50

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Task_requirement_decisionClass

The status for the task requirement.

Task_requirement

LSA Candidate Task
Requirement

Valid classes are to be determined by the project. Proposed classes tobe used includes:- ‘Accepted’- ‘Rejected’- ‘Deferred’- ‘Realized’.
Task_requirement_description

Descr

Description of the maintenance requirements that have been
Task_requirement
determined as the outcome of eg the Reliability Centered Maintenance(RCM) analysis, LSA-FMEA, In-service feedback etc.

LSA Candidate Task
Requirement

Task_requirement_identifier

Id

Identification of a task requirement.

Task_requirement

LSA Candidate Task
Requirement

Task_requirement_revision_identifier

Id

Identification of a revision of a task requirement.

Task_requirement

LSA Candidate Task
Requirement

Note: Revisions is to be seen as design iterations and not as variants.
Task_requirement_special_resource

Descr

Textual description of any special (peculiar) resource needed for the
performance of the required task.

Task_requirement

LSA Candidate Task
Requirement

Task_resource_duration

Prp

The average time that a resource is needed for the performance of atask, scheduled or unscheduled.

Task_resource

Task Resources

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 51

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Task_resource_relationship_category

Class

Determines the relationship between two resources needed within thesame subtask.

Task_resource_relationship

Task Resources

Example:- Person A uses Support Equipment B
Valid classes for Task_resource_relationship_category are to be
determined by the project.
Task_revision_change_description

Descr

Description of the changes introduced between two revisions of a task. Task_change

Task

Task_revision_identifier

Id

Identification of a revision of a task.

Task

Task

Task

Task

Task

Task

Note: Revisions is to be seen as design iterations and not as variants.
Task_revision_status

Class

Code for indicating the progress on the definition of a task (revision).
Valid classes for Task_revision_status are to be determined by the
project.

Task_total_labour_time

PrpTotal time expended within a task. Includes the labor time for all
required personnel resources.

Technology_behaviour_knowledge_rating

Classifi Knowledge of the behavior of the technology used, during normal use
cation or caused by special event

LSA_candidate_technology_beha LSA-FMEA and Special
vior_rating
EventsValid classes for Technology_behaviour_knowledge_rating are to be
determined by the project.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 52

S3000L-B6865-03000-00

Data element

Type

Definition

Technology_sensitivety_rating

Classifi Sensitivity regarding possible damage sources during normal use or
cation caused by special event.

Class/Interface

UoF

LSA_candidate_technology_beha LSA-FMEA and Special
vior_rating
EventsValid classes for Technology_sensitivity_rating are to be determinedby the project.
Threshold_value

Prp

A value that defines the limit (interval) for when a task is to be
performed.

Parameter_threshold

Task Usage (Part 1)

Trade_name

Class

Type or classification of occupation.

Trade

Task Resources

Special_training_requirement

Task Resources

Valid classes for Trade_name are to be determined by the project.
Training_method

Class

Defines how training is to be performed.
The following classes can be used to enable integration with other
ASD specifications:- ‘Classroom’- ‘Correspondence’- ‘Maneuver area’- ‘Simulator’Warning_caution_or_note_description

Descr

Advices concerning safety, legal and health aspects.

Warning_caution_or_note

Task

Warning_caution_or_note_identifier

Id

Identification of the advices concerning safety, legal and healthaspects.

Warning_caution_or_note

Task

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 53

S3000L-B6865-03000-00

Data element

Type

Definition

Class/Interface

UoF

Warning_caution_or_note_type

Class

Classifies the provided safety, legal and health aspects as a warning,
caution or note.

Warning_caution_or_note

Task

The following classes must be used to enable integration with other
ASD specifications:- ‘Warning’- ‘Caution’- ‘Note’.
Zone_element_description

Descr

Description of the zone element under consideration.

Zone_element_revision

Breakdown Zone Element

Zone_element_type

ClassCan be used to indicate further specialization of a zone element.

Zone_element

Breakdown Zone Element

The following classes must be used to enable integration with other
ASD specifications:- ‘Zone’- ‘Work_area’.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 54

S3000L-B6865-03000-00

Table 3 Attributes of the S3000L data types
Data element

Type

Definition

Class

UoF

Class_namechar

The word or code by which the Class is known.

Class

Data TypesClass

Data Types

Source: ISO 10303:239 Product Life Cycle Support.
Class_rdlchar

An identifier for the external class library, where a definition of the class is tobe found.
Note: If appropriate this must be the URL/URN of the external class library.
Source: ISO 10303:239 Product Life Cycle Support.

Classification_date

Date

The date when a class was assigned to the subject under consideration.

Classification

Data Types

Day_component

int

The year element of the Date expressed as a value between 1 and 31.

Date

Data Types

Source: ISO 10303:239 Product Life Cycle Support.
Description

char

Text that provides further information about the subject under consideration.

Descr

Data Types

Description_provided_by_organization

Id

Defines the organization that provided the description.

Descr

Data Types

Description_provided_date

Date

The date when the description was provided.

Descr

Data Types

Identifierchar

The text that conveys the assigned identifier.

Id

Data Types

Source: ISO 10303:239 Product Life Cycle Support.
Identifier_class

Id

Defines the type of identifier being defined, eg OEM part number, NCAGEcode etc.

Id

Data Types

Identifier_set_by_organization

Id

Defines the organization that “owns” the assigned identifier.

Id

Data Types

Limit_qualifierClass

The kind of limit. Valid values are ‘maximum’ or ‘minimum’

Value_with_limit_property

Data Types

Value_range_property

Data Types

Source: ISO 10303:239 Product Life Cycle Support.
Lower_limit_value

doubleThe lower limit of a value range.
Source: ISO 10303:239 Product Life Cycle Support.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 55

S3000L-B6865-03000-00

Data element

Type

Definition

Class

UoF

Lower_offset_value

doubleThe lower limit defined as the lower offset value from the single value (value+ lower limit).

Value_with_tolerances_property

Data Types

Date

Data Types

Source: ISO 10303:239 Product Life Cycle Support.
Month_component

int

The month element of the Date expressed as a value between 1 and 12,
where:
1 = January
2 = February
3 = March
4 = April
5 = May
6 = June
7 = July
8 = August
9 = September
10 = October
11 = November
12 = December.
Source: ISO 10303:239 Product Life Cycle Support.

Property_creation_date

Date

The date when the property value was determined.

Property_representation

Data Types

Property_determinationClass

The method by which the value of the property has been determined. The
value of this attribute need not be specified. Where applicable the followingclasses must be used:- ‘Calculated’: the value has been calculated,- ‘Designed’: the value represents a value intended by the design,- ‘Estimated’: the value has been estimated,- ‘Measured’: the value has been measured,- ‘Set point’: the value is used as an initialization value.

Property_representation

Data Types

Text_property

Data Types

Source: ISO 10303:239 Product Life Cycle Support
Text

char

The string that is the element of representation.
Source: ISO 10303:239 Product Life Cycle Support.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

2010-04-01 Page 56

S3000L-B6865-03000-00

Data element

Type

Definition

Class

UoF

Unit

Class

The unit with which the quantity is expressed.

Value_with_unit_property

Data Types

Value_range_property

Data Types

Value_with_tolerances_property

Data Types

Value_with_unit_property

Data Types

Date

Data Types

Source: ISO 10303:239 Product Life Cycle Support.
Upper_limit_value

double

The upper limit of a value range.
Source: ISO 10303:239 Product Life Cycle Support.

Upper_offset_value

double

The upper limit defined as the upper offset value from the single value(value + upper offset value).
Source: ISO 10303:239 Product Life Cycle Support.

Value

doubleThe value of the quantity.
Source: ISO 10303:239 Product Life Cycle Support.

Year_component

int

The year element of the Date expressed as a value between 1 and 9999.
Source: ISO 10303:239 Product Life Cycle Support.

S3000L-A-22-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-22-00-0000-00A-040A-A_001_00_EN-US.doc

Chap 222010-04-01 Page 57