S3000L-B6865-03000-00

International procedure specification
for Logistics Support Analysis (LSA)
S3000L-B6865-03000-00

Issue No. 2.1

S-Series IPS specifications
Block release 2021

Usage rights:

Refer to S3000L-A-00-00-0000-00A-021A-A

Copyright © 2023 by:

AeroSpace, Security and Defense Industries Association of Europe (ASD)

Publishers:
AeroSpace, Security and Defence Industries Association of Europe
Aerospace Industries Association of America (AIA)

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-001A-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-001A-A

2023-03-01 Page 1

S3000L-B6865-03000-00

Copyright, user agreement and special usage rights
1

Copyright
Copyright © 2010, 2014, 2019, 2021 2023 AeroSpace, Security and Defense 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 copyrightact or in writing by the publisher.
S3000L™ is a trademark owned by ASD.
All correspondence and queries should be directed to:
ASD
Rue du Trône
1050 Brussels
Belgium

2

Agreement for use of the specification S3000L™ suite of
information

2.1

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

the International procedure specification for Logistics Support Analysis LSA - S3000L
S3000L XML schemas
S3000L UML model
examples (eg, XML instances, PDF files)
the input data specification S3000X
any other software or information on the page titled " Downloads" on the website
www.s3000l.org

Copyright holder means AeroSpace, Security and Defense 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 to you
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.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-021A-A_004-00_EN-US.docx

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

2023-03-01 Page 1

S3000L-B6865-03000-00

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.

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 Alternative Dispute Resolution (ADR) or within such other period as theparties may agree in writing, such dispute shall be finally settled under the rules of arbitration of
the International Chamber of Commerce by three arbitrators appointed in accordance with thesaid 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.

3

Special usage rights
Permission to use, reference, or deliver training from the information contained in thisdocument, and in the S-Series IPS Specifications, and the right to reproduce or publish the SSeries IPS Specifications, in whole or in part, is hereby given to the following:1

National Associations who are members of ASD and all their member companies.

2

Members of Aerospace Industries Association of America.

3

Armed Forces that are customers of Companies included in these special usage rights
Categories 1 and 2 inclusively.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-021A-A_004-00_EN-US.docx

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

2023-03-01 Page 2

S3000L-B6865-03000-00

4

Ministries and Departments of Defense of the member countries of ASD, AIA, NATO, andNATO Partners.

5

NATO bodies, organizations & agencies.

6

The industries of ASD, AIA, NATO’s nations, and NATO’s Partners.

7

Universities, Educational Institution, Technologies and Research Institutes within ASD, AIA,NATO nations and NATO Partners.

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

Applicable to: All

End of data module
DMC-S3000L-A-00-00-0000-00A-021A-A_004-00_EN-US.docx

2023-03-01 Page 3

S3000L-B6865-03000-00

Highlights
This issue includes updates to the Copyright, user agreement and special usage rights
only. There have been no technical changes in this issue. The highlights below are those of
the 2021 Block Release.

Table of contents
1
2
3

General ............................................................................................................................ 2
Technical and editorial changes ...................................................................................... 2Content ............................................................................................................................ 2

List of tables
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

References ...................................................................................................................... 1
Introduction to the specification ....................................................................................... 2
General requirements ...................................................................................................... 3
LSA process .................................................................................................................... 3
Product structures and change management in LSA ...................................................... 3
Influence on design ......................................................................................................... 4
Human factors analysis ................................................................................................... 4
Corrective maintenance analysis..................................................................................... 4
Damage and special event analysis ................................................................................ 4
Operational support analysis ........................................................................................... 4
Development of a preventive maintenance program ...................................................... 5
Level of repair analysis .................................................................................................... 5
Task requirements and maintenance task analysis ........................................................ 5
Software support analysis ............................................................................................... 6
Life cycle cost considerations .......................................................................................... 6
Obsolescence analysis .................................................................................................... 6
Disposal ........................................................................................................................... 6
In-service LSA ................................................................................................................. 7
Interrelations to other S-Series IPS specifications .......................................................... 7
Data model ...................................................................................................................... 7
Data exchange............................................................................................................... 12
Terms, abbreviations and acronyms ............................................................................. 13
Data element list ............................................................................................................ 13

Table 1 References
Chap No./Document No.

Title

S1000DInternational specification for technical publications using acommon source database

S4000PInternational specification for developing and continuously
improving preventive maintenance

S6000TInternational specification for training analysis and design

SX000iInternational specification for Integrated Product Support(IPS)

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 1

S3000L-B6865-03000-00

SX002D

Common data model for the S-Series IPS Specifications

SX004G

Unified Modeling Language (UML) model reader’sguidance

1

GeneralChanges that are included in this issue 2.0 of S3000L are results from improvements in existingprocesses and the introduction of new content in several chapters. Additionally, the S3000L
data model was updated in line with the common data model of the S-Series IPS Specifications,which is documented in SX002D.

2

Technical and editorial changes
Technical and editorial changes are not change marked in this issue 2.0 of S3000L. Any
editorial changes are not described in the highlight pages.

3

Content
Highlights of changes to chapters 1 to 22 are provided in the following tables:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

chapter 1 - Introduction to the specification, refer to Table 2
chapter 2 - General requirements, refer to Table 3
chapter 3 - LSA process, refer to Table 4
chapter 4 - Product structures and change management in LSA, refer to Table 5
chapter 5 - Influence on design, refer to Table 6
chapter 6 - Human factors analysis, refer to Table 7
chapter 7 - Corrective maintenance analysis, refer to Table 8
chapter 8 - Damage and special event analysis, refer to Table 9
chapter 9 - Operational support analysis, refer to Table 10
chapter 10 - Development of a preventive maintenance program, refer to Table 11
chapter 11 - Level of repair analysis, refer to Table 12
chapter 12 - Task requirements and maintenance task analysis, refer to Table 13
chapter 13 - Software support analysis, refer to Table 14
chapter 14 - Life cycle cost considerations, refer to Table 15
chapter 15 - Obsolescence analysis Table 16
chapter 16 - Disposal, refer to Table 17
chapter 17 - In-service LSA, refer to Table 18
chapter 18 - Interrelations to other S-Series IPS specifications, refer to Table 19
chapter 19 - Data model, refer to Table 20
chapter 20 - Data exchange, refer to Table 21
chapter 21 - Terms, abbreviations and acronyms, refer to Table 22
chapter 22 - Data element list, refer to Table 23
Table 2 Introduction to the specification

Chapter

Summary of changes

Chap 1−clarification added regarding S3000L compliance and logistics support vs. logistic
support

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 2

S3000L-B6865-03000-00

Table 3 General requirements
Chapter

Summary of changes

Chap 2−term "LSA Guidance Conference Document (LSA GCD)" was changed to "LSA
Guidance Document (LSA GD)" in general−term "implementation rules" was changed to "business rules" in the LSA GD−

term "scheduled maintenance" was changed to "preventive maintenance" in general(in some cases, the term scheduled maintenance is kept in the context of preventive
maintenance tasks which are able to schedule based on repeated intervals)−

reference to logistic/logistics was replaced by product support−

additional paragraph listing the relevant Unit of Functionality (UoF) from Chap 19 forthe population of LSA data which are an outcome of Chap 2

Table 4 LSA process
Chapter

Summary of changes

Chap 3−

general clarification of the further usage of the terms "logistics" and "supportability"
within the specification−

improvement and completion of relations to the IPS elements−

improvement and completion of content concerning event driven corrective andpreventive maintenance in the context of FMEA, special event analysis andPreventive Maintenance Analysis (PMA), including the harmonization of wording
according to S4000P−

adaption of wording to harmonize with Chap 19−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 3

Table 5 Product structures and change management in LSA
Chapter

Summary of changes

Chap 4−

chapter was completely reworked to clearly explain the full capabilities for thegeneration of different product breakdown structures, including breakdown element
realization, part lists and product variant aspects−

establishing a logical chapter structure based on Units of Functionality (UoF) of
Chap 19 enabling traceability with the S3000L data model−

rework of change management aspects for a better understanding of how S3000L
supports change management processes and how it impacts the LSA process−

generating additional illustrations and rework of existing illustrations from S3000L,
issue 1.1, for a better understanding of product breakdown structure and change
management concepts−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 4

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 3

S3000L-B6865-03000-00

Table 6 Influence on design
Chapter

Summary of changes

Chap 5−no major technical changes in Chap 5, only editorial rework−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 5

Table 7 Human factors analysis
Chapter

Summary of changes

Chap 6−no major technical changes in Chap 6, only editorial rework

Table 8 Corrective maintenance analysis
Chapter

Summary of changes

Chap 7−clarification added about the objectives and perimeter of the chapter−

separation of the main paragraph into two separate paragraphs to distinguishcorrective maintenance on the Product and corrective maintenance on equipment atworkshop after it has been removed from the Product−clarification added about the type of input (FMEA) and the process in each case−additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 7

Table 9 Damage and special event analysis
Chapter

Summary of changes

Chap 8−

separation of special event analysis and damage analysis−

clarification of special event process to be consistent and complementary tocorresponding paragraphs dedicated to special events in S4000P−

clarification of damage analysis as an independent process with the following steps:
identification of damage with different inputs, assessment of damage relevance,
analysis of acceptable damage size and repair procedure−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 8

Table 10 Operational support analysis
Chapter

Summary of changes

Chap 9−no major technical changes in Chap 9, only editorial rework−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 9

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 4

S3000L-B6865-03000-00

Table 11 Development of a preventive maintenance program
Chapter

Summary of changes

Chap 10−

harmonization of terminology with S4000P, focusing on different classes of Preventive
Maintenance Task Requirements (PMTR), Preventive Maintenance Task
Requirement Interval (PMTRI) for a PMTR based on an interval and Preventive
Maintenance Task Requirement Event (PMTRE) for PMTR after the occurrence of a
special event−

harmonization of terminology with Chap 19 in the context of time limits, thresholds
and triggers−

inclusion of an interval adaption example in the context of preventive maintenancepackaging−

additional paragraph listing the relevant UOF from Chap 19 for the population of LSA
data which are an outcome of Chap 10

Table 12 Level of repair analysis
Chapter

Summary of changes

Chap 11−clarification of the term maintenance level in the context of personnel competence,
facilities or support equipment available−

inclusion of an additional sub paragraph on the definition of operational concept as
part of data gathering for Level of Repair Analysis (LORA)−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 11

Table 13 Task requirements and maintenance task analysis
Chapter

Summary of changes

Chap 12−extension and improvement of the explanation of the task requirements approach(each rectifying task needs to be justified by at least one task requirement)−

improvement of the presentation of the task categorization−

rework of the task documentation paragraphs referring to the representation of the
UoF (refer to Chap 19) covering the aspects of Maintenance Task Analysis (MTA)−

adding a paragraph to describe the data model capability to document required circuit
breaker settings to perform a task−complete rework of maintenance task examples (deletion of misleading figures in theparagraph)−extended adaption of wording to harmonize with Chap 19−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 12

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 5

S3000L-B6865-03000-00

Table 14 Software support analysis
Chapter

Summary of changes

Chap 13−

improvement of the explanation, which software related tasks are relevant and to be
included in LSA activities from a supportability point of view−

adaption of wording to harmonize with the data model chapter 19−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 13

Table 15 Life cycle cost considerations
Chapter

Summary of changes

Chap 14−

inclusion of the synchronization of LCC analysis between contractor and customer
software tools−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 14

Table 16 Obsolescence analysis
Chapter

Summary of changes

Chap 15−

reorganization of the paragraphs for better readability−alignment of the phases definitions with SX000i and relevant chapters/paragraphs−

inclusion of additional concepts and references (eg, Registration, Evaluation,
Authorization and Restriction of Chemicals (REACH))−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 15

Table 17 Disposal
Chapter

Summary of changes

Chap 16−

former chapter number 17 from S3000L, issue 1.1, is now chapter number 16. Inservice LSA chapter was shifted to chapter number 17, refer to Table 18.

Note
Disposal aspects are applicable during all life cycle phases of the product and provide
task requirements. Logical sequence of the chapters was changed to have allprocedural chapters providing task requirements before the In-service LSA chapter.
−harmonization of terminology within chapter figures−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 16

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 6

S3000L-B6865-03000-00

Table 18 In-service LSA
Chapter

Summary of changes

Chap 17−

former chapter number 16 from S3000L, issue 1.1, is now chapter number 17. Inservice LSA chapter was shifted to chapter number 17, refer to Table 17.

−complete rework of in-service LSA chapter−

rework of definition of in-service LSA activities−

inclusion of flowcharts and explaining descriptions to start an In-Service Support
Optimization (ISSO) process−

definition of ISSO analysis process subdivided by different support task types,
including flowcharts and basic analysis questions for each support task type−inclusion of a detailed ISSO analysis logic to analyze a disposal task as an example

Note
The example includes detailed flowchart diagrams as an example how to preparesuch analysis baselines within an ISSO guidance document.
−

rework of ISSO follow on phase−

additional paragraph listing the relevant UoF from Chap 19 for the population of LSA
data which are an outcome of Chap 17

Table 19 Interrelations to other S-Series IPS specifications
Chapter

Summary of changes

Chap 18−

restructure of chapter paragraphs to provide a better overview−

S-Series IPS Specifications completed by adding S6000T−

rework of the interface description to engineering and supportability engineering

Table 20 Data model
Chapter

Summary of changes

Chap 19−

removal of introduction paragraphs on how to read UML models

Note
The content of the introduction about how to read UML models is covered by the
specification SX004G.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 7

S3000L-B6865-03000-00

Chapter

Summary of changes
The part of Chap 19 which contains the graphical representations and descriptions of therespective Units of Functionality (UoF) has been reworked. Many changes were driven
by the harmonization with SX002D, issue 2.1. In this context, changes were incorporated
like:−

updated representations of classes, attributes and relationships (including cardinality)
inside many UoF−

renaming of classes or attributes−

separation of specific aspects within former UoF of S3000L (issue 1.1) to their own
UoF−

splitting of some UoF into several UoF to simplify and improve readability of the data
model

Note
Detailed changes like renaming, changes of classes and attributes, changes ofrelationships, changes of cardinalities, changes in graphical representation, editorialchanges, which were incorporated to the single UoF are not mentioned in thishighlights chapter.
Additionally, new UoF were created to support new subjects from the procedural
chapters 2 to 17.
In the following listing, a general overview concerning changes is given for each single
UoF of S3000L, issue 2.1−

UoF Aggregated Element
Incorporation of minor editorial changes.

−

UoF Applicability Statement
Incorporation of minor changes to simplify the reading and implementation of the data
model. Incorporation of changes to harmonize with SX002D, issue 2.1.

−

UoF Breakdown Structure
Incorporation of changes to harmonize with SX002D, issue 2.1. The one significant
change that has been introduced is the possibility to define relationships between
breakdown revisions (BreakdownRevisionRelationship).

−

UoF Change Information
New UoF to allow for traceability of authorized changes. This change is harmonizedwith SX002D, issue 2.1.

−

UoF Circuit Breaker
New UoF for the separated representation of circuit breakers. This change is driven
by the harmonization with SX002D, issue 2.1.

−

UoF Competence Definition
New UoF for the separated representation of competence definitions. This UoF
includes a portion of the previous UoF Task Resources in S3000L, issue 1.1.
Changes are driven by the harmonization with SX002D, issue 2.1, and S6000T issue
2.0.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 8

S3000L-B6865-03000-00

Chapter

Summary of changes−

UoF Damage Definition
New UoF for the separated representation of damages. This UoF includes a portion of
the previous UoF Special Event and Damage in S3000L, issue 1.1. This change isharmonized with SX002D, issue 2.1 and has been part of the harmonization with
S4000P.

−UoF Decision Tree Template Definition
New UoF to support in-service LSA. Changes are driven by the completely reworked
content of the in-service LSA, Chap 17. This change is harmonized with SX002D,
issue 2.1.

−

UoF Design Change Request
New UoF for the separated representation of a design change request. This UoF
includes a portion of the previous UoF LSA Candidate Task Requirement in S3000L,
issue 1.1. This change is driven by the harmonization with SX002D, issue 2.1.

−

UoF Digital File
New UoF to support the exchange of digital files as part of the data set. This change
is harmonized with SX002D, issue 2.1.

−

UoF Document
Incorporation of minor changes to harmonize with S1000D. The one significant
change that has been introduced is that any class in the data model now can definereferences to documents. This change is harmonized with SX002D, issue 2.1.

−

UoF Environment Definition
New UoF to add capabilities for the definition of concepts included in the UoF Product
Usage Context, for task definitions and applicability statements. This change isharmonized with SX002D, issue 2.1.

−

UoF Facility
New UoF for the separated representation of facilities and includes portions of theprevious UoF Product Usage Context in S3000L, issue 1.1. This change isharmonized with SX002D, issue 2.1.

−

UoF Failure Mode
New UoF for the separated representation of failure modes. This UoF includes a
portion of the previous UoF LSA Failure Mode in S3000L, issue 1.1. Changes are
driven by harmonization with S4000P and modifications within Chap 7 how to use
FMEA data in the context of corrective maintenance analysis.

−

UoF Failure Mode Isolation
New UoF for the separated representation of failure modes. This UoF includes a
portion of the previous UoF LSA Failure Mode in S3000L, issue 1.1. Changes are
driven by harmonization with S4000P and modifications within Chap 7 how to use
FMEA data in the context of corrective maintenance analysis.

−

UoF Failure Mode Symptom
New UoF for the separated representation of failure modes. This UoF includes a
portion of the previous UoF LSA Failure Mode in S3000L, issue 1.1. Changes are
driven by harmonization with S4000P and modifications within Chap 7 how to use
FMEA data in the context of corrective maintenance analysis.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 9

S3000L-B6865-03000-00

Chapter

Summary of changes−

UoF Hardware Element
New UoF for the separated representation of a hardware element. Changes are
driven by the harmonization with SX002D, issue 2.1.

−

UoF In Service Optimization Analysis
New UoF to support in-service LSA. Changes are driven by the completely reworked
content of the in-service LSA, Chap 17. This change is harmonized with SX002D,
issue 2.1.

−

UoF Location
New UoF to provide additional capabilities for the definition of an operating base anda maintenance facility. This change is driven by the harmonization with SX002D,
issue 2.1.

−

UoF Logistics Support Analysis Message Content
New UoF to support data exchange. Creation of UoF is driven by harmonization with
SX002D, issue 2.1, and by the need to define the structure for the S3000L XML dataset.

−

UoF LSA Candidate
New UoF to replace the previous UoF LSA Candidate Analysis Activity and portionsof the previous UoF LSA Candidate Item in S3000L, issue 1.1. Changes are driven by
the harmonization with SX002D, issue 2.1.

−

UoF LSA Failure Mode GroupNew UoF for the separated representation of failure modes. This UoF includes a
portion of the previous UoF LSA Failure Mode in S3000L issue 1.1. Changes are
driven by harmonization with S4000P and modifications within Chap 7 how to use
FMEA data in the context of corrective maintenance analysis.

−

UoF Message
New UoF to support data exchange. Creation of UoF is driven by harmonization with
SX002D, issue 2.1.

−

UoF Organization Assignment
The one significant change that has been introduced is that any class in the data
model now can define references to organizations. This change is harmonized with
SX002D, issue 2.1.

−

UoF Part Definition
Incorporation of additional classes/attributes and changes of attribute names.
Changes are driven by harmonization with SX002D, issue 2.1. The one significant
change that has been introduced is that parts lists now have explicit revisions.

−UoF Performance Parameter
New UoF to replace portions of the previous UoF LSA Candidate in S3000L, issue
1.1. Creation of UoF is driven by harmonization with SX002D, issue 2.1.

−

UoF Product and Project
Incorporation of minor changes. Changes are driven by the harmonization with
SX002D, issue 2.1.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 10

S3000L-B6865-03000-00

Chapter

Summary of changes−

UoF Product Design Configuration
Representation of this UoF was modified significantly. Changes are driven by theneed to improve readability of the UoF and a better representation of Productconfiguration aspects within Chap 4. This change is harmonized with SX002D, issue
2.1.

−

UoF Product Usage Context
Incorporation of minor changes. Changes are driven by the harmonization with
SX002D, issue 2.1.

−

UoF Product Usage Phase
New UoF for the separated representation of usage phases. This UoF includes a
portion of the previous UoF Special Event and Damage in S3000L, issue 1.1.
Creation of UoF is driven by harmonization with SX002D, issue 2.1.

−

UoF Remark
The one significant change that has been introduced is that any class and attribute in
the data model can have remarks. This change is harmonized with SX002D, issue
2.1.

−

UoF Resource Specification
New UoF for the separated representation of resource specification aspects. ThisUoF includes a portion of the previous UoF Task Resource in S3000L, issue 1.1. Thischange is harmonized with SX002D, issue 2.1.

−

UoF Security Classification
Incorporation of minor changes. Changes are driven by the harmonization with
SX002D, issue 2.1.

−

UoF Software Element
New UoF for the separated representation of a software element. Changes are driven
by the harmonization with SX002D, issue 2.1.

−

UoF Special Event
New UoF to replace portions of the previous UoF Special Event and Damage in
S3000L, issue 1.1. Changes are driven by the need to have a better representation of
special events as described in Chap 8 in the S3000L data model. This change isharmonized with SX002D, issue 2.1.

−

UoF Task
Incorporation of minor changes. Aspect of circuit breaker definition was moved to its
own UoF. Changes are driven by the harmonization with SX002D, issue 2.1.

−

UoF Task Requirement
New UoF to replace portions of the previous UoF LSA Candidate Task Requirementin S3000L, issue 1.1. Changes are mainly driven by the harmonization with SX002D,
issue 2.1.

−

UoF Task Resource
Incorporation of minor changes to simplify the reading and implementation of the data
model, adding of attributes and moving resource specification to a separate UoF.
Changes are mainly driven by the harmonization with SX002D, issue 2.1.

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 11

S3000L-B6865-03000-00

Chapter

Summary of changes−

UoF Task Usage
New UoF to combine portions of the previous UoF Task Usage (Part 1) with theprevious UoF Task Usage (Part 2) in S3000L, issue 1.1. Incorporation of renaming of
attributes and minor modification of classes. Changes were driven by the need tohave a logic separation of different aspects which were included in one UoF in
S3000L, issue 1.1. Changes are harmonized with SX002D, issue 2.1.

−

UoF Time Limit
New UoF for the separated representation of time limits and thresholds. This UoF
includes a portion of the previous UoF Task Usage (Part 1) in S3000L, issue 1.1. UoF
is extended by additional attributes and relations. Adaption also includes thecapability to handle condition based maintenance in the UoF. Changes areharmonized with SX002D, issue 2.1.

−

UoF Zone Element
Incorporation of minor changes. A breakdown element (or a revision thereof) can now
be associated with a zone. Changes are driven by the harmonization with SX002D,
issue 2.1.

Table 21 Data exchange
Chapter

Summary of changes

Chap 20−

no major technical changes in Chap 20, only editorial rework

Note
The exchange of data for S3000L is defined using XML and XML schema. S3000L
XML schemas are published separately on the S3000L website (www.s3000l.org).

Applicable to: All

DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

S3000L-A-00-00-0000-00A-00UA-A

2023-03-01 Page 12

S3000L-B6865-03000-00

Table 22 Terms, abbreviations and acronyms
Chapter

Summary of changes

Chap 21−

update of terms, abbreviations and acronyms according to the modifications
performed for all chapters

Table 23 Data element list
Chapter

Summary of changes

Chap 22−

update of data elements and data element descriptions according to the changes
established within Chap 19−

inclusion of a list of all classes defined in the respective UoF in Chap 19 and thecorresponding class definitions−

inclusion of a list which contains valid values for classification attributes

S3000L-A-00-00-0000-00A-00UA-A

Applicable to: All

End of data module
DMC-S3000L-A-00-00-0000-00A-00UA-A_004-00_EN-US.docx

2023-03-01 Page 13

S3000L-B6865-03000-00

Table of contents
The listed documents are included in issue 2.1, dated 2023-03-01, of this publication.
ChapterDocument title

Data module code

ApplicChap 1
Chap 2Chap 3Chap 4Introduction to the specification
General requirements
LSA process
Product structures and change
management in LSA
Influence on design
Human factors
Corrective maintenance analysis
Damage and special event analysis
Operational support analysis
Development of a preventive maintenanceprogramLevel of repair analysis
Task requirements and maintenance task
analysis
Software support analysis
Life cycle cost considerations
Obsolescence analysis
Disposal
In-service LSAInterrelations to other S-Series IPS
specifications
Data model
Data exchange
Terms, abbreviations and acronyms
Data element list

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

All
All
All
All

S3000L-A-05-00-0000-00A-040A-A
S3000L-A-06-00-0000-00A-040A-A
S3000L-A-07-00-0000-00A-040A-A
S3000L-A-08-00-0000-00A-040A-A
S3000L-A-09-00-0000-00A-040A-A
S3000L-A-10-00-0000-00A-040A-A

All
All
All
All
All
All

S3000L-A-11-00-0000-00A-040A-A
S3000L-A-12-00-0000-00A-040A-A

All
All

S3000L-A-13-00-0000-00A-040A-A
S3000L-A-14-00-0000-00A-040A-A
S3000L-A-15-00-0000-00A-040A-A
S3000L-A-16-00-0000-00A-040A-A
S3000L-A-17-00-0000-00A-040A-A
S3000L-A-18-00-0000-00A-040A-A

All
All
All
All
All
All

S3000L-A-19-00-0000-00A-040A-A
S3000L-A-20-00-0000-00A-040A-A
S3000L-A-21-00-0000-00A-040A-A
S3000L-A-22-00-0000-00A-040A-A

All
All
All
All

Chap 5Chap 6Chap 7Chap 8Chap 9Chap 10Chap 11
Chap 12Chap 13Chap 14Chap 15Chap 16Chap 17Chap 18
Chap 19
Chap 20
Chap 21Chap 22

S3000L-A-00-00-0000-00A-009A-A

Applicable to: All

End of data module
DMC-S3000L-A-00-00-0000-00A-009A-A_004-00_EN-US.docx

2023-03-01 Page 1

S3000L-B6865-03000-00

Chapter 1
Introduction to the specification
Table of contents

Page

Introduction to the specification ..................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Purpose ........................................................................................................................... 3
1.2
Background...................................................................................................................... 3
1.3
Scope ............................................................................................................................... 52
How to use the specification ............................................................................................ 6
2.1
General ............................................................................................................................ 6
2.2
Application ....................................................................................................................... 6
2.2.1
S3000L application policy ................................................................................................ 6
2.2.2
S3000L application .......................................................................................................... 7
2.2.3
Tailoring processes ......................................................................................................... 7
2.2.4
Compliance with S3000L ................................................................................................. 7
2.3
Basic definitions ............................................................................................................... 7
2.4
Integrated Logistics Support vs. Integrated Product Support .......................................... 7
3
Organization of the specification ..................................................................................... 7
3.1
Chapter 1 - Introduction to the specification .................................................................... 7
3.2
Chapter 2 - General requirements ................................................................................... 8
3.3
Chapter 3 - LSA process ................................................................................................. 8
3.4
Chapter 4 - Product structure and change management in LSA .................................... 8
3.5
Chapter 5 - Influence on design ...................................................................................... 8
3.6
Chapter 6 - Human factors .............................................................................................. 9
3.7
Chapter 7 - Corrective maintenance analysis ................................................................. 9
3.8
Chapter 8 - Damage and special event analysis ............................................................. 9
3.9
Chapter 9 - Operational support analysis ........................................................................ 9
3.10
Chapter 10 - Development of a preventive maintenance program ................................. 9
3.11
Chapter 11 - Level of repair analysis ............................................................................... 9
3.12
Chapter 12 - Task requirements and maintenance task analysis ................................. 10
3.13
Chapter 13 - Software support analysis ........................................................................ 10
3.14
Chapter 14 - Life cycle cost considerations ................................................................... 10
3.15
Chapter 15 - Obsolescence analysis ............................................................................. 10
3.16
Chapter 16 - Disposal .................................................................................................... 10
3.17
Chapter 17 - In-service LSA .......................................................................................... 10
3.18
Chapter 18 - Interrelation to other S-Series IPS specifications ..................................... 11
3.19
Chapter 19 - Data model ............................................................................................... 11
3.20
Chapter 20 - Data exchange ......................................................................................... 11
3.21
Chapter 21 - Terms, abbreviations and acronyms ........................................................ 11
3.22
Chapter 22 - Data element list ....................................................................................... 11
4
Maintenance of the specification ................................................................................... 12
4.1
General information ....................................................................................................... 12

List of tables
1
2

References ...................................................................................................................... 2
Participating companies/organizations .......................................................................... 4

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

List of figures
1

Functional elements of integrated logistics support ........................................................ 6

References
Table 1 References
Chap No./Document No.

Title

Chap 1Introduction to the specification

Chap 2

General requirements

Chap 3

LSA process

Chap 4

Product structures and change management in LSA

Chap 5

Influence on design

Chap 6

Human factors

Chap 7

Corrective maintenance analysis

Chap 8

Damage and special event analysis

Chap 9Operational support analysis

Chap 10Development of a preventive maintenance program

Chap 11

Level of repair analysis

Chap 12

Task requirements and maintenance task analysis

Chap 13

Software support analysis

Chap 14

Life cycle cost considerations

Chap 15

Obsolescence analysis

Chap 16

Disposal

Chap 17

In-service LSA

Chap 18

Interrelations to other S-Series IPS specifications

Chap 19

Data model

Chap 20

Data exchange

Chap 21

Terms, abbreviations and acronyms

Chap 22

Data element list

S1000DInternational specification for technical publications using acommon source database

S2000M

International specification for material management Integrated data processing

S4000PInternational specification for developing and continuously
improving preventive maintenanceApplicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

S5000F

International specification for in-service data feedback

S6000TInternational procedure specification for training analysis
and design

SX000iInternational specification for Integrated Product Support(IPS)

IPS-C-2020-010

Governance of the S-Series Specifications

DEF-STAN-00-60

Integrated Logistic Support - UK MoD

DEX1A&D

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

DEX3A&D

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

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

1

GeneralThis chapter gives a basic overview of the purpose of the S3000L specification, including its
development through the years.

1.1

Purpose
Logistics Support Analysis (LSA) is one of the most important processes of Product support.
It is the main tool for:−−designing Products relevant to maintainability, reliability, and testability activities, and to
optimize life cycle costdefining 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, defense, and commercial
Products.

1.2

BackgroundThe development of this specification originated within the Aerospace and Defence Industries
Association of Europe (ASD) in 2005. At that time, MIL-STD 1388-1A was no longer in force
and DEF STAN 00-60 had become too specific to UK-MoD acquisitions to be applied as aninternational handbook for general purposes.
The lack of a common valid procedure resulted in the development of various project specific
LSA handbooks and relevant IT solutions. These specific activities were also needed for new
projects (such as Eurofighter Typhoon, NH-90, Tiger, A400M, and Gripen). This caused
considerable effort for both industry and its military and non-military customers.
This situation prompted ASD and the Aerospace Industry Association of America (AIA) toconsider the joint development of a new common international specification for LSA.

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

This initiative started with an "Inaugural meeting on S3000L" held in Brussels on January 18,
2006. The attendees expressed their thoughts on the need for an international LSA specificationin the light of shortfalls in current standards, specifications, and handbooks. It emerged that itwas not a matter of shortfalls, but rather an overabundance of standards.
In March 2006, in Munich, the following basic requirements were identified during a meeting forthe project definition phase. The new LSA specification will:−−

be generally based on the processes laid out in MIL-STD-1388-1A, MIL-HDBK-502, DEFSTAN-00-60 and the activity model given by ISO 10303-239 PLCS
be the standard 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 mechanism to address the relevant data from MIL-STD-1388-2B for
LSA purposes.

use experience gained from the performance of LSA for current programs such asEurofighter Typhoon, NH-90, Tiger, A400M, Rafale, Gripen, JSF, etc
include process application guidelines and rules for information exchange
be tailorable to specific needs and include guidelines for tailoringtake into account current ISO/EN baseline documents
enable interfaces to the suite of the S-Series IPS specifications: S1000D, S2000M,
S4000P, S5000F and S6000T

An international team of experts, working under the joint supervision of AIA and ASD
representatives, contributed to the development of the specification. Table 2 shows thecompanies/organizations contributed to the initial phases of the activity.
Table 2 Participating companies/organizations
CompanyCountry

AgustaWestland

United Kingdom

Airbus Deutschland GmbHGermany

BoeingUnited States

Dassault Aviation

FranceEADS Casa

Spain

EADS Military Air Systems

Germany

Eurocopter

FranceLOGSA

United States

MBDA

FranceSaab AB

SwedenThe final draft of S3000L (Issue 0.1) was officially published in June 2009. The main purpose ofthis draft was to enable experts from interested companies and organizations to provide the
S3000L expert team with comments on the first approach. The commenting phase officiallyconcluded at the end of 2009. In this phase, experts from several nations contributed their input
to improve the final draft for the publication of the first official Issue 1.0.
Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

In June 2010, Issue 1.0 of S3000L was finally released and published. At the Farnborough Air
Show in July 2010, ASD and AIA signed a Memorandum of Understanding to form the ASD/AIA
Integrated Product Support (IPS) Council. The IPS community implemented a new platform toharmonize and coordinate the different IPS specification activities.
S3000L Issue 1.1 is the consequence of the constant review to maintain and improve thespecification and harmonize it with other specifications included in the S-Series IPS
Specifications. Additionally, XML schema became the new format for data exchange. In July
2014, S3000L Issue 1.1 was released and published together with the XML schemas.
S3000L Issue 2.0 is the consequence of various programs implementing S3000L and providing
feedback. Furthermore, there is an ongoing harmonization process with other specifications of
the S-Series IPS Specifications.

1.3

Scope
S3000L design covers all processes and requirements governing the performance of LSA
activities.
−
−
−
−
−

It provides rules for the usage of Product breakdown for Product support purposes and forthe selection of LSA candidate items
It describes the types and methods to perform specific analyses
It gives guidelines on how to process the results of the analyses and achieve a costeffective support solution
It covers the interface between LSA and the support engineering areas, for example
Reliability, Availability, Maintainability and Testability (RAMT)
It covers the interface between LSA and the IPS functional areas such as supply support,
technical data, special tools/test equipment (support equipment), and training. Refer to Fig
1.

In particular, S3000L describes the interaction between industry (contractor) and the customer
that, as per the existing agreements, will provide the typical deliverables of LSA as given in thisspecification. Examples of typical deliverables of an LSA process include, but are not limited to:−−−−a reliable and maintainable Product because of influence on design from a Product support
perspective
cost efficient support system
supportability product data
support concept in the context of identification and description of maintenance tasks(corrective and preventive) and operational support tasks

S1000D and S2000M specifications describe in detail activities related to technicaldocumentation and material management, respectively. These activities are therefore out of
S3000L scope. This also applies to methodologies on carrying out Preventive MaintenanceAnalysis (PMA) as described in S4000P or detailed performance of Level of Repair Analysis(LORA).

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

ICN-B6865-S3000L0001-003-01
Fig 1 Functional elements of integrated product support

2

How to use the specification

2.1

GeneralThis chapter gives an overview of:−−−

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

2.2

Application

2.2.1

S3000L application policy
S3000L will be the common LSA specification for customers and contractors (eg, governments,
procurement authorities, support agencies, and industry). Customers and contractors can agree
to integrate S3000L with additional international or national requirements for specific projects.
The use of the specification and any additional processes is the object of the agreement
between the customer and contractor.

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

2.2.2

S3000L application
At the start of any project using S3000L, it is necessary for the customer and contractor toagree on how the specification will be implemented, and to define and agree on the variables
and options that S3000L provides. The project’s LSA Guidance Document (LSA GD) must
contain these decisions. The customers and contractors use the LSA Guidance Conference(LSA GC) to determine the information to be included in the LSA GD. Refer to Chap 3.
It is necessary to define a project interchange agreement, for data and other deliverables, inorder to supplement the LSA GD. Based on the project complexity, the specification will either
be stand-alone, or integrated within the LSA GD.

2.2.3

Tailoring processes
In order to ensure efficient implementation, the S3000L design helps users select thefunctionality that is appropriate to their specific projects.
Individual chapters can be included or excluded. Tailoring can also determine the number andrange of LSA candidate items, the number of analyses per candidate item and the data usedduring an analysis.

2.2.4

Compliance with S3000L
ASD and AIA do not provide any type of validation that a software product, a training course, or
any other product is compliant with the S3000L specification. This is also valid for compliancewith the methodology of the proposed analysis processes.

2.3

Basic definitions

2.4

Product

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

Product variant

A member of a Product family that is configured for a specificpurpose and is offered to customers. The Product Variant is
uniquely identified by the Model Identifier. The term “Product
Variant” is synonymous with “model.”Project

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

Integrated Logistics Support vs. Integrated ProductSupportIn the context of product support, these terms are treated like synonyms. On the other hand,"logistic" is often used in the context of the transportation business. Beginning in this issue ofthe S3000L specification, the term Integrated Product Support (IPS) will be used to avoid
confusion.
Note
The official name for the processes and analyses commonly known as Logistics Support
Analysis will continue to be known as LSA.

3

Organization of the specification
S3000L is organized into chapters, each dealing with individual aspects of LSA.

3.1

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

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

3.2

Chapter 2 - General requirements
Chap 2 provides general information on how to set up and manage an LSA program as part ofan IPS and overall development program. It describes the interfaces, dependencies, and time
constraints in relation to the other IPS disciplines within a typical project scenario.

3.3

Chapter 3 - LSA process
Chap 3 is designed to provide a full, in-depth description of the complete LSA process. It covers
the activities beginning at the definition of the operational framework to the starting point of thecreation of IPS element deliverables (refer to SX000i). The operational framework andcontractual requirements provide input for the LSA GD, which establishes the binding businessrules for the LSA process. This includes establishing a Product breakdown method, rules for
LSA candidate selection, and tailoring the specification to the specific project needs.
The chapter further describes potential supportability analysis activities and documentation ofanalysis results within LSA data. Finally, it covers aspects concerning customer involvement
during the LSA process and LSA review conference organization. This is the final step in
accepting the LSA results and determining the maintenance and operational support concept.
The acceptance of the LSA results can be regarded as a precondition to start the production of
IPS element deliverables.

3.4

Chapter 4 - Product structure and change management in
LSA
The generation of a Product breakdown is an essential activity of the LSA process. An
appropriate Product breakdown ensures proper identification and versioning of the Productconfiguration throughout the Product life cycle. The chapter describes the different sources,
methods, and criteria used to generate a Product breakdown.
It is also essential to control changes, analyze the impact on LSA, and record theimplementation of changes in the Product physical and functional characteristics. Change
management allows updating LSA for different Product baselines throughout the Product life
cycle as consequence of different sources of Product configuration change (eg, triggered bydesign, technology, obsolescence, etc).
LSA plays an active role in the Product configuration management process to perform these
activities as part of the LSA process, generation of a Product breakdown, and change
management. This process records, communicates, and controls integrity and continuity ofdesign, systems engineering, and supportability. Configuration management efforts provide acomplete audit traceability of decisions and design modifications.
Chap 4 defines the details and methodology to apply the principles of Product breakdown
generation and change management to the LSA process as part of the configuration
management.

3.5

Chapter 5 - Influence on design
Influence on design is the goal of an industrial activity known as supportability engineering.
Supportability engineering influences Product characteristics vital for Product operationaccording to performance and design requirements, with a view to minimizing Life Cycle Cost
(LCC).
The Product characteristics to be influenced are primarily RAMT. Early RAMT
activities/programs and the performance of LSA serve as tools for supportability engineering.
Design reviews are also encouraged after the Product entry into service, to improve the Productbased on operational experience and an effective sustainment of a competitive Product. During
the in-service phase of a Product, in-service data feedback provides a basis for measuring andanalyzing the RAMT and LCC performance of the design.
Supportability engineering acts as the enabler between design/development and IPS.

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

Chap 5 describes how the methods of supportability engineering are applied and how theresults are linked to the LSA process.

3.6

Chapter 6 - Human factors
Chap 6 describes the relationship and integration between human factors engineering and the
support analysis process. Like all other supportability engineering functions, human factors
analysis provides source data used by the support analysis team to determine maintenancecrew and support equipment requirements. This relationship begins in the design review
process and continues through the development of the Maintenance Task Analysis (MTA).

3.7

Chapter 7 - Corrective maintenance analysis
Chap 7 covers the methodology and decision logic applied to identify corrective maintenancetask requirements, as well as the diagnosis procedure in case of Product failure during normal
use. The scope includes corrective maintenance to be carried out on the Product to restore its
availability as well as corrective maintenance of equipment removed from the Product in aworkshop.

3.8

Chapter 8 - Damage and special event analysis
Chap 8 covers the methodology for identifying and justifying appropriate maintenance tasks incase of special events or damages found on the Product during general or detailed inspections.

3.9

Chapter 9 - Operational support analysis
Chap 9 covers the methodology for identifying and justifying tasks related to Product operationand operational support that cannot be performed in the areas where the Product is directly
used (documented in operating instructions) or maintained (documented in a maintenancemanual). However, they are performed in operations and maintenance facilities in support ofnormal operation (eg, packaging, handling, storage, mooring, preparation for transportation).
These tasks can be important for the proper use of any Product. There are many operational
aspects (eg, ease of operation, usability, flexibility of usage, mobility) restricted by operational
support tasks.

3.10

Chapter 10 - Development of a preventive maintenanceprogram
Chap 10 describes how to handle Preventive Maintenance Task Requirements Interval (PMTRI)
identified and determined by Preventive Maintenance Analysis (PMA) activities (refer toS4000P). Preventive maintenance is vital to the operation of Products. After identifying all
PMTRI, the development of a preventive maintenance program is required, which results inpreventive maintenance task packages performed at a specific time limit or interval.
The chapter further describes how to link corresponding preventive maintenance tasks to the
PMTRI and to group the PMTRI/tasks based on appropriate time limits (eg, intervals based on
Product usage). For this purpose, a series of rules indicates how to adapt PMTRI by extendingor reducing the single PMTRI time limits during the grouping process.

3.11

Chapter 11 - Level of repair analysis
Chap 11 describes Level of Repair Analysis (LORA) activities performed as part of any
acquisition program. An LSA plan or similar documents, usually include a request for LORA.
LORA is an analytical methodology performed on a list of selected LSA candidates. It takes into
consideration customers’ support capabilities and support/operational requirements, producttechnical information, costs, legal and environmental constraints to determine an optimized
support solution. The outcome is the definition of where each selected candidate is for example
removed, replaced, repaired, checked, overhauled, inspected, or discarded.

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

3.12

Chapter 12 - Task requirements and maintenance task
analysis
Chap 12 covers two main aspects of the LSA process. One aspect explains how to combine atask requirement with the corresponding maintenance (corrective and preventive) or operational
support task. The other main aspect analyzes the identified corrective maintenance, preventive
maintenance, and operational support tasks in terms of task execution and required resources
like spare parts, consumables, support equipment, personnel, facilities and infrastructure.
Finally, additional information for tasks is included in the LSA data. Such information also
includes preferred maintenance level, task duration, training requirements and criticalities withrespect to personnel.

3.13

Chapter 13 - Software support analysis
Chap 13 provides guidelines on how to handle the requirements concerning software in thecontext of Product operation and maintenance. Today, software is an essential element ofnearly all Products. The chapter describes the typical task requirements for software, as well as
the relevant maintenance or operational support tasks. In this context, a clear differentiation ismade between maintenance or operational support tasks relevant to the software, and software
modification activities (eg, bug fixing).

3.14

Chapter 14 - Life cycle cost considerations
LCC includes all direct costs and any indirect-variable cost associated with the procurement,
operation, support, and disposal of the Product throughout its life cycle.
Chap 14 provides an overview of LCC aspects and indicates which information developed by an
LSA process can be used to support LCC analysis activities, and vice versa.

3.15

Chapter 15 - Obsolescence analysis
Chap 15 describes the relationship between obsolescence analysis and the support analysis
process.
In the design and development process, LSA is aimed at avoiding/controlling the use ofcomponents and material that are likely to be subject to obsolescence in the early operational
phase. During the in-service phase, the analysis of obsolescence events will also include LSA,
which will lead to the definition of economic alternatives with respect to maintenance andsupport plans.

3.16

Chapter 16 - Disposal
Chap 16 deals with the disposal of Products and Product components, as a result of their active
and/or passive use. Although disposal of Products normally occurs during the last phase of thelife cycle, when acquiring a Product, it is necessary to take into consideration disposal in theearly phases of every program plan.
Adequate disposal activities can include, but not be limited to:
−
−
−
−

3.17

professional disposal of equipment/components, structural parts or consumables
destruction/neutralization of toxic substances
recycling to ensure a sustainable development
demilitarization of defense systems, to avoid weapons proliferation

Chapter 17 - In-service LSA
Chap 17 gives an overview of LSA activities recommended for the in-service phase of a
Product. This chapter covers the regular update of LSA data and corresponding IPS elements
as a consequence of changes in engineering design, and of usage and/or support scenarios on
the operator’s side. It also covers the In-Service Support Optimization (ISSO) process. This
process provides a methodology to optimize maintenance and operational support tasks
continuously based on the operator’s feedback. Feedback information/data from the ProductApplicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

user provides the opportunity to compare assumptions based on analysis activities to the actual
in-service experience/data. Additionally, analysis and solving problems, which occurred during
maintenance or operational support is facilitated.
To ensure continuous maintainability and operability, it is necessary to scrutinize themaintenance and operational support concept repeatedly during the Product life cycle.

3.18

Chapter 18 - Interrelation to other S-Series IPS specifications
Chap 18 addresses the benefits of using the S-Series IPS-specifications in conjunction with thisspecification. The chapter addresses LSA relationships to the following specifications:
−
−
−
−
−
−

3.19

SX000i - International specification for Integrated Product Support (IPS) specifications
S1000D - International specification for technical publications using a common source
database
S2000M - International specification for material management - Integrated data processing
S4000P - International specification for developing and continuously improving preventive
maintenance
S5000F - International specification for in-service data feedback
S6000T - International specification for training analysis and design

Chapter 19 - Data model
Chap 19 defines a coherent UML data model supporting the S3000L LSA process and its
interaction with the related business processes. These processes can depend on data derived
from LSA or from business processes that provide input to the LSA process. Additionally, thechapter defines all data elements used in the S3000L data model.

3.20

Chapter 20 - Data exchange
Chap 20 defines the standard technology used for the exchange of data that results from LSA
activities as defined in S3000L. The exchange of data for S3000L is defined using XML andXML schema.

3.21

Chapter 21 - Terms, abbreviations and acronyms
Chap 21 provides a glossary of terms, abbreviations, and acronyms used within S3000L. It
contains two different lists with items in alphabetical order:

3.22

−

Glossary of terms
A comprehensive list of terms used in this specification−

Abbreviations and acronyms
Definitions of abbreviations and acronyms used in this specification

Chapter 22 - Data element list
Chap 22 lists all of the data elements used in the S3000L data model and in the S3000L dataexchange specifications.
Data elements are listed alphabetically by name. The list contains:
−
−
−
−
−

Data element name
Data element data type
Data element definition, including a textual definition and a list of valid values
Class name identifies all classes of the S3000L data model where the data element is used
Unit of Functionality identifies all Units of Functionality (UoF) of the S3000L data model
where the data element is used

Applicable to: All

S3000L-A-01-00-0000-00A-040A-A
Chap 1DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

4

Maintenance of the specification

4.1

General information
S3000L is maintained by the S3000L Steering Committee (SC) operating under the supervisionof the IPS Council. Both the S3000L SC and the IPS Council include representatives from AIA
and ASD member companies and nations.
Technical issues related to S3000L can be raised using the change request application locatedat www.sx000i.org.
Technical issues can, in due course, become a Change Proposal (CP), both of which should besubmitted with the understanding that any revisions to S3000L can affect one or more of theother S-Series IPS specifications, and that proposed changes are subject to international
agreement from AIA and ASD member companies and nations.
Upon receipt of a CP, the S3000L SC will follow the change management process described in
IPS-C-2020-010, that includes obtaining an agreement from the participating organizations prior
to the publication of changes. The S3000L SC considers CP at each meeting and ratifies themfor incorporation in the specification or otherwise. The S3000L SC also decides when changes
will be published in S3000L.

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

Applicable to: All

End of data module
DMC-S3000L-A-01-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 12021-04-30 Page 12

S3000L-B6865-03000-00

Chapter 2
General requirements
Table of contents

Page

General requirements .................................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 32
LSA program.................................................................................................................... 3
2.1
LSA program plan ............................................................................................................ 3
2.1.1
Organizational requirements ........................................................................................... 3
2.1.2
General requirements ...................................................................................................... 4
2.1.3
Functional requirements identification ............................................................................. 5
2.1.4
Unique functional requirements ....................................................................................... 6
2.1.5
LSA program plan - generic example .............................................................................. 6
2.1.6
LSA guidance document - generic example .................................................................... 8
2.2
LSA program organization ............................................................................................. 11
2.3
LSA management responsibilities ................................................................................. 11
2.3.1
The LSA manager.......................................................................................................... 11
2.3.2
Program LSA managers and leads ............................................................................... 12
2.3.3
Program technical staff (system engineers and analysts) ............................................. 12
2.3.4
Supportability analysis integrated product team ............................................................ 12
3
Product development organization ................................................................................ 13
3.1
Integrated product teams ............................................................................................... 13
3.2
Multidisciplinary teams .................................................................................................. 13
3.3
Single point accountability ............................................................................................. 14
3.4
Empowerment................................................................................................................ 14
3.5Management plans ........................................................................................................ 14
3.6
Clear product definition and interfaces .......................................................................... 14
3.7
Disciplined processes .................................................................................................... 14
3.8
Effective communications .............................................................................................. 14
3.9
Performance metrics ..................................................................................................... 15
3.10
Implementation .............................................................................................................. 15
3.10.1 LSA activities and performance ..................................................................................... 15
3.10.2 Develop an early LSA strategy ...................................................................................... 16
3.11
Program management principles ................................................................................... 16
3.11.1 Integrated product support management ...................................................................... 17
3.11.2 Operating product support organizational structures .................................................... 17
3.11.3 Formal support organizations ........................................................................................ 17
3.12
Product support management objectives and policies .................................................. 17
3.12.1 Product support ............................................................................................................. 17
3.12.2 Product support management policies .......................................................................... 18
4
Associated parts of the S3000L data model .................................................................. 18

List of tables
1

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

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

List of figures
1
2
3

Example of content of an LSA PP ................................................................................... 6
Example of content of an LSA GD ................................................................................... 9
Simplified LSA process .................................................................................................. 16

References
Table 1 References
Chap No./Document No.

Title

Chap 10Development of a preventive maintenance program

Chap 19

Data model

Chap 20

Data exchange

MIL-STD 1388-2B

DoD requirements for a logistic support analysis record

GEIA-STD-0007

Logistics Product Data

1

General1.1

Introduction
The Logistics Support Analysis (LSA) process is considered a subset of Integrated ProductSupport (IPS). IPS has overall responsibility for the development of technical information andthe support environment used to support a Product throughout its intended life cycle. It isnecessary to harmonize the different disciplines in the context of supportability. The main
disciplines are:
−
−
−
−
−
−
−
−
−
−
−
−

design influence
product support management
supply support
support and test equipment
technical data/technical publication
personnel and manpower
IT/software support
facilities and infrastructure
maintenance planningpreventive maintenance program
Packaging, Handling, Storage and Transportation (PHST)
training and training devices

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

to link product design and IPS requirements to product readiness thresholds and to define
detailed support element requirements
throughout the acquisition cycle to assess and alter product design and to establish andupdate support element requirements
as an important source of design-related data for determining and integrating all
supportability requirements, analyzing alternative design, operational, and support
concepts, and conducting trade-offs between design and the various elements of Productsupport of technical data for IPS planning and resource decision

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

The supportability analysis results and support resource data will be stored in a database togive all program elements access to a common data source for evaluating the supportability ofdesign alternatives and objectives. The Integrated Product Team (IPT) will ensure the timely
interaction of the LSA activities and data for all elements of the design process.

1.2

Purpose
IPS, supported by an embedded LSA process, ensures there is an open exchange of
information to the product support disciplines and to the design. It pursues two major goals
simultaneously:

1.3−

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

−

Design of support
The design, development, funding, testing, and acquisition of all support resources needed
to ensure optimum performance and readiness of the Product in its intended operational
environment and usage/mission profiles.

Scope
This chapter is directed at IPS managers and LSA managers both for customers and forcontractors. It is important to understand how an LSA program needs to be integrated into thesuperordinate IPS program. The approach for implementing an LSA program varies acrossorganizations, and sometimes even across projects within an organization. Regardless of theorganization or project, there must be shared policies that establish the functional
responsibilities and expectations of the LSA program.

2

LSA program
LSA is a systematic, iterative process that integrates product design and support system
requirements, and evaluates supportability requirements relative to satisfying the specificsystem/component sustainability and availability requirements. The use of an electronic
database optimizes the analysis documentation process. Information on supportability consistsin the identification, optimization, and traceability of IPS resources (eg, spares, manpower,
personnel, support and test equipment, training and training equipment, facilities, PHST, andtechnical publication).

2.1

LSA program plan

2.1.1

Organizational requirements
The LSA Program Plan (LSA PP) describes the strategy for developing LSA activities during theengineering and manufacturing development phase of the complete program. It identifies andintegrates the LSA activities, identifies management responsibilities and activities, andestablishes the approach for analysis activities. Furthermore, this plan provides the approach to
LSA and a basis to measure progress throughout the various phases of the program. Since the
LSA process is iterative and dynamic, 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 perform
this process. It details how the LSA process will take place to satisfy the intended requirements.
LSA is an iterative process that usually continues as long as the item under analysis is incontinuous use. Once the item has been retired, the LSA data can be used as baselinecomparison data for future supported items.
The LSA PP describes the management, organizations, and procedures required to accomplish
program requirements. It includes:−a description, correlation, and schedule of procedures to be accomplished by eachorganizational element concerned in support of the LSA program

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

−
−
−
−
−
−
−

an indication of requirements for LSA program participants (eg, subcontractors, suppliers,
partner companies, agencies)
the identification of LSA program monitoring points
the dissemination of LSA requirements to design and description of techniques to be
employed to ensure that desired LSA is inherent in the Product design
a description of the planned approach for LSA activities, and specific methods and sources
to satisfy qualitative supportability analysis and resolve design issues
a description of numbering systems for database, Work Breakdown Structure (WBS),
breakdown element identification, and handling methods for government furnishedinformationa description of methods to identify, control, and report problems
a description of provisions for plan update

Systems engineering managers are responsible for LSA planning and coordination. LSA
managers provide technical guidance in conducting LSA and have special analytical skills
required to perform activities specific to LSA. Procedures must ensure the identification of
supportability requirements as an integral part of systems engineering and design.
Supportability design baselines identify:−

quantified reliability and maintainability comparative analysis requirements, such as:
•
•
•

−

the maintenance concept, including:
•
•
•
•

−
−
−
−

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

justification for any support activity (events and operational requirements)
preventive and corrective maintenance activities
operational support activities
maintenance level and maintenance location information

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 IPS management plan or IPS program plan.
It is recommended to have a separate document in case of more complex projects. Customers
and contractors must agree and harmonize many other aspects during an LSA Guidance
Conference (LSA GC).
2.1.2

General requirements
The information in the LSA PP includes, but is not limited to, the following elements: Moreover,
the range and depth of information for each element is tailored to the project phases.
−
−
−
−
−

a description of how the LSA program will be conducted to meet the system andsupportability requirements defined in the applicable project documents
a description of management structure and authorities applicable to LSA. This includes thecorrelation between line, service, staff, and policy organizations.
the identification of each LSA task and how it will be performed
a schedule with estimated start and completion points for each LSA program activity or task.
It is necessary to identify scheduled relationships with other IPS program requirements andassociated system engineering activities.
a description of how LSA activities and data will interface with other IPS and systemoriented tasks and data. This description will include analysis and data interfaces with thefollowing programs, as applicable:•

Product design

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
−

−
−
−
−
−
−
−
−
−

Product maintainability
Product reliability
Product testability
facilities and infrastructure
Human Factors Integration (HFI)
Initial Provisioning (IP)PHST
parts control
standardization
support and test equipment
survivability
system safety
technical documentation
test and evaluation
training and training equipmenta breakdown structure identification of items, including software, which are the object of
LSA performance (LSA candidates) and documentation. Identification of an LSA Candidate
Item List (CIL), and criteria for LSA candidate item selection. The list must include all items
recommended for analysis, items which are not recommended, and the appropriate
rationale for selection or non-selection.
an explanation of the breakdown element numbering system
the method of dissemination of supportability and supportability-related design requirements
to designers and associated personnel
the method of dissemination of supportability and supportability-related design requirements
to subcontractors and the relevant controls under such circumstances
government data to be furnished to the contractor
the procedures for updating and validating LSA data to include configuration control
procedures for LSA data
LSA requirements on Government Furnished Equipment/Materiel (GFE) andsubcontractor/vendor furnished materiel, including end items of support equipment
the procedures to evaluate the status and control of each task, and to identify 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, required corrective activity, and the status of actions
taken to solve the problems
a description of the data collection system used by the contractor to document, disseminate
and control LSA and related design data

Note
The range and depth of information for each element is tailored to the project phases.
2.1.3

Functional requirements identification
This activity identifies the required operations and support functions for the Product. The
primary inputs are the results of supportability and supportability-related design factors, as well
as results of reliability, maintainability and testability programs and analyses. The results of thistask form the basis for support system alternatives. LSA personnel will revise functional block
diagrams as applicable, identifying subsystem component changes and their functional
interaction within the subsystem and with associated subsystem components. To do so, theLSA personnel must cooperate and interact with design engineering, maintainability, testability,
human engineering, and technical manuals. LSA personnel will then evaluate and identify
operations and maintenance actions required to implement the maintenance and operational
concept for LSA candidates.
The functional requirements for Product maintenance and operation include:−

inspection

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

−
−
−
−
−
−
2.1.4

servicingtesting
operation
repairreplaceconfiguration for specific usage

Unique functional requirements
The same process used to identify maintenance and operations functions will identify any
unique functional requirement. These unique functional requirements are normally associatedwith new technologies and equipment incorporated in the Product or its support system. The
process will also consider hazardous materials, hazardous waste, and environmental pollutants.
Although the same analysis techniques are used to identify and evaluate these uniquefunctions, it is necessary to pay special attention to them because they have a tendency to
exhibit higher risks. The product support organization will track configuration changes, andidentify and evaluate their impact on identified unique functional requirements.

2.1.5

LSA program plan - generic example
The LSA PP is a crucial output document of the LSA GC. It contains general sections anddescriptive subsections, followed by appendices. The general section must cover at least the:
−
−
−
−
−
−
−

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

Fig 1 shows a simplified and generic example of the structure of an LSA PP:

ICN-B6865-S3000L0006-002-01
Fig 1 Example of content of an LSA PP

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

The LSA PP appendices will provide additional clarification and specific needs, which support
the content in the subsections. It is possible to cover risk management issues in a separate
appendix or include it into the rules for performance measuring and verification.
2.1.5.1

Purpose of LSA and supportability analysis activities
As an outcome of the LSA GC, the contractor and customer must agree on the principles of use
for data coming from supportability analyses. Therefore, it is strongly recommended to carefully
select which data elements will be documented and then link the data to their corresponding
purpose. This also applies to supportability analysis activities. The selection must consider
technical and economic aspects, especially for very extensive analysis activities, for example:−−−

2.1.5.2

a detailed or simplified LORA
optimization methods, such as via simulation runs
a detailed Preventive Maintenance Analysis (PMA)

Hierarchical Product breakdown methodology
This appendix to the LSA PP must detail the rules for a Product breakdown methodology. The
customer and the contractor must decide how to identify breakdown elements, for example,
using the S1000D Standard Numbering System (SNS), Logistics Support Analysis Control
Number (LCN) in accordance with MIL-STD 1388-2B or GEIA-STD-0007, or any otheridentification system preferred by the customer.
In case of different Product breakdown methodologies (eg, physical and functional) within aprogram carried out in parallel, it is necessary to clarify whether and how to interconnect thesedifferent Product breakdowns. Additionally, it is necessary to document the purpose of its use(eg, a functional breakdown).
Note
It is recommended that detailed examples be included in the appendix, covering all possible
cases (eg, how software will be incorporated within the hierarchical breakdown, how tocover different variants of a Product). In case of complex projects, a separate document
can be used to determine Product breakdown structure and coding/numbering method forthe corresponding Breakdown Element Identifier (BEI).

2.1.5.3

Breakdown depth for the item under analysis
In addition to the decisions required for the types of Product breakdown, the breakdown depth isa 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 Line Replaceable Units (LRU) applicable and effective?
What depth of breakdown is required to identify all spare parts for a repair concept at theauthorized level?
For what purpose a functional breakdown is established (eg, for PMA) and how is thefunctional breakdown linked to the physical breakdown?

2.1.5.4

LSA candidate selection criteria
The criteria for LSA candidate selection must be documented in an appendix of the LSA PP.
The appendix can also include a decision flowchart.

2.1.5.5

Candidate item list
As an input to the LSA GC, the contractor must prepare a draft of the CIL, as an input
document. During the LSA GC, the contractor and the customer must discuss this draft toproduce an agreed CIL. The CIL will be a formal output document of the LSA GC.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Note
For the LSA GC, a completed CIL is often not available. The CIL is a living object during thedesign and development phase (and also later during in-service phase) and must becontinuously updated as required (eg, by design changes). As a minimum, LSA candidate
selection criteria must be determined at the LSA GC.
2.1.5.6

Potential analysis activities for candidate items
The CIL contains the selection of LSA candidates from the Product breakdown and can also
contain the analysis activities for each LSA candidate. It is necessary to clarify the selection ofanalysis activities, as well as the depth of the analysis. For example, Maintenance Task
Analysis (MTA) must determine whether the description of the maintenance task must be
detailed in full or in Simplified Technical English (STE), or whether to include personnel
requirements for the project.
Finally, the CIL can serve as an LSA program overview that summarizes the complete effort.
Additionally, the CIL can be a helpful management tool, documenting the progress of the LSA
program.
Note
It is necessary to generate a drafted CIL as a final output from the LSA GC. It is
recommended that this list be designated as a reference table and part of the projects
master data to be shared and synchronized across the project’s master data management
system. It can serve as a monitoring tool to supervise the progress of the project. This will
avoid duplicating data, such as breakdown information, in external lists that are notsynchronized to master data.

2.1.5.7

Performance measurement and verification of LSA activities
It is necessary to evaluate the performance of LSA activities continuously, and document it, forexample, by status information. The criteria, when an analysis activity is fulfilled or when an LSA
candidate must be clear and documented in a list of acceptance criteria that are part of an
appendix within the LSA Guidance Document (LSA GD). The process and the rules for
performance measurement and verification must be clear. Customers and contractors mustobserve these rules for each review/delivery of any analysis result.

2.1.5.8

IT aspects
It is recommended that the use of different software packages for the same analysis activities atdifferent locations is avoided. Integration and harmonization processes can be extensive andare a potential risk factor. However, many programs currently use different software packages
because of existing licenses, contractual constraints, or IT environment necessities. For any
task to be performed, in this case, it is recommended to establish a common working
environment which can be used by all LSA program stakeholders, or, as a minimum, use one
common suitable software package compatible with the IT systems of all parties involved.
LSA GC must indicate the decisions about software packages. All involved parties must
harmonize and agree to any change to software releases during a program.

2.1.6

LSA guidance document - generic example
The LSA GD is another crucial output document of the LSA GC. It contains the business rulesof the LSA process on reporting, data element definitions, data exchange procedures, andselection of software packages to perform analysis activities.
Fig 2 provides an example of content for an LSA GD.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

ICN-B6865-S3000L0007-002-01
Fig 2 Example of content of an LSA GD
The LSA GD includes a general section and a number of appendices. In the general section,business rules definition covers at least:−

Data Element List (DEL). This is a list of all the required data that must be recorded.

−

Reporting process and definition of required reports. It is necessary to define andformat all report content. Any data elements required for the reports must be available andaccessible. All contracting parties must agree on content, format, and derived calculations.
Any business rules necessary to calculate and/or select source data must be identified anddocumented.

−

Data exchange process. For a proper exchange of information, the customer and thecontractor must establish and harmonize a data exchange process. In programs involving
several customers and contractors, a clear process for data integration and harmonizationmust be established. A time schedule must be agreed to during the LSA GC, withclarification on the consequences of missing the time schedule.
Note
Chap 20 provides information about recommended data exchange format (XMLschema).
Note
The LSA GD can also cover additional aspects like the detailed explanation of the
Product breakdown methodology or the detailed description how to document theresults of the MTA (including LORA methodology and LORA decision). It is
recommended to include appropriate examples.

2.1.6.1

Data element list and input instructions
The detailed DEL describes the context and description of the collected data. This includes
syntax (if required) and allowed codification. In addition, a mathematical appendix can detailcalculation methods of numeric values.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

It is recommended that a simple draft DEL is created as an input to the LSA GC, to support theinitial selection of data elements. The justification for the project's LSA DEL selection is basedon the following questions:
−
−
−
−
−
−
−

Is the data element required for the proof of any specification values?
Is the data element required for the calculation of any supportability parameters?
Is the data element required for disciplines such as technical publication, material support,
identification of special support equipment, and identification of facilities or training
requirements?
Is the data element required for the performance proof of the LSA itself?
Is the data element required to document the results of supportability 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)?
Note
It is recommended that data elements are selected, based on a logical, traceable needfor project requirements. Any listed data element that does not relate to a requirement
or the development (calculation) of a requirement is a candidate for elimination.

The DEL must be arranged during the LSA GC and will be a part of the official LSA GD.
Nevertheless, it must be considered a living document. Updates to the DEL occur due toadditional needs that arise during program maturation (eg, matured project design as indicatedby contractor and customer).
2.1.6.2

List of selected software packages
In the LSA GC, the decision must be made, or at least prepared, as to which LSA software
packages will be used by the contractor and the customer to support the required analysis
activities. The selection of software packages can be contractual. It is necessary to investigate
carefully any upgrade or complete change of software packages within the project, including all
participants involved with such changes in the IT department.

2.1.6.3

Examples for documentation of task requirements
The LSA GD can include examples to ensure the correct documentation of different types oftask requirements which justify the corresponding task. This can cover corrective and preventive
maintenance task requirements, operational task requirements, and task requirements fromother sources (eg, initiated by authorities, customer needs, regulations by law).

2.1.6.4

Examples for MTA documentation
The LSA GD can include examples to ensure the correct documentation of tasks. This can
include the correct usage of subtasks by definition and subtasks by reference, correct
assignment of warnings, cautions and notes and the correct assignment of task resources ontask or subtask level, as required and appropriate.

2.1.6.5

Reports examples
The LSA GD can include examples to ensure a common understanding of reporting. Those
examples can include an overview of required data elements, report formatting, sorting, fillingand calculations for each relevant report provided by the LSA program.

2.1.6.6

Mathematical appendix
It is possible to document methods of calculation to complete the business rules. Both thecustomer and the contractor must evaluate the calculation of values, which must be available
for review to the stakeholders. Mathematical appendices cover two basic aspects:−−

Mathematical equations and their explanations, including a list of mathematicalabbreviations and symbols used
Sources and business rule logic from which the data is obtained for calculation

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

2.2

LSA program organization
The program manager is the final authority for the implementation of the LSA program
integrated into the Product development organization. LSA is part of the system engineering
integration. LSA is an integral element in the IPT commitment to provide 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, which are to:−−−perform the functional analysis and allocation, and providing them to the IPT
provide Product and process solutions that meet the supportability requirements
provide system analysis and control activities through the system engineering process

IPT leaders are responsible for completing the LSA program on their Product.
The IPS manager is responsible for monitoring LSA activities performed by all teams, ensuringconsistency across the program and for delivery of LSA data submittals (if required). The
program manager has final authority for all program functions. Supportability is an active
member of the IPT. The objective of these teams is to develop guidance on system design tomeet performance, producibility, and supportability requirements, and achieve low Life Cycle
Costs (LCC).

2.3

LSA management responsibilities
An overview of the potential responsibilities of the different players in the LSA process, is given
in Para 2.3.1 through Para 2.3.4.

2.3.1

The LSA manager
The typical responsibilities of LSA managers can include, but are not limited to:
−
−
−
−
−
−
−
−
−
−
−
−
−
−

implementing established company operating policies and procedures concerning LSA
accomplishing quality reviews of LSA data through in-process reviews and formal reviews
prior to data submittal
addressing questions and coordinating required corrective activity for the development,
implementation, and modification of integrated maintenance concepts, support resources
and related problems/statusassessing subsystem design and support concepts for supportability influence/impact for
their assigned subsystems
assisting in the resolution of problems related to the acquisition of supplier/customerfurnished supportability data that are necessary to support the assigned subsystems
assisting in the development and implementation of formal LSA review activities for theirrespective system, to ensure integration of maintenance concepts and compatibility with
contractor and customer requirements
conducting LSA reviews with the customer
coordinating evaluation of design changes for LSA impacts and ensuring impacts arereported to decision makers in case design changes will have an adverse impact on easeand cost of support
coordinating with appropriate program and functional management to ensure problems on
their assigned subsystems are solved
documenting supportability task analyses and coordinate task scheduling and planningmaintaining technical liaison with design/supportability engineering and IPS elements
managing the technical aspects of the LSA process, and the documentation for
considerations on design and identification of supportability resources
monitoring/coordinating the technical aspects of LSA relative to established program
objectives, schedules, and directives
participating in customer and supplier design and program reviews, and ensuring LSA is anagenda topic as appropriate

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
2.3.2

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

2.3.3

ensuring LSA program requirements are being met
implementing established company operating policies and procedures
controlling program costs and maintaining program schedulemaintaining a regular contact with team members, subcontractors and/or vendors
maintaining a program interface with program management and the customer
holding technical responsibility for the accuracy of the LSA

Program technical staff (system engineers and analysts)
The technical staff is responsible for the proper operation of the IT systems. This includes theevaluation and provisioning of Product support data for other IPS disciplines or for management
purposes, such as:
−
−
−
−

2.3.4

participating in technical coordination meetings and design reviews with suppliers and/or thecustomer, ensuring that each review include a formal review and assessment of
supportability and related design requirements
providing assistance and information to program and functional management to achieve
contractor and customer objectives
scheduling LSA in accordance with engineering documentation release dates/support.
tracking supportability task accomplishment and participating in problem solving
establishing company LSA operating policies and procedures
supporting the organization of a program statement of work, and approving man-hour
estimates for all LSA activity
supporting the assignment of personnel to programs and projects, as required for the LSA
statement of work
monitoring and assisting LSA program managers/leads in the performance of program
statements of work
establishing training requirements for LSA personnel and supportability-related tasks

having responsibility for the performance of data analysis
operating data collection software and generate reports
managing supplier and customer interfaces for data collection
having working relationships with engineering departments, all IPS elements, suppliers, andcustomer

Supportability analysis integrated product teamThis team participates in the development of an early LSA strategy, including, but not limited to:
−
−
−
−
−
−
−
−
−
−
−
−

developing the LSA PP
participating in program and design reviews
coordinating the operational requirements
coordinating the requirements for mission hardware, software, and support systemstandardization
participating in developing the requirements for comparative analysis
coordinating the requirements for technological opportunities
coordinating the requirements for supportability and supportability-related design factors
performing PMA and/or processing PMA results (eg, packaging of preventive maintenancetasks, refer to Chap 10)
participating in the development of support system alternatives
participating in the evaluation of alternatives and trade-off analyses
coordinating inputs from maintainability and packaging, and develop maintenance task
analysiscoordinating the requirements for early fielding analysis

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00−−

3

coordinating the requirements for post-production support analysis
coordinating the requirements for supportability test, evaluation, and verification

Product development organization
The Product development 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. This approach aims to induce the developer to consider all elements of the productlife cycle, from conception through disposal, including cost, schedule, performance,
supportability, quality and user requirements as soon as possible.
Integrating product development during design will help achieve first-time quality. Moreover,
improved compliance with requirements will:−−−

support completing the program within target costmeet affordability requirements through design for producibility and concurrent
manufacturing process improvements
reduce operational and support costs through design-to-supportability, with emphasis on
reliability, testability, maintainability and life cycle cost

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

3.1

IPT
clear product definition and interfaces
multidisciplinary teams (integrated teams)
disciplined processes
single point accountability
effective communications
empowerment
performance metrics

Integrated product teams
A product team owns each of the product items in the entire system, including supplier andcustomer furnished items. Resource allocation and integration normally occur through a WBS
hierarchy of product teams, starting with the overall system team. The workflow runs downward
from team to team, to the detailed subassemblies or components. These teams represent
significant, identifiable subsystems, sub-subsystems and components, operation planning andsupport segments.
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 Product. At all levels, team leaders
assume full responsibility, authority, and accountability of their teams. A single, unbroken line ofauthority runs through the team leaders, from the program manager to the subassembly orcomponent team leaders. Team leaders allocate roles and responsibilities based on specific,
tangible support products. Each team member has a clear charter that focuses on thedevelopment or creation of a support product.

3.2

Multidisciplinary teams
Multidisciplinary teams ensure identification of design conflicts by taking into consideration
Product life cycle as early as possible. Multidisciplinary teams include personnel with different
perspectives and a common mission. Team members share a common effort, whether they areskilled in:−−−−designquality assurance
manufacturing
reliability, testability and maintainability

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−

safetytechnical data and technical publication
support equipment
supply support
facilities
technical services
PHST
personnel and training

The objective of an integrated team is to identify and resolve as many design conflicts as
possible in the shortest time, with the understanding that each perspective is of equal value.
Each team member brings a unique perspective to the creation of a single, concurrently
engineered design. Without this integration of perspectives, there is no integrated support
product development, nor concurrently engineered design.

3.3

Single point accountability
The IPT leader is accountable for the development of all Products. This feature is beneficial to
avoiding redundant efforts and clearly defining the purpose.
The IPT leader brings together the right resources (eg, manpower, skills, budget and facilities)
to achieve the goal.

3.4

Empowerment
Empowerment enables IPT members to achieve their mission and provides them with the ability
to influence and control their disciplines destiny to the maximum extent possible. Team
members are empowered enough to fulfill their individual roles and responsibilities, but theirultimate destiny is controlled by the performance of their teammates. By definition, eachmember within a team depends on the other team members. Empowerment means providing
sufficient and adequate resources to team members to help them performing their specified
roles and assuming their responsibilities.

3.5

Management plans
Corrective actions for resource problems consist of procurement actions (eg, early orders forlong-lead-time items or changes to schedule, cost, and budget), and support concept changes
or design changes. Technical analysis reviews and schedules will bring these changes inresources to the attention of the IPS management. The responsible functional management will
work on the identified problems. The responsible subsystem supportability manager will ensurethat appropriate action is assigned and that proposed changes are implemented.

3.6

Clear product definition and interfaces
Mission success depends on a clear and complete understanding of the Product that the teamis accountable for providing. In addition to requirements like performance, supportability, andproducibility, the Product description indicates how the Product must relate or interact with other
Products.

3.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 a rigorous and consistent application of standardized processes for thedevelopment of all Products, along with a continuous search for methods to improve theprocess. As the processes are documented, the team is committed to management by processrather than management of the Product.

3.8

Effective communications
In the integrated Product development process, the term communication means that a free andopen exchange of data, information and opinions is the fuel that keeps the process working.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

Effective communication establishes the roles and responsibilities of the teams, defines the
team's products, establishes team goals and objectives, and favors design conflict identification
and resolution. It is made possible by having:
−
−
−
−
−
−
−

3.9

a collocation of team members
regularly scheduled IPT meetings
all-hands meetings
functional and program staff meetingseffective use of memos
use of electronic communications (eg, emails, video conferences)
an exchange of up-to-date data and information

Performance metrics
It is important to know how well each IPT is progressing toward development of their Products.
To this end, it is necessary to identify critical parameters in the product development process
and establish an associated metric. The parameters selected by an individual or team must
define:
−
−
−
−

3.10

product quality
schedule
costrisk assessment

Implementation
Design reviews and technical information meetings take place throughout the program. Hostdesign reviews and in-house design reviews ensure that design program goals and objectives
are being achieved. LSA analysts and IPS personnel will be aware of supportability andsupportability-related design issues by taking part to design reviews meetings and/or byreceiving the relevant minutes of meeting. Supportability concerns involving equipment designthat arise during meetings, or throughout the overall and continuous design process, arebrought to the attention of the integrated Product engineers. It is necessary to document all
information on design-related supportability issues, including status, to ensure a timely andappropriate resolution. LSA reviews are conducted in conjunction with scheduled design
reviews.

3.10.1LSA activities and performance
The LSA process (refer to Fig 3) applies selected quantitative methods to:
−
−
−
−
−

determine and establish, at the beginning of the process, supportability criteria as an input
to system design
evaluate various design alternatives
identify and provide support resources
provide feedback to design, if required, based on the results of MTA and LORA
assess, at the end of the process, the system support capability during use

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

ICN-B6865-S3000L0095-004-01
Fig 3 Simplified LSA process
The LSA program is based on an integrated product definition. The following major elements
can determine the LSA program:−−−−an LSA program plan that identifies all the required LSA activities to influence design forsupportability and determines the appropriate resources
scheduling that identifies the timing of LSA requirements. LSA schedules are based on theneeds of each project phase, and are established to support and be mutually beneficial toother project requirements.
assignment of LSA activities to design, supportability, and IPS personnel with suitable skills
and qualification
effective management of a wide range of design, supportability, and IPS disciplines

3.10.2Develop an early LSA strategy
It is necessary to develop an LSA strategy to be performed early in the acquisition program.
This strategy will identify the scope of the proposed supportability objectives for the
Product/equipment, and the qualitative analysis to provide the best cost-benefit ratio for theacquisition program. The LSA requirements will be analyzed in order to establish acomprehensive LSA program, including quantitative, qualitative, and test LSA requirements for
Product systems, subsystems, and components. The result is a tailored, cost-effective programthat performs any procedure required by the customer, and provides a system that meets orexceeds any customer requirement on LSA.

3.11

Program management principles
The product support team is responsible for developing the support system. This team is asubset of the IPT responsible for the design, development, manufacture, operation, safety, andsupport of a specific Product.

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

3.11.1

Integrated product support management
It is necessary to collaborate constantly with the IPS manager to provide continuity between
program management direction and the development of the LSA results. Maintaining a properinterface between the LSA manager and other functional managers ensures a smooth
execution of the LSA program.
The IPS manager is responsible for providing the program teams with IPS and supportability
expertise and resources. In the Product development process, each IPT leader controls thebudget and is accountable for the development of Products by that team. Consequently, most
supportability personnel are assigned to and work with the different IPT. Supportability
resources are provided to the different IPT to:−−−−

3.11.2

incorporate supportability into the design of the Product and support system by providing
reliability, maintainability, testability, human engineering, integrated diagnostics, andenvironmental suitability resources
develop the support and training systems, and plan supportability resources by providing
supply support, support equipment, technical data, facilities, PHST, manpower andpersonnel, as well as training and training equipment personnel
accomplish supportability engineering in systems engineering and design process for
Product development
provide for LSA, standardization, interchangeability and interoperability, and environmental
assurance

Operating product support organizational structures
It is possible to align the operating organizational structure for a support program with the WBS.
The hierarchical characteristics of the WBS can be used to establish lines of responsibility,
authority, accountability, and reporting chains from the lowest level of responsibility up to theprogram manager. Integration of supportability into the organization aims at:−−reflecting each supportability element identified by the WBS and system specification
providing effective interaction for supportability-related design functions that are crucial todeveloping the support system, and to achieving readiness goals

Each IPT manager bears total responsibility for all aspects concerning the team's support
products.
At each organizational level, Product team leaders combine the responsibilities of all
subordinate Product teams. As leaders of the IPT and responsible for all Products, Productmanagers lead the responsibility and reporting chain, as they bear responsibility for all products.
A significant feature of this type of organization is that every Product has a specific point ofresponsibility, authority, and accountability in the organization.
3.11.3

Formal support organizations
Functional leaders, such as leaders for Product support, production, and engineering
departments, 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 and ensure 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 different IPT.

3.12

Product support management objectives and policies

3.12.1

Product support
Integrating supportability into the Product development program ensures:
−
−
−
−
−

design reflects test data assessment, supportability alternatives, and tradeoff evaluations
detailed specification requirements are provided
supportability resource planning is adjusted as necessary
operational availability and readiness thresholds are met
the item is supportable in the expected operational environment

Applicable to: All

S3000L-A-02-00-0000-00A-040A-A
Chap 2DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00−−

the operational environments are accurately assessed
the support system achieves expected performance

An underlying objective of the product support program is to identify and resolve as early as
possible any supportability technical risk, prior to beginning Product production and deployment.
3.12.2

Product support management policies
To achieve supportability management objectives, a proper organization must be established
for design-for-supportability through the integration of design and the development of the
support system and training system. To this end, it is necessary to:−−−

structure an integrated Product development organization, which provides for active
supportability participation and influence on design
structure the IPS process to interact constantly, on a working level, with design engineering
through the system engineering processplan to work closely with customers and suppliers to develop the Product

Furthermore, it is necessary to establish an LSA process that:−−−provides analysis procedures for integrating supportability requirements into the baseline
designrequires the support system configuration to match the Product design configuration
provides the detailed maintenance planning and bottom-up identification of total
supportability resource requirements

To provide further control, it is necessary to establish a reporting system for IPS program
progress, status and management. The system will document that program design,development, test and evaluation, and transition accomplishments meet or exceed
supportability priorities and developing supportability requirements.

4

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:−

S3000L UoF Product and Project−

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

Applicable to: All

End of data module
DMC-S3000L-A-02-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 22021-04-30 Page 18

S3000L-B6865-03000-00

Chapter 3
LSA process
Table of contents

Page

1
1.1
1.2
1.3
2
2.1
2.2
2.2.1
2.2.2
2.2.3
2.3
3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
3.4
3.5
3.6
3.7
4
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.2
4.2.1
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
4.4.1

General ............................................................................................................................ 5
Introduction ...................................................................................................................... 5
Purpose ........................................................................................................................... 6
Scope ............................................................................................................................... 6
LSA process overview ..................................................................................................... 6
LSA activities before contract signing.............................................................................. 6
LSA process flowcharts after contract signing ................................................................ 8
Establishment of LSA process ......................................................................................... 8
Determination of scope of LSA activities ......................................................................... 8
Execution of LSA process and related analysis activities ............................................... 9
LSA process details ......................................................................................................... 9
Establishing Product use and general support data ...................................................... 10
General use and support aspects.................................................................................. 10
Operational requirements document ............................................................................. 11
General use scenario .................................................................................................... 12
Geographical position of locations and special conditions of each location ................. 12
Product deployment ....................................................................................................... 12
Use overview ................................................................................................................. 12
Customer requirements document ................................................................................ 13
Supply concept .............................................................................................................. 13
Support equipment concept ........................................................................................... 13
Personnel integration and staff training ......................................................................... 13
Facilities and infrastructure ............................................................................................ 13
IT and communication resources .................................................................................. 13
New organizational structures ....................................................................................... 14
Schedule considerations ............................................................................................... 14
Additional aspects.......................................................................................................... 14
Detailed checklist for the creation of a customer requirements document .................... 14
Time schedule for document creation ........................................................................... 14
Site surveys ................................................................................................................... 14
Qualification requirements ............................................................................................. 15
Certification requirements .............................................................................................. 15
Establishment of Product design and performance data............................................... 15
Selection criteria concerning LSA relevant data and information .................................. 15
LSA data and information derived from contractual documents ................................... 15
LSA data and information derived from Product use and general support data ........... 16
LSA data and information derived from design and performance specifications .......... 16
LSA data and information relevant for Product certification and verification ................. 16
Influence of overall LSA strategies and principles on LSA data selection .................... 17
Procedures and principles influencing selection of LSA data ....................................... 17
Acceptance rules concerning the verification of values................................................. 18
Category of measurement values.................................................................................. 18
Identifying tolerances ..................................................................................................... 18
Establishment of acceptance criteria ............................................................................. 18
Establishment of special rules ....................................................................................... 18
Criteria and procedural aspects for verification of projected values .............................. 18
Determination of measurable target values ................................................................... 18

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

4.4.2
4.4.3
4.4.4
4.5
5
5.1
5.1.1
5.1.2
5.2
5.3
5.4
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.147.2.157.2.167.2.17
7.3
7.4
7.5
7.5.1
7.5.2
7.5.3
7.6
7.6.1

Verification of the individual projected values ............................................................... 19
Verification method ........................................................................................................ 19
Verification for special purposes .................................................................................... 19
Checklist for the LSA guidance conference .................................................................. 19
LSA guidance conference ............................................................................................. 20
Documents and information for LSA guidance conference ........................................... 20
Input to the LSA guidance conference .......................................................................... 21
Output of the LSA guidance conference ....................................................................... 22
Candidate item list ......................................................................................................... 23
Contractual documents .................................................................................................. 23
LSA database ................................................................................................................ 23
Candidate item selection and identification ................................................................... 23
Definitions and general terms ........................................................................................ 24
Candidate and non-candidate ....................................................................................... 24
Maintenance relevant items ........................................................................................... 24
Structural items, structure significant items and structural details ................................ 24
Non-hardware items ...................................................................................................... 25
Classification of LSA candidates ................................................................................... 25
Selection process and criteria list .................................................................................. 26
Preconditions for the selection process - Product breakdown ...................................... 26
Preconditions for the selection process - existing analysis results ............................... 26
Preconditions for the selection process - Candidate selection rules ............................. 26
Preconditions for the selection process - candidate classification selection rules ........ 27
Influencing factors.......................................................................................................... 29
Recommendations for LSA candidate selection ............................................................ 29
Candidate item list (draft) .............................................................................................. 31
Candidate item list as an output of LSA guidance conference ...................................... 31
Analysis activities in the context of an LSA process ..................................................... 31
Principles for analysis activity selection ........................................................................ 32
Potential analysis activities ............................................................................................ 32
Analysis for identification of general LSA needs ........................................................... 33
Comparative analysis .................................................................................................... 33
Human factor analysis ................................................................................................... 33
Product breakdown and configuration assessment ....................................................... 34
Assessment of reliability analysis .................................................................................. 34
Assessment of maintainability analysis ......................................................................... 34
Assessment of testability analysis ................................................................................. 35
Corrective maintenance analysis ................................................................................... 36
Damage analysis ........................................................................................................... 37
Special event analysis ................................................................................................... 37
Preventive maintenance analysis .................................................................................. 37
Level of repair analysis .................................................................................................. 38
Maintenance task analysis ............................................................................................ 38
Software support analysis ............................................................................................. 39
Operations analysis ....................................................................................................... 39
Simulation of operational scenarios............................................................................... 39
Training needs analysis ................................................................................................. 39
Analysis relations and general overview ....................................................................... 39
Analysis activities selection criteria ............................................................................... 40
Checklist for analysis activity recommendation ............................................................. 42
Analysis activities recommendation sheet ..................................................................... 42
Analysis activities decision sheet .................................................................................. 42
Selection example ......................................................................................................... 42
Analysis workflow processes ......................................................................................... 43
Supportability analysis activities in the preparation phase ............................................ 44

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

7.6.2
7.6.3
7.6.4
7.6.5
8
8.1
8.1.1
8.1.2
8.1.3
8.2
8.2.1
8.2.2
8.2.3
8.2.4
8.2.5
9
9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.3.4
9.4
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.212

Supportability analysis activities in the design and development phases ..................... 45
Supportability analysis activities in the production phase ............................................. 45
Supportability analysis activities during the in-service phase ....................................... 45
Summary of activities over the life cycle phases ........................................................... 46
Customer involvement ................................................................................................... 46
Customer assessment of candidate items and recommended analysis activities ........ 46
Establishing LSA assessment rules .............................................................................. 47
Initial assessment and re-assessments ........................................................................ 47
Establishing an assessment procedure ......................................................................... 48
Information exchange between customer and contractor ............................................. 48
Commenting process ..................................................................................................... 48
Informing the contractor by the customer ...................................................................... 48
Final clarification on open issues................................................................................... 50
Customer decision (status influencing) ......................................................................... 50
Exchange of analysis data with the customer ............................................................... 51
LSA review conference .................................................................................................. 52
LSA review process ....................................................................................................... 52
Subject for review .......................................................................................................... 52
Example for review structuring ...................................................................................... 53
LSA review step - CIL and maintenance analysis allocation ......................................... 53
LSA review step - Identification of task requirements ................................................... 53
LSA review step - MTA .................................................................................................. 54
LSA review step - LORA results and support concept information ............................... 54
Status code .................................................................................................................... 54
Starting point and management of the creation of the IPS products............................. 55
Starting point recommendations .................................................................................... 55
Technical publications ................................................................................................... 55
Material support ............................................................................................................. 57
Standard and specific support equipment ..................................................................... 59
Training .......................................................................................................................... 59
Management of the development of the IPS products .................................................. 60
Influence of modifications on IPS products ................................................................... 61
Checklists ...................................................................................................................... 62
Detailed checklist for the creation of an ORD ............................................................... 62
Detailed checklist for the creation of a CRD .................................................................. 65
LSA candidate selection flowchart examples ................................................................ 69
Non-structural items ...................................................................................................... 69
Structural items .............................................................................................................. 71
Associated parts of the S3000L data model .................................................................. 72

List of tables
1
2
3
4
5
6
7
8
9
10

References ...................................................................................................................... 4
Required input documents for the LSA GC ................................................................... 21
List of output documents from the LSA GC ................................................................... 22
Definition of MRI ............................................................................................................ 24
Definitions in the context of structural components of a Product .................................. 25
LSA candidate categories .............................................................................................. 25
Classification criteria for full LSA candidates ................................................................ 27
Classification criteria for partial LSA candidates ........................................................... 28
Classification criteria for LSA candidate family ............................................................. 28
Recommendations for LSA candidate selection ............................................................ 30

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

11
12
13
14
15
16
17
18
19

Depth of maintainability analysis depending of item type ............................................. 35
LORA approaches ......................................................................................................... 38
Analysis activities selection criteria ............................................................................... 41
Summary of LSA activities during the life cycle phases ................................................ 46
Explanation of schedule for the commenting process ................................................... 49
Examples for status codes ............................................................................................ 54
List of different spare part types identified by LSA ........................................................ 57
Checklist of detailed questions to support the ORD creation ........................................ 62
Checklist of detailed questions to support the creation of a CRD ................................. 66

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

LSA activities in conjunction with the preparation of an offer/contract ............................ 7
Flowchart of LSA process at a glance (sheet 1 of 3)....................................................... 8
Flowchart of LSA process at a glance (sheet 2 of 3)....................................................... 8
Flowchart of LSA process at a glance (sheet 3 of 3)....................................................... 9
Schedule for the creation of the basic documents ........................................................ 14
LSA GC, inputs and outputs .......................................................................................... 21
Analysis activities relations and overview ..................................................................... 40
Example of a recommendation sheet for analysis activities .......................................... 43
Position of LSA activities in the overall project schedule .............................................. 44
Process of information exchange between customer and contractor (example) .......... 49
Correlation between LSA and technical publications .................................................... 56
Correlation between LSA and material support ............................................................. 58
Correlation between LSA and support/test equipment .................................................. 59
Correlation between LSA and training ........................................................................... 60
Influence of modifications on IPS elements in general.................................................. 61
Full LSA candidate selection flowchart .......................................................................... 69
Partial LSA candidate selection flowchart ..................................................................... 70
LSA candidate selection flowchart for structural items .................................................. 71

References
Table 1 References
Chap No./Document No.

Title

Chap 5

Influence on design

Chap 7

Corrective maintenance analysis

Chap 8

Damage and special event analysis

Chap 9Operational support analysis

Chap 10Development of a scheduled maintenance program

Chap 12Maintenance task analysis

Chap 13

Software support analysis

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

Chap No./Document No.

Title

Chap 14

Life cycle cost considerations

Chap 15

Obsolescence analysis

Chap 16

Disposal analysis

Chap 17

In-Service LSA

Chap 19

Data model

Chap 20

Data exchange

S1000DInternational specification for technical publications using
a common source database

S4000PInternational specification for developing and continuously
improving preventive maintenance

MIL-STD 1388-2B

DoD requirements for a Logistics Support Analysis Record

SAE ARP5580

Recommended Failure Modes and Effects Analysis(FMEA) Practices for Non-Automobile Applications

1

General1.1

Introduction
When introducing a new Product, it is necessary to make available all supportability
requirements in a timely manner. This requires projects to establish a process that ensures the
Product design takes into account supportability requirements. This process includes several
analysis activities concerning a wide range of support considerations. The customer and thecontractor must agree on the activities necessary to achieve proper supportability. Early
consideration of supportability aspects is increasingly important with respect to both operationaland economic aspects. Customers cannot accept a product that is not cost-effective to operate
and maintain.
Modern products very often contain software elements. The overall Logistics Support Analysis(LSA) process for software and hardware is similar. Therefore, this chapter is valid for the
supportability of software, as well as hardware. However, Chap 13 contains additional aspects
specific to software that it is necessary to consider.
Product support activities are significant in terms of cost. Support costs are much higher thanacquisition costs in the life cycle of a complex technical Product. Because of this, there is atrend in projects to consider supportability aspects as important as performance aspects.
Note
What is the meaning of the term logistics? There is certainly a tendency to associate thisterm to transportation. However, the term logistics is also used when referring to Productsupport activities. In the past, logistics was often used in the context of supportability.
Logistics support covers the supportability characteristics with respect to required
maintenance (both, corrective and preventive) and operational support, which includes forexample servicing activities and Packaging, Handling, Storage and Transportation (PHST).
However, the association of the term logistics to transportation can lead tomisunderstandings on the actual meaning of LSA. For this reason, the tendency is toreplace the term logistics by supportability in the current version of S3000L, wherever
appropriate.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

The word logistics is included in the acronyms Logistics Support Analysis (LSA) and Integrated
Logistics Support (ILS). As this is a well-established term, Logistics Support Analysis (LSA) will
still be in use in this specification. However, in order to harmonize with the rest of the ASD/AIA
S-Series IPS specifications the term Integrated Product Support (IPS) will globally replace
Integrated Logistics Support (ILS). Eventually, Product Support Analysis (PSA) will globally
replace LSA, but not within this issue.

1.2

PurposeThis chapter is a guideline for the establishment of an effective LSA process. It considers eachphase of a Product life cycle and emphasizes the importance of supportability requirements.
Additionally, it describes the interaction between the contractor and the customer during thedifferent phases of the Product's life cycle. The LSA process has two main purposes:−−

additional influence on design (beside the support engineering analysis activities) to ensure
appropriate supportability with the help of different analysis methods
coordination of the creation of IPS products

The LSA process identifies requirements for spare parts, consumables, technical publication,
support equipment, personnel, training, facilities, infrastructure, and software support. It
supports and coordinates the development of the IPS elements. Altogether, this is a complex
and extensive challenge, which requires accuracy. An efficient plan for a successful introductionof new complex technical Products calls for a properly established LSA process that thecustomer and the contractor must adopt and use.

1.3

Scope
The target readers of this chapter are IPS and LSA managers either working for the customer orthe contractor. It aims to highlight that LSA is a powerful methodology to build the core needs
for IPS realization. Additionally, the use of relevant LSA information helps performing monitoring
and control functions. The application of an LSA process can positively influence the quality andcommonality of IPS products. Taking into consideration the various analysis results ensures thefulfilment of the customer's needs for supportability, operability, and availability.

2

LSA process overview
The LSA process includes a set of activities:
−
−
−
−

2.1

activities before contract signing - Refer to Para 2.1
activities to establish the LSA process - determination of basic requirements andpreparation and attendance of the LSA Guidance Conference (LSA GC) - Refer toPara 2.2.1
determination of scope of LSA activities by selection of LSA candidates and corresponding
analysis activities per LSA candidate - Refer to Para 0
execution of LSA process - performance of analysis activities and documentation ofanalysis results - Refer to Para 2.2.3

LSA activities before contract signing
It is necessary to negotiate essential decisions influencing the LSA effort before the LSA GC
takes place. The LSA process usually begins when preparing an offer. The final version
contained in the corresponding contract will be like the original one. This applies to any LSA
significant aspect within the contract (eg, related Statement of Work (SoW)), as well as tocontractual details such as deliverable items, indispensable specified values, or major
milestones. For this reason, it is necessary to carry out a series of investigations before
submitting the contractual offer (eg, identification of LSA activities considered mandatory,
recommended, or voluntary, depending on early strategy judgment and/or the kind of Productand equipment under assessment). Refer to Fig 1.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

The LSA GC serves as a means to provide the customer with the details of all activities, alongwith the associated rules, time schedule and deliverables (including required formats) based on
the contractual agreements. Finally, it will be possible to clarify all customer questions regarding
the LSA effort. LSA GC must contemplate a certain amount of project-specific adaptation,
without the need to discuss contract or cost changes. Considering the iterative nature of LSA
activities, a project must allow for customizations (tailoring), in order to be flexible.

ICN-B6865-S3000L0003-002-01
Fig 1 LSA activities in conjunction with the preparation of an offer/contract

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

2.2

LSA process flowcharts after contract signing

2.2.1

Establishment of LSA process

ICN-B6865-S3000L0004-003-01
Fig 2 Flowchart of LSA process at a glance (sheet 1 of 3)
2.2.2

Determination of scope of LSA activities

ICN-B6865-S3000L0004-003-01
Fig 3 Flowchart of LSA process at a glance (sheet 2 of 3)
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

The selection of LSA candidates and corresponding analysis activities is an ongoing process.
After a first determination based on the results of the LSA GC, the progress of the design anddevelopment process can justify an adjustment of the CIL and analysis activities per LSA
candidate item.
2.2.3

Execution of LSA process and related analysis activities

ICN-B6865-S3000L0004-003-01
Fig 4 Flowchart of LSA process at a glance (sheet 3 of 3)
The analysis activities are an ongoing process. The analysis processes lead to a continuous
growth of data/information concerning the expected maintenance and operational support
solution. It is necessary to harmonize all analysis results with the customer. The customer must
agree to the proposals concerning all maintenance and operational support tasks. In case ofany disagreement, an LSA review (refer to Para 9) can serve as an instrument to discuss andfinally clarify the unresolved issues, which could not be clarified in advance. After an LSA
review, the parties can come to a final agreement after clarification of the pending issues. If it is
not the case, the contractor must update/repeat the analysis, taking into account the customer's
objections.

2.3

LSA process details
Para 3 to Para 10 describe in detail the activities illustrated in Fig 2, Fig 3 and Fig 4.
−

details concerning Para 2.2.1 - Establishment of LSA process
•
•
•

−

establishing Product usage and general support data, refer to Para 3
establishment of Product design and performance data, refer to Para 4
LSA GC, refer to Para 5

details concerning Para 0 - Determination of scope of LSA activities••

candidate item selection and identification, refer to Para 6
analysis activities in the context of an LSA process, refer to Para 7

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00−

details concerning Para 2.2.3 - Execution of LSA process and related analysis activities
•
•
•
•

3

analysis workflow processes, refer to Para 7.6
customer involvement, refer to Para 8
LSA review, refer to Para 9
starting point and management of IPS products creation, refer to Para 10

Establishing Product use and general support data
To identify the pertinent supportability aspects of a new Product, it is necessary to collect all
relevant information related to the intended use and document it in a set of consistently
structured, mandatory documents. Sometimes, the complete relevant information is notavailable during the preparation phase of a project. In this case, iterative steps are necessary toprovide a complete definition of the customer's use of the Product under analysis. In any case,changes to the use scenario play a crucial role in Product support and supportability analysts
must consider them accordingly.

3.1

General use and support aspects
Some general decisions are necessary to establish an initial overview that identifies pertinent
supportability aspects. These first decisions must consider the overall preconditions for the useof the new Product to be introduced, as well as consider some strategic aspects coming fromthe Product design and performance data, which are described in Para 4. A general project
document describing the overall support strategy must define these general decisions. This
strategy must serve as a basic guideline for the further execution of any supportability analysis
and the creation of the Operational Requirements Document (ORD) and the Customer
Requirements Document (CRD).
It is necessary to answer the following general questions before, or at least in parallel to thecreation of the ORD and CRD:−

How will the Product be used?
It must include a short description of the Product including key features, key requirements,
and basic technical data.

−

Will contractor support be required? If yes, at which maintenance levels?
It is possible to answer this crucial question only 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 influence the methods for item repair? If so, there canbe a better approach than contractor support.

−

How long will the Product be used (predicted service life)?
If the Product will only be on the inventory for a few years, then contractor support ispreferable to a lengthy and costly organic support structure.

−

How many maintenance levels are planned for product support?
It is necessary to establish the repair strategy clearly before writing the ORD.

−

What are the features and/or typical activities within each maintenance level?
For example, in a classical two-level maintenance concept, the typical activity isreplacement of equipment and returning the faulty equipment to the contractor or to theoriginal manufacturer for repair.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00−

Is it possible to use directly existing maintenance capabilities and adapt them to the support
concept for the new Product?

−

Is it possible and effective to use existing maintenance capabilities from other products orother similar products at or nearby the operating locations?

−

Is it better to involve the customer in any repair activity of the Product, or to limit thecorrective maintenance to simple equipment replacement? The involvement of thecustomer depends on the abilities that the customer can provide.

−

What is the acceptable frequency and duration of preventive maintenance (expressed inmeasurable terms)?

−

Are there limitations for preventive maintenance (eg, because of special preconditions
concerning available personnel, competence or facilities and infrastructure)?

−

How much of the software is mature? How much is unique to the customer?
In case the delivered software is not 100% bug-free, it can take several years for thesoftware to mature. The Product support structure must also address software support ofpotential upgrades required by the user. However, any modifications in the software sourcecode cannot be regarded as maintenance. They are a design change and must also follow
the process of software development, refer to Chap 13.

−

Is there any software/data loading and/or unloading that the customer must perform?
Which concept must be established to ensure 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(GPTE) concept for software, required software device, and encrypting system for loading
and/or unloading).

−

What is the expected need for Product upgrades due to changes in technology?
This question determines how the customer's support structure can keep up with thechanges in the Product, and how to modify the support strategy, if required. If it is difficult oreven impossible for the customer to perform this, it is preferable to use contractor Productsupport.

It is necessary to provide the most complete answer to all these general questions. Additionalquestions can arise, depending on the project and on the Products included in the project. The
basic principle is to use the best information available. It is recommended that the customer andthe contractor create and negotiate a basic document with all general information. Ideally, thisoccurs before the preparation of the ORD and CRD.

3.2

Operational requirements document
The definition of operational requirements must be quantitative and qualitative. It is necessary toconsider analyses conducted previously and concerning the area of operation and Product use,as these analyses identify the relations between hardware, use, and supportability. It is also
necessary to define the identified operational requirements and gather metrics. Operational
requirements serve as a starting point to develop supportability requirements. Eachsupportability requirement must be based on an operational requirement, and it is necessary to
identify their relation clearly. 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 thepertinent operational requirements related to the intended use of the new Product. The authorsof the ORD are required to identify the Key Performance Indicators (KPI). Any parameters
identified as KPI must be candidates for review if they have a negative impact on supportability
attributes. At an early stage of the project, the ORD requires the Product developer to makedifficult choices between “must have” and “nice to have” items. This information is vital for the
supportability analysts to understand what they must support, regardless of costs, and what
they can trade off.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

3.2.1

General use scenario
In the general use scenario, it is necessary to collect all information on the environmental
aspects of Product use. This information includes but is not limited to:
−
−
−
−
−
−

3.2.2

Geographical position of locations and special conditions of each location
It is necessary to collect details on each location in which the Product will be operated and any
special aspects of those locations. These details include, but are not limited to:−−−−number and geographical position of the operating locations
type of each operating location
special conditions at each operating location
Is the location in a region currently at war?
Threat situations require a special emergency support concept limited to the minimum
amount of intervention.

−−−

Is sufficient infrastructure available to access each operating location?
special infrastructural requirements for reaching a location
capabilities (existing and planned) of each location (eg, support equipment, facilities,
infrastructure, personnel, supply depot, repair shop)
interactions between different locations concerning, for example, maintenance support,
from one location to another location

−

3.2.3

Product deployment
It is necessary to collect details about the deployment of the Product and the interactions
coming from the deployment. The location of the Product affects the decision to use either
integrated or contractor support. These include but are not limited to:
−
−
−

3.2.4

general description of overall use areas and/or mission areas
possible operational scenarios and requirements for each scenario
influence on the environment by the use of the Product and resulting activities to avoid or
reduce negative influence
supportability problems arise during the life of the Product currently in use
interaction and dependability with existing Products
mobility requirements

number of supported Products per location
deployment of Products per locationinteractions between the different locations concerning use

Use overview
Depending on the customer, defining the planned Product use provides some basic input tosupportability analysis. The frequency and duration of the use, in combination with the reliabilityof the Product, provide the initial basis for determining the range and quantity of the required
support resources. These include but are not limited to:−−

key use/key missions per location
performance parameters and constraints
It is necessary to identify Product performance parameters such as range, accuracy,
payload, or speed in measurable terms, avoiding general or potentially ambiguous terms.

−
−
−
−
−
−

allocated operational availability and use/mission success rates
operation per unit of time
operation profile per operating day, week, month, or year
use of the Product as training equipment, taking up a portion of operating timepermanent operational conditions/possible maintenance windows
average duration of each unique use event

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00−

key measurement base of use per unit of time

For a detailed checklist on how to create an ORD, refer to Para 11.1.

3.3

Customer requirements document
The customer must consider all Product support requirements to ensure proper Product use.
The supportability analysts can influence the supportability and design of a new Product in themost efficient way during the early development stages of the Product. One method to convey
these needs is to document them in a CRD. Para 3.3.1 thru Para 3.3.9 provide the scope of the
CRD.

3.3.1

Supply concept
The supply concept is crucial for logisticians. A general decision on how to organize theprovision of spare parts and consumables can have high impact on the maintenance scenario.
The analyst must decide whether there is a need to plan facilities and infrastructure to organize
supply storage areas, and determine who will manage the supply chain when outsourcing the
supply chain management. Costs (especially facility construction) and obsolescence areimportant aspects.

3.3.2

Support equipment concept
To be cost effective, it is advisable to acquire common support equipment, instead of special
support equipment wherever possible. To reduce costs, it is important to evaluate whether it ispossible to use or adapt for use the existing support equipment.

3.3.3

Personnel integration and staff training
Manpower issues are crucial to the supportability of many Products. It is necessary to plan thetimely training of all support personnel. It is necessary to address acceptable risk levels, training
level needs, and manpower ratios as supportability requirements. There are two types oftraining needs: initial and on-going. Both are important to ensure adequate personnel
competence. Preserving a specific competence is often a crucial issue, considering a high levelof turnover in personnel. There can be a rapid turnover in repair and maintenance personnel aswell. Support planning must deal with these issues.

3.3.4

Facilities and infrastructure
Early planning for facilities and infrastructure is necessary because of the long lead times
associated with site acquisition and allocation. It is necessary to plan the facilities formaintenance activities to ensure the relevant support to process needs and activity workflow.

3.3.5

IT and communication resources
IT and communication resources need proper preparation. The preparation includes, but is not
limited to:−−−What constraints are necessary 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 developed additionally?

IT resources must include all aspects such as computer hardware, computer network
components, network wiring, communication protocols, software packages, data security, andstandards.
This subject also requires an understanding of future capabilities. The engineer andsupportability analyst must be aware of the status of other related projects, in order to design a
Product that, at the time of its deployment, will interface with the other forecasted Products. It isnecessary to address how the Product interacts with the planned future communications
architecture. The analyst must assess the impact of expected IT system changes to determine
necessary adjustments to the support structure.
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

3.3.6

New organizational structures
Considerations on new organizational structure cover two aspects:−−

any change to the established organizational structure at a location of the customer tosupport and operate the Productany change in the organizational structure (eg, reduction in personnel) because a new
Product replaces an existing Product or because the new Product is easier to maintain

Organizational structure changes have a major impact on available support infrastructure andthis impact must be accounted for the development of a new Product.
3.3.7

Schedule considerations
The supportability analyst is obviously concerned with scheduling decisions. Product support isa vital and integral part of any fielded Product. It is necessary to consider the risk of delays
and/or inefficient use of resources. If supportability considerations are integrated in each project
phase, the supportability schedule will be synchronized efficiently and integrated with otherdiscipline schedules (eg, engineering or production).

3.3.8

Additional aspects
This paragraph addresses special aspects such as PHST considerations, and defines uniquedata requirements. Logisticians must know how and when they will use the data they require,
and they must be able to separate essential data from data that can be useful to cover possible
contingencies. PHST, disposal, and environmental impact considerations are far from being themain concern of system designers, developers, and users, but they are important and canpotentially cause expensive consequences. Supportability analysts must understand thepotential impact of these issues on the Product from the outset and must raise these issues
whenever they have an impact on project planning.

3.3.9

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

3.4

Time schedule for document creation
To ensure that all required information is available for each of the three basic documents that
identify Product use data, it is necessary to identify a sequence or workflow for the creation ofthese documents. Refer to Fig 5.

ICN-B6865-S3000L0002-002-01
Fig 5 Schedule for the creation of the basic documents

3.5

Site surveys
Site surveys of operational units and maintenance/repair workshops can provide a significant
input to the operational and customer requirements as they identify existing capabilities,
resources, and potential problems. Once there are sufficient details on the operational

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

environment for a new Product, site surveys can help determine existing operational units andrepair facilities that are most likely involved in the operation and support of the new Product. It isnecessary to document the results of site surveys, and include them in the ORD (eg, as anadditional appendix).

3.6

Qualification requirements
If the customer requires a qualification process, the customer and the contractor must clarify, at
an early stage, which aspects of maintenance and operational activities to take into account toachieve Product qualification by the customer's authorities. The customer must define therequirements for the qualification and transmit them to the contractor together with the ORD.

3.7

Certification requirements
If a certification process is necessary for Product operation in the predicted environment,
special attention must be given to the collection and documentation of the maintenance andoperational support activities that are a part of the certification. These activities are necessary,
regardless of their cost. All aspects of maintenance and operational support activities that
influence certification must have priority. In its early stages, the project must clarify which efforts
to consider in order to fulfil the requirements of the certification authority. The certification
authority defines the certification requirements and the customer and contractor must be familiar
with them.
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.

4

Establishment of Product design and performance data
LSA requires the identification and documentation of relevant Product design and performancedata/information. This includes, but is not limited to:
−
−
−
−

4.1

selection criteria concerning LSA relevant data and information - Refer to Para 4.1
influence of overall LSA strategies and principles on LSA data selection - Refer to Para 4.2
acceptance rules concerning the verification of values - Refer to Para 4.3
criteria and procedural aspects for verification of projected values - Refer to Para 4.4

Selection criteria concerning LSA relevant data andinformation
In this context, all data and information subject to verification and control within the intended
LSA process must be considered relevant. Depending on the individual Product subjected to
LSA, the related contract and specifications, as well as the established IPS plan, it will benecessary to provide details on the related criteria. Relevant information must be documented
as requirements in order to set a goal to be verified within the established LSA process. A
general approach must consider the selection criteria described in the following paragraphs.

4.1.1

LSA data and information derived from contractual documents
It is necessary to examine contractual documents carefully, as they can contain Product design
and performance features relevant to LSA that documented LSA data/information can verify.
Usually, these documents cover overall Product requirements or crucial KPI to establish
mandatory goals and/or thresholds potentially related to contract incentives or contract
penalties. Example KPI are:−Specified maximum maintenance man hours per operating hour
This value can serve as a benchmark concerning successful maintenance design.

−

Specified maximum Mean Time To Repair (MTTR) paired with specified MTTR percentile
These values can serve as an indication for successful design as they relate to repair withinestablished time constraints.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

4.1.2

−

Specified maximum failures per operating hour
This value indicates the desired reliability of the Product and, inversely, the maintenanceworkload.

−

Specified figures concerning minimum availabilities
These values can indicate successful design in terms of readiness for operation.

−

Testability characteristics
These values indicate how the design ensures internal means like Built-In Test Equipment(BITE) and overall test architecture monitor vital functions, and detect and localize potential
malfunctions.

−

Minimum operational lifetime
This value indicates a minimum lifetime requirement. This must indicate any risk of falling
below the established threshold.

LSA data and information derived from Product use and general support data
It is possible to document relevant information as a baseline reference. In this context, refer toPara 3. Examples are:
−
−
−
−
−

4.1.3

Annual Operating Requirements (AOR) with their measurement basenumber of operating locations to be considered
number of Products to be operated at each location
maintenance levels to be established at each location
maintenance personnel available at each location (number of persons by specificcompetence)

LSA data and information derived from design and performance specifications
For verification and/or control purposes, it is possible to document LSA relevant parameters
influencing the design and performance of the Product. In this context, refer to Chap 5.
Examples are:
−
−
−
−
−

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 MTTR, paired with specified MTTR percentile

These values can indicate successful design in terms of repair within established time
constraints.
4.1.4

LSA data and information relevant for Product certification and verification
It is also possible to gather LSA relevant information from other documents and/or analysis
results originated by the design department, Configuration Management (CM), maintainability,
safety, stress department or from the customer's documents. Examples are:
−
−
−
−
−
−
−

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 the functional failures that must be avoided by means ofpreventive maintenancePreventive Maintenance Task Requirements (PMTR) - Refer to S4000P
storage limitations and/or requirements
criticality classification of specific parts

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

4.2

Influence of overall LSA strategies and principles on LSA
data selection
Prior to determining the relevant Product design and performance data, the tailoring of the LSA
program must include an overall LSA strategy. The tailoring processes are dependent on the
project’s complexity, value to business units (contractor), and known risk factors. Afterwards, itis necessary to balance these constraints and performance requirements between the required
analysis efforts, time, schedule, and allocated budget, aiming at the best cost/benefit value forthe project. All stakeholders will review and evaluate these requirements, issues, andconstraints during the LSA GC to achieve consensus. A corresponding document that
represents the agreed business rules will record these findings, analyses and resulting
agreements.
This tailoring activity is an iterative process that must take place at each program phase. The
tailoring analysis for each phase must include the results and lessons learned from the previous
phases.

4.2.1

Procedures and principles influencing selection of LSA data
The overall support strategy and principles can influence the selection of Product design andperformance data in relation to the LSA process. Typical examples for influencing support
strategy and principles are:−Pre-determined two-level maintenance concept:
Maintenance is mainly limited to two maintenance levels, one for item replacement, and theother for item repair. This will avoid requiring duplicate inventory at different repair facilities.
If the equipment that requires removal and replacement at the operational site has a low
failure rate and a high detectability rate (eg, by BITE), and if there is a responsive supply
chain between the operational sites and suppliers, then the two-level maintenance concept
is normally preferable because of overall cost considerations. With this concept, LSA data
are limited to pre-determined Maintenance Levels (ML).

−

Repair only at a certain ML:
Repair is limited to user sites to achieve maximum autonomy, independent of costeffectiveness. With this concept, repair option data are limited to the pre-determined ML.

−

Limited repair at ML1 and/or ML2:
The corrective maintenance activities can be limited to the replacement of an item (noin situ repair) to shorten any operational downtime. With this concept, maintenance tasks
are limited to pre-determined criteria.

−

Single source principle:
In case of a major repair, the best solution is to choose the item supplier because of, forexample, their related experience, and readily available personnel and equipment. With thisconcept, repair data are limited to the information provided by the supplier.

−Interim support concept:
In order to acquire experience and reduce risks prior to final decisions on support concept,
it is possible to establish an interim support phase. Within a temporary phase, the customer
normally makes use of direct support provided by the contractor or by the equipment
manufacturer. With this concept, support concept data are limited to preliminary
information.

−

Commercial Off-The-Shelf (COTS) concept:
If the equipment used is already available on the market, related conditions must be
accepted. However, a COTS equipment needs support as well. It is strongly recommended
not to underestimate the effort needed to determine required maintenance and operational
support based on the information provided by a supplier. Such information can be very

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

limited, or rather extensive. With this concept, data must reflect related supplierinformation/conditions.

4.3

Acceptance rules concerning the verification of values
Clearly defined acceptance rules must be established to avoid uncertainty during the verification
process. These rules will allow accurate acceptance or rejection of the results for Productdesign and performance data relevant to LSA.

4.3.1

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

4.3.2

Identifying tolerances
For each identified value, it is necessary to express its associated tolerances such as:
−
−

4.3.3

mandatory values
objectives
thresholds (minimum or maximum values)

tolerances for the dedicated value expressed by the requirement for one single value
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 rate of
the group instead of the single items, (eg, by following additional constraints)

Establishment of acceptance criteria
It is necessary to establish measurable acceptance rules for each specified value, along with its
related requirement. These rules must identify the basic conditions (eg, fulfillment of minimum
required values based on sufficient statistic confidence levels) that lead to the acceptance orrejection of specified values.
In addition, it is necessary to state the consequences of the established status information:
−
−
−

4.3.4

Establishment of special rules
If special rules are established, it is mandatory to define the related conditions and values toavoid uncertainty:
−
−

4.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 and the related
justification
status of the IUA indicating the conditional acceptance of the documented figure (eg, in
general acceptable, but requiring minor adaptation)

establishment of penalty regulations for failure to meet specified LSA significant data
establishment of rewards in case of exceeding specified LSA significant data

Criteria and procedural aspects for verification of projectedvaluesFinally, it is necessary to establish the criteria for verification of data and/or other information
subject to verification.

4.4.1

Determination of measurable target values
For data element under consideration, it is required to establish and document the related
projected value range by considering the original target along with its established tolerancesand relevant acceptance rules, if any. It is possible to allocate the projected value range to asingle item and/or a group of dependent items covered by relevant acceptance rules, toestablish the related acceptable values that fulfill the requirements.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

4.4.2

Verification of the individual projected values
It is necessary to make a comparison between the relevant data or other information derived
from the analysis process and the associated acceptable values. The results must be reported
to the analyst and/or involved management and indicate whether the actual LSA values are
consistent with the projected values.

4.4.3

Verification method
The customer and contractor must agree on the projected values and the relevant verification
method:
−
−
−
−
−
−

verification by provision of analytical proof
verification by analytical methods based on appropriate tests (eg, performed at a test rig)
verification by demonstration on a prototype or serial versions of the Productverification in compliance with 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)

4.4.4

Verification for special purposes
Rules can be required when verification for special purposes is necessary in order to gain
certifications, qualifications, or licenses.

4.5

Checklist for the LSA guidance conference
The checklist must contain all relevant proposals for design and supportability requirements. For
example:−Have Product design and performance data relevant to LSA been identified?
•
•
•
•
•

−

Have acceptance rules on the verification of relevant values been identified?
•
•
•
•
•
•
•

−

list of selected LSA data and information derived from contractual documents
list of selected LSA data and information derived from Product use datalist of selected LSA data and information derived from design and performance
specifications
list of selected LSA data and information contained in other Product documents
list of selected LSA data and information subject to certification and verification

Have measurable target values been identified for the selected data/information?
Has the category of measurement figures been indicated for 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?
Have the consequences of acceptance/agreement concerning status information been
identified?
If applicable, have penalties and/or rewards regulations been established?

Have the overall LSA strategies and principles, which influence the aspects above, been
established?
•
•
•
•
•
•

Identify the preferred maintenance concept (eg, is a two-level maintenancemandatory?)
Has the supply chain management support concept been identified?
Have the repairs been focused on one maintenance level and, if so, which level?
Is repair at Maintenance Level 1 and/or 2 limited?
Has the single-source principle been determined?
Is an interim support concept applicable?

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00•

Is it necessary to consider the COTS concept?

The details of the LSA GC checklist must be part of an LSA Guidance Document (LSA GD).

5LSA guidance conference
The LSA GC must be the central event. Management staff and specialists from both thecustomer and the contractor must attend it. At this conference, the binding agreements for the
performance of the LSA process must be established. During the LSA GC, the customer must
agree on the selection of Product design and performance data subject to verification andcontrol within the LSA process. This also applies to the relevant rules for the implementation of
the LSA process.
To maximize the outcome of this conference, it is necessary to prepare inputs and to have aclear understanding of the expected results and final agreements. It is recommended to havechecklists concerning preparations and expectations for the LSA GC.
Note
It is recommended to avoid the use of the phrase "to be defined" as an input for any subject
to be discussed during the LSA GC. Specialists must prepare concrete proposals
concerning the performance of the required activities, and these proposals must serve as
the basis for all discussions. Evaluate the advantages and disadvantages (cost/benefit) of
the alternatives under consideration. Provide documentation of all alternative analysis anddecisions.

5.1

Documents and information for LSA guidance conference
Para 5.1.1 and Para 5.1.2 include lists of applicable documents relevant for the LSA GC. Theselists provide a guideline on the methodology to document the required information. The project
can add additional aspects or skip some information. Fig 6 gives a summarized overview of therecommended inputs and outputs for the LSA GC.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

ICN-B6865-S3000L0005-002-01
Fig 6 LSA GC, inputs and outputs
It is necessary to negotiate the majority of essential decisions influencing the LSA effort, anddocument them in the contract. This applies to any LSA relevant aspect within, for example, a
SoW and the corresponding parts of the commercial offer, as well as for contractual details suchas delivery items, indispensable specified values and major milestones. This mandates toperform a series of investigations prior to the contractual offer. Said investigations include theidentification of LSA activities considered as mandatory, recommended or voluntary, dependingon early strategy judgment and the Product/equipment type to be assessed. Refer to Para 2.1.
5.1.1

Input to the LSA guidance conference
Table 2 provides an overview of the required documents/information to prepare for an LSA GC.
Table 2 Required input documents for the LSA GC
Type of document

Content

Responsible
party

General use andsupport aspects

Strategic aspects of the Product design andperformance data concerning use and supportability
framework. Refer to Para 4.

Customer

Contractual
documents

Contractual decisions that can influence the LSA
process must be available during the LSA GC andtaken into account (eg, SoW, contracted LSA
deliverables, milestones).

Customer
andcontractor

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

5.1.2

Type of document

Content

Responsible
party

Operational
Requirements
Document (ORD)

Details about the use of the Product in the planned
scenario at all operational locations. Refer to Para 3.

Customer

CustomerRequirements
Document (CRD)

Details of customer requirements regarding theoperational scenario described in the ORD. Refer toPara 3.

Customer

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

Customer
andcontractor

LSA business rules DRAFT

Implementation rules for the LSA program

Customer
andcontractor

Candidate Item List
(CIL) - DRAFT

A preliminary list of Breakdown Elements (BE) and/or
parts to consider as potential LSA Candidate Items(CI). It is necessary to present at least the rules forcandidate selection.

Contractor

Data element list
(DEL) - DRAFT

A list of proposed data elements required to document
the performance of all potential supportability analysis
activities.

Contractor

Output of the LSA guidance conference
The result of the LSA GC must be a series of measurable rules, agreed by customer andcontractor, to guide the LSA process. These rules, checklists, and documents provide a clear
road map of needs and expectations between the customer and the contractor. The customer
and contractor must agree to and sign this collection of official documents. These documents
must at least contain the items shown in Table 3.
Table 3 List of output documents from the LSA GC
Type of document

Content

Responsible party

LSA Program Plan
(LSA PP)

Initial release of the LSA PP. For details
concerning an LSA PP, refer to Chap 2.
Consensus of LSA GC participants required.

LSA GC participants(customer andcontractor)

LSA business rules

The business rules determine theimplementation of the LSA process. Typically,
an appropriate document, for example an LSA
GD, contain these rules. For details concerningan LSA GD, refer to Chap 2.

LSA GC participants(customer andcontractor)

Candidate Item List
(CIL)

List of LSA candidates containing all BE andparts selected for supportability analysis
activities, including the selected analysis
activities for each CI.

LSA GC participants(customer andcontractor)

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00

5.2

Type of document

Content

Responsible party

Data Element List
(DEL)

A list of agreed data elements required to
document the performance of all potential
supportability analysis activities. The DEL canbe an appendix to an LSA GD.

LSA GC participants(customer andcontractor)

Candidate item list
Para 6 describes in detail the creation of the CIL, including the associated rules.

5.3

Contractual documents
Contractual conditions are the basis for any project. It is necessary to consider all contractual
decisions made prior to the LSA GC. If these decisions affect the IPS process, they will also
have a major impact on the selection of the supportability analysis activities.
Another contractual consideration is the significance of the output documents of the LSA GC.
The supporting LSA GC documentation must support contractual requirements and needs forboth the customer and the contractor.

5.4

LSA database
The documentation of LSA data/information requires proper IT support. As a generalrecommendation, an effective approach is to implement and maintain an LSA database basedon existing standards or specifications. Chap 19 and Chap 20 of S3000L specification provide
the baseline for the development and implementation of an IT solution.
During the LSA GC, it is necessary to determine the approach for the implementation of an LSA
database (or alternate solutions) within an LSA program. Some basic IT requirements must be
considered, including:
−
−
−
−
−
−

6

selection of IT toolset
common data source principle to avoid time-consuming and error-prone data exchange
processes (one LSA database for all stakeholders, if possible)
processing LSA data by import and export (if required)
LSA data evaluation by creating project specific reports
network capacity and security requirements (crucial for international projects)
access rights to database content and database functionality (role concept)

Candidate item selection and identification
It is necessary to consider the LSA process to be cost-intensive. For that reason, the selectionof LSA candidates and the associated analysis activities must be carried out with reasonablecare to keep a good balance between the effort for LSA and the benefits obtained from the LSA
process. The LSA candidates can be different in quality, therefore the type of analysis process
and the depth of the analysis must vary depending on the LSA candidate type.
The selection of the LSA candidates requires a proper Product breakdown, and IPS aspects
must drive the breakdown. The configuration of the Product is of crucial importance. The firstbaseline analysis establishes an appropriate Product breakdown, and it is necessary to lead all
further technical/supportability analyses performed during the entire LSA process. The
representation of a Product by Product breakdown must include a set of aspects, summarized
by the general term "configuration" of a Product:−−−types of Product breakdown (eg, functional or physical)
installation location and realization by hardware (parts) or software
multiple installations of the same part at different locations

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00−−−

alternate parts for the realization at one and the same installation location
substitute components for equipment repair
handling of variants of equipment/components within variants of the Product (configuration
aspect)Chap 4 provides details on how to establish an appropriate Product breakdown using LSArelevant aspects.

6.1

Definitions and general terms
First, some definitions of terms used to describe Product components in the context of
supportability are introduced.

6.1.1

Candidate and non-candidate
The LSA candidate is the driver for all LSA activities. In general, any IUA on system, subsystem,
equipment, module, sub module or part level can be a potential LSA candidate. The IUA can be
an element of the Product breakdown, identified by a Breakdown Element Identifier (BEI), or anelement from a part list identified by a part identifier (eg, a part number). The analysis of the
LSA candidate aims to determine its need for any maintenance (preventive and/or corrective)
and/or operational support. The set of criteria described in Para 6.3 determine whether an IUA
will be part of the CIL.
In addition to this hardware-related definition, special activities and/or descriptions can be partof a Product breakdown. For example, it is possible to document the description of standardpractices for the repair of structural components within a special area/chapter of the Productbreakdown. In this case, these specific non-hardware breakdown elements can be LSA
candidates as well because of special events or maintenance tasks associated with them. Noncandidate items do not require a detailed supportability analysis. These items do not need toappear in a Product breakdown under a unique BEI or a part identifier. In case of a complex
breakdown, all items that do not fit into any of the selecting criteria given in the LSA candidate
selection checklist are potential non-candidates. Items that are only subject to standard tasks
and do not require any special resource are also potential non-candidates. Consumables andbulk items (eg, screws, bolts, nuts, washers), as well as wiring or fuel lines, are typical examplesof non-candidate items.

6.1.2

Maintenance relevant items
It is necessary to consider any IUA affected by any maintenance activity to be relevant for
supportability analysis. Table 4 provides a definition for Maintenance Relevant Item (MRI).
Table 4 Definition of MRI

6.1.3

Item typeDefinition

MaintenanceRelevant Item(MRI)

A MRI is an item that can be repaired or replaced in case of failure ordamage. These items are potential LSA candidates.

Structural items, structure significant items and structural details
The structure of a Product, such as the bodywork of a car, is also part of the Productbreakdown. Structural items can be typical LSA candidates, which can be repaired or replaced.
They can also be candidates for the Preventive Maintenance Analysis (PMA), and are therefore
relevant for potential PMTR. Refer to Table 5.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00

Table 5 Definitions in the context of structural components of a Product
Item typeDefinition

Structural Item(SI)

A SI is any part of the Product structure.

Structural
Significant Item
(SSI)

A structural item or assembly considered crucially important because it
carries aerodynamic, ground, pressure or control loads, and whose failure
can affect the structural integrity necessary to operate the Product safely
and/or can become a hazard to human safety, and/or can affect law and/or
environmental integrity. Refer to S4000P.

Significant
Detail (SD)A limited area of an SSI or a local spot that is part of the whole SSI. Refer toS4000P.

Note
The definitions for SSI and SD are in line with those in S4000P. In order to document an
SD within the Product breakdown, it is necessary to consider that a part identifier normallycannot identify an SD, because the SD is just a specific area of an SSI. For this reason, it isrecommended to identify an SD using an additional BEI one level below the SSI itself.
6.1.4

Non-hardware items
A hierarchical hardware breakdown usually documents only hardware (including software, if
required). It must be possible to include non-hardware items in the Product breakdown, in casethere is a need to describe any general task that cannot be assigned to a specifichardware/software or that is a standard procedure for a group of items (eg, standard repair
procedures for electrical wiring). Refer to Chap 4. Logical aggregation by systems/subsystems(eg, fuel system of a vehicle, hydraulic system on an aircraft) or segmenting of a Product byzones are typical examples of non-hardware items. These non-hardware items can also
become LSA candidates because there can be maintenance or operational support tasks which
need to be documented against these items (eg, a system test or a zonal inspection).

6.2

Classification of LSA candidates
It is recommended that categories for LSA candidates be established. This ensures keeping theanalysis effort to an adequate level for each category of LSA candidate. Table 6 shows thepossible categories for LSA candidates. The customer and contractor must define andharmonize the exact meaning of each category, especially for partial candidates, as it can benecessary to define more than one partial type within a specific project.
Table 6 LSA candidate categories
Candidatecategory

Description

Full candidate

Provide the complete range of selected LSA information applicable to therelated item.

Partialcandidate

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

CandidatefamilyProvide LSA information focused on specific requirements for similar items.
For example, for a family of items such as specific wirings, harnesses, pipes,
lines. Provide information on minor items of the same type (eg, clamps orconnectors). Those items can only require a summary analysis for the family.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

Candidatecategory

Description

Standard
procedures
candidate

Provide a partial scale of LSA information because the LSA information ofother non-hardware BEI (eg, tasks concerning standard repair procedures ofstructure or electrical wiring) covers all relevant information for this item.

For every LSA candidate type, it is necessary to establish a list of criteria and to develop a
flowchart for the decision process to support the analysts together with this list of criteria.

6.3

Selection process and criteria list
For LSA candidate selection, it is necessary to evaluate the significance of each breakdown
element and/or part with respect to LSA purposes. If the agreed selection process indicates thatan item is a candidate according to the selection rules, the relevant item will become an LSA
candidate.
It is necessary to adapt the LSA candidate selection process to each project. Para 6.3.1 thru
Para 6.3.4 give examples for typical selection criteria. Additionally, Para 11.3 includes basic
LSA candidate selection flowcharts. Depending on the project, it is possible to modify somequestions in the flowcharts or to adapt the selection flowchart with additional questions.
To perform the LSA candidate selection process, it is necessary to fulfil some preconditions
concerning Product breakdown and the establishment of rules.

6.3.1

Preconditions for the selection process - Product breakdown
A hierarchical Product breakdown will establish the LSA candidates from the root level (ingeneral the Product itself) down to the required depth for the sub-module or part level.
Therefore, the availability of a Product breakdown is the most important precondition to perform
an LSA candidate selection. It is essential that the existing breakdown be applicable to this task
by considering the following criteria:
−
−
−

6.3.2

Preconditions for the selection process - existing analysis results
LSA candidate selection must use each existing analysis result (eg, from analysis activities
performed in advance or provided by the manufacturer). Examples are:
−
−
−

6.3.3

Is the Product breakdown available in a sufficient maturity, depth and extent? Refer toChap 4.
Is this a preliminary issue of the Product breakdown (eg, to respond to a request by apotential customer, or to enter into a pre-contractual agreement with a potential customer)?
Has the customer already accepted the existing or initial Product breakdown (including
methodology)?

existing experience for equipment already used in other products
existing maintainability, reliability or testability information/data
existing Failure Mode and Effects Analysis (FMEA), or Failure Mode and Effects Criticality
Analysis (FMECA) results

Preconditions for the selection process - Candidate selection rules
As a part of the LSA GC, the contractor and the customer must establish the rules for LSA
candidate selection and the extent of analysis per LSA candidate. This means that, at the
beginning of an LSA GC, it is only possible to present a preliminary CIL rather than a final CIL.
The criteria that can serve as a basic guideline for aspects potentially relevant to LSA candidate
selection include, but are not limited to:Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 26

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−

the item has a significant impact on maintenance concerning the related failure/defectfrequency or the awaited workload
the item requires special resources, such as highly qualified personnel or specific training,material or support equipment
the item is subject to preventive maintenance with a scheduled interval (eg, preventive
replacement of life-limited items)
the item is subject to other preventive maintenance procedures (eg, after special events
such as lightning, overheat, hail strikes, contact with obstacles)
the item is subject to diagnostic and/or functional test tasks (eg, complete system tests)
the item is potentially endangered by damage due to the installation area and/or the designof another item
the item is subject to the use of new technology
the item contains user-loadable software (including data)

The following items are potential LSA candidates that require assessment for a global point ofview or 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 explicit customer interest
The item is subject to contractual fulfillments related to LSA

The following items are potential LSA candidates that require assessment only or mainly forstandardization reasons:−−−

The items require only removal and installation tasks in order to gain access to an LSA
candidate. These items do not require full LSA activity, but it is necessary to standardize
and document the involved supportability requirements.
Documentation of general tasks. Those tasks need to be considered mainly for registrationand documentation of the associated supportability requirements. Often, the general tasks
are linked to non-hardware BEI.
Groups of items that could require a summarized supportability analysis, for example afamily of non-specific wirings, harnesses, pipes, lines, minor items of the same type (eg,clamps or connectors)

It is necessary to detail all the criteria above using measurable threshold values. For example,
the criteria must use a clear threshold value (eg, the MTBF) to indicate whether an item issignificant for maintenance with respect to the related failure/defect frequency. The above
criteria fit for all types of candidates. Para 6.3.4 describes the possible criteria for thedifferentiation of the candidate types.
6.3.4

Preconditions for the selection process - candidate classification selection rules
To support this part of the LSA candidate selection process, Table 7 thru Table 9 provide
examples of criteria for the different candidate types. Para 11.3 provides the flowcharts forcandidate item selection.
Table 7 Classification criteria for full LSA candidates
Candidate
Classification criteria
classification

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

Yes

Is the item a Line Replaceable Unit (LRU)?

Applicable to: All

Yes

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 27

S3000L-B6865-03000-00

Candidate
Classification criteria
classification

RequiredanswerIs the item a repairable item?

Yes

Is the item a low-reliability item (is low-reliability measurable)?

Yes

Is the item relevant for maintenance? In other words, are there
any dedicated maintenance tasks planned such as repair,servicing, lubrication, or calibration (no general tasks such as
simple cleaning)?

Yes

Are dedicated maintenance tasks complex, time-consuming or do Yes
they require many staff members?
Is the required support equipment for dedicated maintenancetasks non-standard or non-existent?

Yes

Is specific preventive maintenance, as identified by PMA,
required for the item?

Yes

If the answer is "No" to all the questions in Table 7, the IUA will not be a full candidate. If theanswer is "Yes" to any of the questions above, then this item is a potential full candidate andcan be classified as such in the CIL.
Table 8 Classification criteria for partial LSA candidates
Candidate
Classification criteria
classification

RequiredanswerPartialcandidate

Is it necessary to remove the item to gain access?

Yes

Is 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, and will a fault location and/or a test
procedure or other general maintenance procedures be
described?
Is the item a non-hardware item, for which general activities (eg,cleaning, storing, parking, mooring, general inspections) will be
described?

Yes

If the answer is "No" to all questions in Table 8, the IUA will not be a partial candidate. If theanswer is "Yes" to any of the questions above, then this item is a potential partial candidate andcan be classified as such in the CIL.
Table 9 Classification criteria for LSA candidate family
Candidate
Classification criteria
classification

RequiredanswerCandidatefamilyIs the IUA installed within the Product many times in the same orin a similar way?

Yes

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

Yes

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 28

S3000L-B6865-03000-00

It is recommended that the LSA candidate family concept be used when a large number of
equal or similar items is installed within the Product. Refer to Table 9. For example, all electricalwiring with the same properties and identical or similar connectors can be summarized under
one LSA candidate family. For this family, all information relevant to maintenance (eg, aconnector repair concept) is valid for all single cables of the whole family.

6.4

Influencing factors
It is necessary to take into account the following factors to select candidate items and/or
establish the related rules:
−
−
−
−
−
−
−

project phase to which the LSA program belongs
complexity of the Product to be analyzed
price of the Product to be analyzed
budget available for the overall Product support and budget planned specifically for the LSA
process. Budget limitation will always influence the number of LSA candidates that can beanalyzed. In these cases, a reduction of the real maintenance and cost drivers is required.
importance of the LSA results for the internal IPS elements
importance of the information required by the customer and the industry management tomake decisions and fulfill the contractual requirements of the LSA-related items
items already in use under comparable conditions
•
•
•
•

−
−
−
−
−
−

6.5

items already in use, but not under comparable conditions
COTS items usable with or without any 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, support concept, Product support requirements)
proposal of recommended support concept
identification of tasks associated with the intended support concept
identification of related Product support requirements
estimation of related Product Support Costs (PSC) as part of Life Cycle Costs (LCC)

Recommendations for LSA candidate selection
Table 10 provides a list of recommendations concerning essential and extra criteria to provide
the analyst with an overview on how to handle the LSA candidate selection criteria in detail.
Additionally, the table provides assistance in the selection process and recommendations todetermine whether IUA selection as an LSA candidate is mandatory, recommended, orvoluntary.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 29

S3000L-B6865-03000-00

Table 10 Recommendations for LSA candidate selection
Aspects

Description of criteria

Risk andcriticality

Is it necessary to integrate LSA candidates from separate
Mandatory
LSA programs? External LSA information to be integrated
into one LSA program without any change (eg, LSA data
for an engine derived from a separate contractor), or
external LSA information to be integrated with adaptation toan LSA program that requires changes to be harmonizedwith the original contractor.

Item type

Generalattributes

Considerationas potential
candidate item?

The IUA is subject to PMA (eg, S4000P) and PMTR are
identified.

Mandatory

The structural IUA is subject to PMA and PMTR 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 such as lightning, bird, hail strikes or 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 customer has a vested interest in the IUA (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, but not under comparable conditions

Mandatory

Item already in use, but requiring major modification

Recommended

Item newly developed

Mandatory

COTS items

Recommended

Part of an item family significant for maintenance

Voluntary

Item containing user-loadable software and/or data

Mandatory

Item is line-replaceable

Mandatory

Item is shop-replaceable

Recommended

Item is line-repairable

Recommended

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 30

S3000L-B6865-03000-00

Aspects

Maintenancesignificance

6.6

Description of criteria

Considerationas potential
candidate item?

Item is shop-repairable

Recommended

Item is repairable at customer depot or at industry level

Voluntary

FMEA/FMECA available for 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 damage

Voluntary

Item is potentially subject to general tasks

Voluntary

Item is potentially subject to standard procedures

Voluntary

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

Voluntary

Candidate item list (draft)
For LSA candidate selection purposes, it is recommended to use a matrix to structure anddocument the selection results. The contractor must prepare a recommendation which reflects
the proposed selection criteria and must include a first draft of the matrix. Moreover, thecontractor must prepare the draft of the CIL for the LSA GC. After harmonizing the proposed
selection rules between the contractor and the customer, it is possible to rework this draft.

6.7

Candidate item list as an output of LSA guidance conference
It is necessary to include the CIL in an obligatory list, reflecting the decisions taken by thecustomer. This CIL must be a living document in order to record any change occurring during
the different project phases. During the LSA GC, (refer to Para 5) the improvements to the draft
version of the CIL must be considered as one of the most important steps regarding contractual
terms. In the CIL, it is possible to manage a collection of all LSA candidates and thecorresponding workload from the selected analysis activities. To support the management of the
LSA process, it is necessary to use status codes to document the progress of the LSA anddocumentation work. The codes must reflect the status for all the different contractual relevant
analysis activities to be covered within the LSA process.
To increase effectiveness, it is recommended that the CIL or the candidate item identification
process, accordingly, be integrated as a central management tool into an LSA IT solution. Thisapproach enables linking the relevant management information to the corresponding items
within the Product breakdown. Appropriate evaluations or reports easily provide an overview ofthe project.
The customer and contractor must discuss, harmonize and document any change to the CIL
occurring for whatever reasons (eg, technical, budgetary, redesign). LSA and IPS managers forboth the customer and the contractor must consider the CIL as a valid document to control thewhole LSA process. The customer and the contractor must understand, at every stage of the
project, who is the holder of the CIL issue that is contractually valid.

7

Analysis activities in the context of an LSA process
In the early life cycle, LSA must support cost-relevant decisions by performing adequate frontend analysis like Level of Repair Analysis (LORA). Where necessary, analysis results must
influence design concerning supportability aspects from the beginning of the definition phaseand throughout the lifetime of the Product. The inputs for the design come from different

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 31

S3000L-B6865-03000-00

analysis sources such as reliability, maintainability, testability, or PMA. The performance ofanalysis activities for LSA candidates can cause concerns about its cost if there are no
established threshold to reduce the effort to a suitable level. It is necessary to perform a seriesof assessments to balance between analysis-related efforts and acquired knowledge, which ismandatory to identify adequate supportability requirements (that satisfy the user's needs andsupport cost constraints). The contractor must identify the related allocation criteria and rules
and propose them to the customer as general guidelines tailored to meet the specificrequirements of a given project.
NoteThis largely influences costs for the LSA program effort and future support activities during
the overall life cycle of the IUA. It is recommended that this task be performed on apreliminary basis as an initial assessment early in a project, and to harmonize the derived
strategy with the customer before signing a contract.

7.1

Principles for analysis activity selection
LSA candidates must only include analysis activities considered to be an improvement to theinvestigation results, in such a way that the expected benefit is greater than the effort spent for
the analysis activity.
Both the customer and the contractor must take into account the knowledge acquired by"lessons learned". This includes both positive and negative experiences. Based on thatknowledge, LSA relevant decisions can be predetermined without further analysis activities.
It is necessary to take into account new available analysis methods where feasible. For
example, a simulation result is much more comprehensive than a traditional analysis.
Note
Based on the experience of industry, powerful simulation software packages are available
and expected to be of interest for LSA purposes.

7.2

Potential analysis activities
The following activities are a list of potential analysis that, depending on the kind of project, canbe performed and documented in different ways.
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

analysis for the identification of general LSA needs
comparative analysis
human factor analysis
product breakdown and configuration assessment
reliability analysis assessment
maintainability analysis assessment
testability analysis assessment
corrective maintenance analysis, based on existing FMEA/FMECA
damage analysis
special event analysis
PMA
LORA
Maintenance Task Analysis (MTA)
Software Support Analysis (SSA)
operations analysis
simulation operational scenarios
Training Needs Analysis (TNA)In addition to the analysis activities listed above, it is possible to consider some other aspects,
such as:Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 32

S3000L-B6865-03000-00−−−

LCC, refer to Chap 14
obsolescence, refer to Chap 15
disposal (consideration of environmental regulations), refer to Chap 16

For each analysis activity, the contractor and the customer must agree whether, and how, todocument, deliver, comment, and assess the results. It is recommended that most of the resultsof the analysis activities be documented within the LSA data, but it is also possible to document
them as a special analysis report, or as an official document. Prior to any analysis, it isnecessary to clarify the required results and benefits from the collected data, and how the data
will be used for evaluation purposes.
7.2.1

Analysis for identification of general LSA needs
This is the starting point for any LSA activity, and is the basic precondition for any of thefollowing activities. During this phase, it is necessary to provide a justification for the analysis
performance. It is advisable to avoid using valuable resources for analysis work without aclearly defined objective. The identification of general LSA needs mainly relates to contractual,customer and user interests. In order to ensure that the customer addresses properly andagrees to the general LSA needs for the project, the following aspects must be addressed:−−−−

Consider the results determining Product use and general support data (ORD and CRD),
intended support strategy and principles, and alternative solutions. Clarify which scenarios
must be analyzed, how and to what depth
consider which contractual agreements must be verified by LSA results, how and to what
depth
consider the definition of required reports concerning areas of special interest (eg,management reports, status overviews, performance measuring reports, verification
reports)
Consider trade-off analysis results to guarantee the best return of investment. This means,for example, it is possible to use other methods to discuss customer demands and achieve
the goal. The alternative solution can require significantly less effort, but it must lead to acomparative result that meets the customer's requirements at a similar and acceptable level

As a result of these first considerations, the contractor and the customer must agree on the
purpose, goal, depth of analysis, and documentation method for each analysis type, in order tohave a common view on the performance of LSA. The LSA PP must include the result of thisanalysis.
7.2.2

Comparative analysis
Performance of this analysis occurs only by special request. As a precondition, comparative
information at equipment, system, or Product level must be available and effective for decision
making (limited to the initial LSA activities). If it is possible to define a comparative system,
appropriate analyses must be performed to derive applicable comparative data. For the
documentation of the results, it is necessary to identify special summary reports concerningcomparative factors and data and/or support alternatives addressed to comparable LSA
candidates.

7.2.3

Human factor analysis
The results of human factor analysis influence the LSA candidates for which an MTA is
performed. Human factors can be a reason for special limitations (eg, concerning theapplicability of a support task requiring special abilities). It is necessary to consider ergonomic
aspects, as well as the definition of rules for an appropriate man-machine interface. Refer toChap 6. Below are some aspects that can have limiting consequences for the performance of
maintenance and operational support:−−

ability to lift and carry heavy loads
ability to move for a long time in special conditions

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 33

S3000L-B6865-03000-00

−
−
7.2.4

handling of dangerous materials
limitations of personnel employment by law and/or security restrictions

Product breakdown and configuration assessment
During the LSA process, it is essential to perform an analysis to develop a structured view of the
Product.
−−−−

How is it structured?
Which functional systems and subsystems are included?
Which items (hardware/software) are installed, how often and where?
Are there different variants of the Product to be considered, and which different
configurations are applicable for which specific variant?

For more information how to develop an appropriate Product breakdown, refer to Chap 4.
In the case of significant deviating design configurations of any LSA candidate, configurationassessments are mandatory. It is necessary to examine potential changes to validity,
engineering, and deviations or waivers. Configuration assessments determine the need todeviate support concepts and/or support requirements (eg, personnel, material) in order to reassess the need for analysis activities on LSA candidates.
The customer and the contractor must clarify how to document the configuration deviations of
LSA candidates.
7.2.5

Assessment of reliability analysis
Reliability analysis is a part of the support engineering activities, referred to as Reliability,
Availability, Maintainability, and Testability (RAMT). It is necessary to assess reliability
predictions (eg, MTBF) related to the intended use scenario of the LSA candidates. Determining
reliability values is related to reliability analysis activities, but the documentation of certain
results of this analysis is important for LSA purposes. Normally, a reliability analysis ismandatory for each hardware LSA candidate. Additionally, it is recommended to extend
reliability predictions to all essential items of a Product breakdown and to ensure consistency ofthese values over all breakdown cascades.
Note
Reliability values are directly linked to the results of FMEA activities. Any concrete value,
for example the failure rate or MTBF of an equipment, is particularly interesting for LSA
activities, for example to calculate the frequency of a rectifying task.

7.2.6

Assessment of maintainability analysis
Maintainability analysis is a part of the support engineering activities, often referred to as RAMT.
For each LSA candidate, it is strongly recommended to perform a maintainability analysis todetermine, from a technical point of view, whether and how it is possible to support an item. It isnecessary to establish rules for related conditions and time frames and investigate alternative
repair solutions, if applicable. Where applicable, maintainability analysis addressing thefollowing aspects must be performed:−−−

assessment of maintainability features reflecting customer requirements
identification of maintenance and operational support tasks to develop an appropriate
support concept for each applicable LSA candidate
investigation of supportability aspects such as modular design of the Product, goodaccessibility, installation concept in special zones (the item with the worst MTBF must not
be installed behind other items)

In general, it is possible to perform the maintainability analysis by following applications withdifferent level of detail and effort:−

best engineering judgment in the case of lowest level of available information

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 34

S3000L-B6865-03000-00−−−

assessment with or without the need to transform information on the equipment provided by
the supplier. In case information from suppliers is required, apply data sheet templates toensure that every supplier will be able to deliver the required information correctly andcompletely. Harmonize these templates with the customer and the contractor (andcontractor suppliers).
take into account supporting analyses such as LORA with a view to compare alternative
support solutions on different maintenance levels or PMA methods, such as S4000P, inorder to complete the support concept for the IUA
use simulation tools for Products performing missions according to operational profiles,
focusing on maintenance and support while evaluating potential consequences, forexample from limited maintenance resources or changed operational profiles

Depending on the different types of items, it is necessary to perform the analyses given in Table
11 as a minimum level of analysis:Table 11 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

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

COTS items without major
modification

The customer must document and agree to any noncompliance of supportability features and/or requirements

Items currently available
requiring minor modification

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

Items currently available
requiring major modification

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 require careful documentation. Therefore, thecustomer and the contractor must define and harmonize maintainability reports (eg, a RAMT
case report). In addition to these reports, the support concept reflected by the identified
maintenance and operational support tasks will include the results of the maintainability
analysis.
7.2.7

Assessment of testability analysis
Testability analysis is a part of the support engineering activities, often referred to as RAMT.
The main aspects for a testability analysis to consider are:
−
−
−
−
−

identification of maintainability strategy aspects to be observed
identification of overall test architecture and test principles
identification and verification of contractual testability requirements
evaluation of FMEA/FMECA results concerning testability information
description of failure detection and localization methods at equipment, subsystem, system
and Product level

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 35

S3000L-B6865-03000-00−−

description of functional test requirements at all involved levels
identification of related resource requirements (eg, personnel, test equipment, test
software)

The testability analysis is closely related to the maintainability analysis. Results from testability
directly influence the maintainability analysis. Any corrective maintenance depends on theability to detect and localize the failure to be corrected. In addition, conditions must allow theperformance of a functional test of an item or a complete system after the repair. The depth of
failure detectability, localization, and verification is one of the most important factors influencing
an applicable maintenance concept.
Since it is nearly impossible to implement testability features after the finalization of the item, it
is necessary to describe and document the testability requirements for each applicable item
very early during the design and development phase. Testability capability must be planned
down to the level on which maintenance is intended.
For all items containing full Built-In Test (BIT) capability, a testability analysis is mandatory. It isnecessary to identify and document the related testability features. A testability analysis reportand a summary of the analysis are required. For items with reduced BIT capability (eg, COTS
equipment) that are somehow monitored within the overall test architecture, a testability
analysis is recommended. It is necessary to identify and document the related testability
features.
The types of data concerning testability features relevant for Product support activities must be
documented and harmonized with the customer. It is necessary to establish and verify the rules
for suppliers and/or manufacturers on how to implement testability features (eg, by testability
demonstrations/validations together with the customer and/or the contractor).
7.2.8

Corrective maintenance analysis
In the context of a supportability analysis process, the aim of a corrective maintenance analysis
is to assess existing FMEA/FMECA results to identify the potential failure behavior of a Productand the need for corrective maintenance tasks.
A clear distinction is made between functional and technical failures. A system FMEA
identifies/analyzes functional failures, while a so-called equipment or technical FMEA approach
identifies/analyzes technical failures.
Note
SAE ARP5580 provides a detailed description of system FMECA and equipment FMECA
methodology. S4000P describes the system FMEA applied for PMA purposes.

7.2.8.1

System failure modes and effects analysis
A system FMEA analyzes the different systems and subsystems of a Product using a top-down
approach to the potential functional failures, their functional failure effects with corresponding
criticality and finally, the corresponding failure causes. Refer to S4000P.
It is required to avoid potential failure effects that prove to be critical to safety, legal orenvironmental integrity. The same applies to other failure effects that are undesirable for
operational, mission, or economic reasons.
Analysis results are the baseline for the identification of the Preventive Maintenance Task
Requirements Interval (PMTRI) or, in the worst-case scenario, even for mandatory redesign
requirements, if no preventive maintenance task is applicable and/or effective. Refer to S4000P.
Additionally, safety analysis activities like a Fault Tree Analysis (FTA) are based on system andtechnical FMEA. That way, it is also possible to identify additional safety critical failure
combinations. Depending on probability values, redesign and/or preventive maintenancerequirements must be defined and harmonized with the PMA results. Refer to S4000P.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 36

S3000L-B6865-03000-00

7.2.8.2

Technical failure modes and effects analysis
A technical FMEA uses a bottom-up analysis approach to identify in detail the consequences
and the probability of technical failures, which can occur to any equipment within a Product. The
technical FMEA results help determining corrective maintenance tasks, such as repair orcomplete replacement of equipment, including task frequencies. Chap 7 describes how thetechnical FMEA results are used for LSA purposes.

7.2.9

Damage analysis
It is advisable to consider items susceptible to damage at least as partial LSA candidates. In
general, damage is a special event, and it is not possible to predict the criticality or extent forevery case. Nevertheless, it is useful to identify classes of damages that can be rectified and/or
detected in the same way. It is strongly recommended to use analysis types that at least
address initial diagnostic tasks and simple repair procedures (eg, simple repair of damages
such as scratches). The result of these analyses must be documented as specific maintenancetasks. For example, the standard test and repair procedures for structural items or for electricalwiring are collected within a non-hardware chapter of the Product breakdown.
Normally, reliability values concerning damages are not available, therefore general quantitative
statements are generally not possible. It can be possible to predict the required effort resulting
from damages only using statistical evaluations. It is recommended to use such predictions withcaution. Chap 8 describes how the damage analysis results are used for LSA purposes.

7.2.10Special event analysis
In addition to damages, which are more or less a specific type of special event, other events
can have an impact on the support concept for an IUA or for the Product. It is recommended to
identify and document probable special events that require special maintenance tasks toguarantee the proper functionality of the Product for further use. Refer to Chap 8. Those special
maintenance tasks are a part of the preventive maintenance that a proper task selection
process must determine for each relevant special event. The selection process determines thePreventive Maintenance Task Requirements Event (PMTRE). Refer to S4000P.
Examples of special events that require maintenance tasks are, but not limited to:
−
−
−
−
−
−
−
−

7.2.11exceeding 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)Preventive maintenance analysis
PMA aims to avoid critical failures. This includes critical failures concerning safety, law,environmental regulations, operation and/or mission completion and economic aspects. This
analysis is mandatory for aspects relevant to safety, or concerning law and environmental
regulations. It is strongly recommended in case significant economic disadvantages can be
expected or if there is a risk in operating the Product or completing a mission. The PMA is anextensive analysis and the results have direct impact on the support concept and in worst caseon Product design. It is necessary to document the requirements for preventive maintenancetasks identified by a PMA. It is recommended that rules be established to harmonize PMA
results with the documentation method within the LSA program.
Each item for which at least one PMTRI is identified via a PMA process must become a full LSA
candidate.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 37

S3000L-B6865-03000-00

7.2.12

Level of repair analysis
Depending on the general support strategy, it can be necessary to decide the maintenanceand/or repair level of each item. To support this decision, it is possible to perform a LORA by
applying one of the available methods, which will depend on the type of LSA candidate to beanalyzed, the required effort and/or the available information. Depending on LSA GC
agreements, there can be different LORA approaches. Refer to Table 12.
Table 12 LORA approaches
LORA
classification

Description

Simplified LORA

The best engineering judgment derives the simplified LORA by taking
into account the best information available. The results of this analysis
must be documented and harmonized with the customer for example bymeans of a "simplified LORA report".

Economic LORA(ELORA)

An ELORA approach is a front-end analysis using LORA software
packages based on mathematical models of different complexity andaccuracy. All required data concerning the item itself and its context ofuse (eg, operational scenario, spare part provision, and cost elements
relevant for the support) must be available to perform this type of
extended analysis.

Analysis via
simulation

A simulation that considers detailed information about the IUA, its
deployment and operational scenario can produce the best LORA
results. To use a simulation software package, a complete set of
information/data at the required depth and format is necessary. The
preparation of this data can require a considerable effort.

Note
As shown in Fig 7, MTA information can be relevant for LORA activities. In general, aspecific LORA data set is required to perform the analysis. This data set contains basic
MTA information, as well as information about costs for IPS elements and information about
the support organization on the operator's side.
After determining the support concept, the full MTA will be performed as required. It isadvisable to avoid the creation of extended MTA data for tasks later performed at industry
level.
7.2.13

Maintenance task analysis
The MTA is one of the central analysis activities within the LSA process. Here, the identified
support tasks (preventive and corrective maintenance, as well as operational support) aredescribed in detail using all required available information. The following list gives a shortoverview. For more information, refer to Chap 12.
−
−
−
−
−
−

documentation of general information on tasks, such as preconditions for task performance,
training requirements or criticality information
assignment of maintenance tasks to the identified events (eg, failures, damages, special
events, intervals or thresholds for preventive maintenance tasks)
concise task description, including the sequence of subtasks
identification of required task resources (eg, personnel, support equipment, spares,
facilities and infrastructure, software)time estimations
calculation of task frequencies

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 38

S3000L-B6865-03000-00−

7.2.14

consideration of required pre- and post-work (eg, gaining access, final test, release byinspector)

Software support analysis
Each item containing user-loadable data/software must be analyzed with respect to loading,unloading, transportation and documentation of existing software releases. This covers
maintenance and servicing tasks applicable for:−−−maintenance of hardware containing user loadable data/ software
data and/or operational software required for preparation for use
software support to update items with new user loadable software releases

If a Software Support Analysis (SSA) program manages software changes, releases, andupdates in case of software failure (bug fixing), it is necessary to establish a process alignedwith the LSA process for hardware. It is important to agree that any change in the software
source code is an item modification, and that is not possible to regard it as a maintenance task
in the context of a repair activity. Refer to Chap 13.
7.2.15

Operations analysis
It is necessary to analyze operational support requirements to identify and document important
support tasks for the general handling of the entire Product, or the handling of equipment that ispart of the Product in the context of PHST and/or servicing. It is also necessary to determine themethod to perform the task and the required resources. Refer to Chap 9.

7.2.16

Simulation of operational scenarios
Performance of this analysis occurs only by special request. Simulation represents a very
powerful tool to evaluate operational scenarios in combination with support scenarios.
Simulation software packages offer the opportunity to analyze and optimize the planned use ofa Product or of a combination of several Products (sometimes also described as a system ofsystems) under particular operational and support conditions. Only the combination of planned
use scenario and planned support scenario allows generating meaningful analysis results. It is
possible to achieve better results with a detailed description of the scenario.
Simulation analysis can require a multitude of input data at a certain level of depth. If simulationis selected as a required analysis activity, it is recommended that the examination of therequired data of the simulation software package be started early in the project. The decision to
perform simulation can influence the depth and quality requirements for any supportability
information/data (eg, the detailed description of a support scenario can require additional effort
within an MTA). Also, the creation of an operational scenario can require additional effort fromthe customer.

7.2.17

Training needs analysis
Within this analysis, it is necessary to determine whether a task requires special training or not.
If training is required, it is necessary to determine how to provide the training in the mosteffective way. LSA data can effectively support this analysis process.
During the LSA GC, the customer and the contractor must discuss and harmonize the criteria
for training requirements. It is possible to evaluate LSA data against those criteria to support apreliminary TNA decision. It is recommended that an IT-supported process for the TNA beestablished.

7.3

Analysis relations and general overview
All the analysis activities described in Para 7.2 are interconnected and can influence each other.
Some analysis can be a basic precondition for other ongoing analysis processes. Someanalysis activities are of general significance for all other analysis processes. Fig 7 shows agraphical representation of the relations between the different supportability analyses.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 39

S3000L-B6865-03000-00

ICN-B6865-S3000L0018-002-01
Fig 7 Analysis activities relations and overview

7.4

Analysis activities selection criteria
It is necessary to consider the aspects given in Table 13 in order to select and allocate LSArelevant analysis activities to LSA candidates that are applicable and effective depending on thetype of items, candidates and required information.
During the LSA GC, the customer and the contractor must harmonize the selection criteria andaspects, and tailor them to each project by taking into account any specific circumstances.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 40

S3000L-B6865-03000-00

Table 13 Analysis activities selection criteria
Criteria group

Criteria

Recommendation

Items with existing
experience

Items already in use undercomparable conditions

Transformation of existing analysis
data

Items already in use but notunder comparable conditions

Transformation of existing analysis
data

COTS items usable withoutmajor modification

Transformation of existing analysis
data

Items currently available thatwould require (minor/major)
modification

Transformation of existing analysis
data or performance of new analysis

Newly developed items basedon well-known technology

Recommended performance ofanalysis activities at the required
depth

Newly developed items basedon new technology

Mandatory performance of analysis
activities at the required depth

Potential readiness drivers
and/or cost drivers

Criteria for these items must be
detailed within the LSA GC

Of particular interest to thecustomer

Items must be detailed within the LSA
GC

Subject to LSA-related
contractual fulfillment

Items must be detailed within the LSA
GC

Item is significant for
maintenance with respect to therelated failure/defect frequency,
workload, special support
requirements (personnel and/or
material)

Criteria for these items must be
detailed within the LSA GC

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

Items that needassessment for
inherent reasons or
due to theinstallation area

Item is subject to preventive
Data transfer from PMA results tomaintenance (PMTRI or PMTRE LSA must be detailed within the LSA
available)
GC

Type of LSA
candidates

Item is potentially susceptible todamage due to its installation
area or its technology

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

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 41

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
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,support concept, support
requirements)

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

Proposal of recommended
support concept, including
corresponding tasks

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

Estimation of related support
costs

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

7.5

Checklist for analysis activity recommendation

7.5.1

Analysis activities recommendation sheet
For the LSA GC, the contractor must prepare a recommendation matrix, based for example on
the CIL, identifying the LSA candidates, the selection criteria for analysis activities and somepreliminary recommendations, if applicable.

7.5.2

Analysis activities decision sheet
The recommendation matrix will be harmonized and finalized during the LSA GC, and reflects
the decisions made by customer and contractor. The recommendation matrix can be a part of
the CIL. It must be a living document in order to reflect changes, incorporate the results of thelessons learned, and enable traceability during the life cycle phases of the project. It is
recommended to include in the commercial proposal a preliminary recommendation matrix
including the best information available to provide the customer with a general guideline for LSA
activity allocation and reduce risks.

7.5.3

Selection example
To identify the relative importance of the allocated analysis activities, it is possible to agree on
the ratings concerning the importance of the selected LSA candidate, as well as the importanceof the potential analysis activity. The result helps ranking LSA candidates and analysis activities
from mandatory to voluntary. Such a ranking can be used to refine the selection ofcandidates/analysis activities, for example in case of limitations of budget or time constraints.
The results of this selection procedure will compose the initial issue of the LSA CIL, as well as
the range of LSA activities considered to be relevant and effective for the LSA candidates. The
industry partner companies must identify and harmonize appropriate rules, and the customer
must agree to them during the LSA GC.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 42

S3000L-B6865-03000-00

ICN-B6865-S3000L0019-003-01
Fig 8 Example of a recommendation sheet for analysis activities
Fig 8 shows an example of a tailored recommendation matrix for the selection of analysis
activities (based on a simple mountain bike example). For a real project, it can be necessary to
add more analysis activities or further details. For example, a special software package canhelp divide the performance of a LORA into categories, such as simplified LORA or ELORA.
Additionally, it is possible to provide further details on the rating values.
Note
If considered as part of the LSA program, other considerations such as obsolescence, LCC
or disposal analysis can be added to the matrix.

7.6

Analysis workflow processes
In the different project phases, different sets of data/information are available for the executionof the supportability analysis activities. The performance of some of the activities described canoccur during an early phase of the project. Alternatively, the performance of some of theactivities can only occur when detailed and final information on the design is available. For
example, it is possible to carry out an extensive MTA during a later stage of design, because
this analysis requires detailed information. Refer to Fig 9.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 43

S3000L-B6865-03000-00

ICN-B6865-S3000L0020-003-01
Fig 9 Position of LSA activities in the overall project schedule
Supportability analysis activities continue after the end of the design and development phase.
Within the next phases (production, in-service), supportability analysis can be required multiple
times, depending on the modifications being made to the Product.
This is especially relevant for the in-service phase, which is normally the longest phase. There
will be extensive modifications during the in-service phase and, depending on the modifications,
supportability analysis will be necessary again at the corresponding depth. As a result, theiterative LSA/IPS process will reappear repeatedly. Therefore, it is recommended that
supportability data and decisions be documented throughout the entire project, ending with thedisposal phase. Even for this final phase, it is necessary to consider supportability aspects.
Note
In many projects, it is not possible to draw a clear line between the phases. As a matter offact, design and development phases and production can significantly overlap, and thesame holds for production and in-service phase.
7.6.1

Supportability analysis activities in the preparation phase
In the preparation phase of a project, the supportability analysis activities can be limited to thoserequiring a low level of information. Before the LSA GC, information about the operational andcustomer requirements is usually made available, and drafts for basic rules for the LSA process
are prepared.
At this stage, detailed information on the Product or the IUA is usually not available. Basic
conditions and rules for the application of the process must be available during the early stages.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 44

S3000L-B6865-03000-00

Nevertheless, some analysis activities can, or even must, start during the early stages of the
LSA process:
−
−
−
−
−
7.6.2

analysis for identification of general LSA needs
comparative analysis
human factor analysis
operations analysis
first concepts for Product breakdown methodology and configuration assessment

Supportability analysis activities in the design and development phases
During the design and development phases, the LSA process accompanies the design process.
This applies to almost all LSA activities, except for the activities that must be performed in avery early phase or after a design freeze. The activities that must accompany the design anddevelopment phases are:
−
−
−
−
−
−
−
−
−
−
−
−
−

Product breakdown and configuration assessment
reliability analysis assessment
maintainability analysis assessment
testability analysis assessment
corrective maintenance analysis
damage analysis
special event analysis
PMA
LORA
MTA
software and data uploading/downloading/transportation analysis
SSA (software design and software maintenance)
operations analysis

Sometimes, the collection of supportability relevant data is almost complete after the design
freeze. Therefore, analysis activities that need many detailed data must be performed at a laterstage of the design process, to guarantee a fixed design and reduce the risk of repeating costly
analysis activities. This applies to:−−simulation of operational scenarios
TNA

7.6.3

Supportability analysis activities in the production phase
Because the improvement of a Product by ongoing design and development activities does notstop when the production phase begins, the supportability analysis activities also continue
during the production phase. Design and development phases and production phases often
overlap. For that reason, although the production phase has already started, it is necessary toensure an ongoing supportability analysis process during the production phase as well, to take
into consideration any potential design change to the Product. In some cases, production needs
can also cause design changes which must be considered.

7.6.4

Supportability analysis activities during the in-service phase
During the in-service phase, the supportability analysis activities will repeat to a lesser extent. If
the Product has technical upgrades or design changes, it is necessary to perform new analyses
concerning supportability requirements. The depth and range of these analyses will depend on
the type of IUA and the degree of change.
As a second aspect, it is recommended to monitor an established support solution with respect
to efficiency and cost. For this purpose, optimization processes can be performed as the InService Maintenance Optimization (ISMO), refer to S4000P, and the In-Service Support
Optimization (ISSO), refer to Chap 17.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 45

S3000L-B6865-03000-00

7.6.5

Summary of activities over the life cycle phases
Table 14 shows a summary of the potential analysis activities over the entire life cycle phases(eg, data and information collection, management, and technical/supportability analysis andpreparation tasks). In this table, the design and development phases additionally contain review
thresholds relevant to each phase, for example a Preliminary Design Review (PDR) and a
Critical Design Review (CDR).
Table 14 Summary of LSA activities during the life cycle phases
Preparation
phase

Design and development phases
Feasibility
study

Preliminary
Design
Review (PDR)

Critical Design
Review (CDR)

M-studiesM-analysis

M-analysis
updates

R-studies

R-analysis

R-analysis
updatesComparative
studiesComparative
studies
updates

Production
phase

In-service
phase

Disposal
phase

Performance Performance
Product data Product data
(CRD)
updates(CRD)
Product use
data (ORD)

Comparative
studies

Product use
data updates(ORD)

Planning ofdevelopmentof IPS
elements

Developmentof IPS
elements

Ongoing
optimization of
supportconcept
based onfeedback data in-service
LSA
Update of
IPS
elements

Update ofrelevant
analysis
results and
IPS products
based onconfiguration
changesPlanning ofdisposal

8

Customer involvement
To ensure that the interpretations and approaches to the LSA process by the industry and thecustomer are in line with one another, the customer must be involved to an appropriate extent
during the whole LSA program. It is necessary to cover the customer's involvement with respect
to the selection of LSA candidates, relevant analysis activities and resulting analysis data, 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 determination of appropriate analysis
activities must be considered as the aspect of the LSA process with the highest impact on

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 46

S3000L-B6865-03000-00

costs. For that reason, it is necessary to perform and assess these selections with care during
an early project stage. To reduce risk, it is advisable to carry out an initial selection, or at leastan estimation, concerning the expected number of LSA candidates prior to the signing of thecontract.
In general, the contractor must select the LSA candidates and the related analysis activities
relevant to LSA based on a Product breakdown, as detailed in Para 6 for LSA candidate
selection, and in Para 7 for recommended analysis activities. The contractor must forward theresults to the customer for assessment purposes and the related analysis activities be assessed
between both parties to reach a well-balanced decision.
8.1.1

Establishing LSA assessment rules
The customer must agree to the assessment of the proposals, and the parties must establish
some general rules concerning principles for the assessment. These rules must include at least:
−
−
−
−

−
8.1.2
8.1.2.1

Initial assessment and re-assessments
Initial assessment
During the initial assessment, it is necessary to consider principles, such as:−−−−

8.1.2.2

only aspects concerning rules established during the LSA GC, or rules that the customer
and contractor can agree to within the subsequent LSA process (eg, during LSA reviews)
must be considered as relevant for the assessment
if an assessment has been performed and has reached a successful final clarification, there
is no need to reassess it, unless new aspects have emerged and are relevant to theassessment
it is necessary to establish rules concerning time limits between the release of LSA
deliveries and an adequate response, as well as the consequences for failure to observe
those rules
Both the invitation for assessment of details within the contractor's LSA deliverables andthe assessment result must be documented by using adequate status information. The
contractor is responsible for the structure and information details of the status codes, but
the contractor must coordinate with the customer. Refer to Para 9.4.
any status information concerning each LSA candidate must be up to dateIs the Product breakdown considered in line with the rules established during the LSA GC,
especially the rules concerning its structure, content and depth?
Are rules for the selection, for non-selection or non-recommendation of LSA candidates
available and sufficient?
Is the selection of LSA candidates and relevant analysis activities in line with the rules
established within the LSA GC?
it is necessary to document the assessment results and pass them to the contractor
according to the established assessment procedure, with a follow-up until a final
clarification status is reached?

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

items released by the contractor and 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 differences with respect to prioragreements

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 47

S3000L-B6865-03000-00−

it is necessary to document the assessment results and pass them to the contractor
according to the established detailed assessment procedure, with a follow-up until a final
clarification status is reached

8.1.3

Establishing an assessment procedure
It is necessary to establish a detailed assessment procedure (including an appropriate
commenting process) tailored to the specific requirements of the individual LSA program andcomprising the above elements. The customer and contractor must harmonize this procedure.

8.2

Information exchange between customer and contractor
To proceed with the LSA process, the customer must inform the contractor on the assessment
results that are relevant to the agreements/disagreements, along with the reasons for any
disagreement. In addition, there can be general comments covering global aspects and/or
general questions. It is necessary to separate these comments and questions from the othercomments, as they usually need a special response (eg, a dedicated explanation or request for
special training).
This is not limited to LSA candidates and the related analysis activities, but it also applies todetailed results of the analysis process and to a response on any official LSA report.

8.2.1

Commenting process
It is necessary to establish a structured commenting process to facilitate the management ofcomments and enable traceability. This process includes as a minimum:−−−

registration and official comment on any LSA delivery from the contractor to the customer
released for assessment
documentation of any customer agreement
documentation of any customer disagreement, along with the related reasons. Affected
items must be monitored until final clarification has been reached and the clarification is
documented.

To address these subjects, the commenting process must cover the registration of LSA
deliverables, comments, and LSA status. This includes:−

Registration of LSA deliverables:
Any LSA delivery that needs assessment must be registered according to the agreed rules−

Registration of comments:
It is necessary to document the customer's response for each LSA delivery released forassessment. Depending on the consequences of the customer's response, each applicable
LSA candidate must have a registered status.

−

Registration status information:
The structure of an LSA status code must comply with different information requirements
for the released LSA candidate (refer to Para 9.4)

Note
If the customer can access the actual LSA data in the LSA program, it is recommended thatthe customer involvement be organized within the LSA IT environment.
8.2.2

Informing the contractor by the customer
As agreed in the established commenting process, the customer informs the contractor about:−Agreements concerning released LSA deliverables:
The contractor will document any customer agreement according to the establishedmanagement rules. In the case of a consortium, all companies involved in the contractor
network must receive all the information on the related rules.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 48

S3000L-B6865-03000-00−

Disagreements concerning released LSA deliverables:
In these cases, the contractor (or the involved company) will investigate the customer’s
disagreements to identify adequate responses (eg, further explanation, proposed rework byindustry). The contractor will forward the responses to the customer in order to reach an
agreement (in an iterative manner, if required).

−Unresolved issues:
In case of iterative commenting cannot resolve an issue, an adequate solution is necessary
to reach a final clarification.

Fig 10 is an example of a simple process of information exchange between the customer andthe contractor. Fig 10 Process of information exchange between customer and contractor(example)
Table 15 gives an explanation of the time intervals.

ICN-B6865-S3000L0021-003-01
Fig 10 Process of information exchange between customer and contractor (example)
Table 15 Explanation of schedule for the commenting process
Time

Activities

To

The contractor starts preparing the LSA delivery items. This preparation can
include the integration and harmonization of data between one or more
contractors, in case of a contractor consortium.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 49

S3000L-B6865-03000-00

Time

Activities

T1

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

T2

Between T2 and T1, the customer will comment the delivered items (eg, LSA
data, LSA reports). At the agreed point of time T2, the customer will deliver thecomments to the contractor.

T3

If possible, the contractor must handle any comment that can be answered
easily, before the LSA review, with a view to reducing the effort of the LSA
review. Nevertheless, it is necessary to document carefully any decision
concerning the customer's comments.
During this time, more than one question-answer loop can clarify specificquestions in detail. However, the number of loops must be limited since more
extensive questions require clarification (eg, at the LSA review or by a longer
clarification process between the contractor and customer).

T4

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

TReview

Time of LSA review. It is necessary to ensure the documentation of every
decision in the LSA review by updating the corresponding status information.

8.2.3

Final clarification on open issues
For any remaining open issues, it is necessary to identify an adequate solution. If this is notpossible during a regular review session, a meeting of dedicated specialists can be required toreach a satisfactory final solution.

8.2.4

Customer decision (status influencing)
Normally, it is required to distribute an LSA delivery for assessment to different recipients (eg,different authorities in different nations and, since LSA is interdisciplinary, to all involved
supportability stakeholders). Subsequently, it is necessary to collect and harmonize (in case ofdeviating responses) individual comments to provide one official customer response.
Note
It is important for the contractor to receive only one official customer response in order tocarry out the LSA process in a manageable way. The customer must provide the decisions
in the form of 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) must be documented as well, as part ofthe contractor response and it must remain untouched for traceability reasons.
For LSA program traceability, there are two ways to document the LSA delivered as proposed
for assessment and the customer's response (if applicable, including final clarification results):−−

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

In the case of essential documents such as LORA or PMA results, the resulting
recommendation/decision documents can facilitate some clarification requirements.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 50

S3000L-B6865-03000-00

Within the contractor's LSA documentation, it is necessary to update the corresponding status
codes concerning the involved LSA candidate. However, contractor's information can supersede
the status code allocated by the customer (eg, on-going work status, required deletions).
8.2.5

Exchange of analysis data with the customer
Exchange of analysis data must include, but is not limited to, the following steps:
−
−
−
−
−
−

8.2.5.1

Establish appropriate rules for data and document exchange
During the LSA GC, the customer and the contractor must document and determine appropriate
agreements and rules. For example:
−
−
−
−
−
−

8.2.5.2−−

distribution of the LSA deliverable (directly or via a designated management unit) by taking
into account the agreed distribution rules including the due date, if applicable
contractor internal documentation and distribution of the official LSA delivery

Customer assessment and distribution of assessment results
During the LSA GC and the subsequent LSA agreements, the customer and the contractor must
document and determine appropriate agreements. This includes, but is not limited to:−−−

8.2.5.5

establish 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

Delivery of LSA data/documents by the contractor
During the LSA GC and the subsequent LSA agreements, the customer and the contractor must
document and determine appropriate agreements. This includes, but is not limited to:−

8.2.5.4

software to be useddata and report formats (eg, XML-format for LSA data and MS Excel for reports orevaluations)periodicity
other reasons for delivery
distribution partners
binding sequences

LSA data and document collection by the contractor
During the LSA GC, the customer and the contractor must document and determine appropriate
agreements. This includes, but is not limited to:−−

8.2.5.3

establish appropriate rules for data and document exchange - Refer to Para 8.2.5.1.
LSA data and document collection by the contractor - Refer to Para 8.2.5.2.
delivery of LSA data/documents by the contractor - Refer to Para 8.2.5.3.
customer assessment and distribution of assessment results - Refer to Para 8.2.5.4.
distribution of customer responses by the contractor - Refer to Para 8.2.5.5.
distribution of contractor responses on rejected comments - Refer to Para 8.2.5.6.

distribution of the contractor's LSA delivery, as required
harmonization of the individual responses to one official customer response
distribution of customer response to the contractor

Distribution of customer responses by the contractor
During the LSA GC and the subsequent LSA agreements, the customer and the contractor must
document and determine appropriate agreements. This includes, but is not limited to:−registration of the official customer response

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 51

S3000L-B6865-03000-00

−
−
−
−

distribution within the industry
identify, distribute and harmonize the contractor investigation results
update of the LSA data according to the customer response details (as much as possible)
preparation of harmonized contractor response to general comments and disagreements

8.2.5.6

Distribution of the contractor response on rejected comments
The steps concerning iterated analysis data from the contractor are applicable. Para 8.2.5.3
describes them.

9

LSA review conference
The contractor and customer personnel must take part to the planning of the LSA Review
Conference (LSA RC), in order to:
−
−
−
−
−

9.1

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

LSA review process
The LSA RC must be conducted at LSA candidate level. Prior to the conference, the contractor
must inform the customer about the LSA candidates under discussion.
During the LSA RC, it is necessary to assess and take decisions on the related LSA deliveries
and the relevant data elements, by taking into account established acceptance criteria. Any
decisions must be documented.
Depending on the type of information available at different project stages, complex LSA CI canrequire a sequence of analysis activities distributed over a long period. On the other hand, somedecisions must be made very early in the project, based on limited information (eg,establishment of a preliminary support concept), while other decisions require a stable designthat is not typically available until a very late stage (eg, final task description in the context of an
MTA). Therefore, it is possible to establish a set of review steps to enable sequenced decisions
in line with the structured analysis process. Furthermore, the overall review process can bedivided into different review steps, each supported by coherent information. Review step
indicators can help identify the review steps (refer to Para 9.3). It is necessary to define thedata/information required for each review step.
Due to the iterative nature of an LSA process, any approval given during an LSA RC must be
considered a temporary assessment, but it must allow the contractor to continue with the LSA
process. Because of the iterative nature of LSA, it is possible to re-examine the data due tochanges in the design, the updating of technical data and/or the support or operational
environment.
The final results documented within the LSA data (eg, at the end of each project phase) must be
considered as fixed. During the LSA GC, the parties must agree to the related acceptancecriteria.
The evolving design and the progress of the intended analysis activities must be the basis of the
LSA RC. These meetings must take place regularly within an agreed time frame or dependingon the amount of information to be assessed. Minutes of each LSA RC must be prepared torecord the results and give evidence of the actions that the customer and the contractor musttake. Updating related LSA data in accordance with the results of an LSA RC is a required
iterative activity.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 52

S3000L-B6865-03000-00

9.2

Subject for review
In general, during an LSA RC the review will concern any contractual item agreed upon duringan LSA GC, or items agreed upon in subsequent agreements entered into by the customer andthe contractor. In addition, during an LSA RC it will be possible to discuss any aspect that canbe identified as essential for the LSA process or that could influence other support processes
with interfaces to the established LSA program. The aim is to determine modified or additional
LSA activities. The customer and the contractor must coordinate any occurrence within the LSA
process that require common assessment in order to correct any essential problem.
The contractor must provide the customer with introductions to procedures and/or principles of
LSA relevant analysis required. This will help reach a common understanding of the goal ofanalysis activities, related restrictions, and essential LSA results including the introduction to
global analysis work flowcharts. Refer to Fig 3 and Fig 4.
The contractor must provide progress reports and assessment summaries on data quality, as
well as summary reports reflecting useful information for the customer. Said reports can include,for example, a set of supportability KPIs:
−
−
−

9.3

mean man hours per operating hour
failure localization capability, such as the percentage of successful failure localization to
one component within an LRU (ambiguity group/level 1)
Mean Elapsed Time (MET) for support tasks that occurred within specified limits, along withthe related percentage (eg, 90% of LRU replacement tasks must be performed in less than
2 hours)

Example for review structuring
The structure of a typical review process can have a series of steps. This way, it is possible tocover different aspects and/or types of information at different stages of the overall analysis
process. The arrangement of the steps will depend on the project requirements and will realize
LSA data release and acceptance within the LSA review process. Example:
−
−
−
−

9.3.1

LSA review step - CIL and maintenance analysis allocation. Refer to Para 9.3.1
LSA review step - Identification of task requirements. Refer to Para 9.3.2
LSA review step - Maintenance Task Analysis (MTA). Refer to Para 9.3.3
LSA review step - LORA results and support concept information. Refer to Para 9.3.4

LSA review step - CIL and maintenance analysis allocation
This step is the basis for all subsequent LSA activities and includes:−−−

BEI allocation and BE realization by corresponding parts. Refer to Chap 4
LSA CI selection including grouping candidates, where applicableidentification of the type of candidate and related attributes, such as:
•
•
•
•

−
−
−

9.3.2

identification of LRU
potential cost drivers
potential maintenance drivers
potential readiness drivers

allocation of LSA relevant analysis activities to be performed for each selected candidate
status code providing details
management and documentation of any update regarding changes in the design
configuration at CI level

LSA review step - Identification of task requirements
In this step, the support engineering analysis results help identifying the task requirements. The
task requirements cover at least:

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 53

S3000L-B6865-03000-00

−
−
−

9.3.3

LSA review step - MTA
In this step, the support tasks based on the identified task requirements will be analyzed todetermine the methodology and resources needed for task performance:
−
−
−

9.3.4

corrective maintenance task requirements, such as requirements justified by FMEA results
PMTR, such as requirements justified by PMA results
operational support task requirements, such as requirements justified by PHST analysis
results

description of the required maintenance tasks in applicable detail and depth
duration of each task step
identification of related resources required to support the maintenance activities (eg,personnel, support equipment, spare parts, consumables, facilities and infrastructure, dataand software)

LSA review step - LORA results and support concept information
In this step, a support concept recommendation will be prepared by allocating tasks to acorresponding maintenance level and relevant facilities. This task typically includes:−−

support concept recommendation proposed by the contractor
identification of maintenance tasks relevant for equipment integration into the Product, such
as:
•
•
•

−
−

9.4

gain access and then restore the item to the initial statusremove and install equipment
perform functional tests at equipment and system level, as required

substantiation concerning the proposed support concept as required (eg, LORA results,
applied method or procedure, main influencing aspects to be considered, other analysis
applied or assessed to perform LORA)
customer decision on the support concept which could be rejection or alternative solution

Status code
A status code reflects the review process structure, and addresses contractual issues that
require documentation within a project. Typically, status codes are assigned to LSA candidatesor also to support tasks to document the progress of the analysis activities and customer's
acceptance of LSA data. This part of a status code serves as an indicator of the review step
progress. Additionally, status codes can include further management or technical information,such as:−−−The responsibility of the companies involved. For each task group, it is necessary to identify
the responsible company. This also reflects the agreed work share details concerning thissubject.
the type of LSA candidate (eg, full, partial)
technical aspects (eg, LSA candidate contains user-loadable software and/or data)

Table 16 gives examples of codes that correspond to different status situations:
Table 16 Examples for status codes
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

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 54

S3000L-B6865-03000-00

Code

Description

A

Customer (temporarily) agrees to the review step content

B

Customer assesses the review step content and in principle (temporarily) agrees toit. However, minor rework is expected prior to final acceptance. In terms ofcontractual status, "B" can be treated like "A".

O

Customer did not agree to the review step content, which remains an open issue

The contractor can also use a status code internally in order to give a stop or go status to the
IPS elements, to avoid any risk when creating the IPS products like technical publication.
During the LSA GC, the customer and the contractor must agree upon the intended review
steps, as well as the related status code structure and applicable status codes.

10

Starting point and management of the creation of the IPS
products

10.1

Starting point recommendations
During a design and development phase, several factors influence the starting point for thecreation of the IPS products. The main driver is the required availability of the IPS products, forexample technical publications or an illustrated spare parts catalogue. However, the productionof the IPS products needs a mature situation concerning the basic supportability
information/data provided by the LSA process. There must be a balance between the risk tocreate IPS products that will be rejected at a later stage, and the need to make the IPS products
available in time. Design changes, modifications to the use scenario and/or the basic support
concept have a significant influence on the IPS elements. IPS elements to be considered
include:−−−−technical publications
material support
standard and specific support equipment
personnel and training

Note
Facilities and infrastructure must be considered an IPS element not directly dependent on
LSA results. Decisions on the need for facilities and infrastructure are typically made at an
early stage of the project because the qualification and realization phases are usually
longer. However, during the LSA process it is possible to develop some detailed
requirements for specific equipment needed within a facility (eg, a workshop).
10.1.1

Technical publications
In general, technical publications consists of two main parts:−−

handbooks for Product maintenancehandbooks for Product operation, including real use (eg, how to drive a truck) andoperational support (eg, how to tow a truck)

Depending on the progress of supportability analysis during a design and development process,the LSA results become more precise. It will be possible to determine the basic support
concept, the required personnel, support equipment and spares, as well as details on how thetask will be executed (task description). Therefore, the development of technical publications
concerning Product repair and maintenance must commence at a later point. Accurate
information from the LSA activities will decrease the risk of inaccurate technical publications,which can lead to rework.
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 55

S3000L-B6865-03000-00

In some cases, however, the development of technical publications must start early because oftime constraints and contractual preconditions. The documented LSA data are the basis for thedevelopment of the technical publications providing details on Product support tasks. It is
recommended that an effective solution to trigger the development of technical publications be
implemented. The contractor’s LSA/support engineering and the technical publications
departments must harmonize this process. A good solution is to use the status information for
LSA candidates, or even for support tasks, and the mechanisms for drafting technicalpublications as described in S1000D.
Fig 11 shows the correlation between LSA and technical publications.

ICN-B6865-S3000L0022-005-01
Fig 11 Correlation between LSA and technical publications
Generally, the development of the technical publications for the operation of the Product isindependent from the LSA process. However, it is recommended that this documentation (eg,for a prototype of a technical system ready for testing and qualification) be made available as
early as possible. It is particularly important to consider the information acquired fromoperations analysis activities. The tasks described and documented in this area can be part of
the technical publications for both Product maintenance and Product operation. In this case, therecommendations for the maintenance documentation are also valid for the results of operation
analysis.
The technical publications for Product maintenance and operational support must reflect eachsupport task identified and documented within the LSA data.
However, the technical publications for Product repair and maintenance can contain further
information in addition to the documented LSA tasks. In fact, sometimes it is not possible toinclude each single maintenance activity within the LSA data (eg, because of budgetary
reasons). Not every part will be an LSA candidate. The LSA must aim to analyze, in depth, theactual drivers for maintenance and cost. It is also necessary to consider the remaining
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 56

S3000L-B6865-03000-00

equipment or piece parts that require technical publications. During the corresponding GC, thecontractor and the customer must clarify the depth and extent of this additional technicalpublications.
To guarantee a meaningful information flow between the LSA and technical publications, it isrecommended that the LSA and the technical publications department exchange information
concerning the status of work on a regular basis. In this way, the technical publications
department can be constantly updated on all relevant information needed to start thedevelopment of the technical publications. Aspects that should be covered include, but are notlimited to:−−−−

10.1.2Is the relevant support task ready for technical publications?
If the status of the LSA task is "Not ready for technical publications", what are the possible
risks in producing technical publications regardless of the status?
Is there a blocking status in LSA, which prevents the production of technical publications?
Are there any additional activities that the technical publications must include, which are nota part of the documented LSA data (no trigger from LSA for those aspects)?

Material support
The identification of relevant spare parts and specific consumables is a main task within the
LSA process. The identification of spare parts reflects the depth of the breakdown and theextent of the analysis activities. Depending on the support concept, the identification of spareparts and specific consumables can differ drastically. For example, in a simple 2-level
maintenance scenario, the complete equipment will be replaced, and the operator of the
Product will not perform any repair activity. In this case, only a small number of spare parts willbe identified. However, it is possible to identify additional spare parts such as standard parts(eg, screws, nuts) as being additionally required within a replacement task of the equipment.
The depth of the Product breakdown within the LSA is a crucial point. Theoretically, a very
detailed Product breakdown which even includes piece parts is possible, but the effort is huge
and unacceptable from a project's point of view. Therefore, the identification of spare parts
within the LSA process stops at a certain level. Typically, the maintenance and cost drivers are
identified within the LSA process. This information is documented within the required resourcesof any maintenance and operational support task within the LSA data. For material support, it isnecessary to establish a process like the process described for technical publications.
Depending on the progress of the supportability analysis activities, LSA-relevant maintenanceand cost drivers must trigger the creation of the IPS products concerning material support.
The same applies to technical publications, since in many cases LSA will not identify all
required spare parts. However, it is necessary to include in material support all spare parts
identified by an LSA task. Table 17 gives an overview of the different types of spares and theirconsideration in the identification process.
Table 17 List of different spare part types identified by LSA
Spare parttype

Description

Correlation between LSA andmaterial support

Completepiece ofequipment−

maintenance driver−

cost driver

A maintenance task definedwithin the LSA must approve theidentification of the equipment asa required spare part.

Required spare parts for (preventive or
corrective) replacement tasks at operatorsite (replacement of complete equipment
without any repair at operator site)

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 57

S3000L-B6865-03000-00

Spare parttype

Description

Correlation between LSA andmaterial support

Dedicatedspare parts

Required spare parts for equipment repair
or maintenance tasks at operator site
(repair of the equipment will be performedat operator site)

A maintenance task definedwithin the LSA must approve theidentification of this component asa required spare part.

Standard
parts

Required piece parts (eg, attaching partsor seals) for repair or maintenance tasks at
operator site (repair of the equipment will
be performed at operator site)

A maintenance task definedwithin the LSA must approve theidentification of this piece parts asa required spare part.

Consumables Required consumables such as liquids,
grease, special chemical products, source
material, glue.

A maintenance task definedwithin the LSA must approve theidentification of consumables as arequired item.

Note
The dataset of IT systems for material support usually contains many more parts comparedto those identified by an LSA process. The reason is that a documented support task does
not identify many piece parts (eg, like screws, nuts, bolts, washers, attaching parts).
Although these kinds of parts will not fail inherently, they can be lost or damaged.
Therefore, it must be possible to procure those items as well.
If a maintenance task requires the replacement of any piece part, the LSA data must
document said piece part as a required resource.
Fig 12 shows the process to begin the preparation of illustrated parts data within material
support:

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 58

S3000L-B6865-03000-00

ICN-B6865-S3000L0023-004-01
Fig 12 Correlation between LSA and material support
10.1.3Standard and specific support equipment
The identification of relevant support and test equipment is one of the main activities of the LSA
process. The timely provisioning with required support/test equipment is crucial, and it isnecessary to make a distinction between common and special support/test equipment.
Particularly, the LSA process must identify the requirements for special support/test equipment.
After the identification, a development or procuring process must begin. Refer to Fig 13.
As a requirement, each item of support and test equipment that is identified by the LSA, must
be a part of a development or procurement process. The LSA status information can be used toinitiate activities within the department responsible for support and test equipment. However, insome cases, sources other than the documented LSA tasks can fulfill the requirement for
support/test equipment. This is valid, for example, for common tools (eg, a simple screwdriver
does not need to be identified by a special LSA task), as well as for support equipment thatdefinitely will be needed (eg, a forklift to move heavy components in case of maintenanceactivities). It is possible to determine the need for this kind of support equipment before the LSA
data document the first support task.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 59

S3000L-B6865-03000-00

ICN-B6865-S3000L0024-002-01
Fig 13 Correlation between LSA and support/test equipment
10.1.4Training
Training requires particular attention. It is possible to identify training needs concerning
maintenance activities once the complete information on the required maintenance andoperational support tasks is available (eg, details of performance, required support equipment,difficulty and criticality, duration, number of working steps, required personnel). TNA must be
the first step in identifying training requirements. It is possible to base TNA on the support tasks
identified by the LSA. An exchange of status information between the TNA and the LSA must be
introduced to help identify the best starting point for activities to develop training.
Note
To support the identification of training needs not documented in LSA, and to support thedevelopment of training content, additional information should be taken from the technicalpublications. Refer to Fig 14.
The customer must agree to the process to identify and develop training content by taking input
from LSA and/or available technical publications. The development of training equipment can be
expensive (eg, production of training videos, training rigs, training simulators). Therefore,
decisions concerning training must be based on reliable information.
For the best possible support, it is recommended to document the training information that iswithin the LSA data. The LSA data can contain simple markers, such as training required, or
any other available information concerning personnel competence. Those markers ensure theextraction of training requirements from the LSA data for TNA purposes.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 60

S3000L-B6865-03000-00

ICN-B6865-S3000L0025-002-01
Fig 14 Correlation between LSA and training

10.2

Management of the development of the IPS products
The coordination of IPS activities is one of the main challenges within the development or
introduction of a new Product. Developing the IPS deliverables for new Products can becomplex. Therefore, an effective solution must be at the core of the management of thisdevelopment process. It is recommended that IPS managers be provided with the appropriate
means to use LSA data/information as a central management tool for the entire IPS process.
The contractor must consider:−−

LSA status information must support the timely development of the IPS products. The
support engineering and/or LSA department must generate the triggering of the IPS
elements to ensure a proper start.
any IPS element must avoid creating unnecessary effort, such as:••••

creation of technical publications for maintenance or operational support tasks that arenever performed at 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 is neverrequired at the customer operational siteplanning training for maintenance tasks which are never performed at customer
operational site

To avoid negative impacts of these aspects, it is recommended that a permanent quality checkof the content of the IPS elements against the content of the LSA data be carried out.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 61

S3000L-B6865-03000-00

10.3

Influence of modifications on IPS products
It is necessary to consider carefully design modifications that are relevant for any supportability
analysis results and for the IPS elements. But not only design changes can trigger areassessment of the existing support scenario, but also, for example, a change in theoperational framework like a deployment or a new Product use scenario under different
environmental conditions. It is essential to manage effectively the entire IPS process, as acommon process from the design to the IPS elements. A strategy for managing modifications
during every project phase is strongly recommended. Many modifications occurring as early as
the design and development phases will have an effect on the entire project. Moreover, in later
phases of the project, modification management for the IPS elements is vital for both thecustomer and the contractor. Fig 15 illustrates a typical triggering process.

ICN-B6865-S3000L0026-002-01
Fig 15 Influence of modifications on IPS elements in general

11

Checklists

11.1

Detailed checklist for the creation of an ORD
It is recommended that a checklist with a number of detailed questions be used to support thedevelopment of a complete ORD (refer to Table 18). Additionally, there can be project-specificaspects that must be taken into account.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 62

S3000L-B6865-03000-00

Table 18 Checklist of detailed questions to support the ORD creation
Detailed ORD questions

Answer/Action

General use scenario
Which are the expected uses or mission areas?

Describe use areas

Is the normal use of the Product the only possible scenario?

Yes/No?

Are there any special use scenarios, which must be taken into
consideration?

Yes/No?

Is permanent use expected?

Yes/No?

If yes, describe special use
scenarios in detailIf yes, describe in detailIs an out-of-area use under rough conditions expected?

Yes/No?
If yes, describe in detailIs the noise from Product use or maintenance expected to have an
impact on the environment?

Yes/No?

Is the pollution from Product use or maintenance expected to have an
impact on the environment?

Yes/No?

Is the Product use or maintenance expected to have any other impact on
the environment?

Yes/No?

Are there any activities necessary to avoid the negative impact of noiseand pollution on the environment?

Yes/No?

Are there any problems concerning the performance of the Productcurrently in use?

Yes/No?

Are there any problems concerning the maintenance of the Productcurrently in use?

Yes/No?

Are there any problems concerning the supportability of the Productcurrently in use?

Yes/No?

Is the Product used in combination with other existing products (on aregular basis, or only occasionally)?

Yes/No?

Does the use of the Product depend on other existing Products?

Yes/No?

If yes, describe in detailIf yes, describe in detailIf yes, describe in detailIf yes, describe in detailIf yes, describe problems

If yes, describe problems

If yes, describe problems

If yes, describe interaction

If yes, describe dependence
Is it possible to transport the Product?

Yes/No?

How long does it take to prepare the Product for transportation?

Duration

Does transportation require special protection and/or packaging?

Yes/No?
If yes, describe in detail

Define transportability requirements (mode, type, quantity, distance,
duration and conditions of transport)

Applicable to: All

Define details

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 63

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

Which are the existing requirements concerning support equipment andpersonnel for the preparation of Product transportation?

Define details

What is the maximum acceptable time interval to recover full Productcapability after transportation?

Define duration

Which are the existing requirements concerning support equipment andpersonnel for the recovery of full Product capability after transportation?

Define details

What other items must be transported (eg, support equipment, spares,
personnel) to ensure proper Product operation at the destination andwhat are the requirements for these additional transportation tasks?

Define details

Deployment of locations and special conditions of every location
How many operating locations are there?

NumberIs 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 capabilities?

−

Is the location a home base or an offshore location for the Product?

−

Is the location a training base equipped with training facilities?

Define the special conditions at each location:−

Are there extreme sandy or dusty conditions?

−

Is the atmosphere at the location salty?

−

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?

Define details

In a wartime scenario, are there special locations that would preclude
contractor maintenance? (eg, contractors experience difficulty inperforming maintenance and repairs in wartime environments)

Yes/No?

Are there any special situations involving threats that might require a
special emergency support concept, with a minimum level ofintervention?

Yes/No?

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 64

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

Is the available infrastructure adequate 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 seaports

Are there special infrastructure 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 facilities
and infrastructure?

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 facilities
and infrastructure?

Define details

What are the planned capabilities of each location concerning personnel? Define details
Will there be plans to establish a repair station at special locations?

Yes/No?

Will there be plans to establish a supply depot at special locations?

Yes/No?

Will there be plans to exchange of support equipment or personnel
between different locations?

Yes/No?

Product support and deployment
How many supported Products are planned per location?

Define details

Deployment of Products per location

Define details

Will there be plans to share Products between different locations?

Define details

Product use overview
What will be the normal use of the Product at every location (key use)?

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?

Applicable to: All

Define details

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 65

S3000L-B6865-03000-00

Detailed ORD questions

Answer/Action

Are there any periods of special use of the Products at a special location? Define details−

low payload period−

temporary peak loads−

temporary storage of the Product−out-of-area use under special or rough conditions−

wartime use

In the case of permanent operational conditions, what are the possible
downtimes for maintenance (maintenance windows)?

Define time periods formaintenanceDefine additional Product performance parameters in measurable andquantifiable terms, such as:

Define detailed values−

range of use−

required accuracy−

payload values−

required temperatures−

required speed−

required distances

What is the key measurement unit for Product use per unit of time?
Examples are:−operational hours for general Products−

flight hours for airborne Products (aircraft, helicopters)−

kilometers or miles for land-based vehicles−

rounds or cycles for periodic processes in a Product−tons for transportation systems

Define detailed values

What is the expected operational profile at each location?
−−

Define an operational profile
How many operating hours or missions are planned per day? In case as detailed as possible
there are different days for typical use, define the operating profile foreach "day type".
What are the typical operational profiles for longer periods, such as
weeks, months or 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 use (eg, operation,
mission, trip, flight, dive)?

Define detailed values

11.2

Detailed checklist for the creation of a CRD
It is recommended that a checklist with a number of detailed questions be used to support thedevelopment of a complete CRD (refer to Table 19). However, there can be project-specificaspects that must be taken into account.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 66

S3000L-B6865-03000-00

Table 19 Checklist of detailed questions to support the creation of a CRD
Detailed CRD questions

Answer/Action

Supply concept
Are central depots expected, and how is their deployment planned?

Define details

Are depots planned directly at the operational locations?

Yes/No?

Is a material exchange between different locations expected?

Yes/No?

Has a selection process for suppliers been defined and how will suppliers Define details
be integrated into the expected supply concept?
Is it possible for a production line to provide spare part support (especially Yes/No?
at early stages)?
Is outsourcing via a support agency expected?

Yes/No?

What are the limitations for spare part availability and lead times?

Define details

What distribution and IT systems will be used to supply spare parts?

Define details

Which concept will be used for initial provisioning?

Define details−

Is it expected to use an optimization or a simulation tool?

−Is the deployment schedule properly supported by the initial sparesdelivery?

Will spare part delivery have an impact on the production schedule?

Yes/No?

During out-years, is the industrial base compelled to provide sparessupport for items that remain in the inventory?

Yes/No?

Support equipment concept
How can you ensure that all support equipment be available in time?

Define details

What is the identification and realization process for standard and special Define details
support equipment?
Is the automated test equipment used effective to support the Product?

Define details

What are the plans for maintenance and support of the support
equipment?

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

Is it the customer or the contractor that provides staff for operating the
Products?

Define details

Is it necessary to consider cooperative models?

Yes/No?

How can you ensure the timely verification of the required operator
training?

Define details

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 67

S3000L-B6865-03000-00

Detailed CRD questions

Answer/Action

How can you ensure the timely verification of the required maintenancetraining?

Define details

What training processes must be developed to ensure adequate
operational and maintenance support at all levels during the entire
Product life? It is necessary to consider the possible rapid turnover of
personnel.

Define details

Facilities and infrastructure
Which infrastructure must be available at the required facility (eg,electricity supply, hydraulic power, compressed air, special working
environment)

Define details

Are existing facilities at operational locations adequate 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 a realistic time schedule available for the building activities for therequired new facilities?

Yes/No?
Define details

Is there a plan to identify and reduce risks caused by the delay in building Define details
the facilities?
IT and communication resources
Which are the existing IT architectures at every operational location
concerning the following aspects:−

network capabilities−

data storage capabilities−

computer capabilities−

communication resources

Define details

Are the existing IT and communication capabilities appropriate for the
new Products that are going to be introduced?

Yes/No?

Are there any risks related to future changes in IT or communicationarchitecture that can affect the operation of the new Products?

Define details

Are there any concepts for the initial provision of data for the required IT
systems?

Define details−

Who holds the required data?

−

Are there any contractual aspects to be considered?

−

Are there any problems concerning data security requirements?

Are there any plans for a first installation of required new IT systems andfor the appropriate service of IT systems during the life of the Productwhich requires support?

Applicable to: All

Define details

Yes/No?

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 68

S3000L-B6865-03000-00

Detailed CRD questions

Answer/Action

Are there any service contracts for hardware and software (planned andexisting)?

Yes/No?

−ensure fast reaction to downtimes−

the terms of any service contract must include the upgrade of
hardware and software in case of technical progress

Are the 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 structure be changed at operational locations andwhat are the risks related to these changes?

Define details

What are the existing opportunities in structure changing for the
introduction of a new Product (eg, reduction of personnel)?

Define details

Schedule consideration
What are the plans to include IPS elements at an appropriate level in allphases of the project?

Define details

Are supportability analysts involved since the earlies phases of the
project, so they can influence basic decisions concerning design?

Yes/No?

Additional aspects
What additional aspects specific to the project are highly significant forthe supportability analysts?

Applicable to: All

Define details

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 69

S3000L-B6865-03000-00

11.3

LSA candidate selection flowchart examples

11.3.1

Non-structural items

ICN-B6865-S3000L0036-002-01
Fig 16 Full LSA candidate selection flowchart
Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 70

S3000L-B6865-03000-00

The selection flowchart in Fig 16 shows the typical process used to determine full LSA
candidates from an existing breakdown. Depending on the project, it can be necessary to adapt
the selection criteria as there can be additional criteria. The flowchart must be applied to eachbreakdown element or part. If the selection flowchart for full LSA candidates leads to the IUA
not being a full LSA candidate, it will be necessary to apply to each of those breakdown element
or part the second LSA selection flowchart for partial candidates. Refer to Fig 17.

ICN-B6865-S3000L0037-002-01
Fig 17 Partial LSA candidate selection flowchart
Depending on the project, it can be necessary to adapt the selection criteria as there can beadditional criteria. In general, the analyst must have a guideline for the LSA candidate selection.
The contractor and the customer must harmonize any required change of flowchart logic withina project and agree to it during the LSA GC.

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 71

S3000L-B6865-03000-00

11.3.2

Structural items
In the case of structural components, the selection process for LSA candidates differs from theselection process for non-structural items. Refer to Fig 18.

ICN-B6865-S3000L0038-002-01
Fig 18 LSA candidate selection flowchart for structural items

Applicable to: All

S3000L-A-03-00-0000-00A-040A-A
Chap 3DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 72

S3000L-B6865-03000-00

12

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:
−
−
−
−
−
−
−
−
−
−

S3000L UoF Applicability Statement
S3000L UoF Breakdown Structure
S3000L UoF Logistics Support Analysis Message Content
S3000L UoF LSA Candidate
S3000L UoF Message
S3000L UoF Part Definition
S3000L UoF Performance Parameter
S3000L UoF Product and Project
S3000L UoF Product Usage Context
S3000L UoF Security Classification

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

Applicable to: All

End of data module
DMC-S3000L-A-03-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 32021-04-30 Page 73

S3000L-B6865-03000-00

Chapter 4
Product structures and change management in LSA
Table of contents

Page

Product structures and change management in LSA .................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Introduction ...................................................................................................................... 3
1.2
Purpose ........................................................................................................................... 4
1.3
Scope ............................................................................................................................... 4
2
Product ............................................................................................................................ 4
2.1
Product development and LSA ........................................................................................ 4
2.2
Use of the term Product in S3000L ................................................................................. 4
2.3
Project and system of systems in S3000L ...................................................................... 5
3
Product structure ............................................................................................................. 6
3.1
Introduction ...................................................................................................................... 6
3.2
Breakdown structures ...................................................................................................... 7
3.2.1
Breakdowns and breakdown elements ........................................................................... 7
3.2.2
Breakdown revisions and breakdown element revisions ................................................ 9
3.2.3
Breakdown element identification .................................................................................. 10
3.2.4
Breakdown element relationships.................................................................................. 11
3.2.5
Breakdown element in multiple breakdowns ................................................................. 13
3.3
Parts lists ....................................................................................................................... 14
3.4
Replaceability aspects ................................................................................................... 16
3.5
Product design configuration ......................................................................................... 16
3.5.1
Usable on product variant .............................................................................................. 17
3.5.2
Effective on product configuration ................................................................................. 18
3.6
Nested product variants and product configurations ..................................................... 19
4
Product structures from Product design and development ........................................... 20
5
Product structures for support ....................................................................................... 21
5.1
Introduction .................................................................................................................... 21
5.2
Breakdown structure for support ................................................................................... 22
5.2.1
Product and product variant .......................................................................................... 22
5.2.2
System/functional breakdown structure ........................................................................ 23
5.2.3
Physical breakdown structures ...................................................................................... 26
5.2.4
Zonal breakdown structures .......................................................................................... 30
5.2.5
Mixture of breakdown philosophies (hybrid breakdown structures) .............................. 31
5.2.6
Interrelating elements in different breakdown structures .............................................. 31
5.2.7
Managing revisions of breakdown structures and its elements ..................................... 32
5.2.8
Managing Product design configuration information ..................................................... 32
5.2.9
Supportability-oriented breakdown element identifiers.................................................. 32
5.2.10 Hardware and software element characterization ......................................................... 34
6
Change management in LSA ........................................................................................ 35
6.1
Introduction .................................................................................................................... 35
6.2
Reason for change ........................................................................................................ 35
6.2.1
Design change ............................................................................................................... 35
6.2.2
Design concessions and waivers .................................................................................. 36
6.2.3
Preventive maintenance change ................................................................................... 36
6.2.4
LSA change ................................................................................................................... 36
6.3Managing changes ........................................................................................................ 36
6.4
Implementation of changes in LSA ................................................................................ 37
6.4.1
Impact of changes to the LSA ....................................................................................... 37
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

6.4.2
6.4.3
6.4.4
6.5
7

Traceability between the source of changes and consequential LSA changes ............ 37
Change process............................................................................................................. 37
LSA update .................................................................................................................... 38
Introducing design changes ........................................................................................... 38
Associated parts of the S3000L data model .................................................................. 38

List of tables
1
2
3
4

References ...................................................................................................................... 2
Aspect of replaceability .................................................................................................. 34
Aspects of reparability ................................................................................................... 34
Aspects of software installation and execution .............................................................. 35

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

System of systems example ............................................................................................ 6
Example on implicit and explicit breakdown structures ................................................... 7
Relationship between breakdown elements and parts .................................................... 8
Examples of breakdown revisions defined during the Product development .................. 9
Example of multiple identifiers for breakdown elements ............................................... 10
Example of use of breakdown element relationship ...................................................... 12
Example of breakdown element usage relationship ...................................................... 13
Example of usage of breakdown elements in multiple breakdowns .............................. 14
Example of parts list and the use of substitute and alternate parts ............................... 15
Example of usable on product variant construct ........................................................... 18
Use of product configuration .......................................................................................... 19
Example of nested product variants and their nested breakdowns............................... 20
Example of a Product and its product variants .............................................................. 23
Example of simple system breakdown .......................................................................... 24
Example of a functional breakdown structure for a Product .......................................... 25
Example of family groupings ......................................................................................... 26
Example of a physical breakdown structure for a Product ............................................ 27
Breakdown example, all hardware elements with their own representation ................. 28
Breakdown example, grouping of hardware elements into one single representation .. 29
Example of a zonal breakdown structure for a Product ................................................ 30
Example on hybrid breakdown as a mixture of system and physical elements ............ 31
Supportability oriented BEI ............................................................................................ 33

References
Table 1 References
Chap No./Document No.

Title

Chap 1Introduction to the specification

Chap 3

LSA process

Chap 5

Influence on design

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Chap 11

Level of repair analysis

Chap 12

Task requirements and maintenance task analysis

Chap 17

In-service LSA

Chap 19

Data model

Chap 20

Data exchange

S1000DInternational specification for technical publications using
a common source database

S2000M

International specification for material management

S4000PInternational specification for developing and continuously
improving preventive maintenance

SX001G

Glossary for the S-Series IPS specifications

ISO 10303:239

Product Life Cycle Support

MIL-STD 1388-2B

DoD requirements for a Logistics Support Analysis Record

GEIA-STD-0007

SAE Handbook for Logistics Product Data
(former MIL-STD 1388-2B)

1

General1.1

Introduction
Product structures and change management ensure the correct identification of different
Product configurations, controls changes, and records the change implementation of thephysical and functional characteristics of the Product’s structure, systems, subsystems,
equipment and components.
Establishing a Product breakdown is essential to identify support Product structure for all
configurations during the project life cycle. Traceability between design structure and support
breakdown structure is needed in order to control possible changes in the design Productstructure during all project phases and implement those modifications into the support
breakdown.
Change management is another aspect that must be controlled. Along the life cycle of the
Product, changes coming from different sources modify the original Product baseline structure.
The LSA process must be part of the Configuration Management (CM) process to identify andanalyze what was/is required, designed, produced and supported. It also evaluates changes, toidentify their impact on LSA activities and implement such changes.
This chapter covers two main subjects. First, it focuses on the ways in which to define andmanage Product structures with a view to organizing and recording the results for the respective
LSA activity. Second, this chapter illustrates that the S3000L data model and its associatedexchange format define constructs which support an iterative LSA process.
S3000L supports the definition of Product structures with varying degrees of complexity. A
Product structure in S3000L can cover anything from a simple piece of equipment to anadvanced Product such as a combat vehicle, an aircraft or a carrier.
It also describes how to manage support analysis activities for system of systems and Products
in Products using constructs enabled by the S3000L data model and its data exchange format.
Although it is possible to develop these Products at different times, and in accordance with

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

different product data and support analysis standards, it is also possible to incorporate them into
one overall support definition.

1.2

PurposeThe purpose for this chapter is to present how the LSA process can reuse Product structures
coming from design and development, and use those structures as a basis to define additionalor modified Product structures that support the LSA activities. The purpose is also to illustrate
how LSA is an integral part of the overall CM process and how to control and implementchanges in the support solution throughout the Product life cycle. Product structures defined
during LSA will also be the basis for Product structure needed by other IPS disciplines.
The chapter provides rules and guidance for the creation of Product structures for different
types of Products. Below some examples are given to allow an efficient CM. The chapter also
analyzes change management and the impact on LSA activities.

1.3

Scope
The target readers of this chapter are analysts who perform analysis activities within the LSA
process, giving the necessary guidelines on the different available options to define the mostappropriate Product structures based on the project requirements. It is also essential for
traceability between design and support Product structures, and for change management
control within the CM process.
Note
Figures in this chapter do not always reflect the exact representation in the S3000L data
model. In many cases, they are simplified to give the reader a basic understanding ofconcepts and constructs covered in the specification.

2

Product

2.1

Product development and LSA
The core principles behind product structures and change management in S3000L are:−−

LSA is performed in parallel with product design and development
LSA supports a system of systems perspective

This means that S3000L is designed to meet the requirement to start LSA activities at the sametime as product design, and those LSA activities will iterate as product design and development
progresses.
It also means that S3000L is designed to support LSA activities to be performed against a set of
Products, taking into consideration that individual Products can be in very different life cycle
phases, and their respective Product can be structured and documented in a completely
different way. Some Products can be newly developed, while others are mature and have been
in service for some time.
Therefore, S3000L supports the idea that different principles can underlie the organization of a
Product structure. However, it must be possible to incorporate Products into an overall Productand system of systems breakdown structure.
To this end, product structure definitions in S3000L share the same underlying principles asexisting Product Data Management (PDM) / Product Lifecycle Management (PLM) systems andstandards, such as ISO 10303-239 Product Life Cycle Support.

2.2

Use of the term Product in S3000L
A Product in S3000L (and in SX001G) is defined as a family of items, which share the sameunderlying design purpose.
Examples:− Nexter VBMR Griffon

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

−
−
−
−
−
−

Airbus A340
Boeing 787
Aegis Class Destroyer
Ford Fusion
Rolls Royce Pegasus Engine
Apple iPhone 7

A Product then comes in one or many variants, and each product variant is configured for a
specific purpose and made available to the market. As laid out in S3000L, each Product musthave at least one defined product variant.
Examples:− Nexter VBMR Griffon Command Vehicle vs. Medical Vehicle vs. Personnel Carrier− Boeing 787-800 vs 787-900− Ford Fusion S vs. SE vs. SELNote
In S3000L, the term "product variant" corresponds to the broader sense of the term
Product. A common definition of Product is something that is offered to the market to satisfy
a requirement or need.
Note
Product variant is also referred to as model in S1000D and S2000M.

2.3

Project and system of systems in S3000L
Chap 3 provides a general description of LSA projects. It is necessary to underline theimportance of being able to define and manage Product structures from a system of systems
perspective.
A system of systems is often defined as a collection of Products, each capable of independent
operation, that interoperate together to enable more advanced capabilities. However, S3000L
defines a system of systems as a collection of Products. Although each Product is potentiallydefined and developed independently, its respective support requirements must be harmonizedagainst a common support solution.
The project concept in S3000L aims to organize a set of contracts and Products under one LSA
project, and to meet the requirements for the overall system of systems even when performing
LSA analysis activities individually for each Product.
ExampleAn air ground surveillance system of systems can include, for example, an unmanned
aircraft, ground based antenna trailer and communication shelters (refer to Fig 1).

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

ICN-B6865-S3000L0115-001-01
Fig 1 System of systems example

3

Product structure

3.1

Introduction
S3000L covers two basic capabilities, which can be used to define hierarchical productstructures.
The first capability allows partitioning a Product into hierarchical parent-child structuresconsisting of related elements. Hereafter these structures are referred to as breakdown
structures, or simply breakdowns. For example, it is possible to use this capability to define asystem breakdown, a functional breakdown, and/or a zonal breakdown (refer to Para 3.2).
The second capability allows managing different types of parts lists, often referred to as a Bill ofMaterial (BOM). A part list represents the collection of parts included in the assembly of theparent part (refer to Para 3.3).
S3000L also supports the possibility to combine breakdown structures with part lists. For
example, a breakdown element that represents an installation location for equipment within a
Product, can refer to one or many parts that can be installed at that location. These parts canhave part lists, and it is not necessary to include these part lists in the breakdown structure that
includes the relevant part.
Another important aspect of S3000L is that it does not dictate any specific principles for Productstructure definition for LSA. The goal of S3000L is not to impose any specific Product structure
principle, since the principles for Product structure definition vary depending on application
domains, companies, etc. This also includes principles and rules on how to set up theidentification of elements in the defined breakdown structures. For example, S3000L does notdictate the use of Logistics Control Number (LCN) or Standard Numbering System (SNS) like
GEIA-STD-0007 or S1000D, respectively. However, individual programs and projects candefine project-specific business rules to use any of those, or other principles.
In addition to defining breakdown structures and parts lists, S3000L can also keep detailed
information for the allowed product configurations. In the context of product variants, serialized

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

products and/or complex part assemblies, an allowed product configuration defines permitted
combinations of breakdown elements, hardware parts, software parts, and parts list entries.

3.2

Breakdown structures

3.2.1

Breakdowns and breakdown elements
Breakdowns represent the partition of a Product or product variant into a hierarchical parentchild structure of related breakdown elements. For example, it is possible to use breakdowns todefine a system breakdown, a functional breakdown, a physical breakdown and/or a zonal
breakdown for a Product. A breakdown can also be hybrid, containing a mixture of system,
zonal and physical breakdown elements.
S3000L has one generic capability which can be used to represent any number of breakdowns.
The breakdown type attribute determines the type of breakdown being defined.
Each breakdown consists of a set of breakdown elements. Breakdown elements can beorganized into hierarchical structures either by establishing explicit parent-child relationships
between the respective breakdown elements, or by assigning identifiers to the respective
breakdown element to indicate its position in the breakdown structure. These approaches arereferred to as explicit and implicit breakdown structures, respectively (refer to Fig 2).

ICN-B6865-S3000L0082-003-01
Fig 2 Example of implicit and explicit breakdown structures
Note
The implicit breakdown approach reflects legacy IPS standards and specifications like
GEIA-STD-0007 and S1000D, which use Logistics Control Number (LCN) and Standard
Numbering System (SNS) respectively to indicate the breakdown structure. The explicit
breakdown approach reflects current PDM/PLM approaches, which organize objects
through explicit parent-child relationships.
In S3000L, a breakdown can include four different types of breakdown elements. These are:−−an aggregated element, which acts as a container for a collection of other breakdown
elements. Aggregated elements are typically used to represent systems, subsystems,
functions, sub-functions, families, etc.
a hardware element, which is "realized" by hardware part(s)Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00−−

a software element, which is "realized" by software part(s)a zone element, which represents a three-dimensional space related to the Product

Then, it is possible to further specialize each type of breakdown element using its respective
type attribute.
It is important to note that hardware and software elements represent the use of hardware andsoftware parts in the context of a Product. For example, hardware and software elements do not
represent the hardware or software part themselves. Each hardware and software element canrefer to one or many hardware or software parts used to realize the respective hardware andsoftware element. Refer to Fig 3. If there is more than one allowed realization for a hardware orsoftware element, these alternative realizations are regarded as substitutes (eg, as alternates ina specific usage). For more details on substitute and alternate parts, refer to Para 3.3.
Note
It is necessary to consider breakdown elements and parts as separate entities, and as
having separate specifications (definition). The specification for the part must be in line withthe specification for the breakdown element. If not, it is necessary to define a deviation withrespect to the realization of the breakdown element (eg, the inclusion of the part as apossible realization).

ICN-B6865-S3000L0116-001-01
Fig 3 Relationship between breakdown elements and parts
It is necessary to give special attention to software since it is an integral part in most modern
state-of-the-art Products. Any supportability analysis must consider software, which can require,for example, to define loadable software packages as part of the breakdown structure, if thesoftware requires a task definition for its installation/de-installation. The Product breakdown
must also define the effectivity of software and hardware combinations (refer to Para 3.5). If the
hardware does not undergo any modification, but the integrated software does, it is necessary
to document such modifications as being part of the Product structure.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

Note
Software implementers need to be aware that breakdown structures do not refer to theincluded breakdown elements, but to objects that represent the usage of the respective
breakdown element (BreakdownElementUsageInBreakdown). Refer to Chap 19.
3.2.2

Breakdown revisions and breakdown element revisions
In S3000L, breakdown revisions and breakdown element revisions manage the changes tobreakdowns and breakdown elements respectively.
Each breakdown revision and breakdown element revision define a new release of a breakdown
and breakdown element respectively (refer to Fig 4). Revisions trace the development progress(often referred to as development iterations). The use of revisions supports configuration
management, and in particular, enables synchronization between changes introduced from
Product design, and their impact on the LSA results.
The use of breakdown revisions and breakdown element revisions is especially important for
projects where LSA starts during the early phases of the program, and is an integral part ofproduct design and development. Explicit revisions enable an iterative development and allow
for explicit traceability between product structures defined as part of product design, andproduct structures defined for LSA.

ICN-B6865-S3000L0117-001-01
Fig 4 Examples of breakdown revisions defined during the Product development
Note
Adding hardware and software parts to hardware and software elements respectively often
results in new hardware and software element revisions.
Note
Breakdown element revisions must not be confused with legacy methods to document
alternate solutions within a Product breakdown, such as Alternate Logistics Control Number(ALC) in GEIA-STD-0007, or disassembly code variant in S1000D.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Note
Revision identification can include both release and progress (in-work) identifications. As an
example, the S-Series IPS specifications identify the issue number as a value between"000" and "999", in combination with a progress (in-work) identification with a value
between "00" and "99". The issue number and progress identification must be separated
with a hyphen ("-"), for example "001-01".
3.2.3

Breakdown element identification
A Breakdown Element Identifier (BEI) is used to identify an individual breakdown element within
a Product breakdown structure. A key feature in S3000L is that it allows for more than one BEI
to be assigned to one and the same breakdown element (refer to Fig 5).
The rationale for this is that breakdown elements can use identifiers generated by the system,
early on in a project, then wait to assign more supportability-oriented identifiers when the
Product breakdown structure stabilizes. However, it is possible to present the hierarchicalstructure using explicit parent-child relationships.
Note
If a breakdown element has multiple BEI, the additional characterizations must differentiate
the respective identifier, in terms of identifier type and/or the organization that assigned theidentification.
If frequent changes are introduced into the breakdown structures early on in a project, the useof explicit parent-child relationships reduces the amount of work, since it does not require
reassignments of BEI due to changes in the design product structure.

ICN-B6865-S3000L0118-001-01
Fig 5 Example of multiple identifiers for breakdown elements

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

Note
Supportability-oriented BEI provide an explicit understanding of what portion of the Producta given breakdown element belongs to, and of its position in the hierarchical structure.
Examples of supportability-oriented identifiers are Logistics Control Number (LCN) in GEIA0007 and Standard Numbering System (SNS) in S1000D (refer to Para 5.2.9).
Note
If there is a need to establish supportability-oriented breakdown BEI, it is necessary toharmonize them with the other IPS elements, such as technical documentation and material
support.
Note
Software implementers must also note that it is possible to assign supportability-oriented
BEI to objects representing the usage of breakdown elements in a specific breakdown(known as BreakdownElementUsageInBreakdown in the data model, refer to Chap 19 and
Fig 11). For example, it is possible to use a breakdown element in different locations in a
breakdown, and still differentiate its usages from the breakdown perspective. For example,
one breakdown element represents a wheel, which can then be instantiated multiple times
in a breakdown structure (eg, right front wheel, left front wheel, etc.).
3.2.4

Breakdown element relationships
There are two ways to define relationships between elements in breakdown structures.
The first approach defines relationships between breakdown elements (refer to Chap 19, Unit of
Functionality (UoF) Breakdown Structure, BreakdownElementRevisionRelationship). Thisapproach can be used if the relationship is stable and will not change between different
revisions of breakdowns. For example, it is possible to use this approach to:−−−include of physical breakdown elements in a system breakdown relationship (refer to Fig 6)
define the relationship between functional breakdown element and physical breakdown
element, like GEIA-STD-0007. Two breakdown elements represent the same thing fromdifferent perspectives.
create an access point relationship, in case one breakdown element is located behind
another breakdown element (eg, a panel or hatch)

Note
Using the explicit breakdown element in zone relationship, as defined in the UoF Zone
Element (refer to Chap 19), is the most suitable means to define in-zone relationships.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

ICN-B6865-S3000L0119-001-01
Fig 6 Example of use of breakdown element relationship
The second approach defines relationships between the different usages of breakdown
elements in a given breakdown (refer to Chap 19, UoF Breakdown Structure andBreakdownElementUsageRelationship). This approach is most suitable for relationships that
represent configuration aspects of breakdown elements in a specific breakdown, such as
mutual inclusion and mutual exclusion.
An example of a mutual exclusion is "If breakdown element X is installed, then breakdown
element Y must not be installed”. For example, these types of definitions are especially usefulfor mission equipment and mission configurations (refer to example in Fig 7).

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

ICN-B6865-S3000L0120-001-01
Fig 7 Example of breakdown element usage relationshipNote
The example of breakdown element usage relationship in Fig 7 does not explicitly illustrate
the representation of BreakdownElementUsageInBreakdown for the respective breakdown
element, but rather it conveys a more simplified view (refer to UoF Breakdown Structure,
Chap 19).
3.2.5

Breakdown element in multiple breakdowns
As such, breakdown elements are not explicitly included in any given breakdown structure, but
their usages are (refer to Chap 19, UoF Breakdown Structure andBreakdownElementUsageInBreakdown). This way, it is possible to use the same breakdown
element in multiple breakdown structures or in breakdowns defined for totally different purposes(refer to Fig 8). Because this principle is used, it is possible to use the same breakdown element
in different breakdown types, therefore there is no need for defining explicit breakdown element
relationships between breakdown elements defined in different breakdowns (eg, system versus
physical breakdown) for the same Product.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

ICN-B6865-S3000L0121-001-01
Fig 8 Example of usage of breakdown elements in multiple breakdowns

3.3

Parts lists
A part list (Bill of Material, BOM) represents the collection of parts included in the assembly of
the parent part (refer to Chap 19, UoF Part Definition). A part in S3000L can have zero, one or
many associated types of parts lists. In fact, there can be different parts lists for the same partconsidered from different perspectives. There is often a need to manage both engineering parts
lists, often referred to as Engineering Bill of Material (EBOM), and support or service parts lists,
often referred to as Service Bill of Material (SBOM).
Examples of the difference between EBOM and SBOM include, but are not limited to:−−an EBOM includes all detail parts needed to manufacture the assembly part, whereas an
SBOM only includes the parts that can be replaced in the context of a maintenance task
an EBOM can also include parts assembled before they are made available as spare parts
to the market. This means that the SBOM can include parts which have different part
identifiers (part numbers) from those indicated in the EBOM.

Parts included in a part list can also change over time. This can be due, for example, toadditional substitute parts added to the EBOM, or to required changes to the SBOM because ofchanges in the maintenance concept. Therefore, S3000L allows for managing revisions of partlists over time.
S3000L also allows for defining relationships between part list revisions.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

Example:Part list relationship records that the SBOM revision B for part "54555-101" is based onrevision C of the EBOM for the same part.
A part can also have one or many alternate parts. An alternate part can replace the base part in
all its usages. Therefore, interchangeability is context-independent, and the parts coincide withrespect to their form, fit and function.
A part in a specific part list can have a substitute part. If a substitute part can only replace thebase part in the context of a specific part list, the interchangeability is context dependent.
Note
Alternate parts are often defined for details such as nuts and bolts. In most cases,
substitute parts are defined for equipment, either as substitute parts within a parts list or asalternative realizations for an installation location on Product level. The latter is best
represented using breakdown element realizations in S3000L (refer to Para 3.2.1).
Note
It is not possible to represent alternate or substitute vendor parts using the multi-valued
identifier attribute for a Part As Designed.
Note
The terminology of alternate and substitute parts is used in most product data standards,
such as ISO 10303:239.

ICN-B6865-S3000L0122-001-01
Fig 9 Example of part list and the use of substitute and alternate parts

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

Fig 9 illustrates that V/UHF transceiver (VUHF-5026) is an assembly of a power supply, a
V/UHF transmitter and a V/UHF receiver. The SBOM for the V/UHF transceiver (VUHF-5026)
indicates that there are two power supply parts (6025P-200 and 6025P-300), and both can beused as the power supply in the V/UHF transceiver (VUHF-5026). The substitute part
relationship specifies that it is not possible to install both at the same time, but that they areinterchangeable in the context of the V/UHF transceiver VUHF-5026.
Note
Since the power supply 6025P-300 is defined as a substitute part for power supply
6025P-200 in the context of the parts list for V/UHF transceiver VUHF-5026, this only
allows for power supply 6025P-300 to replace power supply 6025P-200 in the context of
V/UHF transceiver VUHF-5026, and not in any other context unless explicitly defined.
On the other hand, V/UHF receiver 1040R-200 can replace V/UHF receiver 1040R-100 in any
usage, and therefore does not need to be explicitly defined as a substitute in the context of
V/UHF transceiver VUHF-5026.
Note
It is necessary to define substitute parts as part list entries in every part list where they canbe used as an alternative part.
Note
In the example above, identification of each entry in the part list is unambiguous. In manycases, substitute part list entries are listed with the same position number, often derived
from in a drawing. This kind of information can be represented in S3000L using the part list
entry attribute "reference designator".
S3000L also considers software as parts. This means that software parts can be included inparts lists for both hardware parts and software parts.

3.4

Replaceability aspects
Replaceability can be defined for hardware elements as well as for parts. In both cases,
replaceability can be defined from either a technical perspective or a chosen support strategy
perspective. The technical perspective defines whether the associated part can be replaced(yes/no), whereas the replaceability strategy defines, for example at what maintenance level thereplacement takes place (refer to Chap 11).

3.5

Product design configuration
Product design configuration defines allowed configuration standards for a given Product or
product variant. Product design configuration allows the user to define permitted combinationsof breakdown elements, hardware parts, software parts and parts list entries in the context of a
Product, of a given product variant, or of a highly configurable assembly part. Allowed productconfigurations are also often referred to as effectivity definitions.
The UoF Product Design Configuration (refer to Chap 19) can restrict the allowed usage forbreakdown elements and parts, included in more generic product structures by restricting theirapplicability to specific allowed product variants and/or specific product design configurations. It
is possible to restrict the respective breakdown element, breakdown element realization andparts list entries to be effective just for a given product variant, a given part-numbered item,
and/or for a specific serial number range.
S3000L supports two basic principles for defining product design configurations. These are:−usable on product variant, where an item (breakdown element, breakdown element
realization or parts list entry) in the Product structure for the overall Product is defined as
being effective only for a given product variant, or even for a specific serial number range ofa product variant

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00−

effective on product configuration, where detailed allowed design configurations can be
defined in order to identify allowed configuration (build) standards

Note
The rationale behind including product design configuration information in the context of
support analysis is to filter elements in the Product structure to allow the analyst to identify
prioritized elements. For example, this allows meeting delivery schedules for specificproduct variants and/or for a defined Product design configuration (build standard). Second,
this information can be useful to the customer/operator to ensure consistent Productconfiguration and also to filter out task steps and resources needed in performing a task ona certain product variant.
Note
When shared with the customer/operator, LSA must not be considered as an authoritative
source for allowed product configuration information.
3.5.1

Usable on product variant
If the Product structure contains certain elements which are defined for the overall Product but
are only effective for certain product variants, it is necessary to identify those elements byproviding "usable on product variant" information (refer to Fig 10).
It is also possible to associate usable on product variant information with a limited serial number
range.
Additionally, there is also the possibility to apply usable on product variant information at
different levels of the Product structure, for example:−−−

at breakdown element level, usable on product variant can be defined for the breakdown
element independent on breakdown type and breakdown revision
at breakdown element realization level, usable on product variant can identify which partnumbered items can be used on specific product variants
at breakdown element usage level, usable on product variant can be defined per breakdown
element in the context of an individual breakdown revision

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

ICN-B6865-S3000L0123-001-01
Fig 10 Example of usable on product variant construct
3.5.2

Effective on product configuration
Effective on product configuration information can manage very granular definitions of permitted
combinations of breakdown elements, hardware parts, software parts, part list revisions andpart list entries, either in the context of a product variant or in the context of a highly
configurable assembly part (allowed product configuration). Refer to Fig 11.
There can be a need for an allowed product configuration to have an authority to operate (eg,type certificate), often granted by a government entity.
For example, an allowed product configuration can be used to further define specific allowed
configuration standards to meet specified development steps for a given product variant. In
order to fulfill the allowed configuration standards, set by the manufacturer, the operator must
adhere to the allowed product configuration. The scope of many LSA programs does not include
the exchange of this information and does not claim that the LSA data is the authoritative
source. However, it can be important in order to:−−

identify prioritized elements, for example based on development plans and delivery
schedules
define detailed applicability statements for task-related information

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

ICN-B6865-S3000L0124-001-01
Fig 11 Use of product configuration

3.6

Nested product variants and product configurations
S3000L has also the capability to define nested structures for product variants and allowed
product configurations (refer to Fig 12).
This allows for defining effectivities regarding use of sub-Products in overall Products, forexample to define that it is possible to use a specific engine model only on a specific aircraft
variant, or that certain configured mission kits are only suitable for certain variants of anarmored vehicle.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

ICN-B6865-S3000L0125-001-01
Fig 12 Example of nested product variants and their nested breakdowns
Note
Nested product variants are not the same concept as a system of systems. A system ofsystems defines the aggregation of independent Products that, if considered together,
provide an overall operator capability (refer to Para 2.3).

4

Product structures from Product design and development
Product structures coming from product design and development are one of the most important
inputs for LSA activities. Design Product structures can come in many different forms andformats, including 3D model representations. This is one of the reasons why S3000L has ahighly flexible data model, which can represent many Product structure philosophies using
breakdowns and parts lists.
Product design and development activities will often generate more than one Product structure.
Typically, there will be at least one system-oriented breakdown and one physical productstructure. The representation of a system-oriented breakdown is often a hybrid breakdown
which consists of both pure system elements both often refers to physical elements as its leaf
elements.
The representation of the physical Product structure can vary depending on the ComputerAided Design (CAD) tool and/or the Product Data Management (PDM) system being used.
There can also be functional or zonal breakdowns. It is necessary to determine the relevant
Product structures for the LSA activities as early in the program as possible.
In most cases, design Product structure(s) will change over time, often as a result of continuous
Product improvement and/or new Product requirements. It is important that LSA activities track
and react to these changes.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

The frequency and extent of Product design changes often depends on the maturity of the
Product. The earlier the LSA activities are initiated during Product design and development, themore changes LSA activities must be able to manage (refer to Para 6).
It is important that LSA can establish an unambiguous traceability between the design Productstructure(s) and the Product structure(s) used as the basis for the LSA activities. The ideal
situation is that both Product design and LSA could work against one and the same set of
Product structures.
In the case the definition and management of the Product structures for LSA occur in a different
environment than Product design and development, it is recommended to start LSA activities by
establishing the Product structure that reflects the design Product structure, and keep themseparated from the Product structures used for LSA. It will then be easier to identify changes
introduced into the Product design in order to analyze their impact on LSA.
Note
S3000L dictates that there must be as least one defined product variant for each Product. It
is necessary to take this aspect into consideration also when documenting the design
product structure.
Para 3.2 and Para 3.3 describe the means of establishing a design product structures.

5

Product structures for support

5.1

Introduction
Early on in the program (refer to Para 4), it is necessary to determine whether the design
Product structure(s) can also be used for LSA, or if there is a need to define new Productstructure(s) for LSA.
Either way, there is a set of requirements to consider when defining Product structure(s) that
support LSA activities. These are, for example:
−
−
−
−
−

define breakdown elements, which represent families (collections) of parts such as wires,composites, tubes, etc. These are often needed to identify general repair procedures.
assign operational tasks, as well as functional tests, to relevant levels ofsystems/subsystems and/or functions/sub-functions
define breakdown elements for all LSA candidates that will be maintained and/or be
replaced on Product, including “LRU in LRU” (LRU = Line Replaceable Unit)
define zonal location and access points for installation locations
assign supportability-oriented identifications (refer to Para 5.2.9)

The Product structure(s) defined to support the LSA process and the relevant analysis activities
have the following objectives:
−

−
−
−
−
−
−

give a clear understanding of how the Product is structured with respect to systems,
subsystems, functions, hardware and software. This also applies to enabling peripheral
equipment that can be included in the LSA process (eg, complex training equipment andsupport equipment).
give a clear relationship between the included hardware elements and their possible
realizations in terms of manufactured hardware parts
give a clear relationship between the included software elements and their possible
realizations in terms of actual software releases (software parts)
enable the allocation of supportability-oriented identifiers
enable an appropriate level of detail for the selection of LSA candidates
identify product variants and allowed product configurations
support configuration management activities with respect to how a specific revision of the
Product breakdown relates to the revisions of the corresponding LSA results. It must
support configuration control of source data on which the LSA results are based, including
documents, design information and Product usage data.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

There is often a need to define a set of breakdown structures for the Product, each serving a
specific purpose. Many projects will have a design breakdown structure for the Product being
defined in a PDM system. The same Product often also has an LSA breakdown, as well as aseparate breakdown structure for recording operational and maintenance data feedback.
Having different breakdowns for different purposes requires a controlled process to ensure
consistency between the different disciplines.
Since the breakdowns and principles depend on the Product or project, S3000L does not dictate
any specific approach.

5.2

Breakdown structure for support
When defining breakdown structures for support, it is necessary to identify:
−
−
−
−
−

Products and product variants in scope for the support program
Product breakdown structures defined during Product design and development, which canbe used as sources for defining the Product breakdown for support
the way to relate/associate Product breakdown structures for support with Productbreakdown structures coming from Product design and development (eg, are they defined
as extensions or as additional breakdown structures?)the types of Product breakdown structures required to support the support analysis activities
and the recording of required outcomes from the support analysis activities
the level of detail of the respective breakdown structure (eg, should a specific breakdown
structure include subsystems, LRU, components)

Note
Breakdown structures often contain a mixture of breakdown element types such as systemelements, physical elements and even zonal elements (also referred to as hybrid
breakdown structures). Regardless of the types of breakdown elements included, it isimportant to define the purpose for the breakdown using its breakdown type attribute.
5.2.1

Product and product variant
It is necessary to identify all Products and product variants that the LSA analysis activities mustcover. This also includes possible sub-products, which are integrated into the Product or arepart of a system of systems platform.
ExampleExamples of sub-products which are integrated within an overall Product are:••engine on an aircraft
mission kit on a combat vehicle

ExampleAn example of Products, which are part of an overall system of systems platform, is an
unmanned aircraft together with its ground station, Ground Support Equipment (GSE) andtraining simulator.
Each Product can have its own Product structure that is a unique combination of systems,
subsystems, component parts/materials and software. Refer to Para 5.2.2.
It is advisable to identify and name Products and product variants early in the program, and thisprocess must preferably involve Product design and development and other IPS disciplines.
Note
A Product is referred to as an End Item Acronym Code (EIAC) in GEIA-0007, and a productvariant is typically referenced by a Usable On Code (UOC).

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00

ICN-B6865-S3000L0126-001-01
Fig 13 Example of a Product and its product variants
Fig 13 uses the colored markings in each defined breakdown element to identify the usable on
product variant effectivity. For example, the breakdown element for "Openings" is effective forall three product variants, while the breakdown element for "Officer desk" is only effective for thecommand vehicle product variant.
5.2.2

System/functional breakdown structure
The terms system and functional breakdown are often used as synonyms to refer to apartitioning of a Product into a set of systems and subsystems from an engineering point ofview.
The term system breakdown only indicates this type of breakdown structure. On the other hand,
the term functional breakdown refers to the partitioning of functions typically provided by the
Product from a user/operator point of view, such as taxing, take off, flying or landing for anaircraft. Each function requires one or many systems to realize the function in the same way, as
one system can support one or many functions.
Note
A functional breakdown structure can also reflect Product functions (capabilities) as
acceleration, speed control, etc.
A system breakdown will normally have a set of hardware and/or software elements as its leaf
nodes (eg, the lowest level of the breakdown structure). Given a defined maintenance concept,
it is recommended that the system breakdown required for support analysis activities be

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00

stopped at the level where equipment (assembly parts) will be replaced/repaired directly on the
Product. A system breakdown for support analysis should include nested hardware and/or
software elements where it is possible to perform maintenance or operational tasks onserialized parts within the equipment when installed on the Product. The rationale for this is tobe able to define and describe tasks to be performed on Product as opposed to tasks to be
performed on bench. Fig 14 provides a simple system breakdown example.
A system breakdown is often the basis for defining and documenting LSA analysis activities andthe resulting task requirements from the perspective of the Product.
Note
It is also possible to associate LSA analysis activities and task requirements with partdefinitions (refer to Chap 12).
Note
Although S3000L does not prevent users from defining breakdown elements all the way
down to individual piece parts, it is not the recommended practice.
Note
A recommended practice is to define unique hardware and software elements for each
installation location within a Product, even where there might be multiple elements thatshare most of their characteristics (eg, left front wheel and right front wheel). However, thisis a decision that needs to be made for each individual program and/or Product. It is also
important to distinguish between the part and the usages of the part, where the usage ofparts is represented as breakdown elements (eg, a system breakdown structure).

ICN-B6865-S3000L0127-001-01
Fig 14 Example of simple system breakdown

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00

ICN-B6865-S3000L0008-004-01
Fig 15 Example of a functional breakdown structure for a ProductNote
Fig 15 shows an example of a simple functional breakdown. The breakdown elements on
the left side of the figure represent the functional part, which is connected to a parallelsystem breakdown via a breakdown element relationship. In this case the Observation
System S1-02 contributes to provide the two functions Situational Awareness F1-20 andSurveillance F1-50.
5.2.2.1

Family concepts in system breakdown structures
Similar items can be grouped together for analysis purposes. The family concept can minimize
the efforts and avoid the repetition of similar analysis activities. It is the most effective concept
for detail parts which share common maintenance/repair procedures.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

ICN-B6865-S3000L0013-003-01
Fig 16 Example of family groupings
Note
The example in Fig 16 defines the "Pipe" family elements at the "Cooling system" level. It isalso possible to define a family element at the Product level. For example, it is possible togroup all pipes used on the Product and belonging to a specific category, regardless of thesystem and subsystem they belong to.
Depending on Product breakdown philosophies defined for an individual LSA project, it ispossible to include a family breakdown element either in a system breakdown or in a physicalbreakdown. It is recommended that family breakdown elements be included in the system
breakdown, since task requirements are mostly assigned to breakdown elements in the system
breakdown rather than to breakdown elements in the physical breakdown. General repair
procedures (often referred to as standard repair procedures) are the typical task requirementsthat can be assigned to family breakdown elements.
Examples of items which can be organized using the family concept:
−
−
−

5.2.3

wiring of the same type (eg, standard copper, coaxial, fiber-optical)
structural parts of the same typeParts of a similar type coming from one manufacturer. They can be grouped if themaintenance of these parts is covered by a common maintenance concept supported by the
manufacturer itself (eg, with corresponding repair kits).

Physical breakdown structures
Physical breakdown structures can be used to define and represent, for example:−−

data coming from drawings and CAD systems, including 3D models
assembly definitions from the Product perspective

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 26

S3000L-B6865-03000-00

Note
A 3D model approach often results in a concept that identifies positions in the design space
using x, y and z-coordinates (sometimes referred to as instances). If there is a need to referto defined 3D instances as resources for a task, for example, it is possible to transform
those coordinates into a physical breakdown structure.
Note
Physical breakdown structures are also in the scope of S2000M provisioning projects and
S1000D illustrated parts data. Before defining physical breakdown structures for support
analysis activities, it is advisable to consider a joint effort covering all impacted S-Series
IPS specifications used in a project.
Physical breakdown structures can also be used to represent assembly relationships for major
equipment (eg, a personal survival kit fitted on the seat, refer to Fig 17). This is especially useful
where an equipment belonging to different systems has physical dependencies and it can beimportant to document them as part of remove, install and disassembly tasks. This kind of
structure can also be an important input for fleet management and in-service product structures.

ICN-B6865-S3000L0009-003-01
Fig 17 Example of a physical breakdown structure for a ProductIn the context of LSA, it is recommended that physical breakdown structures include only
physical (hardware) elements down to the level of parts affected by the maintenance tasks at
Product level. If possible, these structures must also include attachment parts. The physicalbreakdown for the overall Product must not include parts which will only be affected bymaintenance tasks when removed from the Product (eg, on bench). These parts are justdefined in the context of part lists (refer to Para 3.3).
A physical breakdown structure typically starts at Product level, and there are different ways toorganize it considering different aspects, for example:

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 27

S3000L-B6865-03000-00

−
−
−
−

−

Product sections (eg, front, middle and aft fuselage)
Product bays (areas) which organize the physical breakdown in accordance with, forexample, access points and installation locations
major systems
Access-oriented structures. The access points are defined on the first indenture level, andfollowed by the installation locations which can be directly accessed. In case of removal of
the respective equipment at a given installation location, this will be listed as a child element
underneath that installation location.
equipment assembly dependencies seen from installation locations, for example:•••

Ejection seat assembly is mounted onto the aircraft fuselage
Seat is mounted on the ejection seat assembly
Beacon and personal survival pack is mounted on the seat

It is also possible to combine a physical breakdown structure with zonal breakdown elements to
identify its physical location (eg, product section, bay).
Note
It is important to understand the difference between a hardware element and a part. A
hardware element represents the usage of a part in the context of an overall Product, but it
does not represent the part in itself (refer to Para 3.2.1).

ICN-B6865-S3000L0010-004-01
Fig 18 Breakdown example, all hardware elements with their own representation
In general, the installation location is the primary information within a physical breakdown
structure. It is then necessary to define the physical breakdown structure to represent each
installation location by individual breakdown elements. The example in Fig 18 illustrates the
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 28

S3000L-B6865-03000-00

situation where two identical fuel tanks are installed on the Product, and each tank is defined asa separate hardware element.
However, it is also possible to define identical physical elements as one single breakdown
element with quantity information (refer to Fig 19). In the example below, there are two identicalfuel tanks installed within the Product. In some cases, it can be sufficient to have only one
breakdown element representing a set of similar/equivalent capabilities.

ICN-B6865-S3000L0011-003-01
Fig 19 Breakdown example, grouping of hardware elements into one single representation
It is recommended to stop the definition of a physical breakdown structure at the level whereparts will not be defined as either:−−

the target for a task/subtask
required resources for any on-product maintenance tasks

The physical breakdown structure should focus on defining breakdown elements for:−−−the LRU, including LRU in LRU (at any indenture level)attaching parts
parts that need to be removed in order to gain access

The rationale for this is that there is no need to define breakdown elements for parts that are
just needed for maintenance tasks on bench, since they are already defined as part of the part
list for the assembly. The location of the assembly installation has no relevance for the tasks onbench or for the resources needed. For more information on how to determine whether tasks
must be associated with breakdown elements or with parts, refer to Chap 12.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 29

S3000L-B6865-03000-00

5.2.4

Zonal breakdown structures
The easiest form of zonal breakdown structures is just a list of all zones defined for the Product(or for the defined product variant), without any hierarchical structure. The required depth andstructure of a zonal breakdown established in an LSA can be different from those established
for design or production purposes. Nevertheless, it is recommended to harmonize zonal
breakdown rules within a project. Typically, it is necessary to use zones as breakdown elements
to document maintenance activities related to the physical area represented by the zone
element (eg, scheduled zonal inspection). Refer to Fig 20.
It is possible to use zones to define the zonal location for hardware elements by establishing
relationships between the respective hardware element and its associated zone element.
Among other things, zonal breakdown structures can also be used to determine:−−−work areas within a ship
dangerous zones
radioactive zones

ICN-B6865-S3000L0128-001-01
Fig 20 Example of a zonal breakdown structure for a ProductApplicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 30

S3000L-B6865-03000-00

5.2.5

Mixture of breakdown philosophies (hybrid breakdown structures)
In many cases, Product breakdown structures are a mixture of systems, functions, zones and/or
physical aspects, as shown in Fig 21. This type of breakdown is often referred to as hybrid
breakdown. For example, hybrid breakdowns subdivide:−−

functions into systems and/or physical elements which support the respective function
systems into functions and or physical elements which realize the respective system

ICN-B6865-S3000L0012-004-01
Fig 21 Example of hybrid breakdown as a mixture of system and physical elements
5.2.6

Interrelating elements in different breakdown structures
If an LSA project requires multiple breakdown structures in order to document different aspectsof the Product(s) under analysis, then it is also necessary to determine whether there is aninterrelation between breakdown elements in the respective breakdown structure, and how theelements interrelate.
For example, the interrelation of functional elements in a functional breakdown and elements ina physical breakdown can be a good basis for troubleshooting analysis.
Based on a functional breakdown, troubleshooting must be able to identify potential failures that
led to the unavailability of certain functions. For this reason, the analyst must know which
hardware elements can be responsible for the missing function. For example, the function "fueldistribution" can contain typical elements such as fuel pipes, but can also be dependent onelectric power supply elements. Therefore, even if the electric power supply is documented inanother area, it must be associated with the function "fuel distribution".

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 31

S3000L-B6865-03000-00

There are two ways of interrelating elements in different breakdown structures:
−
−
5.2.7

defining explicit relationships between breakdown elements (refer to Para 3.2.4)
using the same breakdown element in multiple breakdowns (refer to Para 3.2.5)

Managing revisions of breakdown structures and its elements
In S3000L, breakdown revisions and breakdown element revisions manage the changes tobreakdowns and breakdown elements respectively. Revisions trace the development progress(often referred to as development iterations). Refer to Para 3.2.2.
Note
Traditional LSA breakdown methodologies do not take into consideration revisions ofbreakdowns and breakdown elements, which are being introduced in S3000L to improve
integration with Product design and other IPS disciplines.

5.2.8

Managing Product design configuration information
The need for managing Product design configuration information from an LSA perspective
mostly derives from the need to define the Product effectivity for different equipment at specificinstallation locations within a Product or product variant (refer to Para 3.5.2). Product design
configurations are needed to distinguish between:−−

similar equipment from different manufacturers (equal in form, fit, and function) which areallowed in different contexts, for example based on customer preferences (eg, allowed indifferent product variants)
modified or upgraded equipment (equal in form, fit, but not necessarily in function) which
are allowed in different contexts (eg, serial number ranges for a given product variant)

5.2.9

Supportability-oriented breakdown element identifiers
A BEI uniquely identifies a specific breakdown element. It is possible to define breakdown
structures either using explicit parent-child relationships (PDM approach), or letting a
supportability-oriented BEI imply the position of a given breakdown element in the breakdown,
and how the breakdown element relates to breakdown elements at lower and/or higher
indenture levels (traditional LSA approach). Refer to Para 3.2.1.

5.2.9.1

Supportability-oriented breakdown element identifier syntax
For a traditional Product breakdown approach, the supportability-oriented BEI syntax defines
the relationship between the different breakdown indenture levels. It is necessary to define inadvance the number and the type of characters assigned to each indenture level.
If the supportability-oriented BEI syntax must also be the basis for defining and managing
breakdown structures, it is necessary to define it as early as possible, ensuring that the syntax
is appropriate throughout the Product life cycle. In order to use supportability-oriented BEI as
the basis for breakdown structure organization, it is necessary to ensure that the BEI syntax iscapable, consistent, and broad enough to address the entire project structure, and to deal withall changes that take place, especially in the early development phases.
Note
For projects using the traditional LSA Product breakdown approach, any change to the
supportability-related BEI syntax can cause extended rework within different LSA IT
systems and associated IPS disciplines. For example, there can be a risk that an indenturelevel requires more digits than originally planned for, or that it is necessary to reorganize
supportability-related BEI due to changes in the breakdown structures.
For breakdown structures using a PDM approach (eg, using explicit parent-child relationships),defining a specific supportability-oriented BEI structure is not required, but it can be assigned
when the Product breakdown stabilizes, and subsequent changes will not impact the breakdown
elements, nor the associated BEI. Refer to Fig 22.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 32

S3000L-B6865-03000-00

ICN-B6865-S3000L0129-001-01
Fig 22 Supportability oriented BEI
5.2.9.2

Alternate breakdown element
Projects using traditional LSA Product breakdown approaches will meet the requirement to beable to define alternate breakdown elements like the former usage of ALC from GEIA-STD-0007
or disassembly code variant as defined in S1000D.
Since breakdowns in GEIA-STD-0007 require one breakdown element per combination offunction being performed and part that can realize the function there is a need to introduce socalled alternate breakdown elements (LCN/ALC in GEIA-STD-0007). An alternate breakdown
element within GEIA-STD-0007 uses the same LCN, but different ALC to document alternate
breakdown element realizations. The same LCN indicates that the alternate breakdown element
occupies the same installation location in the Product breakdown.
S3000L does not have an explicit concept for dealing with traditional alternate breakdown
elements but supports the requirement in a different way, primarily by allowing for hardware andsoftware elements to have multiple part realizations and to allow for usable on statements to be
defined for individual breakdown element realizations and not just for breakdown elements(refer to Para 5.2.8). An explicit breakdown element relationship which identifies the alternate
aspect can also be defined.
Note
If legacy LSA programs using MIL-STD 1388-2B or GEIA-STD-0007 is migrated into
S3000L then the LCN and the ALC must both be concatenated into one single BEI in
S3000L. Also, LCN type and EIAC could be included in the concatenated BEI in order touniquely identify its origin.

5.2.9.3

Identification of enabling Products
Besides the Product that is the primary subject of the LSA project, LSA activities can also be
required for enabling Products such as:

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 33

S3000L-B6865-03000-00−−

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

Those enabling Products must also be part of a breakdown structure from a system of systems
perspective.
It is possible to define breakdown structures for enabling Products as separate breakdown
structures per enabling Product, where the respective enabling Product is managed as a
Product in its own right. They can also be included as breakdown elements in the breakdown forthe primary Product.
If enabling Products are managed as a Product in its own right, they can have supportabilityoriented BEI, which are totally independent from the supportability-oriented BEI defined for the
primary Product.
5.2.9.4

Integration requirements
It must be ensured that each supportability discipline, both on customer and contractor side,
identify and reference each breakdown element unambiguously. It is necessary to determine ona project-by-project basis whether this is accomplished using supportability-oriented BEI or bysome other BEI.

5.2.105.2.10.1

Hardware and software element characterization
Hardware element replaceability and reparability
It is possible to classify hardware elements based on the aspects of replaceability andreparability. These classifications are an important input to determine the support concept for
the respective breakdown element (eg, by Level of Repair Analysis (LORA), refer to Chap 11).
Reparability and replaceability classifications include discard information, as well as accessibility
information. Table 2 and Table 3 define a number of general terms which can serve as a
guideline to create the corresponding classifications within a project.
Note
During the LSA Guidance Conference (LSA GC), it is recommended to define a common
understanding of typical terms to be used as part of LSA (refer to Chap 3).
Table 2 Aspect of replaceability
Terminology

Description

Directly replaceable Item that is directly replaceable at the Product level.
Not directly
replaceable

Item that is not directly replaceable at the Product level (installed in aparent assembly/equipment). Before replacement, it is necessary to
remove the parent assembly/equipment. For example, it is possible toreplace the compressor of an engine only after the engine removal.

Non replaceable

Item that is intrinsically tied to another and it is not possible to replace it
separately.
Table 3 Aspects of reparability

Terminology

Description

Always repairable

Item that always can be restored to a functional state.

Not always
repairable

Item that can be restored to a functional state depending on the failure.

Non repairable(discard part)

Item that is not repairable.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 34

S3000L-B6865-03000-00

Normally, the reparability information is related to a part and will be documented against thepart. It is possible to define reparability against the hardware element in the early phases of an
LSA program when the exact part realizations are not yet determined.
5.2.10.2

Software element type
It is possible to classify software elements based on their installation and execution in relation to
the Product. This classification is an important input to determine the support concept for therespective software element.
Table 4 includes the definition of some general terms which serve as a guideline for softwareclassification within a project.
Table 4 Aspects of software installation and execution
Terminology

Description

Loadable

Software or data that can be loaded on the Product without removal of
the target hardware from the aircraft.

Embedded

Software written to control machines or devices that are not typicallyconceived as computers.

Distributed

Software that runs on multiple computers within a network at the sametime and can be stored on servers or with cloud computing.

6

Change management in LSA

6.1

Introduction
Change management is the process that controls the identification and implementation ofrequired changes within a Product.
Change management from the LSA perspective describes:−−−

the types of changes that affect previous LSA decisions and analysis results
how S3000L supports the change management process
the possible impact of a change on LSA, and how to implement changes

Changes can either be changes identified upstream as part of product design and development,or changes that only have an impact on the support solution, not on product design. Eachchange can then have an impact on other IPS elements such as provisioning, training and/or
technical publications. Therefore, change management must include all engineering disciplines
rather than focusing on a single discipline.

6.2

Reason for change

6.2.1

Design change
The introduction of changes to the Product design can occur for several reasons including, but
not limited to:−−−−

new or revised capabilities, including revised customer requirements
new or improved hardware
new technologies, including new test capabilities
hardware and software obsolescence issues

Regardless of the type and rationale for the change, it is always necessary to evaluate thechange from an LSA point of view. There are also many cases where design changes will not
impact the LSA.

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 35

S3000L-B6865-03000-00

6.2.2

Design concessions and waivers
If the existing and approved Product configurations do not comply with the definedrequirements, there can be a concession. A concession is granted before the execution of acontract and is an authorization to depart from a particular performance of the contract,
specification or reference document.
A waiver is another type of deviation from the defined requirements. A waiver is granted after
the execution of a contract, and is an authorization to depart from a particular performance ofthe contract, specification or reference document.
Both concessions and waivers restrict the specified capabilities of the Product, and often result
in restrictions on the Product usage. They can also result in additional or different maintenancetasks (eg, additional and/or more frequent inspections, or reduced authorized life for hardware).
Waivers often result in unplanned design changes, while concessions are known and managed
as part of the design, as well as during LSA performance.
It is necessary to incorporate into the LSA the waivers which require changes in the support
solution, and the resulting changes must refer to change authorizations defined for the waiver.
Changes in the support concept and support solution due to waivers will often be removed oncea redesign resolves the reason for the waiver, or when additional investigations show otherwise.
Note
Waivers and their associated changes in the support solution are often communicated asService Bulletins (SB) to customers and operators.

6.2.3

Preventive maintenance change
Changes in the preventive maintenance defined for the Product (refer to S4000P) can also
impact the LSA. By means of an example, the reasons for changes in preventive maintenancecan be:−−6.2.4

LSA change
LSA change refers to changes which only affect existing results from the LSA activities. Thismeans that there is no change to the Product design itself. For example, LSA changes refer to:
−
−
−
−
−

6.3

new built-in test capabilities
In-Service Maintenance Optimization (ISMO), refer to S4000P

new/revised requirements for the support concept and/or the support solution
new/revised regulations that affect the defined support resources
improvements in the support analysis results based on in-service feedback (refer toChap 17)
supplier changes which affect the defined support resources
new technology which changes the way work can be performed

Managing changes
The scope of S3000L does not include the definition and description of change management
performance. However, it is important to include LSA in the change management process to
identify the impact on LSA analysis results, and to ensure there is always a Product support
solution which meets the requirements in terms of availability and cost.
It is also important that any change introduced to the LSA results refers to a justification for thechange. In most cases, it will be a reference to a change authorization (change order/request).
Depending on the scope of the change, it is possible to introduce change authorizations either
by design or by LSA.
It is possible to track the impact of a change in the LSA analysis results, including changes in
the Product structure for support, using the revision capabilities associated with, for example:

Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 36

S3000L-B6865-03000-00

−
−
−
−
−
−

breakdown revision
breakdown element revisionparts list revision
analysis activity revisiontask requirement revisiontask revisionObjects with explicit revisions are often associated with status information (eg, in-work,
released, approved).
It can be necessary to maintain multiple in-service Product configurations or tasks, for example,
because they need to exist simultaneously as the result of a change. If this is the case, it isrecommended that new objects rather than new revisions be defined. For example, it isrecommended to define an additional task, and distinguish the use of the respective task withan explicit applicability statement. It is possible to use applicability statements to define, forexample, that task A is applicable to product variant A, while task B is applicable to productvariant B.
Note
In the information structure for S3000L, it is possible to define applicability statements at
many different levels (refer to Chap 19). The definition of the methods to use applicability
statements and revisions must occur as early as possible in the IPS program.
A new revision must override (replace) previous revisions by default. However, it isrecommended to keep all revisions and not overwrite them with the latest version (datarepository approach).

6.4

Implementation of changes in LSA

6.4.1

Impact of changes to the LSA
For proper change management, it is necessary to correctly evaluate all impacts that changes
can introduce into LSA based on the respective LSA activity to be iterated/re-evaluated. At theend, each change can have an impact on:
−
−
−

6.4.2

the overall support concept, including which tasks are needed (task requirements) andwhere they must be performed
how tasks must be performed (steps)
the resources required when performing a task in terms of material (spares, consumables
and support equipment), personnel and infrastructure

Traceability between the source of changes and consequential LSA changes
It is necessary to ensure traceability between the source change and LSA changes.
However, the scope of S3000L does not include a detailed method on the performance ofchange management.

6.4.3

Change process
Once it is confirmed that a change has an impact on the existing LSA results, it is necessary to
perform consequential activities to ensure:−−−the correct identification of the impact on LSA
the identification, assignment and timely planning of the different jobs to implement thenecessary changes, and the identification of the necessary resources to implement thechangethe status of the jobs performed by LSA can be known and can be fed back to the overallchange management process

It is necessary to record any change which does not affect LSA needs and provide ajustification. This shows that the entire change has undergone analysis, and it guarantees thetraceability of changes.
Applicable to: All

S3000L-A-04-00-0000-00A-040A-A
Chap 4DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 37

S3000L-B6865-03000-00

6.4.4

LSA update
Update to the LSA results due to a defined change means that any change in the resulting LSA
data must refer back to the change authorization.
The process of introducing a change to the LSA must follow the same principles as defined forthe respective LSA activity described in chapter 5 to chapter 16. Para 3 illustrates how tomanage changes that affect the Product structure.
Chap 20 describes how S3000L can be used to update messages to exchange the result of an
LSA update due to change.

6.5

Introducing design changes
The incorporation of design changes (modifications) into a Product in service usually requires
maintenance instructions specific for the activity. Those tasks are often included in service
bulletins sent to customers and operators. However, it is necessary to analyze and document
those tasks in the same way as any other task requirement (eg, documented as part of the
LSA).
Design change task requirements should therefore be defined and documented in accordancewith Chap 12. The trigger (event driven time limit) for such task requirement/task would be thechange authorization (refer to Chap 19, UoF Time Limit).

7

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following UoF,
refer to Chap 19:
−
−
−
−
−
−
−
−
−

S3000L UoF Product and Project
S3000L UoF Breakdown Structure
S3000L UoF Part Definition
S3000L UoF Hardware Element
S3000L UoF Software Element
S3000L UoF Zone Element
S3000L UoF Aggregated Element
S3000L UoF Product Design Configuration
S3000L UoF Change Information

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

Applicable to: All

End of data module
DMC-S3000L-A-04-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 42021-04-30 Page 38

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
Purpose ........................................................................................................................... 2
1.3
Scope ............................................................................................................................... 3
2
Design considerations ..................................................................................................... 3
2.1
Availability ........................................................................................................................ 4
2.2
Reliability ......................................................................................................................... 5
2.3
Maintainability .................................................................................................................. 5
2.4
Testability ......................................................................................................................... 6
2.5
Prognostics ...................................................................................................................... 6
2.6
Standardization ................................................................................................................ 6
2.7
Interchangeability............................................................................................................. 7
2.8
Environmental considerations ......................................................................................... 7
2.9
Human factors/ergonomics .............................................................................................. 7
2.10
Obsolescence .................................................................................................................. 7
2.11
Supportability ................................................................................................................... 7
2.12
Cost effectiveness ........................................................................................................... 8
2.13
Software design ............................................................................................................... 8
3
Development programs ................................................................................................... 8
3.1
Strategy for LSA influence on design .............................................................................. 8
3.2
Design influence on development programs ................................................................... 9
3.3
Supplier design ................................................................................................................ 9
3.4
Critical/milestone design reviews .................................................................................... 94
Checklists ...................................................................................................................... 10
4.1
Selection of parts/equipment ......................................................................................... 10
4.2
Reliability ....................................................................................................................... 11
4.3
Maintainability ................................................................................................................ 11
4.4
Testability ....................................................................................................................... 11
4.5
Prognostics .................................................................................................................... 11
4.6Standardization .............................................................................................................. 11
4.7
Interchangeability........................................................................................................... 12
4.8
Environment................................................................................................................... 12
4.9
Human factors/ergonomics/accessibility ....................................................................... 12
4.10
Obsolescence ................................................................................................................ 12
5
Associated parts of the S3000L data model .................................................................. 12

List of tables
1

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

List of figures
1
2

Opportunity to influence design and support cost during a Product life cycle ................. 3
Breakdown of availability as an approach to structure design influence ......................... 5

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

3Effectiveness - balancing availability and LCC ................................................................ 8

References
Table 1 References
Chap No./Document No.

Title

Chap 6

Human factors

Chap 7

Corrective maintenance analysis

Chap 8Special event and damage analysis

Chap 11

Level of repair analysis

Chap 12

Task requirements and maintenance task analysis

Chap 13

Software support analysis

Chap 14

Life cycle cost considerations

Chap 15

Obsolescence analysis

Chap 16

Disposal

Chap 17

In-service LSA

Chap 19

Data model

1

General1.1

Introduction
Influence on the Product design (hardware or software) is one of the main objectives for staff
involved in supportability engineering and in the LSA process. Therefore, the Product design
program must consider results of the LSA program from a supportability perspective.

1.2

PurposeThe objectives of LSA are:−−−influencing Product design
developing the most effective support solution
defining support resource requirements

This chapter is in direct relation with the iterative work needed for developing an effective
support solution, and definition of support resource requirements.
General objectives for the Product must be translated into more specific requirements for eachproject. The key to a productive LSA and the ability to develop a cost-effective Product support
is to concentrate available resources on activities that are mostly beneficial to the project. Thisis defined and tailored in an analysis strategy. It is necessary to consider the type and scope ofthe development project when choosing an analysis strategy. Influence on Product design canalso vary due to previous design decisions and the life cycle phase.
The opportunity for influencing design in order to fulfill supportability requirements and reduce
Life Cycle Costs (LCC) is at its highest in the beginning of a project, during the conceptual
phases (refer to Fig 1). Influencing design as early as possible can reduce or eliminate the needfor later changes in design (eg, need for redesign) to make the Product fit for operation andsupport. Supportability requirements are considered useful for designing a new Product with
Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

respect to total system availability and cost effectiveness. The purpose is to influence thedesign with supportability requirements in a similar way as the primary Product design and its
requirements influence the support system design. Reviews and baselines produce theseresults within a project.

ICN-B6865-S3000L0077-001-01
Fig 1 Opportunity to influence design and support cost during a Product life cycle
Integrated design teams, Product design and requirements benefit both the Product and thecustomer. LSA must be considered as an integral part of systems engineering.
Product design influences the logistics footprint, the physical size and distribution of support
resources within the supporting logistics system. A structured iterative, interactive closed loop isnecessary between design disciplines and LSA disciplines.

1.3

Scope
This chapter describes:
−
−
−
−
−

design parameters to be influenced by LSA and vice versa
how to make a strategy for LSA to influence Product design
the perspectives of supplier and vendors
reviews of milestones
the benefits of LSA influence on Product design

The approach to influence the design with the parameters of supportability is applicable on
systems and subsystems within the Product, as well as on the design and development of
support systems.

2

Design considerations
Many considerations can influence the design of a system/subsystem or equipment to make thecomplete Product more efficient and cost effective. Such considerations are:−−

Availability. Refer to Para 2.1.
Reliability. Refer to Para 2.2.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−

2.1

Maintainability. Refer to Para 2.3.
Testability. Refer to Para 2.4.
Prognostics. Refer to Para 2.5.
Standardization. Refer to Para 2.6.
Interchangeability. Refer to Para 2.7.
Environmental considerations. Refer to Para 2.8.
Human factors/ergonomics. Refer to Para 2.9.
Obsolescence. Refer to Para 2.10.
Supportability. Refer to Para 2.11.
Cost effectiveness. Refer to Para 2.12.
Software design. Refer to Para 2.13.

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 can also be referred to as "operational readiness".
Reliability, maintainability, and supportability characteristics contribute to the availability of the
Product. Refer to Fig 2.
The inherent availability of a Product depends on its reliability and maintainability
characteristics. It is the probability that a system will operate at any point in time when used
under stated conditions in an ideal support environment (eg, no lack of support resources). It
excludes preventive maintenance, delay times and is expressed as:

Ai =

MTBF
MTBF + MTTR

Where:−−−Ai is the inherent availability
MTBF is the mean time between failure
MTTR is the mean time to repair

Achieved availability is similar to inherent availability, with the exception that preventive
maintenance is included. It is expressed as:

Aa =

MTBM
MTBM + M

Where:−−−

Aa is the achieved availability
MTBM is the mean time between maintenance
M is the mean time for active maintenance activities

Operational availability is achieved by combining the Product and its support system. It is
described as the probability that a Product will operate sufficiently when called for, provided it isused under stated conditions in an actual support environment. It is expressed as:

Ao =

MTBM
MTBM + MDT

Where:−−

Ao is the operational availability
MTBM is the mean time between maintenanceApplicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00−

MDT is the mean maintenance down time 1

Defining the requirements for both the Product and the support system effectively achieves
Product availability by fulfilling these requirements through adequate maintenance activities.

ICN-B6865-S3000L0078-001-01
Fig 2 Breakdown of availability as an approach to structure design influence

2.2

Reliability
Reliability is a prime driver of support resources. It indicates how long and how likely the
Product will perform under stated conditions without any failure, or the probability that an item
can perform its intended function for a specified period of time under stated conditions.
Products with high reliability are usually cost effective in terms of support. In case it is notpossible to obtain a high level of reliability, the design of the Product must compensate thisissue by providing easy failure location and easy performance of maintenance activities. To
some extent, it is possible to compensate low reliability with increased maintainability andsupportability in order to ensure continuing availability.

2.3

Maintainability
Maintainability measures the ability of an item to be held or restored to a specific condition,
when qualified personnel perform maintenance, using recommended procedures andresources, at each recommended level of maintenance and repair.
Characteristics of maintainability are, for example:−−−−

the time needed to replace an equipment or part in a system
the repair of equipment in order to restore or maintain its functionality
the amount and complexity of support resources that are required
the required level of competence for personnel performing the activities

Product design can include various degrees of protection against environmental conditions,depending on different degrees of harshness. For example, the design can be specific towithstand an operational and maintenance environment in airports/airbases, loading/unloadingwith support equipment in sandstorm, hail or salt-laden environments. Refer to Chap 8.
Refer to Chap 13 for maintainability aspects for software, such as software loading.

1 Availability definitions from Benjamin S Blanchard, Logistics Engineeringand Management, 6th 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_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

2.4

Testability
Testability is a design characteristic, which identifies and establishes the status of an item
(operable, inoperable, or degraded) and the location of any faults/failures within the item in an
effective and timely manner.
It is possible to achieve a design solution to fulfill testability requirements by means of a test
system integrated into the Product (eg, Built-In Test (BIT)), or by a test system as a part of the
support resources requiring an interface to the Product to locate failures. Carefully designed test
systems reduce the effort to detect, localize and correct failures/faults, reduce the number of
No-Fault-Founds (NFF) and can also be used to verify full system functionality.
Redesign driven by testability requirements is a highly complex activity. It is fundamental to add
milestones in the design program to allow for necessary iterations. Testability requirements canalso be driven by the results of failure mode analysis. Refer to Chap 7.

2.5

Prognostics
Product parameters and data can be used in models to predict the need for maintenance orrepair. The functionality of maintenance or repair prediction can either be part of the Product or
the support system.
The benefits of prognostics include a deeper knowledge of Product’s "health" status, which canhelp avoid critical failures and plan for maintenance activities to ensure system functionality.
In systems that do not have a means of prognostics, preventive maintenance is used to prolong
the system lifetime and safety, and is balanced against the corrective maintenance activities
and resources.

2.6

Standardization
Using standard equipment instead of special equipment often proves to be more cost effective.
Development/design cost and time is reduced when using an existing part or system that fulfils
the requirements.
Using standardized equipment provides for the use of existing support resources that fulfill therequirement, thus reducing the need for investments in design and acquisition of support
resources. It is necessary to carefully consider design choices that require specially developed
support equipment, since such equipment increases costs.
Other positive effects include an increased maturity and knowledge of the Product/system andan increased operational unit mobility, by keeping a small logistics footprint.
Factors that support the potential benefits of using standard equipment or Commercial off The
Shelf (COTS) include:
−
−
−
−
−

the use of existing equipment avoids the development costs for new support resources
avoiding costs for the development of new training programs
using common support resources to increase the availability of support resources andreduce the logistics footprint
using standardized equipment to reduce the time required to determine and develop
support resource requirements
using support and test equipment to increase personnel proficiency when personnel use thesame equipment more often instead of having to learn to use different equipment

Standardization also improves the interchangeability characteristics of the Product.
Software design can also be influenced by standardization requirements concerning, forexample, programming languages, information structures or software, and information carrying
media.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

Before starting the design effort, it is necessary to establish requirements on standardization toachieve the benefits and minimize the cost of designing or redesigning to meet requirements.

2.7

Interchangeability
A Product design that enables interchangeability of equipment, components and parts within or
between Products is recommended, where applicable. This provides for increased flexibility ofusage of the equipment and a reduction of spare stock levels.
Before starting the design effort, it is necessary to establish requirements on interchangeability
to achieve the benefits and minimize the cost of designing or redesigning to meet requirements.

2.8

Environmental considerations
Available information on the operational and maintenance environment can influence the choiceof equipment and design solutions. Temperatures, humidity, sandy and salty environments aresome of the parameters that influence operation and maintenance.
Ensuring the Product fulfils requirements in-between operation during transportation,assembly/disassembly, and storage is also useful to increase the robustness of the Product.
Chemicals/materials needed for maintenance, operation and disposal are also important froman environmental perspective. Including hazardous materials, hazardous waste andenvironmental pollutants has an impact on the Life Cycle Cost (LCC), as well as on the safety of
personnel in contact with the Product. Refer to Chap 16.

2.9

Human factors/ergonomics
It is necessary to identify Product requirements related to human factors and ergonomics.
Product design must consider accessibility for operators and maintainers. Activities performed
during operation and maintenance, which include human factors must be considered as well.
Handling qualities, for example, parameters such as weight and size are relevant to support
resources to be able to perform activities physically.
Design tools can be used for early analysis of the accessibility for human and definition ofassembly/disassembly activities in virtual models.
Chemicals/materials included in the Product or needed for maintenance, operation and disposal
are also important from the point of view of human factors. In fact, including hazardous
materials and environmental pollutants have an impact on the safety of the personnel and theneed for support resources.
Product interface requirements, such as access panels for maintenance personnel, andoperator stations requirements are a shared interest between LSA and Product design. Refer toChap 6.

2.10

Obsolescence
Depending on the expected operational life of the Product, it is recommended that the possible
obsolescence situation during the design phase be considered. In case obsolescence occurs,
specific actions will be necessary to ensure continuous functionality. Typical actions include
redesign/modification, purchasing activities during Product lifetime, scrapping of a system andreplacement with a new system. When designing or choosing systems or subsystems during the
Product design phase, it is useful to keep in mind the future replacement of an item due toobsolescence. Refer to Chap 15.

2.11

Supportability
Supportability is the measure of the degree to which all resources required to operate andmaintain the Product are designed properly and available in sufficient quantity. Supportability
encompasses all IPS elements, such as technical information, support equipment, spares andpersonnel.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Careful system design that considers maintainability and reliability helps reduce the amount of
resources required for Product support. It is also possible to reduce Product downtime (eg,
active maintenance time), logistics delay times, and administrative delay times. A Product that
requires many support resources has a higher risk of shortage of support resources, waitingtime or queuing for resources. MTA defines the resource needs. Refer to Chap 12.
LORA defines the characteristics of the support solution by evaluating Product maintenancerequirements, resource needs and logistics footprint limitations against availability, operation,and support cost targets. Refer to Chap 11.

2.12

Cost effectivenessThe design and relevant choices have a cost implication for the LCC. Cost implications can be
broken down into design/development, production/procurement, operational and disposal costs.
It is necessary to perform comparative analyses of different design solutions, including therelevant support resources. These characteristics and costs are necessary to balance
availability and LCC (refer to Fig 3). Refer to Chap 14.

ICN-B6865-S3000L0079-001-01
Fig 3 Effectiveness - balancing availability and LCC

2.13

Software design
Software is usually a part of modern Product design. Software design requires carefulconsiderations, in order to include in the software some of the features mentioned in thischapter.
Considering the consequences of software support activities described in Chap 13, decisions on
software design and implementation are necessary to fulfil Product availability requirements.

3

Development programs
LSA must be integrated in Product development projects, to ensure that the corresponding LSA
activities are acknowledged and performed in a documented, structured, and interactive closedloop process.
The LSA representative is an important member of the entire 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 that most benefit the program.
LSA aims to influence design, develop the most effective support solution, and define
requirements for support resources. These general objectives need to become more specific forApplicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

individual projects. The type of project determines the amount of design flexibility andopportunity to influence the design, and is the main input when deciding on a strategy.
It is necessary to review, refine and balance defined objectives and the analysis strategy
against available resources, until they become definite program goals or requirements.

3.2

Design influence on development programs
The very nature of development programs can vary from:−−−new development programs, where the Product and support products are developed fromthe very beginning
design changes/improvements for systems or subsystems of an existing Productfast-track programs using existing technology developed in-house or by a supplier

Therefore, the amount of design freedom and possible design influence differs depending on
the nature of the development program. Development programs for complex Products are often
a combination of the development types described above. The program will also prioritize LSA
effort and objectives accordingly.
Furthermore, design freedom can be available only for the support system but not for the
Product, 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 towards reliability, maintainability, and supportability
objectives commencing with the design effort.

3.3

Supplier design
Supplier design is design performed by a vendor or subcontractor and must be approached in
the same 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 starting the design efforts.
In conjunction with design influence by goals and requirements, the requiring party must initiallydecide and specify the LSA activities that must be performed by the supplier, which activities
must be shared between the requiring party and the supplier, and those that must be performed
solely by requiring party. Once done, the LSA portion of the contracting plan can be developed
and work requirements written into the procurement documentation. It is often useful to allow
the prospective performing activities, under the bidding terms of the procurement, torecommend adding or deleting LSA activities and to provide a more detailed subtask definitionand schedule.
Additionally, prospective performing activities can be encouraged to make use of cost-effective
data generation procedures. Acquisition program objectives must be considered in preparing
procurement documents. For example, in technology demonstration procurement, certain LSA
activities can be specifically excluded. Supportability objectives for this type of procurement
would best be served through design influence and generation of LSA data for subsequentdetailed analysis efforts when the technology is utilized. If the acquisition program is oriented todevelop and procure a Product, then other LSA activities become equally important.
When a supplier provides a COTS system or equipment, the possibility to influence theequipment design is obviously very limited. However, the influence on the integration of thesystem/equipment in the Product and the support system is still as important as for any otherdevelopment project.

3.4

Critical/milestone design reviews
It is essential to establish and document design review procedures in case procedures do notexist already. They will provide official review and control of released design information jointlywith the LSA program, in a timely and controlled manner.

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

These procedures define accept/reject criteria, the method of documenting reviews, the types ofdesign documentation subject to review, and the degree of authority of each reviewing activity.
Program planning must coordinate and integrate the design and development reviews and the
LSA reviews. Formal review and assessment of LSA requirements are an integral part of each
Product design review. It is necessary to document results of each Product design review.
Design reviews must identify and discuss all pertinent aspects of the LSA program.
Technical information generated and documented during the design process must be sharedwith designers and supportability specialists, in order to identify interface problems between
design concepts and operators, maintainers, and support resources. Design documentationmust include technical design information such as diagnostic features, interfaces, reliability
estimates, obsolescence evaluations, and item functions determining supportability.
It is recommended that subcontractors and suppliers, as appropriate, be included in allscheduled "bottom-up" reviews. Developing and coordinating agendas helps address therelevant topics, as they apply to the program phase activities and the reviews.
Examples of topics are:−−−

LSA performed using task and WBS element
LSA assessment of proposed design features including supportability, cost, and readinessdrivers, and new or critical support resource requirements
corrective actions that have been considered, proposed, or taken, such as:
•
•
•
•
•

−
−
−
−

support alternatives under consideration
system/equipment alternatives under consideration
evaluation and trade-off analysis resultscomparative analysis against 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
required, completed, and scheduled LSA documentation
design, schedule, or analysis problems affecting LSA

Incorporating design reviews during the Product’s in-service, are also encouraged to improve
the Product based on operational experience and to effectively sustain a competitive Product.
In-service LSA deals with the principles and means for such development. Refer to Chap 17.

4

Checklists
To facilitate design work and reviews, checklists can be used as a starting point and input.
However, these checklists serve as examples. It is vital to define the questions and adjustments
to the checklist to suit the program. A synergy between LSA and design disciplines is often
necessary to define those checklists.2

4.1

Selection of parts/equipment
A checklist for the selection of parts/equipment can include, but is not limited to:−−−−Have appropriate standards been consulted for the selection of parts?
Have the selected parts/equipment been evaluated in terms of reliability, maintainability andsupportability?
Have suppliers been selected for component part procurement?
Is the supplier reliable in terms of quality, timeliness, and cost effectiveness?

2 Checklist developed from Benjamin S Blanchard, Logistics Engineeringand Management, 6th 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_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

4.2

Reliability
A checklist for reliability can include, but is not limited to:
−
−
−
−
−
−
−
−

4.3

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 for the system/equipment?
Has equipment design complexity been minimized?
Is protection against secondary failures (resulting from primary failures) incorporated where
possible?
Are reliability requirements met?

Maintainability
A checklist for maintainability can include, but is not limited to:
−
−
−
−
−
−
−

4.4

Has the number of different kinds of fasteners been minimized?
Is the type of fasteners standard items?
Have the fasteners been selected based on the requirements for standard tools rather thanspecial tools?
Are equipment items identified as replaceable?
Has replacement time been minimized?
Has the operational environment (eg, hailstorms, sandy, salty environments) been taken
into consideration?
Have considerations been made on how to load software, loading times and media?

Testability
A checklist for testability can include, but is not limited to:
−
−
−
−
−
−
−
−
−
−
−

4.5

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, warning lights, messages)
Are test points/interface provided to enable checkout and fault isolation beyond self-testlevel?
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 labeled?
Can every equipment malfunction be detected by a go/no-go indication at system level?
Will software provide adequate test information?

Prognostics
A checklist for prognostics can include, but is not limited to:
−
−
−

4.6

Is it possible to identify the functionality to predict maintenance needs for the equipment?
Is it possible to identify and obtain the parameters used to predict maintenance needs?
Do parameters used for prognostics have an adequate sampling frequency?

Standardization
A checklist for standardization can include, but is not limited to:−−−

Are standard equipment/parts incorporated in the design as appropriate?
Are the same parts used in similar applications?
Has the number of different part types used throughout the design been minimized?

Applicable to: All

S3000L-A-05-00-0000-00A-040A-A
Chap 5DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00−

4.7

Are identifying labels, markings and nomenclature standardized in full measure?

Interchangeability
A checklist for interchangeability can include, but is not limited to:
−
−

4.8

Are modules and components with similar functions interchangeable electrically, functionallyand physically (ie, the same form, fit and function)?
Are components with the same part number interchangeable, even if different suppliers
provide them?

Environment
A checklist for environmental aspects can include, but is not limited to:
−
−
−
−

4.9

Are the hazardous materials and pollutants identified and minimized?
Is it costly to handle, store, disassemble or dispose of the materials and equipment chosen
for the design?
Are special containers or facilities necessary to handle hazardous materials or pollutants?
Are the selected materials and equipment consistent with environmental regulations on
operation and disposal?

Human factors/ergonomics/accessibility
A checklist for human factors, ergonomics and accessibility can include, but is not limited to:
−
−
−
−
−
−
−
−
−
−
−
−
−
−

4.10

Are doors provided where appropriate? Are they hinged?
Are the size and location of openings adequate for access?
Are the doors and openings labeled? What information does the label provide?
Are access door fasteners minimized?
Are quick-release fasteners used for access doors?
Are tools necessary to gain access?
If tools are needed to gain access, are they minimized and standard design?
Is access between modules and components adequate?
Are hazardous materials and pollutants identified and minimized?
Is it necessary to use protective equipment when performing the maintenance task?
Is it possible to perform maintenance tasks with protective equipment if necessary (eg,gloves, helmet)?
Is the number of lifting devices for heavy or bulky items minimized?
Compared with the working position, is the time it takes to carry out a maintenance task
reasonable?
Are access requirements compatible with the frequency of maintenance?

Obsolescence
A checklist for obsolescence can include, but is not limited to:
−
−
−
−
−

5

Is the item at risk for obsolescence during the lifetime of the Product?
Does the design facilitate redesign if necessary due to obsolescence?
Is it possible to emulate or recreate the design?
Are any aftermarket sources available?
Is the supplier required to inform and initiate a purchase process or redesign of parts tocover the rest of the Product lifetime?

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:−

S3000L UoF Design Change Request

S3000L-A-05-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-05-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 52021-04-30 Page 12

S3000L-B6865-03000-00

Chapter 6
Human factors
Table of contents

Page

Human factors ................................................................................................................................ 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Objective .......................................................................................................................... 2
1.3
Scope ............................................................................................................................... 2
2
Logistics support analysis and human factors ................................................................. 2
2.1
Physical abilities and limitations ...................................................................................... 2
2.2
Limitations due to hazardous conditions ......................................................................... 3
3
Human factors analysis aspects ...................................................................................... 3
3.1
Influence on design ......................................................................................................... 3
3.2
Guidance for LSA ............................................................................................................ 3
4
Human factors to consider ............................................................................................... 4
4.1
Anthropometric aspects ................................................................................................... 4
4.2
Ergonomic aspects .......................................................................................................... 4
4.3
Environmental aspects .................................................................................................... 4
5
Associated parts of the S3000L data model .................................................................... 5
6
Additional information ...................................................................................................... 5

List of tables
1
2

References ...................................................................................................................... 1
Sources for additional information ................................................................................... 5

References
Table 1 References
Chap No./Document No.

Title

S6000TInternational specification for training analysis and design

MIL-STD 1472F

Human engineering, design criteria for military systems,
equipment and facilities

1272/2008/EC

EU Regulation on classification, labelling and packaging of
substances and mixtures (CLP)

2011/65/EC

Directive on the restriction of the use of certain hazardous
substances in electrical and electronic equipment (RoHS2)

1907/2006/EC

Regulation concerning the Registration, Evaluation,
Authorization and Restriction of Chemicals (REACH)

2006/42/EC

Directive on machinery

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

Chap No./Document No.

Title

2009/104/EC

Directive concerning the minimum safety and healthrequirements for the use of work equipment by workers at
work

ISBN 9780415304306

International Encyclopedia of Ergonomics and Human
Factors

ISO 26800

Ergonomics - General approach, principles and concepts

ISO 6385

Ergonomics principles in the design of work systems

1

1.1

GeneralIntroduction

Human factors provide source data that must be used within LSA activities to determine
maintenance crew and support equipment requirements. This relationship begins in the design
process and continues through the entire life cycle, with the focal point during Maintenance
Task Analysis (MTA).

1.2

Objective

1.3

Scope

2

2.1

It is necessary to coordinate LSA, maintainability and supportability functions to ensure that
potential support solutions are within established support thresholds (including the requirementsof human factors). This is accomplished by considering the crew size and the required support
resources for maintenance and operational support tasks. Human factors limitations influence
the establishment of support environment as well as the design of the Product. The limited
capabilities of a human being determine the limitations on Product usage and support. With
respect to support in particular, human factors have significant influence on the practicability ofoperational support and maintenance.
The capabilities and natural limitations of a human being should influence design and LSA.
This chapter aims to support design and supportability engineers who perform technical andsupportability analyses and describes the relationship and integration between human factors
and the LSA process. Because human factors can influence various phases of the LSA process
it is recommended that the results of the human factors analysis, including warnings andcautions, and the need for specific equipment to mitigate hazardous tasks/conditions be
documented and available at a very early project phase.

Logistics support analysis and human factors
Physical abilities and limitations

The LSA and human factors integration occurs throughout the whole Product life cycle. Productmodifications or proposed design changes can lead to changes to the maintenance activities
that include human factors constraints and/or limitations.
LSA and human factors have a common objective, but specific purposes and goals. Human
factors focus on various aspects, for which several standards (refer to Table 1) provide rules
and guidelines, including:
−
−
−
−
−

anthropometric aspects
ergonomic aspects
other physiological aspects
psychological aspects
legal requirements

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

The diameter of the average human forearm, for example, is a human factor. Any access panelthat requires a reach beyond the wrist must conform to the minimum size indicated in therelevant standards. In this case, the human factors influence the design to ensure all theseaccess panels comply with this size requirement. LSA must take into account these standards
to evaluate potential support solutions. In addition, LSA must consider the need for special
support equipment to complete a task under limited moving space conditions. If alternate design
solutions are identified during the analysis activities, they can be presented back to design forreconsideration.

2.2

Limitations due to hazardous conditions

Another aspect concerning human factors is the limitation of human activity because of healththreat.
The handling of dangerous or hazardous materials must follow strict regulations to ensure thesafety of all persons involved and the environment. At the end of the Product life cycle andduring the disposal phase in particular, human factors can be crucial due to an increased needto handle material, which is a risk for human health.
Other limitations must be considered for work under extreme environmental conditions such as:−−−−

cold or hot environments
humid environment
working underground or underwater
critical environment due other reasons (eg, dust, exposure to fumes, sound, light)

Design guidelines must ensure the protection of human beings against the effects of theseenvironmental impacts. LSA must address these guidelines.

3

3.1

Human factors analysis aspects
Influence on design

There are many industry standards (refer to Table 1) that address human factors design
constraints and requirements. The contractor/customer agreements and the contract include
and makes reference to them as appropriate.
It is necessary to take into account the human factors qualitative data to determine themaintenance crew skills, size and support equipment needs. For example, human factors will
provide weight limits for a single person lift and help identifying the maintenance crew size for a
specific task. This analysis will also identify the need for mechanical lifts, maintenance stands orprovide a feedback to the designers on the need for grips. This information can be used in a
trade-off study for design alternatives as an iterative process. Human factors provide
specifications and standards that must be applied to the individual maintenance tasks.
If applicable, the crew size requirement should take into account the demographic aspects aswell. This means that an all-male crew can have a greater lift limit than a mixed male/female
crew. Therefore, the weight of the item determines the proper number of people required forlifting, but the number will change based on the specific crew demographics. The weight
restriction must be taken into account for mechanical lift requirements and therefore impact
support equipment requirements. The location can influence the need for maintenance stands,
and the type of stand required will depend on the maintenance crew size.

3.2

Guidance for LSA

The LSA Guidance Conference (LSA GC) must identify the rules and guidelines for LSA andhuman factors analysis, including maintenance crew demographics, lift, reach and otherstandards and limitations. The customer and contractor must agree on specific standards. In
addition to this agreement, it is recommended to review all applicable standards and relevant
legislation, and to document any exception.

Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

Note
Exceptions for military equipment are typically only valid during wartime. An ever-increasing
number of civil contractors in military support implies that the Product and the support
equipment must meet civil regulations, regardless of their use.
LSA receives input from design and development trade-off analysis of each design alternative.
From the first design effort, LSA will analyze the design alternatives and compare the relevant
support requirements, and make recommendations based on the supportability and Total Costof Ownership (TCO). Several handbooks such as the “International Encyclopedia of Ergonomics
and Human Factors”, ISO standards as well as military specific standards (eg, MIL-STD 1472)
provide valuable information (refer to Table 1). It is recommended that the applicability of any
local specific rules be verified. The process involves identifying all the possible maintenanceactions and takes into account the mental workload under the expected operational conditions.
Tired people under a high level of stress can have a shorter memory span. Maintenancesequences must follow a similar logic, and color coding must be consistent. Each maintenancetask will result in a list of resources required to accomplish the task. These resources include
spare parts and consumables, maintenance man-hours, training, support equipment and test
equipment. The specific considerations on human factors include the number of maintainers
and the amount of support equipment related to human factors.
The entire analysis process is an iterative process that must be used for each design change.
Within the LSA process, the more detailed MTA starts upon the Product design approval. Each
maintenance task is compared against the human factors requirements to ensure that all
maintenance and operational support activities are within the human factor's limitations.

4

Human factors to consider

4.1

Anthropometric aspects

The human factors are not limited to those listed here, which provide an outline of the aspects
that can influence Product design and the design of the support environment (operational andmaintenance related), especially in LSA.
Anthropometric aspects that influence design include, but are not limited to:
−
−
−
−
−
−
−
−

4.2

Ergonomic aspects

Ergonomic aspects that influence design include, but are not limited to:
−
−
−
−
−
−

4.3

lines of sight (visual field, vertical and horizontal)
audio signals requirements
muscle strength of arms, hands and thumbrequired muscle strength for vertical pull extensions
required muscle strength for horizontal push and pull movements
maximum weight of units to be liftedmaximum 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 panel dimensions
illumination requirements

Environmental aspects

Environmental aspects that influence design include, but are not limited to:Applicable to: All

S3000L-A-06-00-0000-00A-040A-A
Chap 6

DMC-S3000L-A-06-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−

5

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
noise limitations
shock current intensities

Associated parts of the S3000L data model

The human factors analysis activities are performed outside the LSA scope. The results are aprecondition to enable the determination of a specific working environment for the Productoperators and maintainers.
Human factors analysis data is not documented in the frame of S3000L data model and there
are no related Units of Functionality from Chap 19.
Note
Human factors analysis outputs also serve as inputs to human factors analysis in S6000T.

6

Additional information

Each project must determine human factors requirements for the analysis process. Table 2
provides sources for more detailed information on how to evaluate the support equipment
related to human factors for any project.
Table 2 Sources for additional information
SourceURL

Human Factors and
Ergonomics Society (HFES)

http://www.hfes-europe.org

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_003-00_EN-US.docx

Chap 62021-04-30 Page 5

S3000L-B6865-03000-00

Chapter 7
Corrective maintenance analysis
Table of contents

Page

Corrective maintenance analysis ................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Purpose ........................................................................................................................... 3
1.2
Scope ............................................................................................................................... 4
1.3
Terms, abbreviations and acronyms ............................................................................... 4
2
Equipment corrective maintenance analysis ................................................................... 5
2.1
Introduction ...................................................................................................................... 5
2.2
Method ............................................................................................................................. 6
2.3
Candidate items ............................................................................................................... 7
2.4
Perform equipment failure mode grouping ...................................................................... 8
2.5
Identify means or symptoms for equipment failure mode detection .............................. 10
2.6
Define equipment failure mode isolation task requirements ......................................... 12
2.7
Define equipment operational test task requirements ................................................... 14
2.8
Inputs ............................................................................................................................. 17
2.9
Outputs .......................................................................................................................... 17
3
On-Product corrective maintenance .............................................................................. 17
3.1
Introduction .................................................................................................................... 17
3.2
Method ........................................................................................................................... 18
3.3
Candidate items ............................................................................................................. 19
3.4
On-Product failure mode grouping ................................................................................ 19
3.4.1
Possible on-Product failure mode causes ..................................................................... 19
3.4.2
Installed equipment failure mode grouping ................................................................... 19
3.4.3
Family based installation and structure components failure mode grouping ................ 21
3.4.4
Equipment installation details failure mode grouping .................................................... 22
3.4.5
General system/function failure mode grouping ............................................................ 23
3.4.6
General structure failure mode grouping ....................................................................... 24
3.5
Identify means (symptoms) for on-Product failure mode detection ............................... 24
3.6
Define on-Product failure mode isolation task requirements ......................................... 25
3.7
Validation test ................................................................................................................ 28
3.8
Inputs ............................................................................................................................. 28
3.9
Outputs .......................................................................................................................... 28
4
Relevant elements of the S3000L data model .............................................................. 28

List of tables
1
2

References ...................................................................................................................... 2
Terms specific for this chapter ......................................................................................... 4

List of figures1
2
3
4

Logical flowchart for equipment corrective maintenance analysis .................................. 7
Equipment failure mode grouping .................................................................................... 9
Failure mode grouping at equipment assembly level .................................................... 10
Equipment failure mode grouping including failure mode symptoms ............................ 11

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

5
6
7
8
9
10
11
12
13
14
15
16

Equipment failure mode grouping including failure mode isolation tasks ...................... 13
Equipment failure mode grouping including operational test tasks ............................... 15
Equipment failure mode grouping only including operational test tasks ....................... 16
Equipment failure mode grouping only including operational test tasks (simplified) ..... 16
Logical flowchart for on-Product corrective maintenance analysis ............................... 18
Installed equipment failure mode grouping (1) .............................................................. 20
Installed equipment failure mode grouping (2) .............................................................. 21
Family-based failure mode grouping ............................................................................. 22
Equipment installation details failure mode grouping .................................................... 23
General system/function failure mode grouping ............................................................ 24
On-Product failure mode grouping, including failure mode symptoms.......................... 25
On-Product failure mode grouping, including failure mode isolation tasks ................... 27

References
Table 1 References
Chap No./Document No.

Title

Chap 3

LSA process

Chap 4

Product structures and change management in LSA

Chap 8

Damage and special event analysis

Chap 11

Level of repair analysis

Chap 19

Data model

S4000PInternational specification for developing and continuously
improving preventive maintenance1

GeneralThe process for corrective maintenance analysis described in this chapter is a part of the eventdriven analysis activities, which are performed as part of the LSA. Corrective maintenanceanalysis aims to identify the corrective maintenance and failure mode isolation tasks, which arenecessary to develop and document.
This chapter describes possible methods to evaluate and identify corrective maintenance task
requirements that must be performed on the Product and/or its equipment in case an inherent
failure occurs.
Corrective maintenance analysis identifies:−−−

corrective maintenance tasks required to repair and restore the Product and its equipment
after a failure mode has occurred
symptoms indicating that a failure mode has occurred
failure mode isolation tasks required to determine which specific failure mode has occurred,in case where two or more failure modes have the same symptoms but require different
corrective actions

Note
Corrective maintenance analysis does not include step-by-step descriptions on failuremode localization procedures. It only identifies the tasks needed to determine that a
specific failure mode has occurred, or the tasks that can narrow down an ambiguous
Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

symptom to a smaller set of possible failure modes, in case it is not possible to isolate a
specific failure mode.
Failure Mode and Effect Analysis (FMEA) or Failure Mode Effect and Criticality Analysis(FMECA) are the starting point for the corrective maintenance analysis. In many cases,
FMEA/FMECA is performed during the Product Design & Development (D&D) phase, and there
are two possible approaches:−−

The equipment FMEA is a bottom-up analysis methodology that starts with equipment
failure modes, their local effects, and their higher effects on the equipment under analysis
The system/functional FMEA is a top-down analysis methodology that starts from thefunctions of the product/system under analysis, its functional failure modes, the functional
failure effects and the respective failure causes identified for each functional failure mode

Note
This chapter does not provide any guidance on how to carry out an FMEA/FMECA, but it
defines this type of analysis as a prerequisite. If there is no FMEA/FMECA in place, it isnecessary to determine how to develop one, or to define an alternative method on how toprogress with the corrective maintenance analysis.

1.1

PurposeCorrective maintenance analysis aims to describe a method to evaluate and identify corrective
maintenance task requirements during the early phases of Product D&D. This method also
evaluates the Product and its equipment from a testability perspective in order to identify
additional needs for failure mode detection and/or isolation means, and/or design
improvements.
Depending on the overall support concept, corrective maintenance can include tasks to be
performed on the Product itself, as well as tasks to be performed on the equipment whenremoved from the Product.
Corrective maintenance at Product level can be limited to the replacement of the faulty
equipment in order to reduce down time and limit the required resources (eg, special support
equipment and/or specific personnel competences). After that, it is possible to either repair the
replaced equipment at the workshop (at any maintenance level), or discard it. If required, it isnecessary to define and elaborate on-Product repair tasks for non-replaceable equipment (eg,
items of Product structure).
It is not possible to schedule corrective maintenance, which in most cases must be performed
as soon as non-acceptable tolerances are reached or exceeded.
Note
For the evaluation and identification of corrective maintenance driven by induced failurescaused by special events and/or by damages within or outside the specified usage
scenario, refer to Chap 8.
All Product systems, subsystems, equipment and components liable to fail can become
candidates for corrective maintenance analysis.
There are different ways to detect a failure mode, for example:−−−−

during Product operation by the operating crew
during the performance of preventive maintenanceby an integrated test-/monitoring system
by chance (random)

Some failure modes can be detected but not unambiguously localized. Therefore, failure mode
isolation tasks can be required to uniquely determine that a specific failure mode occurred, inorder to replace and/or repair the correct item.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

The need for failure mode isolation tasks is primarily dependent upon the availability of built-in
detection means and measurement points, but also on the availability of failure mode effectdescriptions identified during FMEA/FMECA. These factors come into play when analyzing anddetermining whether each individual failure mode has a unique set of symptoms or it requires
an additional failure mode isolation task.
A failure mode isolation task is a separate task that can support a failure mode localization
process. Typical failure mode isolation tasks include the use of external test equipment,functional tests and visual inspections.

1.2

Scope
The scope for corrective maintenance analysis is to describe a method that covers:−−

The identification of corrective maintenance and failure mode isolation task requirements toperform on the equipment
The identification of corrective maintenance and failure mode isolation task requirements toperform on the Product

Note
During the in-service phase, the maintainer will detect a symptom that triggers a fault
isolation/localization process to identify the faulty element. The corrective maintenanceanalysis starts with the analysis of the individual failure modes, and aims to define how themaintainer will detect, isolate and finally restore the faulty element. Corrective maintenanceanalysis defines all data needed for this process.
Note
The detection and isolation of the failure modes mainly concern the equipment and its
installation on the Product. However, the identification of failure modes on structural parts
mostly occurs through inspections or Non-Destructive Testing (NDT), regardless of them
being preventive or by opportunity.
This chapter mainly focuses on the equipment and its components whether installed on the
Product or in the workshop.

1.3

Terms, abbreviations and acronyms
Table 2 provides a list of terms specific for this chapter.
Table 2 Terms specific for this chapter
Terms

Definition/example

component

A non-repairable part of an equipment or sub-equipment.

equipment

Equipment is a part that is fulfilling a specified function or purpose
related to the Product.

equipment
installation details

Parts necessary to equipment installation on the Product.

failureFailure is the functional performance deficiency manifestation of a fault.

failure cause

Failure cause defines the physical or chemical process that is thereason for the failure mode.

failure mode

Failure mode defines the functional consequence of a fault.

Example: Fasteners, connectors

Example: low, erratic, or no output from an electrical circuit
Failure ModeGroup (FMG)

FMG represents a set of failure modes that leads to the same set ofactions to detect, isolate and rectify those failure modes.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

Terms

Definition/example

fault

Fault defines the unacceptable state of the failed item.
Example: a broken wire

fault isolation
process

Fault isolation process is a process that identifies the item at fault.

fault isolation task

A fault isolation task is a task that can contribute to determine the item
at fault.

general installation
details

Parts of the Product that connect pieces of equipment for a specificfunction (eg, piping, wiring)inherent failure

Inherent failure is a failure due to the existing and inherent
characteristics of an item.

installed equipment

Equipment located in a specific place within the Productobservable
symptom

Observable symptom is a symptom that an operator can recognize as
the manifestation of a fault condition.
Note
Flight crews, maintenance personnel or mission crews canrecognize an observable symptom.

sub-equipment

A repairable/restorable part of the equipment.

symptom

Symptom is a measurable or visible parameter that, if present, can beassociated to a fault, either directly or indirectly.

symptom ambiguity
group

Symptom ambiguity group is a set of items that require further fault
isolation activities, since the given symptom, or set of symptoms is notenough to determine the actual item at fault.

symptoms
signature

Symptoms signature identifies a set of symptoms that, if present, can beassociated with a fault.

2

Equipment corrective maintenance analysis

2.1

Introduction
The equipment corrective maintenance analysis aims to define equipment corrective
maintenance task requirements, and to identify a method to detect and isolate equipment failuremodes.
The result is a set of equipment FMG, which is a unique combination of:−−−

One corrective maintenance task requirement, which is common to the included (grouped)equipment failure modes (ie, all the included equipment failure modes lead to the exact
same corrective action). Some equipment failure modes do not have a viable corrective
maintenance task requirement. In such cases, there is just a discard/scrap decision, andpossibly an associated equipment neutralization/disposal task requirement. It is necessary
to also define this type of conclusion as an equipment FMG.
One or more symptoms that are common to all equipment failure modes which are groupedagainst the equipment FMG
One or more failure mode isolation task requirements that can determine which of the
included equipment failure modes has occurred

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

Note
Any equipment FMG can have more than one defined failure mode isolation task. This isrequired whenever it is not possible to determine directly and unambiguously which of the
failure modes associated with the equipment FMG has occurred. In this case, it isnecessary to proceed step by step to reduce the number of possible equipment FMG, inorder to eventually isolate only one equipment FMG.
Corrective maintenance analysis starts with the equipment failure modes identified for individual
equipment. Each equipment failure mode is then analyzed from the perspective of whatcorrective maintenance task is required to repair/restore the equipment and whether it istechnically and/or economically feasible to perform the corrective task.
Note
In many cases, the Original Equipment Manufacturer (OEM) or equipment supplierperforms this type of analysis. This means that the corrective tasks defined by the OEM or
supplier only need to be analyzed in the context of corrective maintenance analysis definedfor the Product (refer to Para 3).
Note
The result of the corrective maintenance analysis is an important input to the LORA. Refer
to Chap 11.
It is also necessary to analyze each equipment failure mode on the basis of the identified
symptoms, which can support the detection/isolation of individual equipment failure modes.
Symptoms can be built-in test capabilities, measurement points and/or local or next higher
failure mode effects as recorded in the equipment FMEA.
If the symptoms defined for an equipment FMG are ambiguous (ie, there is more than one
equipment FMG with the same symptoms), then it is necessary to associate the equipment
FMG to a failure mode isolation task requirement.
Note
Equipment corrective maintenance analysis does not consider the use of the equipment in
any Product, but it only considers the equipment itself.
It is also important to determine the extent of the performance of the equipment corrective
maintenance analysis. A general rule is that it is only necessary to define corrective
maintenance, failure mode isolation and/or operational test task requirements to be performedon the equipment at customer/operator sites. The analysis often excludes the corrective
maintenance performed by industry.

2.2

MethodFig 1 presents the method for the equipment corrective maintenance analysis in the form of aflow chart.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

ICN-B6865-S3000L0080-002-01
Fig 1 Logical flowchart for equipment corrective maintenance analysis
The method for performing equipment corrective maintenance analysis includes the following
sub-processes:
1

Perform equipment failure mode grouping and define the corrective maintenance task
requirements (refer to Para 2.4).

2Identify the means (symptoms) for equipment failure mode detection (refer to Para 2.5).

3Identify the means for equipment failure mode isolation and define the equipment failuremode isolation task requirements (refer to Para 2.6).

4

Identify the need for equipment operational test and define the equipment operational test
task requirements (refer to Para 2.7).

Equipment corrective maintenance analysis is an iterative process. If there is no obvious way togroup equipment failure modes into one or more equipment FMG based on the resulting
corrective maintenance task requirements, at first it is necessary to consider each equipment
failure mode as an equipment FMG. Afterwards, it is necessary to compare each equipment
FMG to other equipment FMG, to determine the relevant equipment FMG.

2.3

Candidate items
The first activity is to identify equipment which is subject for equipment corrective maintenanceanalysis. This activity is part of the overall candidate selection activity described in Chap 3. It isnecessary to perform it in conjunction with LORA (refer to Chap 11).
Below are some examples of specific questions for the selection of the candidate items for theequipment corrective maintenance analysis:−−−

Is it possible to open/disassemble the equipment to get access to equipment componentsthat can cause the equipment failure mode?
Is it possible to replace equipment components with a reasonable effort?
Is opening/disassembling the equipment covered by the warranty?

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

−
−
−

2.4

Is it possible to procure the relevant equipment components as spare parts?
Is it economically meaningful to repair the equipment?
Does the equipment contain hazardous material, which requires special resources?

Perform equipment failure mode grouping
Equipment failure mode grouping is a bottom-up approach. This means that if an equipment is
an assembly of other repairable/restorable parts, it is necessary to perform the analysis startingfrom the lowest level of repairable/restorable parts, moving upwards towards the “end”
equipment.
Note
The term equipment defines a part that fulfills a specified function or purpose related to the
Product.
Note
The term sub-equipment is used when referring to repairable/restorable parts of anequipment, in order to use the phrase "equipment corrective maintenance analysis" forthose parts as well.
The rationale for this bottom-up approach is to proceed gradually to determine the FMG and its
associated corrective maintenance task requirements for each equipment/sub-equipment.
Moreover, the approach ensures that the FMG for the sub-equipment is analyzed when put into
the context of the parent equipment.
The differences in the corrective maintenance strategies for the equipment (sub-equipment) willaffect the failure mode grouping. Examples of the corrective maintenance strategies are:−−−−only the test tasks are performed at the customer/operator site, while all other tasks are
performed at industry level
the tasks for test and replacement of the sub-equipment are performed at thecustomer/operator site, but all other repair and disposal/neutralization tasks are performed
at industry level
all test, repair/restore and disposal/neutralization tasks are performed at thecustomer/operator site
all test, repair/restore and/or disposal/neutralization tasks are performed at industry level

Note
If the approved equipment maintenance concept requires to perform test, repair, restore,
disposal and neutralization activities at industry level, then the program must define theneed to perform any further corrective maintenance analysis for that equipment/subequipment. It is necessary to keep in mind that this analysis provides an opportunity to
produce inputs in order to consolidate the equipment maintenance concept from a LORA
perspective (refer to Chap 11). It can still be important to keep information on thereparability and testability of the equipment/sub-equipment if the in-service feedback
reveals the need for further substantiation or evolution.
Equipment (sub-equipment) can have multiple failure modes that lead to the same FMG. In thiscase, the number of equipment FMG will be significantly less than the number of failure modes.
In general, the process reuses the existing equipment FMEA/FMECA and equipment part lists(often referred to as EBOM), refer to Chap 4). This information originates from Product D&D
activities or from the equipment OEM or supplier.
This process then uses the identified failure modes and parts lists to determine the possibility todevelop a corrective maintenance task. If it is possible to repair/restore the equipment (subequipment), then its respective failure mode will be associated with an equipment FMG. Then,the latter is associated with a corrective maintenance task requirement that meets the need forthe identified corrective action (refer to Fig 2).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

ICN-B6865-S3000L0081-003-01
Fig 2 Equipment failure mode grouping
For equipment assemblies, it is necessary to analyze the respective FMG for the sub-equipmentin the context of the parent equipment assembly. In this case, it is necessary to consider therespective FMG for sub-equipment in the failure mode grouping activity for the parent
equipment assembly, and not the individual sub-equipment failure modes.
For equipment that contains other equipment (sub-equipment), the failure mode grouping
activity must consider:− Equipment failure modes related to non-repairable/non-restorable components included in
the assembly equipment− FMG defined for included sub-equipment
Note
The FMG defined for the parent equipment must not be the same as the FMG defined forthe included sub-equipment. This is because corrective actions for the sub-equipment
require a redefinition in the context of the parent equipment assembly, and therefore will bedifferent.
An FMG defined for the assembly equipment can trigger either a replacement of the subequipment or a repair of the sub-equipment at equipment assembly level. Since it is necessary
to describe the corrective task for the sub-equipment in the context of the equipment assembly,
the sub-equipment repair at parent equipment assembly level will be different. For example, therepair of sub-equipment at equipment assembly level can require additional steps to get accessto the sub-equipment, as well as different support equipment to gain access.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

ICN-B6865-S3000L0148-001-01
Fig 3 Failure mode grouping at equipment assembly level
Note
The example in Fig 3 shows that a computer can be considered as an equipment assemblythat contains, for example, a mainboard as one of the sub-equipment. The mainboard itself
has its own equipment failure modes and failure mode grouping, which is necessary toconsider in the parent equipment (ie, the computer). In case of a failure of a component on
the main board (eg, the processor), it is possible to repair the computer by replacing thefaulty processor on the mainboard. For this repair, there is no need to remove themainboard from the computer.

2.5

Identify means or symptoms for equipment failure mode
detection
The next step in the equipment corrective maintenance analysis is to identify the means todetect the equipment failure modes. It is necessary to analyze each possible equipment failuremode taking into consideration the following:−−−

Check if there is any form of automatic detection that triggers a warning device in case a
failure mode occurs. If yes, assess the detection rate and false alarm rate of this automatic
detection mean.
Check if there are any measurement points (eg, gauges) that can indicate that the failuremode has occurred
Check functional symptoms and/or physical symptoms that can help detect the failuremode. It is possible to use the failure mode effects listed in FMEA as a guideline.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00−−

Record the associated detection means, measurement points and functional and/or
physical symptoms against the equipment FMG. If the identified detection means,measurement points, functional symptoms or physical symptoms differ between the failuremodes associated with the same equipment FMG in step 1 (refer to Para 2.4), then it isnecessary split into one unique equipment FMG per symptoms “signature”.
If it is not possible to detect the associated equipment failure modes using the means
above, it will be regarded as symptoms “signature” not available. For additional discussions
on hidden failures, refer to S4000P.

Note
Only detection means available at workshop level are part of this analysis. As part of theequipment manufacturing process, an operational test is frequently performed to validate
the manufactured equipment. This kind of test can be considered as an existing means todetect an equipment FMG, refer to Para 2.7 for detail. Para 3 describes the use of detectionmeans built into the Product, which can also provide inputs on the detection of equipment
FMG.

ICN-B6865-S3000L0149-001-01
Fig 4 Equipment failure mode grouping including failure mode symptoms
The example in Fig 4 shows that it is necessary to split the initially identified equipment FMG 2,
into two separate equipment FMG 2A and equipment FMG 2B, due to the differences in thesymptoms. This difference indicates the respective subset of the included equipment failuremodes. Also note that equipment FMG 1 and FMG 2A have the same symptoms and therefore
require additional equipment failure mode isolation tasks in order to determine, upon noticing
the symptoms signature, which of the two equipment FMG has occurred (refer to Para 2.6).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

Note
The same principle also applies to sub-equipment. The only difference is the equipment
failure modes defined in the example above are replaced with FMG defined for the subequipment (refer to example in Para 2.4).

2.6

Define equipment failure mode isolation task requirements
The next step in the equipment corrective maintenance analysis is to identify the means toisolate the equipment failure mode and define the equipment failure mode isolation task
requirements, in case two or more equipment FMG have the same set of failure mode
symptoms (symptoms signature). This is also referred to as symptoms ambiguity groups (refer
to Para 2.5).
If the identified symptoms are unique for the equipment FMG, there is no need to define
additional task requirements. However, if the symptoms identified by a Built-In Test (BIT) with ahigh rate of false alarms, it can be necessary to define an additional equipment FMG for an
operational test task requirement (refer to Para 2.7).
For each equipment FMG that is part of a symptoms ambiguity group, the analysis must include
the following steps:
1

Check if any form of test can isolate the respective equipment failure mode.

2

Check if a functional test or visual inspection can isolate the respective equipment failure
mode.

3

Check if any measurement points (eg, gauges) can isolate the respective equipment failure
mode.

4

Check functional symptoms and/or physical symptoms likely to help to isolate therespective equipment failure mode.

Note
Only test means available at workshop level are part of this analysis. As described in
Para 2.5, it is possible to consider an existing operational test as a means to isolate anequipment FMG. Refer to Para 2.7 for details on operational test. Para 3 describes the useof test means built into the Product. In some cases, these test means can procure inputs
that can be useful to isolate an equipment FMG at workshop level.
Note
The scope of the LSA does not include elaborating the equipment failure mode localizationand isolation process itself (also known as troubleshooting). Although the equipment
corrective maintenance analysis as defined in this chapter indicates how to isolate specificequipment failure modes, the complete troubleshooting process to prioritize and sequence
failure mode isolation tasks for equipment FMG with the same symptoms signature canrequire additional factors (eg, probability of occurrence of each equipment FMG, elapsed
time to restore each equipment FMG). Some of these factors are only available during thein-service phase (eg, status and history for serialized equipment, availability of spares
parts).
The equipment failure mode isolation task requirement then must be recorded against therespective equipment FMG. If the equipment failure modes associated with the same equipment
FMG in step 1 and 2 (refer to Para 2.4 and Para 2.5) have different equipment failure mode
isolation task requirements, then it is possible to split the equipment FMG into a single
equipment FMG per identified equipment failure mode isolation task. Even if this information is
not useful at workshop level, given that the repair solution is the same for the two equipment
FMG, it can provide inputs for an isolation task at Product level, if one or more equipment’s
FMG have the same symptoms signature.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

ICN-B6865-S3000L0150-001-01
Fig 5 Equipment failure mode grouping including failure mode isolation tasks
Fig 5 shows that equipment FMG 1 and FMG 2A have the same symptoms and therefore
require additional equipment failure mode isolation tasks in order to verify which of the two
equipment FMG has occurred upon recording the symptoms signature (refer to Para 2.5).
Furthermore, Fig 5 shows that the equipment FMG 2B has been split into two separate
equipment FMG considering that it requires different equipment failure mode isolation tasks todetermine which equipment failure mode has actually occurred. As previously said, this canprovide an input for the isolation tasks at Product level in case of ambiguity between different
equipment FMG.
Note
Depending on the business rules for a specific program, it is also possible to assign both
Failure mode isolation 3 and Failure mode isolation 4 to the equipment FMG 2B. This
indicates that if one of these failure mode isolation tasks is successful, it is necessary to
perform its associated corrective maintenance task.
The documentation of equipment failure mode isolation task requirements can include
references and additional descriptive information, for example:−−

references to technical documents that must or can be used during the equipment failuremode isolation task (eg, technical plan, wiring diagram, interface description)
possible crosschecks that can help to isolate the equipment failure mode. Suchcrosschecks are useful for identifying the sources of common causes for equipment failuremodes. It is also advisable to document the symptoms to be monitored or recorded during
these crosschecks.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00−

measurements to be carried out to check the physical and/or functional characteristics of
the item under analysis, including:••test equipment required to perform these measurements
expected values for each measurement and signification of unexpected measures

There can be a requirement to assign more than one equipment failure mode isolation task toan equipment FMG. This reflects the need to step by step narrow down possible equipment
failure modes that have led to the same symptoms for multiple equipment FMG. It is possible torecord the logical order for performing the equipment failure mode isolation tasks in the context
of the individual equipment FMG, but it is not documented in the form of logical decision treesthat indicate how to prioritize the different equipment failure mode isolation paths (also referred
to as troubleshooting).
Note
The same principle also applies to sub-equipment. The only difference is the equipment
failure modes defined in the example above are replaced with FMG defined for the subequipment (refer to example in the note below Fig 4).

2.7

Define equipment operational test task requirements
At the Product level, an equipment is sent to the workshop for corrective maintenance when it
has been detected as potentially at fault. At Product level, it is not always possible to identify thefaulty equipment unambiguously. Sometimes, the equipment can be part of a group ofequipment that has the same symptoms signature. This group of equipment is called an
ambiguity group, and it is possible to replace the complete group of equipment to restore theProduct's availability as fast as possible. Sometimes, the detection itself can have a degree of
uncertainty (eg, a BIT on-Product level can have a high false alarm rate).
In these cases, when equipment is received in the workshop, it first undergoes an operational
test to confirm the equipment is actually at fault. This kind of test can be similar to the test
performed at the end of the manufacturing process for the equipment acceptance.
Altogether, this type of operational test task can meet different requirements regarding theequipment corrective maintenance analysis. The requirements are:−Confirm equipment at fault
As previously described, such operational test tasks can be performed on the equipment atworkshop level as soon as the equipment at fault is received in the workshop. The result of
the equipment operational test task will confirm that the equipment is actually at fault, orthat the equipment is not at fault. In the latter case, the equipment is classified as No Fault
Found (NFF) and sent back to the Product level.

−

Provide an additional failure mode isolation test task
In some cases, the operational test task can produce results that can help isolating theequipment FMG at fault, and it can be regarded as a failure mode isolation task
requirement.

−

Final validation test after equipment repair
The operational test task can be performed as the last task of the repair process to validatethat the equipment has been properly restored.

Regarding the equipment operational test task, the equipment corrective maintenance analysis
determines the need to perform an operational test task on each equipment FMG to cover thedifferent requirements mentioned above. Taking into account that such an equipment
operational test can exist through the manufacturing process, record the equipment operational
test requirement for each relevant equipment FMG.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

ICN-B6865-S3000L0151-001-01
Fig 6 Equipment failure mode grouping including operational test tasks
Fig 6 shows that the equipment FMG 2B requires an operational test task, whereas FMG 1 and
FMG 2A don't. The list below shows examples where it is necessary to define requirements
such as:−−−−if the equipment FMG symptoms signature is ambiguous (eg, high false alarm rate for oneof the alarms that is part of the symptoms signature)
if the equipment FMG symptoms signature is common to others equipment FMG, there will
be an equipment ambiguity group. This can lead to having equipment sent to the workshop,with no certainty that the equipment is actually at fault.
if the isolation task for the equipment FMG is not enoughif there is no efficient test to validate the equipment repair action

Some maintenance concepts determine that only operational tests will be performed at thecustomer/operator site. All other equipment corrective and failure mode isolation tasks thenoccur at industry level. For such maintenance concepts, the equipment corrective maintenanceanalysis will only consider the equipment FMG operational test task. There is no need toconsider any further analysis for the respective equipment failure mode (refer to Fig 7).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

ICN-B6865-S3000L0152-001-01
Fig 7 Equipment failure mode grouping only including operational test tasks
Fig 7 shows that there are two identified symptom signatures, one of which requires anoperational test before the equipment is sent to industry for further repair or discard activities. If
the operational test for Symptoms signature 1 is successful, it is possible to record it as NFF.
The example in Fig 7 refers back to a set of equipment failure modes that is the basis for therespective symptoms signature. This is not an absolute requirement if the OEM/supplier only
defines symptoms and test tasks as a simplified approach (refer to Fig 8).

ICN-B6865-S3000L0153-002-01
Fig 8 Equipment failure mode grouping only including operational test tasks (simplified)
Note
The same principle also applies to sub-equipment. The only difference is the equipment
failure modes defined in the example above are replaced with FMG defined for the subequipment (refer to the example in the note below Fig 4).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

2.8

Inputs
The following inputs are required to perform the equipment corrective maintenance analysis:
−
−
−
−

2.9

Candidate Item List (CIL)
equipment part list (often referred to as EBOM)
equipment FMEA (often referred to as technical FMEA)
operational test task used for equipment acceptance in the manufacturing process

Outputs
The equipment corrective maintenance analysis produces the following output:−

equipment FMG and its:
•
•
•
•
•

associated equipment failure modes
failure mode symptoms
corrective maintenance task requirements
failure mode isolation task requirements
equipment operational test task requirements

3

On-Product corrective maintenance

3.1

Introduction
The on-Product corrective maintenance analysis aims to define on-Product corrective
maintenance task requirements, and to identify a method to detect and isolate Product failuremodes.
The result is a set of Product FMG, where each FMG is a unique combination of:−−−

one corrective maintenance task requirement, which is common to the included (grouped)
Product failure modes (ie, all the included Product failure modes lead to the exact same
corrective action)
one or more symptoms that are common to all Product failure modes grouped against theProduct FMG
one or more failure mode isolation task requirement that can identify the included Productfailure mode that has occurred

Note
There can be more than one defined failure mode isolation task requirement for any
Product FMG. This is required whenever it is not possible to determine directly and without
ambiguity which of the failure modes associated with the Product FMG has occurred. In thiscase, it is necessary to gradually reduce the number of possible Product FMG, in order toeventually isolate one Product FMG.
As described at Para 2, corrective maintenance analysis starts analyzing each FMG defined forthe equipment to be installed on the Product, using a bottom up approach and considering theequipment in the context of the Product. This step is a grouping activity where the defined
equipment FMG are analyzed from the perspective of what corrective maintenance task isrequired to repair/restore the Product.
The next step is to analyze and group the failure modes defined for the structure (eg, fuselage)
and the installation details (eg, wires, tubes, fasteners). In the same way as for equipment
corrective maintenance analysis, the on-Product corrective maintenance analysis will produce a
set of FMG. The difference is that Product FMG are primarily associated with breakdown
elements representing, for example, installation locations, families of hardware items (eg,composites, tubes, wiring). Refer to Chap 4.
It is then necessary to analyze each Product FMG on the basis of the identified symptoms,
which can support the detection/isolation of individual failure modes. Symptoms can be built-in

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

test capabilities, measurement points and/or local or next higher failure mode effects asrecorded in the system/functional FMEA/FMECA defined for the Product.
If the symptoms defined for a Product FMG are ambiguous (ie, different Product FMG have thesame symptoms signature), it is necessary to associate the Product FMG with a failure mode
isolation task requirement.
Note
Product corrective maintenance analysis must consider available failure mode detectionmeans incorporated into the Product.

3.2

MethodFig 9 shows the method for the on-Product corrective maintenance analysis in the form of a flow
chart.

ICN-B6865-S3000L0154-001-01
Fig 9 Logical flowchart for on-Product corrective maintenance analysis
The method for performing on-Product corrective maintenance analysis includes the following
sub-processes:
1

Perform on-Product failure mode grouping and define corrective maintenance task
requirements (refer to Para 3.4)

2

Identify the means (symptoms) for on-Product failure mode detection (refer to Para 3.5)

3Identify the means for on-Product failure mode isolation and define on-Product failure mode
isolation task requirements (refer to Para 3.6)

4

Identify the need for Product validation tests (refer to Para 3.7)

Note
The on-Product corrective maintenance analysis is an iterative process.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

3.3

Candidate items
The first activity is to identify the installation locations (equipment), structure and installation
details that will undergo the on-Product corrective maintenance analysis. This activity is part ofthe overall candidate selection activity described in Chap 3.
Examples of specific questions related to the selection of candidate items for on-Productcorrective maintenance analysis are:−−−Is there equipment likely to fail during the estimated Product operational life?
Are there any structure components that are likely to degrade beyond acceptable limits
during the estimated Product operational life?
Are there any installation details (or families of installation details) that are likely to failduring the estimated Product operational life?

Whether equipment, structural component or installation detail is subject to failure or degrading,is often based on an analysis which include criticality assessment, available redundancies etc.
Refer to S4000P.

3.4

On-Product failure mode grouping

3.4.1

Possible on-Product failure mode causes
Based on the different types of corrective maintenance candidate items described in Para 3.3,
this paragraph includes five major failure mode grouping activities. These are:
−
−
−
−
−

3.4.2

installed equipment failure mode grouping
family based installation and structure failure mode grouping
equipment installation details failure mode grouping
general system/function failure mode grouping
general structure failure mode grouping

Installed equipment failure mode grouping
Installed equipment failure mode grouping is a bottom-up approach where the equipment FMG
is analyzed in the context of its respective installation location. Installation locations are best
represented as hardware elements in a Product breakdown structure (refer to Chap 4).
The rationale for this approach is to gradually determine the Product FMG and its associatedcorrective maintenance task requirements for each on-Product installation location, and toensure that the equipment FMG is analyzed when put into the context of individual installation
locations (refer to Fig 10).
Note
On-Product failure mode grouping does not need to consider what will be done with theequipment, its sub-equipment and components once removed from the Product.
Sometimes, however, on-Product FMG can already point to specific maintenance activities
to be performed on shop level after removal of the faulty equipment.
Note
The on-Product failure mode grouping analysis must only consider the FMG defined for theequipment to be installed.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

ICN-B6865-S3000L0155-001-01
Fig 10 Installed equipment failure mode grouping (1)Note
As shown in Fig 10, the corrective maintenance task requirement does not indicate thename of the equipment to be replaced on-Product because there can be more than one
type of equipment installed at the installation location represented by Hardware element X.
Equipment installed at different locations can result in totally different FMG, for example due toaccess aspects (refer to Fig 10 and Fig 11). Fig 11 shows that it is not possible to repair theequipment at Product level for Hardware Element Y (eg, due to tool access).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

ICN-B6865-S3000L0156-001-01
Fig 11 Installed equipment failure mode grouping (2)Other situations to consider when performing the installed equipment failure mode grouping are:−−−more than one equipment can be installed at a given location (form, fit and function
equivalent)
more than one equipment can be installed at a given location (form, fit and function
equivalent), but they can have differences in their respective FMG (eg, one equipment has
a battery that can be replaced while another equipment does not)totally different equipment can be installed (eg, for mission configurations)

Each of these examples can have an impact on both Product breakdown structures as well as
on scoping for individual FMG. It is necessary to define detailed decisions for each project.
3.4.3

Family based installation and structure components failure mode grouping
The installation and structure components failure mode grouping covers two major areas.
−−

installation details that serve one or many pieces of equipment, and/or one or manysystems/functions (eg, electric wiring, hydraulics)
structure components which support the entire ProductDifferent types of platforms can have different approaches for performing on-Product corrective
maintenance analysis and failure mode grouping, but the common denominator should be an
FMG that reflects standard repair procedures for the type of installation and structuretechnology used (refer to the descriptions of breakdown elements that represent families ofparts, Chap 4). Fig 12 shows the basic principle.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

ICN-B6865-S3000L0157-002-01
Fig 12 Family-based failure mode grouping
Note
The family concept described in Chap 4 does not consider parts and part identifiers.
Note
In most cases, no FMEA is performed at this level of detail.
3.4.4

Equipment installation details failure mode grouping
The equipment installation details failure mode grouping considers installation details that are
directly associated with the installation of single pieces of equipment (eg, fasteners,
connectors).
The equipment installation details failure mode grouping is an extension of the installed
equipment failure mode grouping (refer to Para 3.4.1), and it takes into consideration installation
details failure mode grouping based on family (refer to Para 3.4.2). The rationale for performing
this analysis after carrying out the installation details failure mode grouping based on family isthat it will probably not be necessary to repeat the general corrective task requirement forindividual installation locations. In many cases, however, there will only be corrective
maintenance task requirements defined specifically for individual installation locations (eg, for
failure modes where fasteners must be tightened because of vibrations). This is a failure mode
effect. Refer to Fig 13.
System/functional FMEA/FMECA can identify equipment installation details failure modes, but it
is not always the case. Therefore, it is advisable to always analyze possible installation details
failure modes for each installation location as part of the on-Product corrective maintenanceanalysis.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00

ICN-B6865-S3000L0158-001-01
Fig 13 Equipment installation details failure mode grouping
3.4.5

General system/function failure mode grouping
The general system/function failure mode grouping is often organized against the respective
system/function. The rationale for performing this analysis after carrying out the installation
details failure mode grouping based on family (refer to Para 3.4.2) is that it will probably not benecessary to repeat the standard corrective task requirement for individual systems/functions.
For example, there can be a system/function-oriented on-Product FMG, which does not have anassociated corrective maintenance task requirement, but only a set of symptoms and failuremode isolation task requirements.
However, in many cases there can also be uniquely defined corrective maintenance task
requirements for the system/function on-Product (eg, restore an electric circuit, refer to Fig 14).
System/functional FMEA/FMECA can identify system/function failure modes, but it is not always
the case. Therefore, it is advisable to always analyze possible general system/function failuremodes as part of the on-Product corrective maintenance analysis.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00

ICN-B6865-S3000L0159-001-01
Fig 14 General system/function failure mode grouping
Note
General system/function failure modes can often be detected by BIT.
3.4.6

General structure failure mode grouping
General structure failure mode grouping is probably not as common as other failure modegrouping analysis activities. In many cases, special events and damages will call for corrective
maintenance on the general structure (refer to Chap 8). However, it is worth mentioning general
structure failure mode grouping as an explicit analysis activity.
When performed, it will be very similar to a general system/function failure mode grouping, withthe following exceptions:
−
−

3.5

The on-Product FMG for structure failure modes is defined for a breakdown element that
represents the structure or portion of the structure
There will be a lower degree of built in test capabilities

Identify means (symptoms) for on-Product failure mode
detection
The identification of on-Product failure mode detection means (symptoms) follows the same
logic as described for equipment (refer to Para 2.5). It is necessary to analyze each possible onProduct failure mode (including equipment FMG) considering:−−−checking whether there is any form of automatic detection that triggers a warning device
whenever an on-Product failure mode occurs. If yes, assess the detection rate and false
alarm rate of this automatic detection mean.
checking whether there are any measurement points (eg, gauges) that can indicate that theon-Product failure mode has occurred
checking functional symptoms and/or physical symptoms that can help detect the onProduct failure mode. It is possible to use the system/function failure mode effects listed in
the system/functional FMEA/FMECA as a guideline.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00−

recording the associated detection means, measurement points and functional and/or
physical symptoms against the on-Product FMG. If the identified detection means,measurement points, functional symptoms or physical symptoms differ between the onProduct failure modes associated with the same on-Product FMG in step 1 (refer toPara 3.4), then it is necessary to create a single on-Product FMG for each symptoms“signature”.
If it is not possible to detect the on-Product failure mode using the means above, it will be
regarded as symptoms “signature” not available. For additional discussions on hidden
failures, refer to S4000P.

−

Note
The analysis must only include detection means that are available at Product level. Para 2
describes the use of detection means for equipment on bench.

ICN-B6865-S3000L0160-001-01
Fig 15 On-Product failure mode grouping, including failure mode symptoms
Fig 15 shows that the initially identified on-Product FMG 1 has been split into FMG 1A and FMG
1B due to the differences in symptoms. Each division indicates the respective subset of the
included equipment FMG.

3.6

Define on-Product failure mode isolation task requirements
The identification of on-Product failure mode isolation task requirements basically follows thesame logic as described for equipment (refer to Para 2.6).
If the identified symptoms are unique for the on-Product FMG, there is no need to define
additional on-Product failure mode isolation task requirements. However, if the symptoms
identified by a BIT with a high rate of false alarms, it can be necessary to define an additional
on-Product FMG test task (also refer to Para 2.7).

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

For each on-Product FMG that is part of a symptoms ambiguity group, the analysis must include
the following steps:
1

Check if any form of test can isolate the respective on-Product failure mode2

Check if a functional test or visual inspection can isolate the respective on-Product failuremode

3

Check functional symptoms and/or physical symptoms likely to help to isolate therespective on-Product failure mode.

Note
Only test equipment used for testing on Product level are part of this analysis.
Note
The scope of LSA does not include elaborating the on-Product failure mode localization andisolation process itself (also known as troubleshooting). Although the on-Product corrective
maintenance analysis as defined in this chapter indicates how to isolate specific Productfailure modes, the complete troubleshooting process to prioritize and sequence failuremode isolation tasks for Product FMG with the same symptoms signature can require
additional factors (eg, probability of occurrence of each Product FMG, elapsed time torestore each Product FMG). Some of these factors are only available during the in-service
phase (eg, status and history for serialized equipment, availability of spares parts).
Note
Symptom ambiguity groups can occur across the different analysis steps described in
Para 3.4. This means that an on-Product FMG identified as part of the equipment
installation failure mode grouping (refer to Para 3.4.1) can have the same symptoms as an
on-Product FMG identified as part of general installation details failure mode grouping (refer
to Para 3.4.4).
Afterwards, it is necessary to record the on-Product failure mode isolation task requirement
against the respective FMG. If the on-Product failure modes associated with the same FMG instep 1 and 2 (refer to Para 3.4 and Para 3.5) have different Product failure mode isolation task
requirements), then it is necessary to split the on-Product FMG into a single FMG for eachidentified on-Product failure mode isolation task.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 26

S3000L-B6865-03000-00

ICN-B6865-S3000L0161-001-01
Fig 16 On-Product failure mode grouping, including failure mode isolation tasks
Fig 16 shows that the on-Product FMG 1A defined for Hardware element Y and the on-Product
FMG 2 defined for system/function Aggregated element Z have the same symptoms signature,and therefore require additional on-Product failure mode isolation tasks.
The documentation of on-Product failure mode isolation task requirements can include
references and additional descriptive information, for example:−−−

references to technical documents that must or can be used during the on-Product failuremode isolation task (eg, technical plan, wiring diagram, interface description)
possible crosschecks that can help to isolate the on-Product failure mode. Suchcrosschecks are useful for identifying the sources of common causes for on-Product failuremodes. It is also advisable to document the symptoms to be monitored or recorded during
these crosschecks.
measurements to be carried out to check the physical and/or functional characteristics of
the item under analysis, including:••test equipment required to perform these measurements
expected values for each measurement, and signification of unexpected measures

There can be a requirement to assign more than one on-Product failure mode isolation task to
one on-Product FMG. This translates into the need to narrow down the possible on-Productfailure modes that have led to the same symptoms for multiple on-Product FMG.

Applicable to: All

S3000L-A-07-00-0000-00A-040A-A
Chap 7

DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 27

S3000L-B6865-03000-00

3.7

Validation test
At Product level, it is not always possible to identify the faulty component (installed equipment,
equipment installation, general installation detail, etc.) unambiguously. Sometimes, thecomponent can be part of a group of components that have the same set of symptoms. This
group of components is called an ambiguity group. Depending on the circumstances, (eg,requirement to restore Product's availability as fast as possible), the corrective maintenancetasks are applied even if the component actually at fault has not been definitely identified.
Sometimes, the detection can have a degree of uncertainty (eg, a BIT on-Product level canhave a high false alarm rate). Sometimes, the isolation test tasks possible at Product level are
not good enough.
In these cases, there is a need to confirm the Product has been successfully repaired. Thisaction is often called validation test task, and it consists in verifying that all symptoms havedisappeared. There are different types of validation test task requirements, for example a BIT, ameasurement, a functional test or an inspection. Regarding validation tests, the on-Productcorrective maintenance task analysis consists in identifying all means available for each onProduct FMG to ensure that the symptoms have disappeared. During the repair process of the
Product, a validation test will be defined using an optimized combination of means
corresponding to all on-Product FMG. It is necessary to document the corresponding Productvalidation test requirement.

3.8

Inputs
The following inputs are required in order to perform the on-Product corrective maintenanceanalysis:
−
−
−
−
−

3.9

CIL
Product breakdown structures
drawings, 3D models etc.
system/functional FMEA
equipment corrective maintenance analysis results for each Product equipment and therelevant FMG symptoms

Outputs
The following output will be recorded during equipment corrective maintenance analysis:−

On-Product FMG and their:
•
•
•
•
•
•

4

associated equipment FMG
associated installation details and structure failure modes
symptoms
corrective maintenance task requirements
failure mode isolation task requirements
Product validation test task requirements

Relevant elements of the S3000L data model
The following Units of Functionality (UoF) support the documentation of the data associated tothis chapter. Refer to Chap 19:
−
−
−
−
−
−
−

S3000L UoF Environment Definition
S3000L UoF LSA Candidate
S3000L UoF Failure Mode
S3000L UoF LSA Failure Mode Group
S3000L UoF Failure Mode Symptom
S3000L UoF Failure Mode Isolation
S3000L UoF Task Requirement

S3000L-A-07-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-07-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 72021-04-30 Page 28

S3000L-B6865-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
Purpose ........................................................................................................................... 2
1.2
Scope ............................................................................................................................... 2
1.3
Terms, abbreviations and acronyms ............................................................................... 2
2
Special event analysis ..................................................................................................... 3
2.1
Special event analysis logic ............................................................................................. 3
2.2
Special event analysis process ....................................................................................... 3
2.2.1
Identification of special events ......................................................................................... 4
2.2.2
Identification of impacted LSA candidates ...................................................................... 5
2.2.3
Identification of special event impacts and PMTRE ........................................................ 6
2.2.4
Identification of acceptable damage and corrective maintenance task ........................... 6
2.2.5
Full set of information for special events ......................................................................... 6
2.3
Special event analysis process - inputs .......................................................................... 6
2.4
Special event analysis process - outputs ........................................................................ 7
3
Damage analysis ............................................................................................................. 8
3.1
Damage analysis logic ..................................................................................................... 8
3.2
Damage analysis process ............................................................................................... 9
3.2.1
Identification of relevant damage ..................................................................................... 9
3.2.2
Identification of allowable level of damage .................................................................... 12
3.2.3
Identification of corrective maintenance task requirements .......................................... 12
3.3
Damage analysis process - inputs................................................................................. 13
3.4
Damage analysis process - outputs .............................................................................. 13
4
Influence on design ....................................................................................................... 14
5
Relevant elements of the S3000L data model .............................................................. 14

List of tables
1
2
3
4
5
6
7
8

References ...................................................................................................................... 2
Terms, abbreviations and acronyms ............................................................................... 3
Examples of causes of special events ............................................................................ 4
Example of probability rating of occurrence of special events ........................................ 5
Explanation on the tabular report for a special event analysis ........................................ 8
Example of technology behavior rating ......................................................................... 10
Example of damage sensitivity rating ............................................................................ 11
Explanations on the example of damage analysis tabular report .................................. 13

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

List of figures
1
2
3
4
5

General flow chart of special event analysis logic ........................................................... 3
Example on a special event analysis tabular report ........................................................ 7
General flow chart for damage analysis logic .................................................................. 9
Example of a technology/damage evaluation rating...................................................... 11
Example of damage analysis tabular report .................................................................. 13

References
Table 1 References
Chap No./Document No.

Title

Chap 3

LSA process

Chap 4

Product structures and change management in LSA

Chap 12

Task requirements and maintenance task analysis

Chap 19

Data model

S4000PInternational specification for developing and continuously
improving preventive maintenance1

GeneralThe overall maintenance concept must include any maintenance activity that must be performed
after damage or special events occur during normal Product operation.

1.1

PurposeThis chapter aims at providing a method for the identification and justification of maintenancetasks needed after damage or a special event. The analysis process described in this chapter
derives as much as possible from the analytic process included in S4000P.
Considering that damage and special events can also occur on a new Product, in-service
feedback on similar Products can help identifying appropriate maintenance task requirements.

1.2

Scope
Special events and damage can occur throughout the service life of a Product. This analysis
process aims to anticipate the required maintenance task to rectify the special event or thedamage.

1.3

Terms, abbreviations and acronyms
Table 2 provides the definitions of the terms that are specific to damage and special event
analysis.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Table 2 Terms, abbreviations and acronyms
Term

Definition

DamageA loss or reduction of functionality, excluding inherent failure (intrinsic
reliabilities). It normally requires a maintenance task. It is possible to groupdifferent types of damage into families. For example, scratches, dents andcracks are typical structural damage. These damage families are
candidates for standard repair procedures.

External cause

A cause is external when an event independent of Product usage occurs.

Internal cause

A cause is internal when it is a result of Product use.

Special event

A special event occurs during a Product's life and cannot be considered as
normal operation. It can be due either to external causes (eg,meteorological phenomenon) or due to abnormal use (eg, over-G
maneuver of an aircraft).

2

Special event analysis

2.1

Special event analysis logic
Special event analysis identifies maintenance task requirements that are justified by theoccurrence of special events. Refer to Fig 1.

ICN-B6865-S3000L0068-003-01
Fig 1 General flow chart of special event analysis logic

2.2

Special event analysis process
The special event analysis process involves the following activities:−

the identification of relevant special events, refer to Para 2.2.1

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

−
−
−
−

2.2.1

the identification of systems, subsystems, equipment, structural items and zones that the
special event can affect, refer to Para 2.2.2
a description of the impact of a special event and identification of the Preventive
Maintenance Task Requirements Event (PMTRE), refer to Para 2.2.3
the identification of the potential corrective maintenance task requirements, including dataon acceptable level of damage, refer to Para 2.2.4
the creation of the full set of PMTRE and corrective maintenance task requirements andacceptable level of damage for each special event, refer to Para 2.2.5

Identification of special events
The basis for this analysis process is a simple Product usage analysis. It identifies the relevant
special events and their specific causes (refer to Table 3) in the context of the Product usage
phases. This process follows five steps:
Step 1: List the different causes that can produce a special event.
Special events can occur due to external or internal causes, and other elements can affectthem, including natural phenomena or humans. Table 3 provides examples of different types ofcauses. It is recommended to develop a specific table for each project to identify the relevant
special events for the Product in use and for the operational environment.
Table 3 Examples of causes of special events

External
causesTypes of causes

ExamplesNatural phenomena−

Meteorological (eg, lightning strike, hail)−

Animal (eg, bird strike)−

Stones, trees, etc.

−

Threat of combat−

Material maneuver

Caused by operating
environment−

Electromagnetic field−

Salt, sand or pollution laden atmosphere

Caused by transportand storage conditions(eg, sea, air, truck, rail)−

Shocks, movements and vibrations−

Humidity−

Depressurization

Caused by misuse−

Over operational limits like "hard landing","over-G maneuver"Caused by internal
dysfunction−

Excessive heat−

Excessive pressure−

Excessive vibration

Caused by humans

Internal
causesStep 2: Identify the Product usage phases.
Product usage phases are, for example, operation, maintenance, storage or transport. If
necessary, it is possible to divide usage phases further into sub-phases. For example, theusage phase for an aircraft can be subdivided into the sub-phases take off, cruise flight andlanding.
Step 3: Apply the type of causes to the different Product usage phases to identify all possible
special events.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

Examples of special events due to an external cause include, but are not limited to:
−
−
−
−
−

impacts on external skin due to cargo handling equipment during transportation preparation
multiple impacts due to hail during outside parking of a vehicle
water entrapment caused by heavy rain due to a leak during outside parking of a vehicle
impacts on inner external skin due to a debris on a runway during take off
lightning strike on an aircraft during cruise flight or parking

Examples of special events due to an internal cause include, but are not limited to:−−−−excessive stress on a tank structure due to dysfunction of the pressure relief valve during a
refueling operation on groundexcessive temperature in a bay in case of warm air leak during operation
over-G maneuver of an aircraft during a training flightan unexpected wear of mechanical parts during operation

Step 4: Analyze each possible special event in order to determine its probability of occurrence.
It is possible to apply a quantitative approach based on feedback from previous similar Productusage scenarios or by statistics (eg, the average or actual number of bird strikes happening
every year at a specific airport).
If it is not possible to obtain sufficient statistics, it is possible to apply a qualitative approach(refer to Table 4) or a simple description. For this approach, take into account the hypothesis
defined by establishing product usage data within Chap 3.
Table 4 Example of probability rating 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 is unlikely.
Rare numbers of special events are likely to happen.

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 is moderate.
A certain number of special events are likely to happen (tobe determined project specific)

5Frequent

A special event whose probability of occurrence is very high.
This special event is almost certain to occur.

Step 5: Depending on the occurrence rating from Step 4, it is necessary to determine whether
the special event is relevant for further analysis. If so, refer to Para 2.2.2. If not, document thedecision. It is possible to use the rating level to determine a threshold for tailoring analysis
activities.
2.2.2

Identification of impacted LSA candidates
The following questions determine the impact on the Product for each relevant special event:−−−−

Which systems/subsystems does the special event under analysis affect?
Which structural components of the Product does the special event under analysis affect?
Which equipment does the special event under analysis affect?
Which Product zones does the special event under analysis affect?

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

The results associated to each special event provide input for more detailed analysis todetermine the impact of the special event and the PMTRE. Refer to Para 2.2.3.
2.2.3

Identification of special event impacts and PMTRE
All relevant special events are analyzed in detail to identify their impact and to determine anapplicable and effective PMTRE (refer to S4000P).
For each relevant special event, the LSA data must document the following aspects:−−−−

For each affected system or subsystem: Description of expected impacts on complete
systems/subsystems, and identification of applicable and effective PMTRE.
For each affected Product structure: Description of expected impacts on Product structure(including structural items, Structure Significant Items (SSI) and Significant Details (SD)),and identification of applicable and effective PMTRE.
For each affected piece of equipment: Description of expected impacts on equipment(considering their specific installation locations), and identification of applicable andeffective PMTRE.
For each affected zone: Description of expected impacts on complete zones, andidentification of applicable and effective PMTRE.

Note
If the special event analysis method following S4000P is not applicable to a project, it isnecessary to identify another method.
2.2.4

Identification of acceptable damage and corrective maintenance task
For all relevant special events, determine a possible corrective maintenance task requirements
and a corresponding acceptable level of damage. This holds for all impacted LSA candidates,
regardless of whether they are systems/subsystems, a Product structure or a piece ofequipment. The corrective maintenance task requirements identified for the corresponding LSA
candidates can justify a standard repair or a specific damage repair task.
Note
The following aspects influence the identification of an acceptable level of damage:
•
•

2.2.5

the damage does not exceed an acceptable limit  no need to repair the item
immediately
the damage exceeds an acceptable limit and needs a corresponding repair (standardor specific)

Full set of information for special events
Finally, it is necessary to document the full set of data/information for each special event. This
includes:−−−−impacted LSA candidates and corresponding impacts
identified PMTRE
identified corrective maintenance task requirements
information on acceptable damage limits

For each special event, the full set of information is the input for the MTA, as described in
Chap 12.

2.3

Special event analysis process - inputs
The special event analysis requires a set of inputs, which includes at least:−

Suitable Product breakdown is available: A Product breakdown provides a structured
representation of the Product. Refer to Chap 4.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00−

Description of Product use: An Operational Requirements Document (ORD) and/or a
Customer Requirements Document (CRD) describe in detail the Product use. These
documents provide information about project-specific operational and maintenanceenvironment. Refer to Chap 3.
Note
If an ORD and/or CRD is not available for a project, it is necessary to document thedescription of Product use in an alternative way.

−
−

2.4

Statistical data on special events: Data can be based, for example, on feedback fromcurrent or previous similar projects that quantify the occurrences of special events.
Inputs from Preventive Maintenance Analysis (PMA): Applicable and effective PMTRE (refer
to S4000P) and special event impact in the context of potential damage caused by a special
event.

Special event analysis process - outputs
A tabular report is one of the possible outputs of the special event analysis. Such reportprovides all data/information developed during the special event analysis, in a structured andreadable format. In order to keep the traceability of the identified maintenance task
requirements and their baselining analyses, it is recommended to record these results as part of
the LSA data.
Fig 2 provides a simple example of a tabular report approach, which documents the results of a
special event analysis process. Table 5 contains an explanation of the content of each column.

ICN-B6865-S3000L0069-003-01
Fig 2 Example on a special event analysis tabular report
It is recommended to adapt the tabular report as shown in Fig 2 to meet project specificrequirements.
Note
Although not shown in Fig 2, it is recommended to include additional information in thereport, for example release date, issue number, author’s name, approval signatures andinformation required for the identification of the maintenance task.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Table 5 Explanation on the tabular report for a special event analysis
ColumnDescription

1

Special event description
The special event is described by a complete name. The special event can affectmore than one element of the breakdown structure. In this case, identify eachelement on a different line.

2

Probability of special event occurrence
The rating and description of the occurrence.

3

Product item (LSA candidates) impacted
Element name. The breakdown element identifier can follow the element name. It
is possible to group some elements (typically structural elements) into families inorder to minimize the number of entries in the table.

4

Special event impacts or damage description
A short description of impacts and potential damage. If there are multiple
impacts/damage that can affect the same element, identify each impact/damage
on a different line.

5

Preventive Maintenance Task Requirement Event (PMTRE)
PMTRE includes all task requirements to consider after a special event has
occurred, in order to check if any element needs to be repaired/restored before reentry into service.

6

Corrective maintenance task requirement
A short summary or title including the type of maintenance task requirement andthe element involved. If more than one maintenance task is needed to cover thesame special event, identify each task on a different line. Conversely, the same
maintenance task can address more than one special event. This is typically thecase of a standard repair procedure.

7

Acceptable level of damage description
A qualitative or quantitative description of damage that can remain without repair,and damage that can be repaired.

3

Damage analysis

3.1

Damage analysis logic
The damage analysis process identifies relevant damage and the corresponding corrective
maintenance task requirements to repair a detected damage. Refer to Fig 3.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

ICN-B6865-S3000L0146-001-01
Fig 3 General flow chart for damage analysis logic

3.2

Damage analysis process
The damage analysis process involves the following activities:
−
−
−

3.2.1

Identification of relevant damage
The ways to identify the relevant damage to be considered include, but are not limited to:−−

3.2.1.1

damage identification, refer to Para 3.2.1
damage analysis to identify the allowable level of damage, refer to Para 3.2.2
damage analysis to identify the corrective maintenance task requirements, refer toPara 3.2.3

PMA activities in the context of Preventive Maintenance Task Requirements (PMTR)
definition, refer to S4000P
The technology approach, refer to Para 3.2.1.3

Identification of relevant damage by preventive maintenance analysis
PMA activities include analysis processes that identify the Preventive Maintenance Task
Requirements Interval (PMTRI). Refer to S4000P:−−−

system analysis
structure analysis
zonal analysis

Each analysis process listed above can identify relevant damage on Product items as potential
failure causes. This damage requires preventive maintenance in order to avoid functional
failures that can lead to critical situations regarding operational safety, mission accomplishment,
environmental integrity, or economic factors. This potential damage also requires corrective
maintenance and information regarding the acceptable level of damage.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Within PMA activities, there is an additional analysis process to identify PMTRE, refer toS4000P.
3.2.1.2

Special event analysis
The special event analysis process can identify relevant damage on Product items as apotential consequence caused by a special event. This damage requires preventive
maintenance to avoid the risk of using the Product in an unsafe or unclear condition after a
special event has occurred. This potential damage also requires corrective maintenance andinformation regarding the acceptable level of damage.
Note
Para 3.2.1.3 describes a further analysis method, which uses a technology approach. It isalso possible to use this method to evaluate the relevant damage modes identified by PMA
and requiring further analysis. This is helpful to limit analysis effort according to the projectrequirements.

3.2.1.3

Identification or assessment of relevant damage by technology approach
The process described in this paragraph can serve two different purposes:−−

the identification of the damage to consider for the identification of the corrective
maintenance task requirements (eg, if results of the PMA are not available for damage
identification)
the evaluation of previously identified damage by the PMA to determine which damage isrelevant for further analysis, with a view to identifying the corrective maintenance task
requirements and the acceptable level of damage

The analysis process also evaluates the behavior of the technologies used in the Productdesign. Different technologies can show significantly different behaviors with respect to theimpact of damage. The analysis approach identifies the technologies and analyzes themthoroughly from two points of view:−−

Is the technology well known or new?
Is the technology tolerant or sensitive concerning damage?

Identify the potential damage to be considered using the following five step methodology:
Step 1: For all Product items (systems, subsystems, structural parts, equipment, components),
identify the technologies used and indicate the level of knowledge regarding their behavior.
Table 6 provides a qualitative approach to characterize this knowledge. The level of accuracy of
the rating can require some adjustments based on the project requirements.
Table 6 Example of technology behavior rating
RatingTechnology behavior
knowledge

Description

1

Well known

This technology has been used on many similar projects

2

Known

This technology has been used on similar projects, but it
has been slightly modified for the intended project3

New

This technology has been already used on similar recent
projects, but little feedback is available, or the technology
is completely new

Step 2: Evaluate the sensitivity of the technology.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

For each technology identified in Step 1, identify the possible damage types that can occur. For
example:
−
−
−
−
−
−

general surface damage (eg, scratches, dents or cracks)
breakage of structural components or controls
tear off of connectors of electrical or data wiring
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 7 provides a qualitative approach to characterize this sensitivity. The level of accuracy of
the rating can require some adjustments based on the project requirements.
Table 7 Example of damage sensitivity rating
RatingSensitivity degree

Description

1

Extremely low

This technology has an extremely low chance ofdamage during Product life2

Low

This technology has a low chance of damage during
Product life

3

MediumThis technology has a medium chance of damage
during Product life

4

High

This technology is likely to be damaged during Productlife

5

Extremely highThis technology is very likely to be damaged during
Product life

Step 3: Select the association technology behavior/damage sensitivity relevant for further
analysis.
It is possible to identify a selection threshold by combining the technology behavior knowledge
rating and the technology sensitivity rating (refer to Fig 4). The selection threshold is adjustabledepending on the needs of the individual project.
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-002-01
Fig 4 Example of a technology/damage evaluation rating
Step 4: For all items of the Product breakdown identified in the previous steps, analyze theirinstallation design and installation area in order to evaluate their exposure to the different
threats.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

For example, the level of exposure to corrosion depends on the location of the structural part.
Items in a landing gear bay are highly subject to corrosion, whereas to a significantly lesser
extent in watertight bays as they are opened rarely.
Step 5: Criticality analysis
In order to focus on the most significant damages, it is recommended that a criticality analysis
be considered. For each potentially damageable item, it is recommended to evaluate thecriticality in terms of impact on the Product operation using the following questions:−−−

Does the damage result in lowering safety level?
Does the damage result in lowering availability?
Does the damage result in faster deterioration?

Note
The list of questions can change to adapt to specific project needs.
Step 6: Using the results of the previous steps, decide which potentially damageable item isrelevant for further analysis.
3.2.2

Identification of allowable level of damage
The previous analysis steps identified and selected the Product breakdown items that can beaffected by damage during service life. These candidates can be either single items or familiesof items, for example structural items, wiring or tubing in a circuit.
It is possible to analyze each selected item to determine the acceptable level of damage:−−−

Which damage level does not require any corrective maintenance or can be left as it is,either with or without a cosmetic treatment?
Which damage level can/must be repaired immediately by specific or standard repair
procedures?
Which damage level leads to a final discard of the item?

Typically, design department experts perform this evaluation, which can be either qualitative or
quantitative. It can be based on measurements, calculations, tests or best engineering
judgment.
3.2.3

Identification of corrective maintenance task requirements
At this point, it is necessary to analyze each significant item in order to determine thecorresponding corrective maintenance task requirements.
This analysis identifies the corrective maintenance tasks required to:−−

detect and measure exactly each damage that can occur (eg, by visual inspection,
borescope inspection, non-destructive material testing like X-ray or eddy current inspection)
restore the function of the item under analysis (eg, by standard repair task, refurbish task oritem replacement, if necessary)

Note
In addition to specific damage detection procedures, damage can also be detected during
normal Product operation, for example during routine inspections or corrective maintenancetasks. It is also possible to implement a Health and Usage Monitoring System (HUMS). For
this purpose, it is necessary to install sensors or to carry out exact measurements that canwarn the operator on potential damage more effectively.
Note
It is possible to group some items into families, and the associated damage is a candidate
for standard repair procedures (eg, standard repair procedures for structural parts, standard
repair procedures for wiring).

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

3.3

Damage analysis process - inputs
Damage analysis requires the following inputs:
−
−

3.4

Product definition: Suitable Product breakdown available, including information about
technologies used within the different Product elements (eg, systems, subsystems,
structural items, equipment and/or components).
inputs from PMA: Potential damages which can be identified as failure causes for functional
failures or potential damage as a consequence of special events

Damage analysis process - outputs
A tabular report is one of the possible outputs of the damage analysis. Such report provides all
the data/information developed during the damage analysis process, in a structured andreadable format. In order to keep the traceability of the identified maintenance task
requirements and their baselining analyses, it is recommended that these results be recorded,as part of the LSA data.
Fig 5 provides an example of a damage analysis tabular report. Table 8 provides a descriptionof each column.

ICN-B6865-S3000L0147-001-01
Fig 5 Example of damage analysis tabular report
The tabular report above needs some adjustment to meet the project specific requirements.
Note
Although not shown in Fig 5, it is recommended that additional information be included in
the report, for example release date, issue number, author’s name, approval signatures andinformation required for the identification of the maintenance task.
Table 8 Explanations of the example of damage analysis tabular report
ColumnDescription

1

Product item (system, subsystem, structural item, equipment, component)
Element name. This element name can be followed by its breakdown element
identifier. It is possible to group some elements (typically structural elements) intofamilies in order to minimize the number of entries in the table.

Applicable to: All

S3000L-A-08-00-0000-00A-040A-A
Chap 8DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

4ColumnDescription

2

Damage description
A short description of damage. If different types of damage can affect the sameelement, identify each type on a different line.

3

Damage assessment description
A list of qualitative or quantitative elements that supports the decision to select ordiscard a case.

4

Allowable level of damage
There can be more than one value. The value of damage that can be left as it is,and value of damage that can undergo maintenance.

5

Corrective maintenance task requirements
A short summary or title including the type of maintenance task and the element towhich the maintenance task is applied. If more than one maintenance task isneeded for the same item, identify each task on a different line. Conversely, thesame maintenance task can address more than one item. This is typically the caseof a standard repair procedure.

Influence on design
Damage and the impact of special events can have significant influence on Product operation
and availability. Normally, it is not possible to prevent damage and special events fromoccurring at all. However, the reduction/limitation of the impact of damage and special events
must be a common goal of design and development and supportability engineering. For thispurpose, there is a need to consider the potential impact of damage and special events alreadyduring the early phases of Product design. Examples to improve the tolerance against damage
and special events include, but are not limited to:
−
−
−
−
−
−

5

if the damage tolerance is low and the Product is operated under rough conditions, consider
the use of highly sophisticated technology. Consider using different technology if the risk ofdamage is too high for sensitive technology used under rough conditions.
enhance protection for outside structural items which have a high probability of being
affected by damage
design protections for sensitive equipment (eg, covers, appropriate mounting, padding)
improve storage and transport conditions of the Product or Product components by acorresponding robust design or by appropriate means of transport
improve accessibility to ease visual or other inspections in case you suspect damage has
occurredprefer the use of standardized components with well-known technology which can easily berepaired by simple standard repair procedures

Relevant elements of the S3000L data model
The following Units of Functionality (UoF) support the documentation of the data associated tothis chapter. Refer to Chap 19:
−
−
−
−
−
−
−
−

S3000L UoF Damage Definition
S3000L UoF Environment Definition
S3000L UoF Product Usage Context
S3000L UoF Product Usage Phase
S3000L UoF Special Event
S3000L UoF Task Requirement
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-08-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-08-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 82021-04-30 Page 14

S3000L-B6865-03000-00

Chapter 9
Operational support analysis
Table of contents

Page

Operational support analysis ......................................................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
1.4
Terms, abbreviations and acronyms ............................................................................... 32
Operational support tasks ................................................................................................ 3
2.1
Activities in supporting Product use................................................................................. 4
2.1.1
Preparation for usage ...................................................................................................... 4
2.1.2
Servicing .......................................................................................................................... 4
2.1.3
Adjusting .......................................................................................................................... 4
2.1.4
Weighing .......................................................................................................................... 5
2.1.5
Loading and unloading .................................................................................................... 5
2.2
Packaging, handling, storage and transportation aspects .............................................. 5
2.2.1
Packaging and unpacking ............................................................................................... 5
2.2.2
Handling ........................................................................................................................... 6
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
Role change..................................................................................................................... 7
2.4
Deployment...................................................................................................................... 7
2.5
Software and data aspects .............................................................................................. 7
2.6
Product recovery.............................................................................................................. 7
2.7
Special preventive maintenance...................................................................................... 8
2.8
Disposal and recycling ..................................................................................................... 8
2.9
Extraordinary operational support tasks .......................................................................... 8
3
Documenting operational support tasks .......................................................................... 8
3.1
Data collection aspects .................................................................................................... 8
3.2
Operational and customer requirements as a source ..................................................... 8
4
Checklist for operational support analysis ....................................................................... 95
Associated parts of the S3000L data model .................................................................. 10

List of tables
1
2
3

References ...................................................................................................................... 2
Terms, abbreviations and acronyms ............................................................................... 3
Checklist for support related operations analysis ............................................................ 9

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

List of figures1
2
3

Operational support tasks within technical publications .................................................. 3
Typical servicing tasks ..................................................................................................... 4
Typical PHST tasks ......................................................................................................... 5

References
Table 1 References
Chap No./Document No.

Title

Chap 3

LSA process

Chap 10Development of a preventive maintenance program

Chap 12

Task requirements and maintenance task analysis

Chap 13

Software support analysis

Chap 16

Disposal

Chap 19

Data model

Chap 21

Terms, abbreviations and acronyms

S1000DInternational specification for technical publications using
a common source database

1

General1.1

Introduction
With respect to Product operation and handling, there are additional aspects to be consideredbeside Product maintenance and repair activities. Operational support tasks include activities
performed in areas other than the area where the Product is used (documented in operating
instructions) or maintained (documented in a maintenance manual). However, these tasks canbe vital for the proper usage of any Product. Operational support tasks influence many aspects,
including ease of operation, usability, flexibility of usage, or mobility. There is a thin line between
Product use and operational support tasks. This line changes on a project basis and it isnecessary to document these aspects. Sometimes it is difficult to determine whether a task
relates to use or operational support.

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

ICN-B6865-S3000L0039-002-01
Fig 1 Operational support tasks within technical publications
All tasks identified by the operational support analysis will fill a possible gap between user
manual and maintenance manual. Refer to Fig 1. In any project, it is recommended to clarify at
an early stage who will be responsible for the supportability analysis and documentation for
operational support tasks.

1.2

PurposeThis chapter is a guideline for identifying relevant operational support activities. Its target
readers are support personnel responsible for analyzing the relevant operational support tasks.
Para 4 includes a detailed list of potential activities to support analysts.

1.3

Scope
This chapter provides details and examples on the most common operational support tasks.
There can be more activities, especially in relation to environmental conditions (eg, preparation
for transportation under extreme climatic conditions such as an arctic environment). Each
example includes a short description and underlines specific aspects to be considered.

1.4

Terms, abbreviations and acronyms
Definitions that are specific to operational support analysis are given in Table 2. Chap 21
provides the complete set of LSA terms, abbreviations, and acronyms.
Table 2 Terms, abbreviations and acronyms

2

Term

Definition

Operational
support task

In Product operation, any support activity that fulfils task requirements,
such as servicing or Packaging, Handling, Storage and Transportation(PHST) requirements

Operational support tasks
An important aspect of supportability analysis activities is the identification of operational
support tasks, including the requirements for personnel, support equipment, consumables,
spare parts, facilities and required training. Some tasks must be considered early in the designand development process. Some tasks can be considered later, for example when a prototype
for the Item Under Analysis (IUA) is available.

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

2.1

Activities in supporting Product use

2.1.1

Preparation for usage
The tasks required to prepare a Product for usage/operation can include, for example, theexchange of equipment to provide a special capability (also referred to as role change). Productmodification can occur by changing some pieces of equipment. Additionally, peripheral
Products/components must be prepared for proper usage.
Typical preparation tasks include servicing tasks, like cleaning a windshield before driving.
Other typical preparation tasks are the complete conversion of a Product for another use as thechange of the tooling within a machine to produce a new product line. Typical examples of tasks
concerning preparation for use and included in operational support analysis are:
−
−
−
−

2.1.2

preparation of machines for a new production segment (eg, change in tooling and dies)change of vehicle category (eg, a passenger vehicle turned into an ambulance)
preparation of an aircraft for a reconnaissance mission by means of special equipment
preparation of a ship including the required equipment for sailing

Servicing
The term servicing can describe a wide range of tasks performed on a Product, also in
connection with Product preparation for use. Refer to Fig 2. Other servicing activities include
handling Products after usage or maintaining them. This can include, for example, a simple
visual inspection for foreign objects during washing or cleaning procedures, as well as simple
visual inspections to detect any damage or assess the equipment general conditions (eg,condition of tires).

ICN-B6865-S3000L0040-002-01
Fig 2 Typical servicing tasks
Maintenance Task Analysis (MTA) must include servicing tasks, if existing. Refer to Chap 12.
Servicing tasks can have an important impact on resources such as personnel, support
equipment (eg, for lubrication), consumables and facilities (eg, washing facilities with oil/water
separator and water recycling equipment). Typical examples for servicing tasks are:
−
−
−
−
−
−
−
−
2.1.3

washing an engine
gear lubrication
changing engine oil
product polishing and subsequent preservation
brake bleedingchanging hydraulic liquid
replenishing fluids
desalination and equipment rinsing after diving

AdjustingThis type of task can also be performed in connection with Product preparation for usage. There
are no changes in Product functionality, but precision and quality are evaluated as preconditions
for Product usage. Typical examples of adjustment tasks are:−leveling of the entire Product as a basic task

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00−−

calibration of measuring instruments
adjustment of gun sight

2.1.4

Weighing
The analysis of weighing tasks involves the preparation of the IUA for weighing and the relevant
weighing procedure. This includes information on the weighing equipment. The contractor andthe customer must define and agree on the purpose of the weighing procedure (eg, to prepare a
mission or prove compliance to Product specification requirements).

2.1.5

Loading and unloading
It is necessary to analyze loading and unloading procedures for each Product that can be used
for cargo transportation. This information must be collected at an early stage of the life cycle
development. It is necessary to provide examples of loading and offloading techniques, interiorlayout, floor loadings, location and strength of lashing points, stowing and securing methods,
capacities and dimensions of compartment and doors. Analysis questions include, but are notlimited to:
−
−
−
−
−
−
−

What kind of cargo will be transported?
Which size and weight parameters must be considered?
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 (eg, lashing and lashing points, stowing) is required?
Will a cargo container concept be employed?
Does the type of load require special loading devices (eg, rolling devices)?

It is also necessary to address the requirements for special support equipment for loading andunloading.
−
−

2.2

Do loading/unloading operations require special support equipment or vehicles?
Is special support equipment required to secure the cargo?

Packaging, handling, storage and transportation aspects
Fig 3 shows an overview of PHST activities/aspects which must be considered for both, theProduct and Product components like equipment or assemblies.

ICN-B6865-S3000L0041-002-01
Fig 3 Typical PHST tasks
2.2.1

Packaging and unpacking
A packaging concept for IUAs and/or components includes, but is not limited to:−−−−

Is packaging required for short-term storage and/or long-term storage?
Is packaging required for transportation and what is the type of transportation?
Is a special container required for storage or transport?
Is special preservation required because of extreme climatic conditions during storage ortransportation (eg, sea transport)?

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

−
−

2.2.2

Handling
Handling tasks for the IUA can include but are not limited to:
−
−
−
−

2.2.3

Is it required to unpack and repack the IUA during transportation or storage, for example, toperform maintenance activities (eg, storage tasks)?
What is required for the unpacking and removal of preservation concerning support
equipment and facilities?

safety precautions and limitations due to handling
instructions to park, tow, winch or move the IUA for uncommon usage
instructions to jack the IUA, including jacking points, required adapters, supports for special
components, balance weights, jacking procedures
additional equipment and materials required when handling the IUA (eg, tow bars or cables)

Storage
It is necessary to analyze and document storage procedures to guarantee product functionality
during and after storage. The analysis will consider the following aspects:
−
−
−
−
−
−
−
−
−

Is the required storage long term or short term?
Is the Product/component to be stored sensitive?
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 are required to safeguard structuraland Product integrity during storage (eg, wheel rotation, power source, engine running orpressure checks)? Provide a timescale for maintenance during storage.
Are extreme climatic conditions expected during storage (heat, frost, humidity)?
Are there any special techniques required before storing the Product (eg, cleaning andpreservation, fluid system draining/replenishing, static grounding, protective blanking,removal of special components)?
Are there any special techniques required to retrieve the Product from storage and bring it
into operation (eg, cleaning and removing preservation devices, fluid system replenishing,re-installation of special components, functional checks, preparation for usage)?
What kind of securing is required during storage (eg, mooring, blocking of movable
components, and protection from light)?
Is it necessary to consider the storage time in connection with the life of the stored
Product/component?

2.2.4

Stacking
Stacking is a special aspect of storage and transportation of any Product/component. It isessential to address stacking safety requirements for storage or transportation. For example,
the impact of external events such as pushing must be analyzed for storage.

2.2.5

Lifting
Lifting operations must include all necessary procedures to lift the IUA with relevant hoist
devices, cranes, jacks or slings in case of:−−−lifting for transportation or loading purposes
lifting for repair or maintenance purposes
lifting for recovery

In addition to the complete Product, it is necessary to consider the lifting of components as well(eg, lifting an aircraft engine).
2.2.6

Transportation
Based on customer requirements, the analysis of Product transportability must include:

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−

How much work is necessary and how long does it take to prepare the Product fortransportation and recovery after transportation?
What are the requirements for preparation for transportation and for recovery after
transportation concerning personnel, tools, consumables, and facilities?
What are the additional environmental requirements for transportation under special
conditions (eg, extreme climatic conditions, including desert environments, humidity, heat,
frost and transportation by sea)?
What are the additional safety requirements for transport under special conditions (eg,loading securing within a transport aircraft)?
What are the required servicing activities during transportation (especially during long
journeys)?
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?
Can sledges and/or pallets be used?

2.2.7

Mooring
Analysis of mooring tasks for the IUA must consider all weather conditions and any means oftransportation. Mooring can be either long-term or short-term. The purpose of this activity is totie down or secure by other means the IUA to the ground or within a vehicle to avoid any
damage. The analysis must also include information on special techniques applicable toballasting, definition of lashing points and installation/use of special support equipment
applicable to mooring.

2.2.8

Shoring
Shoring analysis must include shoring points, procedures and equipment used during
maintenance, repair and recovery.

2.3

Role change
A Product can be used in different contexts (eg, a transport/cargo helicopter). In this case, theoperational support tasks focus on the tasks aimed at changing the configuration of the Productto facilitate its use in a specific context (eg, removal of seats, removal of intercommunications
apparel and installation of specific equipment and corresponding fixing parts).

2.4

Deployment
Product deployment may need to take into consideration several tasks depending on thecomplexity of the Product itself. It can also include a system of systems that contains several
Products. Deployment can relate to different activities, for example installation, transportation tothe operational area, as well as preparation, operation setup and test of functionalities before
operation. Therefore, the task analysis will vary for each Product based on aspects such as:
−
−
−

2.5

operational scenario (eg, facility preparation, installation or preparation to operation,
personnel competence for Product deployment)
transportation capability (eg, fixing procedures tasks, safety procedures)
preparation to operation (eg, remote or local setup tasks, calibrating procedures, tuning
procedures)

Software and data aspects
Chap 13 addresses operations related to software support.

2.6

Product recovery
Recovery analysis must include any information on planned recovery procedures and the
support equipment required to recover any IUA from any condition that can affect it.
Product recovery during the testing phase must be addressed separately. It is important toguarantee a fast reaction to any unexpected event that involves recovering the Product from an

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

undesired condition. A recovery plan for all emergencies must be detailed to avoid endangering
personnel or the environment.
Recovery also includes rescue procedures or the 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 use of the Product or a Product prototype. For example, an aircraft
performing its first flight marks a specific risk of a crash. All required activities after a potential
crash must be analyzed and documented carefully before the first use of the Product. The
analysis process must include recovery training to reduce the risk of extended damage topersonnel or the environment in case of a catastrophic event. All aspects must be covered,including accidents on land, in water (eg, foundering and the need to salvage the ship) or withinareas that are difficult to access.

2.7

Special preventive maintenance
Chap 10 describes the handling of preventive maintenance in general terms. However,servicing or preparation for use tasks can be preventive in nature, yet Preventive MaintenanceAnalysis (PMA) does not identify them. Being performed frequently (eg, daily), these tasks canhave a high impact, for example on personnel requirements. Typical examples of tasks are:
−
−
−
−

2.8

Visual check before use (eg, engine start)
Visual check after special missions
Preventive replenishment of fuel, fluids or other consumables to guarantee proper function
Cleaning before or after each use

Disposal and recycling
Analysis concerning requirements after the Product life cycle is becoming increasingly
important. This includes both the disposal of the Product, and the handling of components andconsumables to be disposed during the Product life cycle. Refer to Chap 16.

2.9

Extraordinary operational support tasks
The analysis process must address extraordinary operational support tasks. Typical examples
are:
−
−
−
−
−
−

Decontaminating a vehicle
Disinfecting personnel before starting a job
De-icing an aircraft or ship
Checking electrical charge
Checking the strength of magnetic fields during storage
Completing paperwork for statistical purposes

3

Documenting operational support tasks

3.1

Data collection aspects
LSA data must document the identification of any operational support task requirement. To thisend, it is possible to use appropriate existing information codes from S1000D. It is
recommended that operational support tasks be documented at Product level or at theappropriate breakdown level. As a matter of fact, use of a mixed physical/functional breakdown
provides the most flexibility. This supports the exchange of data with S1000D for technicalpublications.

3.2

Operational and customer requirements as a source
In general, the requirements for operational support tasks can be derived from the operationaland customer requirements, which are collected and documented upon the gathering of Productuse data. Refer to Chap 3. As a first input for operational support analysis, it is recommended touse the content of the relevant Operational Requirements Document (ORD) and Customer

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

Requirements Document (CRD). Each aspect covered in the ORD or CRD concerning use of
the IUA can require an operational support task.

4

Checklist for operational support analysis
Table 3 provides an alphabetical checklist for potentially relevant activities.
Table 3 Checklist for support related operations analysis
Activity

Analysis
Probable highrecommended at impact onwhich phaserequirements forfacilities

Probable highimpact on
requirements for
special support
equipment

Probablehighimpact 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

PossibleNo

Containerconcept

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

Applicable to: All

S3000L-A-09-00-0000-00A-040A-A
Chap 9DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

5

Activity

Analysis
Probable highrecommended at impact onwhich phaserequirements forfacilities

Probable highimpact on
requirements for
special support
equipment

Probablehighimpact on
designPreservation

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

PossibleNo

TowingWhen 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

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:
−
−
−
−
−
−

S3000L UoF Environment Definition
S3000L UoF LSA Candidate
S3000L UoF Product Usage Context
S3000L UoF Task Requirement
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-09-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-09-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 92021-04-30 Page 10

S3000L-B6865-03000-00

Chapter 10
Development of a preventive maintenance program
Table of contents

Page

Development of a preventive maintenance program ..................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Development of PMTRI ................................................................................................... 3
2.1
General analysis processes ............................................................................................ 3
2.1.1
System analysis ............................................................................................................... 3
2.1.2
Structure analysis ............................................................................................................ 4
2.1.3
Zonal analysis .................................................................................................................. 4
2.1.4
Additional sources for PMTRI .......................................................................................... 4
2.2
Time limits, thresholds and triggers for a scheduled task ............................................... 4
2.2.1
General ............................................................................................................................ 4
2.2.2
Discrete time limit ............................................................................................................ 5
2.2.3
Periodic time limit - repeat time limit ................................................................................ 5
2.2.4
Periodic time limit - initial and repeat time limit in combination ....................................... 5
2.2.5
Trigger events .................................................................................................................. 6
2.2.6
More than one periodic time limit..................................................................................... 6
3
PMTRI within the LSA ..................................................................................................... 7
3.1
PMTRI from system analysis ........................................................................................... 7
3.2
PMTRI from structure analysis ........................................................................................ 7
3.3
PMTRI from zonal analysis .............................................................................................. 7
3.4
LSA activities for a PMTRI ............................................................................................... 8
3.4.1
Criticality of the PMTRI .................................................................................................... 8
3.4.2
Scheduled maintenance task and MTA ........................................................................... 8
4
Packaging for PMTRI ...................................................................................................... 8
4.1
Packaging process overview ........................................................................................... 8
4.2
Preparation of packaging process ................................................................................. 10
4.2.1
General aspects............................................................................................................. 10
4.2.2
Master task package ..................................................................................................... 11
4.2.3
Interval correlation between PMTRI and master interval .............................................. 11
4.2.4
Preparation completion .................................................................................................. 11
4.3
Packaging process for PMTRI ....................................................................................... 12
4.3.1
Impact of maintenance level on master task packages................................................. 12
4.3.2
Predefined master task packages ................................................................................. 13
4.3.3
Basic rules for interval adaptation based on PMTRI criticality ...................................... 13
4.3.4
Summary of PMTRI interval adaptation......................................................................... 15
4.3.5
Adaptation example ....................................................................................................... 16
4.4
Maintenance task analysis for master task packages ................................................... 16
5
Associated parts of the S3000L data model .................................................................. 18

List of tables
1
2

References ...................................................................................................................... 2
General interval adaptation rules................................................................................... 14

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

List of figures
1
2
3
4
5
6
7
8
9
10
11

Discrete time limit ............................................................................................................ 5
Repeat time limit .............................................................................................................. 5
A combination of tasks with initial and repeat time limits ................................................ 5
Example of a trigger event ............................................................................................... 6More than one periodic time limit for a preventive maintenance task ............................. 7
Process overview from PMTRI to master task packages ................................................ 9
From single PMTRI to completed PMP (and traceability back) ..................................... 10
Initial distribution of PMTRI (on different maintenance levels) ...................................... 12
Clustering of PMTRI to support the identification of master intervals ........................... 13
Principles for interval modification ................................................................................. 14
Integration of single PMTRI into master task packages ................................................ 17

References
Table 1 References
Chap No./Document No.

Title

Chap 8Special event and damage analysis

Chap 11

Level of repair analysis

Chap 12Maintenance task analysis

Chap 14

Life cycle cost considerations

Chap 19

Data model

S1000DInternational specification for technical publications using
a common source database

S4000PInternational specification for developing andcontinuously improving preventive maintenance

DEF-STAN 00-45 Part 3

Using Reliability Centered Maintenance to Manage
Engineering Failures, Part 3, Guidance on the Applicationof Reliability Centered Maintenance

MIL-STD 1843

Reliability-centered maintenance for aircraft, engines andequipment

MIL-STD 2173

Reliability-centered maintenance for naval aircraft,
weapon systems and support equipment

1

General1.1

Introduction
Product preventive maintenance comprises preventive maintenance at regular intervals andmaintenance due to unexpected special events. Preventive maintenance tasks initiated by aninterval (often referred to as scheduled maintenance) aim to achieve continued Product safety,
compliance with the law, protection of the environment, operational/mission availability, andcost-effective feasibility during a Product’s in-service phase.
A PMTRI result from the application of analysis methodologies as described in otherspecifications, for example in S4000P. PMTRI are allocated to relevant and effective scheduled

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

task packages in order to implement an effective Preventive Maintenance Program (PMP) and
optimize the total preventive maintenance effort for a Product. If required, packaging rules andsolutions must comply with requirements from regulatory authorities.
S4000P specification provides an analysis methodology for special events, which generates
PMTRE. All relevant special events are identified during the LSA process. Refer to Chap 8.
After each special event, it is necessary to apply an analysis logic to identify an applicable andeffective set of PMTRE. This will ensure safety, compliance with the law, environmental
integrity, operational/mission availability and best economic feasibility for further Product use
after a special event. PMTRE are not included in the packaging process for PMTRI.

1.2

PurposeThe purpose of this chapter is to define the process, and describe basic rules for the packaging
of PMTRI to implement an effective PMP for the Product.
Note
Different projects, customers and companies use different terminology for PMP. Alternative
terms are Preventive Maintenance Plan (PMP), Operator Maintenance Program orOperator Maintenance Plan (OMP), Scheduled Maintenance Program (SMP), all of themhaving the same meaning.

1.3

Scope
This chapter describes the process and basic rules to adapt preventive maintenance intervals
and develop scheduled task packages based on all identified PMTRI. It is essential to ensure
traceability from each PMTRI to the resulting scheduled maintenance task within a scheduled
task package (and audit trail). Operator’s input and decisions determine the need to adapt
intervals for single PMTRI. Typically, customers/operators specify an interval target value foreach scheduled task package based on availability and/or economic requirements.
In addition to the above-mentioned packaging process, it is necessary to perform Maintenance
Task Analysis (MTA) on all scheduled maintenance task packages to get an estimate of the
Product's scheduled maintenance effort.

2

Development of PMTRI

2.1

General analysis processes
Existing specifications concerning the identification of preventive maintenance requirements(such as S4000P, DEF-STAN 00-45 Part 3, ATA/A4A MSG-3, MIL-STD 1843, and MIL-STD
2173) contain three analysis processes covering the complete Product under analysis, alongwith Product development activities:
−
−
−

2.1.1

system analysis
structure analysis
zonal analysis

System analysis
The system analysis aims at developing applicable and effective PMTRI for Product systems,
subsystems and included equipment and components. The Product systems are analyzed in a
structured and transparent approach to prevent failures, which can be critical to safety,
compliance with the law, environmental integrity, operational/mission availability and higheconomic damage. The central goal of system analysis is to identify effective and applicable
PMTRI to avoid such critical failures.
Refer to S4000P for extended information concerning the system analysis process.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

2.1.2

Structure analysis
The structure analysis aims to develop applicable and effective PMTRI for the mechanical
Product structure (eg, the body of land vehicles, airframes, or ship hulls). Based on theconsequences of their loss of function, there are three types of Product structure:−−−

structural components relevant for Product safety - Structure Significant Items (SSI)
structural components with impact on Product maintenancestructural components with no significant impact on Product operation

Refer to S4000P for further information concerning the structure analysis process.
2.1.3

Zonal analysis
The zonal analysis considers additional aspects not covered by system analysis or structure
analysis to identify further PMTRI assigned to a zone. It takes into account standard impact
parameters for a zone of a Product and gives appropriate attention to additional aspects as
required. As laid out in S4000P specification, the aspects to be considered include, but are notlimited to:
−
−
−
−
−

susceptibility to damage for hardware located in a specific zone
density of equipment within a zone
sources of ignition in a zone (eg, caused by damages on electrical wiring)
combustible material and/or vapor accumulation as a risk factor in a zone
impact of lightning or High Intensity Radiated Fields (HIRF) within a zone

Refer to S4000P for further information concerning the zonal analysis process.
2.1.4

Additional sources for PMTRIIn addition to the identification of PMTRI based on analysis methodologies (included, forexample, in S4000P), there are further sources to justify a PMTRI, such as:
−
−
−
−
−
−
−
−

Certification Maintenance Requirements (CMR) including (national/international) law
provisions and requirements from regulatory authorities
requirements from Product safety analysis/Fault Tree Analysis (FTA)
structural inspections related to material fatigue
Original Equipment Manufacturer (OEM) recommendation/requirements (often aprerequisite for warranty)
best engineering judgment
experience from other projects
PMTRI selected by individual users
recommended scheduled activities during storage periods

2.2

Time limits, thresholds and triggers for a scheduled task

2.2.1

GeneralScheduled tasks are determined for PMTRI identified by PMA. For each scheduled task, it ispossible to assign different types of time limits, thresholds and triggers to:−−discrete time limits (eg, time limits which are performed only once)
periodic time limits, divided in:••−initial time limit (specific interval for the first scheduled performance of a periodic task)
repeat time limits (time limits repeated at specific intervals)

Triggers and thresholds

Triggers and thresholds can be defined as parameter values (eg, 1000 operating hours) or
based on an event (eg, after performing a specific task, after a special event has occurred anumber of times).

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

2.2.2

Discrete time limit
A task satisfying a PMTRI that must be performed only once is characterized by a discrete time
limit. For example, a preventive maintenance task to check wheel nuts after a certain driving
distance or to check the torque of special screws after a certain time of Product usage. Refer to
Fig 1.

ICN-B6865-S3000L0043-003-01
Fig 1 Discrete time limit
2.2.3

Periodic time limit - repeat time limit
A task satisfying a PMTRI that must be performed repeatedly with a constant interval during the
lifetime of a Product is characterized by a repeat time limit. Therefore, it will have a repeatedthreshold, known as a classical interval. Typical tasks are, for example, a periodic inspection ora periodic servicing task, such as an engine oil change. Refer to Fig 2.

ICN-B6865-S3000L0044-003-01
Fig 2 Repeat time limit
2.2.4

Periodic time limit - initial and repeat time limit in combination
A combination of initial and repeat time limits is a common Product maintenance practice, forexample, for Product structures. LSA data must document data for both time limits. Refer to Fig
3.

ICN-B6865-S3000L0045-003-01
Fig 3 A combination of tasks with initial and repeat time limits
The start of the repeat time limit depends on the maturity of the initial time limit and on theexperience gained from the efficiency of performing the corresponding preventive maintenancetask for the first time.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

Note
The examples from Fig 1 to Fig 3 show how to define a threshold using a numerical value
and a corresponding unit of measure. A second specialization is to refer to the number ofoccurrences of an event to set a threshold (eg, occurrence of a special event, performanceof a specific task).
2.2.5

Trigger events
Defining a trigger event can lead to the need to change time limits during the complete Productlife cycle. A trigger event can be based on a numeric parameter or on the occurrences of anevent (eg, a task, a special event, or a failure). The trigger can modify a time limit, but alsochange the type of scheduled maintenance task. Refer to Fig 4.

ICN-B6865-S3000L0046-003-01
Fig 4 Example of a trigger event
A typical use of a trigger event is the consideration of familiarization, learning phases andphases occurring after a certain period in the life of a Product, if for example, deterioration
effects can force the implementation of modified PMTRI.
Note
Furthermore, a trigger event can terminate a PMTRI. This means there will not be any
preventive follow-on task after the trigger event.
2.2.6

More than one periodic time limit
Depending on the deterioration process affecting equipment and/or components of a Product, a
PMTRI can be limited to more than one threshold value. In several cases analysts define aninterval based on usage parallel to a calendar-based interval. This approach is often referred toas a "whatever comes first" situation. In this case, the time limit that comes first during Productusage is the one that triggers the corresponding scheduled maintenance task.
Example:A Product manufacturer determines the need to change the engine oil of a vehicle either after
driving 20.000 kilometers (repeat time limit A), or after one calendar year (repeat time limit B).
Both thresholds are a factor in engine oil deterioration, and have different impact parameters.
For example, if the Product’s driven distance is only 8000 kilometers per year, the calendarbased interval (1 year) launches the scheduled oil change. If the Product’s driven distance isalready 20.000 kilometers after only six months, the usage-based interval (20.000 kilometers)
launches the scheduled oil change. Refer to Fig 5.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

ICN-B6865-S3000L0111-002-01
Fig 5 More than one periodic time limit for a preventive maintenance task

3

PMTRI within the LSA
As described in Para 2, a PMTRI is developed on analytical basis (eg, based on S4000P). The
analysis methodologies use selection logic to identify applicable and effective preventive
maintenance task requirements. After a harmonization and consolidation phase (refer toS4000P), LSA data document the remaining PMTRI based on system, structure and zonal
analysis (refer to Para 2.1.1, Para 2.1.2 and Para 2.1.3) and based on additional sources, refer
to Para 2.1.4.

3.1

PMTRI from system analysis
PMTRI identified by a system analysis are allocated to the impacted Breakdown Element (BE)or part. The relevant system, subsystem, equipment or component represented by a BE or apart within the LSA data becomes an LSA candidate.

3.2

PMTRI from structure analysis
To document PMTRI for structural items within the LSA data, it can be necessary to include
limited areas or Structural Details (SD) in the Product breakdown for the identified structural
items. Documenting an SD within the Product breakdown requires the creation of additional BE
representing structural areas. These additional LSA candidates are necessary to enable thecorrect assignment of the identified PMTRI for these structural areas. Refer to S4000P.

3.3

PMTRI from zonal analysis
PMTRI identified during zonal analysis can be allocated to:−−−the 3-dimensional zonal areas of the Product under analysis (Product zones)
selected equipment/items of Product systems
selected structural items of a ProductProduct zones can comprise equipment and components from different systems and structural
items of a Product. It is possible that some selected Product zones only contain structural items.
It is recommended that a corresponding BE for each identified Product zone (eg, within an
applicable Product zonal plan) be assigned. In general, each zone is a potential LSA candidate.
As a matter of fact, the standard zonal analysis normally defines a General Visual Inspection
Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00(GVI) with a scheduled interval for each Product zone. The manufacturer and/or responsible
authorities must justify and agree to any exception.
PMTRI resulting from zonal analysis and allocated to selected equipment/items of Productsystems or to structural items of a Product are handled in the same way as the PMTRI resulting
from a system analysis or from a structure analysis.

3.4

LSA activities for a PMTRI

3.4.1

Criticality of the PMTRIFor each identified PMTRI, it is necessary to document the "worst-case" criticality of any
Functional Failure Effect (FFE) that can occur at Product system level, in order to enable thepackaging process described in Para 4 and ensure traceability at a later stage.
Note
It is possible to use a Functional Failure Effect Code (FFEC) assigned by S4000P analysis
activities as an example for the documentation of PMTRI criticality.

3.4.2

Scheduled maintenance task and MTA
All PMTRI allocated to LSA candidates subsequently drive the corresponding rectifying
scheduled maintenance tasks. In the LSA data, each PMTRI is linked to one or more scheduled
maintenance tasks. All these tasks undergo an MTA. Refer to Chap 12.
In case an MTA for a single scheduled maintenance task detects potential problems concerning
the applicability and effectiveness of the task, it is necessary to provide feedback to the analyst
responsible for the PMTRI development to clarify the origin of the assumptions related to task
applicability and effectiveness:−−

PMTRI and criticality allocated to Product safety or not complying with the law orenvironmental integrity  immediate feedback with urgent need for clarification
PMTRI and criticality allocated to Product operational/mission availability or best economic
feasibility  feedback and request for clarification depending on contractual requirements
between user and manufacturer

4

Packaging for PMTRI

4.1

Packaging process overview
Fig 6 shows an overview of the entire process starting from PMTRI identification within ananalytical process (eg, based on S4000P) to a final harmonization in form of adequate mastertask packages within a PMP. The figure illustrates which activities belong to development of
PMTRI (eg, based on S4000P) and those that fall within the scope of LSA. The general process
steps are:
−
−
−
−
−
−
−
−
−
−

developing applicable and effective PMTRI
assigning the PMTRI to corresponding LSA candidates within the Product breakdown
assigning scheduled maintenance tasks to each harmonized PMTRI and a corresponding
LSA candidate
performing an MTA for each scheduled maintenance task
selecting all PMTRI/scheduled maintenance tasks relevant for packaging
defining master task packages with corresponding master intervals
assigning PMTRI/scheduled maintenance tasks to the master task packages
defining appropriate LSA candidates within the Product breakdown for the allocation ofmaster task packages
assigning master task packages to appropriate LSA candidates
performing an MTA for the complete master task packages

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

ICN-B6865-S3000L0066-004-01
Fig 6 Process overview from PMTRI to master task packages
Another aspect is traceability of a PMTRI. Fig 7 shows the complete traceability path, from theoriginal PMTRI (eg, developed in accordance with S4000P), via scheduled maintenance tasks
and final master task packages developed within the LSA process, to the final master task
packages documented within the corresponding technical publication. Finally, the master task
packages comprise the binding preventive maintenance activities to be performed during the
Product in-service phase.
Note
It is possible to apply the In-Service Maintenance Optimization (ISMO) process described in
S4000P to optimize preventive maintenance at a later stage. For this purpose, correct andcomplete documentation of the entire analysis chain shown in Fig 7 is of crucial importance.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

ICN-B6865-S3000L0067-004-01
Fig 7 From single PMTRI to completed PMP (and traceability back)

4.2

Preparation of packaging process

4.2.1

General aspects
In order to start an appropriate packaging process for all identified PMTRI, the Productmanufacturer must request information form the customer/operator whether the Product is
operated within the usage parameters determined by Product design and development.
Additionally, it is necessary to determine and document the process and the project-specificrules for PMTRI packaging, for example, using a corresponding packaging guidance document.
It is recommended that the guidance document for the PMTRI packaging process detail at least
the following aspects:
−
−
−
−
−
−

baseline usage scenario and potential deviations for specific customers/operators
rules for the exclusion of a PMTRI/scheduled maintenance task from packaging
decisions/predictions about interval unit of measure and parameter values for the mastertask packages
calculation rules for adaptation of interval unit of measure, if required
rules for PMTRI allocation to a master task package
responsibilities and degree of involvement of regulatory authorities

All resulting PMTRI according to Para 2.1 must be considered by the packaging process within
the scope of LSA activities. MTA must analyze the corresponding scheduled maintenance tasks
to describe the task execution, determine the Maintenance Level (ML) and identify the required
resources, such as personnel, support equipment, spares, consumables, technical publication,
facilities and infrastructure. Based on MTA results, it is possible to decide whether an individual
PMTRI is actually a candidate for packaging. Any PMTRI leading to a scheduled maintenanceApplicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

task that can be performed without any preparation work, any additional support equipment, andmore or less at any time, is not considered as being relevant for packaging.
It is necessary to define the master intervals (unit of measure and numerical values) of therelevant master task packages after determining the packaging relevant PMTRI andcorresponding scheduled maintenance tasks, and confirming Product configuration validity andcompleteness. In general, the customer/operator needs to be involved in the determination of
the master intervals.
For individual Products, it can be necessary to define multiple packaging concepts, possiblywith different units of measure for each master task package (eg, based on calendar versus
based on Product usage), with a view to allowing different customers/operators to provide an
individual definition of master task packages. If a customer intends to deviate from a baseline
Product usage scenario, all calculation parameters used to convert intervals from one unit ofmeasure to another must be checked and, if necessary, adapted.
4.2.2

Master task package
Each master task package requires a master interval. The master interval can be based on:−−−

Product usage parameterscalendar-based parameters
combination of Product usage and calendar-based parameters

Examples for Product usage parameters are:−−−−operating hours
operating cycles
number of activations
driven distance (eg, for vehicles)

Note
If calendar-based master intervals are selected, the actual intensity of usage of the Productcan vary with no impact on the scheduled Product maintenance. The actual intensity ofusage is better represented by usage-oriented master intervals. For example, the real
Product usage can differ significantly depending on individual users.
Depending on the individual PMTRI, more than one threshold can be applicable and effective,refer to Para 2.2.6. In those cases, the threshold expected to be reached first becomes therelevant one for the master task package.
4.2.3

Interval correlation between PMTRI and master interval
It is necessary to correlate the units of measure for the intervals of single PMTRI and therelevant master interval in case they differ. For example, a single PMTRI is based on operating
cycles, and the master interval is based on operating hours. In this case, the usage scenario
must determine the expected number of operating cycles within a certain number of operating
hours (eg, expected aircraft landings within 1000 operating hours). If the correlation is clear, it ispossible to describe the interval of the PMTRI using the unit of measure of the master interval.
However, this type of correlation always assumes there is a tolerable level of constant Productusage. Peaks in the usage of a Product always cause a risk of exceeding thresholds earlier asallowed, especially in the case of correlating units of measure for PMTRI intervals and masterintervals. Also refer to the interval adaptation example in Para 4.3.5.

4.2.4

Preparation completion
Prior to starting the PMTRI packaging process, it is necessary to check the underlying LSA data
to ensure all PMTRI are approved and released for further interval packaging activities. The
PMTRI must represent all valid Product configurations, including variants of the Product underanalysis.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

The preparation process aims to ensure an effective packaging of the PMTRI taking into
account at least the following aspects:
−
−

−

−

A PMTRI can become relevant in more than one master task package (eg, a preventive
maintenance task satisfying a PMTRI to be performed prior and after each Productoperation day)For each identified effective and applicable PMTRI, the "worst-case" criticality of the FFE at
Product system level must be available. This criticality category influences decisions interms of interval extension or reduction to include a PMTRI and the corresponding
scheduled maintenance task into a master task package.
A PMTRI can have one or more different interval types (eg, based on operating hours,
cycles, calendar time, and distances) and different numerical interval values. This requires
the use of conversion factors to adapt PMTRI intervals and allocate them to master task
packages.
A PMTRI can be relevant only for specific ML, because:••

the PMTRI can require specific training and experience of maintenance personnel
which are only available at specific ML
the PMTRI can require material resources (eg, support equipment, spare parts,
consumables, facilities and/or infrastructure) which are only available at specific ML

4.3

Packaging process for PMTRI

4.3.1

Impact of maintenance level on master task packages
After packaging preparation is complete, a set of PMTRI with different interval values based on
the master intervals is identified, consolidated, and documented within the LSA data. The
PMTRI justify scheduled maintenance tasks assigned to different ML after the MTA. Fig 8
provides a generic example for a first distribution of PMTRI.

ICN-B6865-S3000L0110-003-01
Fig 8 Initial distribution of PMTRI (on different maintenance levels)
Each bullet in Fig 8 represents one PMTRI to be performed at the determined ML.
Note
Chap 11 provides examples of ML definitions.
Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

As early as the beginning of the packaging process, PMTRI distribution within one ML can show
a concentration of some PMTRI within limited ranges of intervals. The analyst can use theseranges of similar intervals to support the identification of master intervals. Refer to Fig 9.

ICN-B6865-S3000L0112-002-01
Fig 9 Clustering of PMTRI to support the identification of master intervals
4.3.2

Predefined master task packages
LSA data can also be used and evaluated for all PMTRI/preventive maintenance tasks which
are generally determined (eg, for each Product operating day).
In many cases, there are three predefined master task packages for PMTRI allocation:−−−

Before starting the Product operational/mission phase (eg, preflight inspection of an aircraft)
After an intermediate stop of Product operation or mission (eg, prior to restart, if applicable)
At the end of a Product operation or mission (eg, post-flight inspection of an aircraft)

In addition, further predefined master task packages allow PMTRI allocation. For example, theProduct overhaul/depot-level maintenance must occur after 15 years and the Product usage
period is 30 years. That covers all PMTRI in LSA with a 15-year interval or with an allocation to
Product overhaul/Depot Level Maintenance (DLM).
4.3.3

Basic rules for interval adaptation based on PMTRI criticality
Any change in numerical interval values must follow clear rules. These rules must be traceable
for regulatory authorities and/or Quality Assurance (QA) departments of the Productmanufacturer. For this purpose, it is recommended that adaptation rules be determined, forexample, within a project-specific guidance document for the packaging process, which must be
accepted by the involved parties.
The adaptation of individual PMTRI must be performed after determining the ML and the masterintervals for each master task package. Fig 10 provides examples of use cases for different
interval change options. The general consequences to take into consideration are:−−interval extension increases the risk of failure, but reduces maintenance costs
interval reduction reduces the risk of failure, but increases maintenance costs

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

ICN-B6865-S3000L0047-002-01
Fig 10 Principles for interval modification
Some PMTRI can have the same numerical value as the master interval. However, most of theinterval values of PMTRI typically need to be extended or reduced to fit into a master interval. It
is important to remember that extension of intervals normally causes a higher risk of failure.
The examples in Fig 10 consider the different criticality of the corresponding most critical FFE
for a PMTRI, and the different needs for adaptation (extension/reduction):−−

The examples A1 to A5 are relevant for PMTRI that prevent FFE related to Product safety,
compliance with the law or environmental integrity
The examples B1 to B5 are relevant for PMTRI that prevent FFE related tooperational/mission availability or economic feasibility

For each example, adaptation rules are described. Refer to Table 2.
Table 2 General interval adaptation rules
ExampleAdaptation rules

A1

Interval of PMTRI equal to the master interval, no adaptation required

A2

Interval of PMTRI higher than the nearest master interval and within a range
close to the nearest master interval. Adaptation of interval is possible andagreement by regulatory authorities is expected. High probability of cost
increase within acceptable limits, user involvement is recommended.

A3

Interval of PMTRI lower than the nearest master interval and within a range
close to the nearest master interval. Adaptation of interval is not allowed
because of the related FFE criticality.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

ExampleAdaptation rules

A4Interval of PMTRI outside a close range to the next higher or lower masterinterval. Only adaptation to a lower master interval is possible. Agreement byregulatory authorities is expected. Increase of costs due to a significantly lower
interval of task must be considered, user involvement is recommended.

A5Interval of PMTRI lower than the nearest master interval and within a range
close to the nearest master interval, which is the lowest master interval
available. Direct adaptation of this interval is not allowed because of the related
FFE criticality. This situation requires additional analysis to identify a lower
master interval (eg, daily inspection). In addition to that, the safety department
can recalculate the interval or, in the worst-case scenario, consider Productdesign change.

B1

Interval of PMTRI equal to the master interval, no adaptation required

B2

Interval of PMTRI higher than the nearest master interval and within a range
close to the nearest master interval. Adaptation of interval is possible. Highprobability of cost increase within an acceptable limit, user involvement isrecommended.

B3

Interval of PMTRI lower than the nearest master interval and within a range
close to the nearest master interval. The related FFE criticality allows adaptationof the interval, but the user must agree to the increased risk for FFE.

B4

Interval of PMTRI outside a close range to the next higher or lower masterinterval. Adaptation to either a lower or a higher master interval possible.
In case of interval reduction, it is necessary to consider and the user must agree
to the cost increase due to a significant lower interval of task.
It is necessary to consider an increased risk of FFE occurrence because of asignificant higher interval. User agreement is required.

B5

4.3.4

Interval of PMTRI lower than the nearest master interval and within a range
close to the nearest master interval, which is the lowest master interval
available. Adaptation to the lower master interval is possible. It is necessary toconsider and the user must agree to an increased risk of FFE occurrence
because of a higher interval of task.

Summary of PMTRI interval adaptation
It is prohibited to extend intervals of PMTRI that prevent FFE related to safety, compliance withthe law or environmental integrity. If any PMTRI interval of these FFE categories, is below thelowest grouping interval for the specific maintenance level, the corresponding tasks needs
further investigation, which can result in:−−−−

introduction of a new master task package with a lower interval value
PMTRI modification (change of scheduled maintenance task to cover PMTRI including
recalculation of interval value)
ML change
Product design change requirements

It is possible to either extend, or reduce intervals of PMTRI that prevent FFE related tooperational/mission availability or economic impact. The user must agree to any modification. It
is necessary to balance risk of economic loss or additional downtime with potential cost savings.
Note
The ISMO process described in S4000P takes into account these rules based on the FFE
category for each individual PMTRI. The Product in-service experience, in combination with
Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

ISMO, allows an easier adjustment and optimization of all PMTRI linked to FFE on
operation, mission and economy.
For safety FFE, compliance with the law and/or environmental integrity, no in-service
data/experience can be expected. The optimization of those PMTRI must consequently bebased on other investigations, calculations and/or further analysis.
4.3.5

Adaptation example
A safety relevant PMTRI requires a visual inspection on a hydraulic actuator every 600
Operating Hours (OH). The usage scenario is:
As per the Product design, the maximum operating hours for the Product is 1000 OH in one
calendar year. The user determines the interval type for the master task package based on
calendar, with a small inspection package every 6 months and a full inspection package every
calendar year. Due to the PMTRI category "safety-relevant" in this example, it is only possible toreduce the parameter value of the scheduled interval (refer to the rules described in Para 4.3.3).
Based on this limitation, the first preventive maintenance task must be performed during mastertask packages that do not exceed the repeat time limit of the visual inspection on a hydraulicactuator (here every 600 OH) and the corresponding calendar intervals. Therefore, thescheduled maintenance task must be performed every six months, as the expected operating
hours for half a year is 500 OH. It is not possible to select a task which is performed once a year
and related to the maximum of 1000 OH, because of a clear interval excess for the safety
relevant PMTRI.
In this example, the original PMTRI for the LSA candidate hydraulic actuator is a detailed visualinspection on the hydraulic actuator every 600 operating hours. The result after the packaging
process and corresponding interval adaptation is a detailed visual inspection on a hydraulicactuator every six months performed within the corresponding master task package.
Note
The example also shows a potential conflict with the definition of master task packages withcalendar-based intervals. The original PMTRI is based on actual usage (eg, 600 OH), andthe master task package is due after six months. The predicted usage of 500 OH per six
months is only valid if there is a tolerable level of constant Product usage. The original 600
OH of the safety relevant PMTRI not being exceeded after 6 months of Product operation,must be guaranteed.
The choice often falls on calendar-based master task intervals because they provide a
better planning reliability concerning the use of facilities/infrastructure and personnel.
Usage-based master intervals, on the other hand, exclude the risk of exceeding criticalintervals.

4.4

Maintenance task analysis for master task packages
After allocation of all PMTRI to master task packages, an MTA for the complete packages isrequired. The master task packages can contain a large number of single PMTRI with or without
adaptations of interval. Refer to Fig 11.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

ICN-B6865-S3000L0048-003-01
Fig 11 Integration of single PMTRI into master task packages
Typically, the tasks in the master task package are not performed sequentially. It is
recommended to consider the following aspects:−−−−

there is potential interdependence of single activities/maintenance tasks (eg, an inspector
must close and confirm a maintenance task before another maintenance task can start)
performing time-consuming tasks for gaining access only once can result in saving time (eg,after opening panels and doors, all tasks are performed within the corresponding area
before closing the panels and doors)task packaging can consider the possibility of performing tasks in parallel to ensure a more
realistic estimation of the duration and effort of a complete master task package
required resources such as personnel and support equipment must be harmonized for thecomplete package and are not just a simple collection from the single preventive
maintenance tasks

Once a master task package is finalized, the original PMTRI are no longer the basis for logistic
evaluations, because the master task package is now the subject to those calculations.
However, it is necessary to keep and maintain the original PMTRI in the LSA data to reuse
information in later optimization processes and to ensure full traceability over the entire Productlife cycle.
At any stage of the project, it must be possible to recover the original PMTRI documented at theLSA candidate in the LSA data from an individual preventive maintenance task defined in amaster task package. Moreover, it must be possible to recover the corresponding PMTRI sourcefrom each PMTRI (eg, based on S4000P, MSG-3, RCM, and CMR). Refer to Fig 7.
These traceability requirements ensure the complete consistency of the scheduled Productmaintenance, starting from the first PMA steps, followed by LSA activities, up to the final
generation of the technical publication for a Product.
In addition, this allows to apply the ISMO process with the aim of continuously optimizing
Product maintenance, including the Product’s Life Cycle Costs (LCC). Refer to S4000P andChap 14.

Applicable to: All

S3000L-A-10-00-0000-00A-040A-A
Chap 10

DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

5

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:−−−−

S3000L UoF LSA Candidate
S3000L UoF Task Requirement
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-10-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-10-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 102021-04-30 Page 18

S3000L-B6865-03000-00

Chapter 11
Level of repair analysis
Table of contents
1
1.1
1.2
1.3
2
2.1
2.2
3
4
4.1
4.2
4.3
4.4
4.5
4.6
5
5.1
5.2
5.3
5.4
5.5
6
6.1
6.2
6.3
6.4
7

Page

General ............................................................................................................................ 2
Introduction ...................................................................................................................... 2
Purpose ........................................................................................................................... 2
Scope ............................................................................................................................... 3
Aspects concerning selections of level of repair analysis candidates ............................. 3
Candidate selection ......................................................................................................... 3
Repair or discard decision ............................................................................................... 3
Identification of optimum maintenance level by economic level of repair analysis ......... 4
Data gathering for level of repair analysis ....................................................................... 4
Definition of operational concept ..................................................................................... 4
Determine parts hierarchy ............................................................................................... 4
Determine level of repair analysis candidates ................................................................. 4
Collect unit prices ............................................................................................................ 5
Collect maintenance-related cost data ............................................................................ 5
Other maintenance relevant data .................................................................................... 6
Performance of economic level of repair analysis and preparation of results ................. 7
Economic level of repair analysis baseline run ............................................................... 7
Sensitivity analysis........................................................................................................... 7
Maintenance solution recommendation ........................................................................... 8
Level of repair analysis report ......................................................................................... 8
Maintenance solution documentation .............................................................................. 9
Example of maintenance level definitions ....................................................................... 9
General ............................................................................................................................ 9Level 1 ............................................................................................................................. 9Level 2 ........................................................................................................................... 10
Level 3 ........................................................................................................................... 10
Associated parts of the S3000L data model .................................................................. 11

List of tables
1
2

References ...................................................................................................................... 1
Overview of typical cost elements ................................................................................... 5

References
Table 1 References
Chap No./Document No.

Title

Chap 3

LSA process

Chap 19

Data model

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

1

General1.1

Introduction
Level of Repair Analysis (LORA) is an analytical methodology performed on a list of selected
LSA candidates and associated tasks. It takes into consideration customer support andoperational requirements, customer support capabilities, product technical information, costs,
and legal and environmental constraints to determine an optimized maintenance solution. It
defines where each selected item is, for example, removed, replaced, repaired, tested,overhauled, inspected, or discarded.
The LORA process harmonizes technical and cost assessment. It is recommended to perform
an Economic LORA (ELORA) in conjunction with a Life-Cycle Cost (LCC) analysis, because thecosts for maintenance activities are crucial for the complete LCC. It is necessary to combine
technical and commercial aspects in order to achieve proper results for LORA.
LORA is a two-step process:−−

Determination of whether the Item Under Analysis (IUA) is a repair or discard item
(supporting the repair/discard decision by the customer)
Identification of the optimum maintenance level for the required maintenance tasks, also
called ELORA

Note
Maintenance levels are different due to eg, required personnel competence, facilities orsupport equipment available. Although typically associated with specific organizations
and/or geographic locations, the individual maintenance levels in their purest form also
denote differences in inherent complexity of maintenance capability. There are several
generic levels, for example:•••

Organizational level (inspections, servicing, handling, preventive and corrective
maintenance)
Intermediate level (assembly and disassembly beyond the capability of theorganizational level)
Depot level (any action that requires extensive industrial facilities, specialized tools andequipment, or uniquely experienced and trained personnel not available in lower-level
maintenance activities)

The LSA Program Plan (LSA PP) or similar documents describe the requirements for LORA.
Depending on the specific phase of a project, it is possible to perform LORA for different
purposes and using different methods.
The LORA process can be repeated as often as required during the design and development
and the in-service phases. LORA results determine whether changes to the maintenancesolution are necessary due to design changes or other factors. The results of the LORA process
can illustrate various options useful for supplier selection and lead to the adoption of phased
support.

1.2

PurposeThe purpose of a LORA is to guide the customer in the selection of the most suitable
maintenance solution. Therefore, LORA is performed from a customer point of view, with thecustomer prerequisites and interests in focus. Different customers can come to different
decisions depending on their specific project needs. In the early stage of a project, it isnecessary to consider LORA aspects to influence the design (eg, testability features,
modularity, and accessibility requirements), as well as to support customer strategy decisions(eg, 2-level maintenance strategy, single source principle).

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

1.3

Scope
The target readers of this chapter are contractor and customer supportability personnel who
perform LORA activities. Appropriate LORA reports will document LORA results. It is
recommended to document the derived maintenance solution per LSA candidate.

2

Aspects concerning selections of level of repair analysis
candidates

2.1

Candidate selection
The identification of potential LORA candidates can be based on the LSA Candidate Item List
(CIL) established in accordance with the project’s selection process of LSA candidates. Refer toChap 3.
The first step is to decide whether an LSA candidate is potentially repairable. If so, it isnecessary to choose the most suitable LORA method:−−−−

Best engineering judgment only
Simplified LORA (eg, collecting information and considering values)
LORA based on mathematical models (with the aid of commercial software packages)
Simulation (with the aid of commercial software packages)

It is necessary to document the reason for choosing a specific method. In addition, otherconstraints or specific customer decisions can include:
−
−
−
−
−
−
−
−

exclusions from repair due to danger of destruction or hazardous/unsafe situation
input from system integrator or Original Equipment Manufacturer (OEM) relevant to LORA
cutoff values or design-driven influences (a set of predefined cutoff values can reduce thenumber of ELORA candidates). These cutoff values are usually based on technical andeconomic factors such as low task frequency, low unit price, or repair costs.
customer-imposed maintenance constraints, not related to LORA
customer’s existing maintenance facilities illustrated in the Operational Requirements
Document/Customer Requirements Document (ORD/CRD)
customer requirements derived from ORD/CRD
contractual requirements or LSA Guidance Conference (GC) decisions
clear understanding of LORA requirements set by other disciplines

These external influences or requirements must be addressed, discussed, and agreed during
the LSA GC.

2.2

Repair or discard decision
A repair/discard decision is the prerequisite to any ELORA. It can include non-economic as wellas economic factors. It is, in effect, a screening process aimed at minimizing the number of
ELORA candidates using a logical process of elimination. Each LSA CIL has several items thatare potential ELORA candidates. Taking a repair/discard decision is necessary to identify whichof these items are candidates for further ELORA. This is achieved by determining the repair
feasibility for each item.
Below is a list of crucial technical questions for each potential ELORA item:−−−

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 only include the possible maintenance levels.
Does the design of the item not allow repairs in general? If so, this item must be removed
from the ELORA candidate list. However, the proper maintenance level for replace anddiscard must be identified and documented.

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

It is necessary to document this decision, and the logic behind it for future traceability. For items
that have been identified as potentially repairable, the next phase must determine the method
for performing ELORA. This phase provides the opportunity to take into account any external
influences/requirements (eg, existing maintenance solutions used by the customer, cutoff
values, or influences driven by design).

3

Identification of optimum maintenance level by economic levelof repair analysis
The repair/discard decision process results in a list of remaining ELORA candidates identified
as potentially repairable. ELORA aims to determine the optimum maintenance solution for thesecandidates considering mainly economic cost factors such as spare parts, support equipment
for failure detection/localization and repair, personnel, training, facilities, technicaldocumentation, and Packaging, Handling, Storage and Transportation (PHST). Additionally,
trade-offs should be taken into account when identifying optimum maintenance location. For
these trade-offs, non-economic factors such as availability requirements, customer capabilities,
reliability, and maintainability can be considered.
Many different mathematical ELORA models are available and supported by different
commercial software packages. Simplified LORA often uses an alternate approach that must
develop a project specific or tailored model that addresses the requirements and constraints (forboth customer and OEM) such as available infrastructure, personnel, or technical capabilities.
Within a project, all LORA analyses must be integrated into a common ELORA model as muchas possible. This allows an overview of the cost versus performance of all selected LORA
solutions.

4

Data gathering for level of repair analysis
The following sections provide additional details regarding data needed for LORA. Some ofthem, cost data in particular, are not identified in the S3000L data model yet. Refer to Chap 19.

4.1

Definition of operational concept
Apart from technical and economic data, the LORA outcome depends on the Product intended
context of use. These prerequisites are defined in a CONcept of OPerationS (CONOPS), which
defines Product distribution and use. A CONOPS is normally provided by the customer. The
ORD should contain all necessary information derived from the CONOPS.

4.2

Determine parts hierarchy
Maintenance and operational support activities in LORA are assigned to the hierarchicalbreakdown structure of the Product systems. Failures at the top level of a system are assumed
to be primarily caused by failures of the items (or subsystems) at the next lower indenture level.
Similarly, failures of the items in the second level of indenture are mainly initiated by failures of
the items in the next lower indenture level. For this reason, it is impractical to perform a LORA
until hierarchical relationships are outlined. For Products that are currently in production,
existing LSA data derived from the Product breakdown can determine the hierarchy andsubsequent LORA candidate items.

4.3

Determine level of repair analysis candidates
After establishing the parts hierarchy, the analyst must determine which parts will be included in
the analysis. At first glance, it seems logical to include all of the parts. However, non-repairable
and consumable parts (eg, nuts, bolts, gaskets) will add no value to the analysis and, therefore
are excluded. Establishing a set of rules based on existing repair or maintenance codes, unit
price, repair level, or other criteria can help determining the candidate items.

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

4.4

Collect unit prices
Unit prices for all items are required to fill an ELORA data model and perform the analysis. Unit
prices are available from provisioning records or other documents. The unit price for all ELORA
candidate items is necessary to determine the economic feasibility of repair. It is essential touse correct unit prices for ELORA calculation purposes. Unit prices can differ dramatically fromthe production phase to the in-service phase.
Note
The price of spare parts can be very different from the production unit price.
Sometimes, precise values are difficult to obtain and it is only possible to make an estimate.
These estimations can be acceptable during the initial phases, but they must be reviewed
and/or evaluated through sensitivity analysis.

4.5

Collect maintenance-related cost data
Maintenance cost data include labor time, training, spare parts and consumables, support
equipment, facilities, technical documentation and PHST aspects. With respect to these data, it
is necessary to distinguish between initial and recurring costs. These data are used to calculate
costs at each possible maintenance level.
Table 2 Overview of typical cost elements provides an overview of typical cost elements to be
included in ELORA. Additional data can be required depending on project requirements.
Table 2 Overview of typical cost elements
Cost element

InitialRecurring

Personnel−

Labor time costs−

Training costs (teachers and staff)

X

X

−

Training equipment costs (eg, simulators, classroom
equipment, training facilities)

X

X

X

X

X

Note
It is recommended that costs of direct labor and indirect labor(eg, line managers, inspectors, work preparation department)
be considered.
Spare parts / consumables−

Spare parts / consumables provision−

Spare parts / consumables storage

X−

Disposal costs

X

Support equipment to diagnose and repair−

Support equipment provision and replacement−

Support equipment maintenance−Support equipment upgrade

X−

Development of customized software (eg, test software)

X−

Support of customized software for support equipment

X−

Disposal costs

X

Applicable to: All

X
X

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

Cost element

InitialRecurring

Facilities and infrastructure−

Building of facilities and infrastructure−

Maintenance of facilities and infrastructure

X−

Costs of operation for facilities and infrastructure

X−

Costs for modification of facilities and infrastructure

X

X

X

X

X

Technical documentation−

Documentation costs (eg, user handbooks, maintenance andtraining manuals, illustrations, spare part catalogues)

PHST aspects−

Packaging costs

X

X

−

Stock keeping costs (eg, maintenance tasks and handlingduring storage, special storage containers, administration ofstock)

X

X−

Transportation costs (transport to maintenance facilities andback to user)

X

Others

4.6−

Average repair costs at industry level

X

X

−

Additional costs (documentation, administration, preparatory
work and post processing)

X

X

−

Restocking costs

X

X

−

Requisition costs

X

X

−

Disposal costs

X

X

−

Discount rate

X

X

−

Holding cost percentage

X

X

−

Interest rate

X

X

Other maintenance relevant data
Besides data on direct costs, other pieces of information can be useful for the ELORA process.
This information includes but is not limited to:−

Task execution information
•
•
•
•

−

Task complexity
Required support and test equipment and required competence to use it
Legal regulations which influence the task execution
OEM recommendations or restrictions because of warranty

Frequency and duration information
•
•
•
•
•

Reliability information, eg, Mean Time Between Failure (MTBF), Mean Time Between
Unscheduled Removal (MTBUR)
Frequency of corrective maintenance task
Preventive maintenance interval
Task duration
Logistics down time (eg, waiting time for support resources)

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

Note
Data for repair duration are often difficult to obtain, particularly for newly developed
equipment or systems. During development stage, desired and maximum duration for
failure repair can be specified. This can also serve as a repair duration for items directly
removed and replaced. For estimation of repair duration of lower indenture items, it can benecessary to use the repair duration for similar items in other systems.
−

Availability values
•
•
•
•
•

−

Stock relevant values
•
•
•

−

Minimum availability of IUA (usually, operational availability is specified)Availability of personnel for maintenance activities
Availability of spare parts in stock
Availability of support equipment
Availability of facilities and infrastructure

Procurement lead time
Pipeline transit times
Repair turnaround times

General information
•
•
•
•
•
•

Number and type of contractor industrial facilities
Number of operational sites
Number of operated Products per site
Distances between sites
Inflation/discount rate
Repair policy (eg, 2-level maintenance strategy)

It has been noted that the majority of decisions that influence costs must be made at a very
early stage, even if the available information is limited and the design is not stable yet. For thisreason, it is necessary to perform LORA throughout the Product life cycle, to identify a potential
need for updating the current maintenance solution in a timely manner.

5

Performance of economic level of repair analysis andpreparation of results
ELORA is performed after collecting and harmonizing data together with the customer. A simple
approach must evaluate and balance the given information using best engineering judgment. It
is possible to select a commercial software package in case more complex mathematical
calculation models are used. The data set to be collected depends on the requirements of thespecific software package. The results of the calculation runs must be laid out in an ELORA
report and distributed according to established rules.

5.1

Economic level of repair analysis baseline run
The baseline run using the gathered ELORA data is the first step to perform an ELORA using a
supporting software package. This baseline run will result in a first set of information regarding
costs for the individual maintenance levels. Depending on the different maintenance levels, theresult can be either clear-cut or ambiguous. In either case, it is recommended to confirm thebaseline run results by executing a sensitivity analysis.

5.2

Sensitivity analysis
It is necessary to perform sensitivity analysis on various parameters that are cost significant.
The results of the various sensitivity runs will indicate whether the maintenance solution fromthe baseline run is stable or not. Sensitivity analyses can include, but not limited to:−

major cost influencing parameters of the IUA itself (eg, unit price, MTBF)

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00−−

any parameters that are critical to costly support requirements (eg, facilities, infrastructure,
support equipment, highly educated personnel)
any parameters using assumptions or estimates because of unavailable data (eg, historic orsimilar data from other Products)

Once the parameters for sensitivity analysis are selected, the next step must establish an
appropriate numerical range for the parameter. Finally, when all the requirements are
established, ELORA is performed for each parameter variation. Changing single parameters willkeep the number of runs to a minimum. Multiple parameter changes will lead to nested
analyses. Therefore, it is recommended that these changes be avoided, as they may cause
confusion while evaluating the results.
The output of the sensitivity analysis can be used as a baseline to establish a preliminary
maintenance solution. Additionally, it is useful to influence other support disciplines and/or
design, in order to change their input with a view to achieving the expected maintenancesolution for the equipment.
A sensitivity analysis is usually conducted to complement baseline results. Sensitivity analyses
are performed for cost significant parameters that have a low confidence level or to accomplish
a trade-off study. In case of sensitivity analysis of low-confidence values, the most common
method recommends analyses using the worst- and best-case data. If there is no shift in the
results of the maintenance solutions in the two analyses, then no additional executions using
intermediate values are required.
An example is sensitivity analysis for an item’s MTBF. In this example, the baseline analysis
uses an estimated value of 5,000 operating hours. Preliminary analysis reveals that MTBF forsimilar items range from 1,500 to 15,000 operating hours. The first sensitivity analysis would
include 1,500 and 15,000 operating hours for the MTBF of this item. If the most cost-effective
repair level for both sensitivity analyses is the same as the baseline analysis, no further
sensitivity analysis for this MTBF is necessary. However, if a change in repair level occurs forone or both analyses, further analyses are necessary and must use MTBF values between thehighest and lowest value to identify the break points.

5.3

Maintenance solution recommendation
To achieve a concluding maintenance solution recommendation, it is necessary to consider
costs resulting from ELORA, as well as technical aspects that can have a major impact on therecommendation of the maintenance solution to the customer (eg, destruction of the IUA during
critical repairs, dangerous repair tasks). Additionally, it is necessary to consider the customer’s
preferences.
It is also important to harmonize the maintenance activities in order to avoid splitting similar
maintenance activities to different maintenance sites. For example, it is recommended that theallocation of a piece of electronic equipment for replacement and subsequent repair of different
components be not split between industry and customer sites.

5.4

Level of repair analysis report
It is necessary to produce a report documenting the analysis results. The LORA report must
contain at least:
−
−
−
−
−
−

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 IUAApplicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

•
−
−
−
−
−
−
−

Cost and maintenance data

mathematical methods applied in a simplified ELORA
use of ELORA software package
results of baseline run
results and explanations of sensitivity analysis runs
trade-off studies
consolidation of technical and cost aspects
concluding recommendation on the maintenance solution, including discard decision

It is recommended that a report structure and layout be developed early in the analysis process.
Otherwise, there is the risk of overlooking important information and logic during a lengthy
analysis.
For good traceability, it is recommended to use a standardized format for the maintenancesolution recommendation and related customer decision within the LORA report. The customer
decision will be documented appropriately.

5.5

Maintenance solution documentation
The content of the maintenance solution relates to the corresponding maintenance activities, as
documented in the description of maintenance tasks. Each task for an LSA candidate must
include attributes that reflect the maintenance solution. This information must include at least:
−
−
−
−
−
−
−

maintenance task type (eg, preventive or corrective)
interval or threshold data for preventive tasks
the maintenance level at which the task must be performed
the place at which the maintenance tasks must be performed
special remarks or warnings (eg, if the Product is used under special conditions, theinspection interval must 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 that the basic data set reflecting the maintenance concept be agreed during
the LSA GC, to ensure mutual understanding. Proper documentation within an appropriate
information record ensure to report effectively different aspects of the maintenance concept.
Examples:
−
−
−
−
−
−

Complete overview of maintenance activities at all maintenance levels
Summary of maintenance activities performed at certain maintenance levels
Overview of preventive/corrective maintenance activities
Expected effort at certain maintenance levels
Support for quality checks concerning completeness and conclusiveness of themaintenance solution
Predicted maintenance and support cost distribution according to the defined maintenancesolution

6

Example of maintenance level definitions

6.1

GeneralThis example is based on three maintenance levels, and indicates personnel capability,
availability of special facilities, time limits, and environmental conditions to consider with a view
to determine the tasks relevant to each maintenance level.

6.2

Level 1
Level 1 maintenance aims to ensure the Product remains available. This implies personnel will
perform a fast and easy replacement of Line Replaceable Units (LRU) and/or the replacementof modules on the Product when a malfunction occurs.

Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Level 1 activities typically include, but are not limited to:
−
−
−
−
−
−
−
−
−

6.3

PHST and servicing activities
preparation for use and role changes
pre- and post-operation inspections
functional checks
trouble shooting
preventive maintenancecorrective maintenance (eg, repair by replacement and system adjustment)loading of software (operational and engineering) and data retrieval
simple modifications

Level 2
Level 2 maintenance aims to maintain the highest possible level of availability. Maintenanceactivities at the operating site also include the repair of subassemblies, modules and LRUs after
their replacement at maintenance level 1. Testing on test-benches or integration tests can be
included. Subsequently, level 2 maintenance can be performed either on Product or at specificrepair shops.
Level 2 activities typically include, but are not limited to:
−
−
−
−
−
−
−

repairs down to module and subassembly level
moderate structural repairs
major planned inspections
moderate modifications
technical assistance for the organization of Level 1 maintenancesoftware servicing concerning engineering data
preservation of complete Product

Level 2 activities include corrective and preventive maintenance and specific maintenanceactivities that will be performed on Product (eg, during maintenance, the Product will be
unavailable for use), or at specific repair shops. Level 2 also includes tasks not performed at
level 1 to facilitate the return of the equipment to its full operational state. Level 2 maintenancewill be performed at suitable facilities for the performance of maintenance tasks, which canrequire the use of special equipment or specialized repair shops, and must be performed byappropriately trained and specialized personnel.

6.4

Level 3
Level 3 maintenance aims to ensure the highest possible availability of the Product, as well as
providing engineering support for operational aspects. It must ensure all repairs and overhaul
activities beyond level 1 and level 2 capabilities. Major modifications to improve the design
and/or operational activities will be prepared and, if necessary, performed at this level.
Level 3 activities are expected to typically include, but are not limited to:
−
−
−
−
−
−
−
−

repairs down to full reconditioning
repairs requiring special, rare skills or support equipment
major structural repairs
major planned inspections
extended modifications and update programs
technical assistance for the organization of level 1 and level 2 maintenancesoftware modification
preservation of the complete Product

Level 3 maintenance must ensure the utmost autonomy for the users’ organizations.
International cooperation can allow the setup of an effective and economic authorized level ofmaintenance. It is recommended that single-source repair be considered the best solution.
Applicable to: All

S3000L-A-11-00-0000-00A-040A-A
Chap 11

DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

Level 3 maintenance will be performed in duly equipped facilities or component repair facilitiesof the customer or contractor (or subcontractors). Level 3 requires appropriately trained andspecialized personnel. Level 3 maintenance also comprises the return of defective items(suspected or confirmed) to the OEM for repair/overhaul/retest.
Note
As the "highest" maintenance level, level 3 activities can be subdivided into two or morelevels (eg, level 3 and level 4). This can be used when required to separate clearly useroperated activities (level 3) from contractor-operated activities at industry facilities (level 4).
In this case, the maintenance strategy contains four levels of maintenance (or possiblymore).

7

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:
−
−
−
−
−
−
−
−
−

S3000L UoF Breakdown Structure
S3000L UoF Hardware Element
S3000L UoF LSA Candidate
S3000L UoF LSA Failure Mode Group
S3000L UoF Part Definition
S3000L UoF Performance Parameter
S3000L UoF Task Requirement
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-11-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-11-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 112021-04-30 Page 11

S3000L-B6865-03000-00

Chapter 12
Task requirements and maintenance task analysis
Table of contents

Page

Task requirements and maintenance task analysis ....................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Introduction ...................................................................................................................... 3
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 4
1.4
Terms, abbreviations and acronyms ............................................................................... 42
Task requirements ........................................................................................................... 4
3
Categorization of tasks .................................................................................................... 5
4
Task documentation ........................................................................................................ 6
4.1
General aspects............................................................................................................... 6
4.1.1
Tasks associated with breakdown elements or parts ...................................................... 6
4.1.2
Level of task or task requirement association ................................................................. 6
4.2
Practical considerations ................................................................................................... 8
5
Task structure ................................................................................................................ 10
5.1
Task classification.......................................................................................................... 10
5.2
A simple rectifying task .................................................................................................. 11
5.3
Supporting tasks ............................................................................................................ 13
5.4
Structure of a rectifying task - referencing method........................................................ 14
5.5
S1000D integration considerations................................................................................ 16
5.6
Narrative description ...................................................................................................... 16
6
Task frequency .............................................................................................................. 17
6.1
Maintenance tasks due to inherent equipment failures ................................................. 17
6.2
Task frequency for supporting tasks.............................................................................. 18
6.3
Maintenance tasks due to damages or special events.................................................. 19
6.4
Preventive maintenance tasks....................................................................................... 19
6.5
Task frequency of replacement tasks ............................................................................ 20
7
Task resources .............................................................................................................. 20
7.1
General aspects............................................................................................................. 20
7.2
Task resource assignment ............................................................................................ 21
7.3
Resources out of references ......................................................................................... 23
8
Task location aspects .................................................................................................... 23
8.1
Location in conjunction with maintenance level ............................................................ 23
8.2
Location in conjunction with the Product itself ............................................................... 23
8.3
Location in conjunction with the required facility ........................................................... 24
8.4
Location in conjunction with a Product zone ................................................................. 24
9Additional aspects for tasks ........................................................................................... 24
9.1
Product availability during maintenance performance................................................... 24
9.2
Tasks and applicability .................................................................................................. 25
9.3
Task duration ................................................................................................................. 25
9.4
Parallel activities within tasks ........................................................................................ 26
9.5
Training requirements .................................................................................................... 27
9.6
Circuit breaker settings .................................................................................................. 27
10
Examples for different maintenance solutions ............................................................... 28
10.1
Example 1: Major failure, computer case broken .......................................................... 28
10.2
Example 2: Failure of the mainboard, case 1 ................................................................ 29
10.3
Example 3: Failure of the mainboard, case 2 ................................................................ 30
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

10.4
10.5
10.6
11

Example 4: Failure of the mainboard, case 3 ................................................................ 31
Example 5: Complex maintenance procedure on several levels .................................. 32
Summary of examples ................................................................................................... 33
Associated parts of the S3000L data model .................................................................. 33

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

References ...................................................................................................................... 2
Terms, abbreviations and acronyms ............................................................................... 4
Examples of S1000D information codes usable for task categorization ......................... 6
Task association with different levels of LSA candidates ................................................ 7
Reparability and maintainability properties ...................................................................... 8
Reparability strategy examples ....................................................................................... 9
Typical rectifying tasks for typical events ...................................................................... 11
Formula symbols (task frequency of rectifying tasks based on failures) ....................... 17
Formula symbols (task frequency of supporting tasks) ................................................. 18
Formula symbols (task frequency scheduled maintenance tasks) ................................ 20
Assignment of task resources ....................................................................................... 21
Aggregation of task resources ....................................................................................... 23
Task duration and labor time ......................................................................................... 25
Comparison of resources for sequential or parallel subtasks ....................................... 27
Subtasks for example 1 ................................................................................................. 29
Subtasks for example 2 ................................................................................................. 29
Subtasks for example 3 ................................................................................................. 30
Influence of corrective maintenance options on Product's availability .......................... 31
Subtasks for example 4 ................................................................................................. 31
Subtasks for example 5 ................................................................................................. 32

List of figures
1
2
3
4
5
6
7
8
9
10

Relationship between task requirements and support tasks ........................................... 5
General equipment example ........................................................................................... 7
Simple rectifying task without references ...................................................................... 12
Task components suitable for creating a supporting task ............................................. 13
Example of a supporting task associated with the IUA itself ......................................... 14
Example of a supporting task associated with an LSA candidate different from IUA ... 14
Typical rectifying task - repair procedure ...................................................................... 15
Example of task resources assignment at subtask level ............................................... 22
Parallel activities and their resources/durations ............................................................ 26
General equipment example ......................................................................................... 28

References
Table 1 References
Chap No./Document No.

Title

Chap 7

Corrective maintenance analysis

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Chap 8

Damage and special event analysis

Chap 9Operational support analysis

Chap 10Development of a preventive maintenance program

Chap 11

Level of repair analysis

Chap 13

Software support analysis

Chap 16

Disposal

Chap 19

Data model

Chap 21

Terms, abbreviations and acronyms

Chap 22

Data element list

S1000DInternational specification for technical publications using
a common source database

1

General1.1

Introduction
For a complete documentation of all support activities (generally referred to as task in thischapter) in the context of corrective maintenance, preventive maintenance, and operational
support, it is necessary to consider two main aspects:−−

each rectifying task (refer to Para 5.1) needs to be justified by at least one corresponding
task requirement
each task needs to be analyzed in terms of procedure (how the task is executed) andpersonnel/material resources required to perform the task

Creating a task requirement within the LSA data represents the justification of a task. The
typical task requirements are identified by a set of analysis activities described in Chap 7,
Chap 8, Chap 9, Chap 10, Chap 13, Chap 16, or by other additional analysis activities.
Task analysis must take into account different aspects:
−
−
−
−
−
−

organizing the task into subtasks (also often referred to as work steps)
including all steps necessary to prepare and restore the Item Under Analysis (IUA)
describing the procedure how to perform the task
identifying task resources
documenting additional relevant information for each task (eg, task duration, task location,
safety criticality for personnel, operational impact)
identifying the maintenance level and frequency of task performance

Note
A task can contain hundreds of subtasks, which can be performed sequentially or within
specific parts in parallel. It is necessary to clearly define the sequence and interdependency
between the subtasks.

1.2

PurposeThis chapter is a guideline for the analysis of an identified task with regard to its justification anddetailed performance, and to the identification of all required resources. Maintenance Task
Analysis (MTA) must identify everything that is relevant to the correct task performance.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

1.3

Scope
The target readers of this chapter are analysts who perform analysis activities within the LSA
process to describe the identified tasks in detail. This includes a task description and theidentification of required spare parts, consumables, support equipment, personnel, andfacilities/infrastructure. It is necessary to take into consideration additional information such as
task duration, task criticality, maintenance level and task location, training needs, pre- and postconditions or safety requirements.

1.4

Terms, abbreviations and acronyms
Table 2 provides definitions that are specific to MTA. Chap 21 provides the complete set of LSA
terms, abbreviations, and acronyms.
Table 2 Terms, abbreviations and acronyms

2

Term

Definition

Operational
support task

An operational support task is any support activity that fulfils a task
requirement in the context of Product operation, such as servicing or
Packaging, Handling, Storage and Transportation (PHST) requirements.

Rectifying task

A rectifying task is any support activity that resolves an issue, such as
failures, damages, special events, or thresholds.

Supporting task

A supporting task is a part of a complete rectifying or operational supporttask. Supporting tasks alone cannot rectify issues such as failures,
damages, special events or thresholds.

Task requirements
A justification illustrating the reasons and triggers for a task is necessary for each task. The
principle is to define a task requirement for each rectifying task and operational support task.
One of the main aspects is the approach of event-driven maintenance. A task requirement canrelate to an event identified by the corresponding supportability analysis activities. Failures,
damages, special events, and thresholds are the primary triggers for maintenance tasks, andeach has its specific chapter. Refer to Chap 7, Chap 8 and Chap 10. Additionally, some tasks
originate from other sources like operational support tasks to cover handling and servicing
requirements, software or data loading tasks, and disposal tasks. Refer to Chap 9, Chap 13 andChap 16. Finally, also directives issued by authorities or manufacturers (often in relation withwarranty issues), as well as law regulations (eg, environmental regulations) can justify tasks.
Sometimes, particularly when analyzing operational support tasks, it is not possible to clearly
determine it is a maintenance-relevant event or a general support requirement that justifies atask. For example, a task for towing an aircraft can have several different justifications ( task
requirements):−−−

towing out of the hangar to prepare for a mission
towing for refueling purposes
towing to the maintenance hangar in case of a failure

For proper documentation of the relationship between the justifying task requirement and therelated task, the S3000L data model has established a corresponding data structure. Refer toChap 19. Fig 1 shows an overview of the relationship between tasks and their associatedjustification.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

ICN-B6865-S3000L0049-003-01
Fig 1 Relationship between task requirements and support tasks
Task requirements can change during the product lifetime. The causes of such changes can beengineering changes, changes of the support environment or usage scenarios. For that reason,
both, task requirements and tasks can have several revisions over time in order to keep anappropriate traceability (refer to Chap 19).

3

Categorization of tasks
For task categorization, it is recommended to use a coding system, such as the information
code given in S1000D for technical publications (refer to S1000D).
Each information code has a clear definition in S1000D and enables an easier integration
between LSA and technical publications using S1000D. This avoids the need for a matrix toconvert LSA task coding and nomenclature to the coding and naming used within a technicalpublications system. This approach improves commonality, traceability, and therefore thequality of IPS.
There are appropriate verbs to identify activities clearly, and it is necessary to use them whendefining the information code for a special activity. If a more detailed information is available,
avoid the usage of general information codes. Table 3 shows some examples from S1000D that
also illustrate the generalization/specialization aspect for information codes.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

Table 3 Examples of S1000D information codes usable for task categorization
Information codes Information code definition
200

Servicing
210

Fill
212

Fill with oil

215

Fill with air

300

Examinations, tests and checks
310

Visual examination
312

500

Examination with a borescope
Disconnect, remove and disassemble procedures

520

Remove procedure
525

Ammunition unloading

4

Task documentation

4.1

General aspects

4.1.1

Tasks associated with breakdown elements or parts
Tasks are associated with LSA candidates. As described in Chap 3, LSA candidates can be
breakdown elements or parts. This means a breakdown element or a part (identified as an LSA
candidate) can have one or many associated tasks. If a task is associated to a breakdown
element, this often indicates it is necessary to perform the associated task on the Product. In
this case, the installation location is of crucial importance. For example, remove/install tasks are
typically associated to a breakdown element, because removal or installation of an equipment
always relates to the place where the equipment is located. Tasks associated with a part areoften performed on a part removed from the Product (eg, task to be performed on bench in aworkshop). In this case, the part is no longer associated with its use/installation within the
Product.

4.1.2

Level of task or task requirement association
Any task requirement or task can be associated to different levels of the Product breakdown.
The association of task requirements or tasks depends on the depth of Product breakdown andon the concept to associate a repair or a replace task or the corresponding task requirement.
Fig 2 provides an example of equipment used in this chapter for further explanation.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

ICN-B6865-S3000L0050-002-01
Fig 2 General equipment example
The example shows a simple breakdown of the "control computer" equipment. "Company A"
provides a part identifier for the equipment. It contains a part list with corresponding part
identifiers for each part, as provided by different companies.
Note
A part list is often referred to as a Bill of Material (BOM).
Theoretically, the assembled part (eg, the complete computer), but also components from thepart list of the assembled part, can meet the criteria to be a potential LSA candidate. From an
LSA point of view, there are different possibilities to associate tasks.
Since it is mandatory to consider the documentation of all LSA data associated with an LSA
candidate as a cost-intensive activity, it is recommended to restrict breakdown elements and/or
parts to be selected as an LSA candidate. Table 4 shows a typical either-or situation of LSA
candidate selection and corresponding task association.
Table 4 Task association with different levels of LSA candidates
Assembled part view

Part/component view

Assembled part (complete equipment)
selected as LSA candidate

Parts from the part list of the assembled partselected as LSA candidates

 one LSA candidate for task association

 many LSA candidates for task association

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Assembled part view

Part/component view

Consequence:

Consequence:

One or many maintenance tasks to be
exclusively associated with the assembled
part:

One or many maintenance tasks to be
associated with many single parts from theparts list:−

repair control computer by replacementof mainboard−

replace mainboard−

replace network card−

repair control computer by replacementof network card−

replace power supply

Note
The examples of Table 4 refer to the equipment example of Fig 2.
LSA candidate selection must follow a common philosophy within a project. The project specific
LSA GD must define and explain clearly when to use a repair or a replace task to describe
maintenance, as well as determine which breakdown level of the IUA is suitable to become an
LSA candidate.

4.2

Practical considerations
In reality, the situation is more complex than what is described in Para 4.1.2. Considering theexample in Fig 2, components in the assembled part can be repairable or discard items.
Therefore, a repairable part within an equipment can become an LSA candidate as well.
It is fundamental to determine the properties of equipment parts (including the equipment itself)with respect to reparability and maintainability. Table 5 shows typical properties of parts
concerning reparability and/or maintainability.
Table 5 Reparability and maintainability properties
Part properties

Consequences for reparability and maintainability

No corrective and/or
preventive
maintenance

A part that will not be repaired/maintained.

Corrective and/or
preventive
maintenance on
industry maintenancelevel only

An equipment/part that can only be repaired/maintained at industry
level.

Corrective and/or
preventive
maintenance on
customermaintenance level

A part that can be repaired at customer level.

In this case, a task requirement/task is only necessary if the requiredpart replacement is performed at customer maintenance level.
Replacing the part on or off the Product can determine the element of
the Product breakdown associated with the task requirement/task(breakdown element if on the Product, assembly part if off the
Product).

For such items, the detailed description only relates to theirreplacement (also refer to previous example). It is recommended to
identify the possibility of repair and/or any other maintenance (eg,preventive maintenance tasks) on industry level. Usually, a detailed
description of any corrective and/or preventive maintenance on
industry level within the LSA data is not required.

For such items, it is necessary to document the corresponding task
requirements/tasks for both corrective and preventive maintenancetasks. The LSA GC must clearly define level of technical detail for the
maintenance tasks.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

The properties of a part concerning reparability and maintainability depend on the events
influencing the items. There can be failures that lead to the disposal of the complete
equipment/part, while other failures will result in the need to repair the equipment/part. Although
being aware that a definitive decision is not always possible, it is necessary to analyze each
event to identify the relevant maintenance task and maintenance level to resolve the event.
Correction of some events can occur at several maintenance levels. In this case, it is necessary
to consider both the types of influencing events and the economic aspects. For example, aLevel of Repair Analysis (LORA) can lead to the replacement of the complete equipment (with afollow-on discard) due to economic aspects, although the equipment as such would be
repairable. Mixed scenarios are also possible. For example, a certain percentage of a specificfailure is rectified at customer maintenance level, and the balance will be returned to theindustry maintenance level because of capacity constraints at customer maintenance level.
Different deployment scenarios can affect the decision on whether to repair the element due tofacility and infrastructure requirements.
Note
The term "reparability strategy" indicates the final detailed decision on the method andlocation for equipment/ part repair.
In practice, there can be several different solutions concerning events that drive maintenance(especially failures), and the following required chain of corrective maintenance tasks can occur.
For better understanding, Table 6 gives an overview of typical examples. Additionally, further
examples are given in Para 10.
Table 6 Reparability strategy examples
Event

Corrective
maintenance task
(rectifying)

Potential
follow-on
taskConsequences of reparability strategy

Failure of a nonrepairable partwithin an
equipment

Repair equipment by Disposal of
replacement offaulty part
faulty part at
customer site

Non-repairable part is required as a spare part.

Failure of arepairable partwithin an
equipment, faulty
part is repairable
at customer level(case 1)

Repair equipment by Repair faulty
replacing faulty part part at
at customer site
customersite

Product is used before the completion of therepair of the faulty part.

Failure of arepairable partwithin an
equipment, faulty
part is repairable
at customer level(case 2)

Repair equipment by Nonerepairing faulty part
directly at customer
site

If the discard of the faulty part requires a
description, a specific disposal task will be
documented for the non-repairable part (as theappropriate LSA candidate).

The part itself is required as a spare part for the
repair of the equipment.
Components needed to repair the faulty part are
required as spare parts for the follow-on task.

Applicable to: All

Product is not used until the completion of therepair of the part.
The part itself is not required as a spare part for
the repair of the equipment.
Components needed to repair the faulty part are
required as spare parts.

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Event

Corrective
maintenance task
(rectifying)

Potential
follow-on
task

Failure of arepairable partwithin an
equipment, faulty
part is only
repairable atindustry level

Repair equipment by Forward
Repairable part is required as a spare part at
replacing faulty part faulty part to operational site.
at customer siteindustry
Documentation of repair on industry level is not
required.

Major failure ofequipment, no
repair possible,
faulty equipment
can be replaced atcustomer level

Replace equipment
at customer site

Discardfaultyequipment

Consequences of reparability strategy

Equipment is required as a spare part on
customer site.
If the discard of the faulty equipment requires a
description, a specific disposal task will be
documented against the equipment (as theappropriate LSA candidate).

Depending on additional aspects (eg, competences at the different maintenance levels, scrap
rates of parts, Product waiting for repair or not), there are multiple ways to influence thesequence of activities. The examples clarify the need to summarize maintenance tasks within alimited number of LSA candidates. Possibly, several follow-on tasks on higher maintenancelevels do not require a detailed analysis. The only aspect that can be important is theiridentification.
In most cases, two task types can resolve equipment failure:−−

replacement of the entire equipment (represented by a specific breakdown element)
repair of equipment by replacement of parts (as a follow-on task)

Another important aspect is that not every replace task can be performed at a customer site.
For this reason, it can be necessary to transport the complete Product to industry to replace
specific equipment. In this case, a task requirement/task for the transportation of the entire
Product is required.

5

Task structureThis paragraph reflects a common understanding about how to create a proper task structure. It
is necessary to take into account aspects such as the categorization of tasks, establishing ahierarchy of tasks and subtasks, and reuse of information within already existing tasks with thehelp of references.
Note
There are different potential solutions to document the content of a task. Documentation oftasks depend on the methodology used by the analyst. For example, it is possible to reduce
the repair of an equipment to the pure repair activities just relevant for the equipment
already tested and removed from the Product. It means "ready for repair" in the repair shop.
However, the repair task (eg, gain access, remove/reinstall equipment, test, undo access)can also include the preparation before the actual repair.

5.1

Task classification
The fundamental approach is to divide the tasks into three different task classes:−−−

rectifying tasks ("the event solver")operational support tasks
supporting tasks

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

One or more task requirements drive each rectifying task or operational support task. In thecase of a rectifying task, the task justification is typically an event. Such event can be a failure, adamage, a special event, or an expired threshold/time-limit. A maintenance task will resolvethese events. Each task that can resolve such an event can be defined as a rectifying task.
Typical examples for rectifying tasks are given in Table 7:
Table 7 Typical rectifying tasks for typical events
Event

Rectifying tasks

failurerepair or replace tasks

damagerepair or replace tasks

special event

inspection tasks

thresholdpreventive maintenance tasks

The same holds for an operational support task, which typically resolves a concrete task
requirement in the context of Product operational support (eg, need for preparation fortransportation in the case of Product deployment).
As opposed to a rectifying task, a supporting task cannot resolve an event. However, also
operational needs can cause specific activities that belong to the group of supporting tasks froma technical point of view. Typical supporting tasks are:
−
−
−
−

5.2

test tasks
gain access/undo access tasks
remove and install tasks
assemble and disassemble tasks

A simple rectifying task
Fig 3 provides an example of a repair task of the equipment (control computer with part
identifier A-001, refer to Fig 2). The example illustrates subtasks performed one after the other,
without any reference to already existing supporting tasks.
The examples in this chapter provide a good understanding of task organization. This chapter
should stimulate the use of different approaches to organize tasks. There are different methodsof focusing on the pure activity and to separate, for example, preparation and close-up
subtasks, or to include activities into a rectifying task (eg, fault location, gain access, remove,
install, undo access, and test after reinstallation). It depends on the methodology determined in
the LSA GD for the specific project. S3000L does not mandate one specific methodology as the
only possible one.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

ICN-B6865-S3000L0144-001-01
Fig 3 Simple rectifying task without references
Note
Product operation does not restart until the repair is complete.
Note
It is important to determine the LSA candidate relevant to the task. For the entire repair, therelevant LSA candidate is the equipment as a part (independent from the installation
location before the removal). For the removal and installation of the equipment A-001(subtasks 3 and 8), the installation location is the relevant information. In case of multiple
installations of the equipment A-001 within the Product, the essential information is theinstallation location, as well as the installed part. In fact, it can be possible to install different
parts from different manufacturers at the same installation location. Precondition is that theparts have the same form, fit, function, and interface. However, removal or installation tasks
can be slightly different if there are different realizations. In this case, it is recommended to
introduce independent tasks for the installation location and determine the applicability forthe different methods for the removal or installation of different parts.
The example of Fig 3 contains subtasks that can consist of several steps, for example theremoval of the equipment A-001. Additionally, there are subtasks not directly associated to theequipment A-001, but to other potential LSA candidates (eg, cover 1 or cover 2), which can be
represented by a breakdown element or a part.
All subtasks within the rectifying task above, which can be subdivided into further steps and/or
associated to another LSA candidate as the actual IUA (here the equipment A-001), are typicaltask portions of a rectifying task. They can be moved to a supporting task and later referenced
to from the rectifying task.
There are some criteria to identify subtasks that can be moved to a supporting task. The mostimportant aspect is whether other rectifying or operational support tasks can potentially reuse
the supporting task, too. A typical example is a cover that must be removed to gain access to a
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

set of different equipment behind it. In this case, this removal task is a typical candidate tocreate a supporting task for the removal of the cover against the cover as the corresponding
LSA candidate. Task portions associated to the IUA can also be candidates to be moved to asupporting task. For example, removal of the equipment A-001 can be reused in several
different use cases (eg, in a repair or replace task of the equipment itself), but also in thecontext of another equipment which needs the equipment A-001 to be removed to gain access.
Taking into consideration the aspects above, a set of subtasks from Fig 3 can be identified astask components, which can be potentially moved to a supporting task, as illustrated in Fig 4.

ICN-B6865-S3000L0145-001-01
Fig 4 Task components suitable for creating a supporting task
Note
Subtasks 5 and 6 are not suitable for creating a supporting task. The removal of thedefective mainboard occurs only once in the context of the analyzed repair task. This
subtask will not occur in any other context. The MTA philosophy of S3000L defines this kindof subtasks as "subtask by definition", whereas referenced supporting tasks are "subtask byreference".

5.3

Supporting tasks
With the help of supporting tasks, the analyst can create a "library of task portions" that, if
necessary, helps supporting the creation of more extended rectifying or operational support
tasks. It is also possible to divide supporting tasks into subtasks.
Fig 5 shows an example of the organization of the remove task for equipment A-001 in its
installation location, with the indication of the corresponding Breakdown Element Identifier(BEI).

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

Fig 6 shows an example of the organization of the remove task for cover 1. This task does not
relate to the IUA, but to cover 1 and its installation location (eg, BEI: PRD-A-52-01-04, and thepart identifier for cover 1: C-091A).

ICN-B6865-S3000L0051-003-01
Fig 5 Example of a supporting task associated with the IUA itself

ICN-B6865-S3000L0052-002-01
Fig 6 Example of a supporting task associated with an LSA candidate different from IUA
Note
The tasks shown in Fig 5 and Fig 6 can equate to a procedural data module. Refer to
S1000D.

5.4

Structure of a rectifying task - referencing method
After the creation of a library of supporting tasks, the next step is to organize the rectifying or
operational support tasks, accordingly. Fig 7 illustrates the use of subtasks by definition andsubtasks by reference within a rectifying task. In this example, the rectifying task relates to therepair of the equipment A-001 from Fig 3, which includes subtasks by reference and subtasks
by definition. There are several subtasks within this repair procedure. Other LSA candidates
already describe some of these subtasks (eg, the removal of cover 1, refer to Fig 6). Some ofthem are already described within the same LSA candidate (eg, the removal of the equipment
itself, refer to Fig 5). Using references avoids the repetition of the detailed description of single
steps within the rectifying task.
Note
As a general recommendation, do not use copies of existing task structures within the LSA
data.
Different tasks can reference the supporting tasks many times within a project. Therefore, for
updating reasons, the LSA data must document the original information only once. In case ofmodifications of the supporting task, it is necessary to produce the changes only once.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

ICN-B6865-S3000L0053-003-01
Fig 7 Typical rectifying task - repair procedureFig 7 shows a typical arrangement of a rectifying task. There are both subtasks by definition andsubtasks by reference within the sequence of the entire repair task. In an extreme case, arectifying task can contain only references to existing supporting tasks.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

Note
It is generally recommended to use references for all activities that do not change,
regardless the location and frequency of installation of the IUA on the Product (eg, when
the item is removed from the Product, disassemble or assemble tasks are usually thesame). On the other hand, installation and removal tasks can be different if the installationof the item occurs in several locations within the Product. It is necessary to decide case bycase whether it makes sense to create a supporting task for remove or install activities. It
depends on whether it is possible to reuse these tasks (or parts of them) in other tasks, forexample in case the removal of a part is required in another context.

5.5

S1000D integration considerations
If there is a need to populate S1000D procedural data modules based upon LSA data, it isnecessary to consider some aspects:
A set of preconditions can need consideration in order to perform a task, and they are of special
interest for technical publications. It is required to document preconditions concerning safety inthe preliminary requirements section of procedural data modules. The following aspects can be
included:−

general preconditions:This area describes the general preliminary work to be carried out in order to achieve thenecessary conditions to start the actual task.

−

safety preconditions:This area covers all aspects necessary to achieve conditions to carry out the task in a safe
environment (warnings and cautions).

−

personnel preconditions:This area covers all aspects related to personnel. This includes the requirement for
additional skills or certifications to perform the task, as well as the need for specificpersonnel requirements to comply with safety regulations (eg, the need for personal
protective equipment to perform the task).

The sequence of the complete maintenance task (supporting or rectifying) must include ascorresponding subtasks all activities necessary to reach the required preconditions. It is also
possible to classify those subtasks by assigning them a specific subtask role (eg, by a roleprecondition). Refer to Chap 22.
Another aspect is the identification of startup and close-up activities. Within extended repair or
replace procedures containing several subtasks, the preparation of equipment repair or
replacement (eg, gain access or fault location procedures) can require several subtasks. The
same applies to close-up activities, which do not belong to the actual repair or replace task, butmust be performed to complete the maintenance task (eg, cleaning of support equipment,
paperwork). It is also possible to classify those subtasks by assigning them a specific subtask
role (eg, the startup or close-up role). Refer to Chap 22.

5.6

Narrative description
The narrative description of a maintenance or operational procedure is primarily a matter oftechnical publications. For this reason, it is mandatory to avoid performing the same activity
twice. An extended description of a task within the LSA is not desirable. It is possible to provide
a short description of the subtasks, using a brief wording. The LSA must identify the required
support activities and analyze the identified tasks. The use of narrative texts from the LSA data
as a draft for technical publications must undergo verification. Technical publications must
usually observe strict rules concerning language, formatting and layout.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

6

Task frequency
The expected frequency of the analyzed task is an important piece of information concerning
tasks. Knowing how frequently a task must be performed each year is crucial for planningsupport resources. The task frequency often relates directly to the frequency of the triggering
event. It is possible to foresee the frequency of some events, while some other events need touse statistic methods to estimate their frequency.

6.1

Maintenance tasks due to inherent equipment failures
Equipment failures statistically occur based on a KPI called the Mean Time Between Failure(MTBF). This value indicates the average elapsed time between two failures of an equipment. It
is possible to use a simplified formula to predict the frequency of a rectifying task, assuming a
constant MTBF over the entire usage time and a single installation of the equipment:𝑘

𝑇𝐹𝑟𝑒𝑐 = ∑ 𝐹𝑀𝐷𝑅𝑖 ∙
𝑖=1

𝐴𝑂𝑅
∙𝜆
∙𝜆
𝑀𝑇𝐵𝐹 𝑐𝑜𝑟𝑟 𝑀𝐵

Table 8 Formula symbols (task frequency of rectifying tasks based on failures)
Formula symbol

Explanation

𝑇𝐹𝑟𝑒𝑐

Frequency of the rectifying task (1/year)

𝐴𝑂𝑅

Annual Operating Requirements (AOR)
For equipment in continuous operation, AOR is 8760 hours per year. AOR
can also have a different measurement basis (eg, driven distance inkilometers or number of cycles instead of operating hours).

𝑀𝑇𝐵𝐹

Mean Time Between Failure
Typically, operating hours are the measurement basis of the MTBF, butthere can also be a different (eg, driven distance in kilometers or numberof cycles instead of operating hours).

𝐹𝑀𝐷𝑅

Failure Mode Distribution Ratio
Several parts inside an equipment can cause the failure of the equipment.
Each part/component within the equipment can be responsible for the
failure of the whole equipment, with a certain ratio.

𝜆𝑐𝑜𝑟𝑟

Correction factor for MTBF (in case of special conditions at special
installation areas). This correction factor can differ at each installation
location of equipment, and can be especially relevant in the case of amultiple installation of equipment.

𝜆𝑀𝐵

Correlation factor in case AOR and MTBF have different measurement
bases (eg, in case of a vehicle, the measurement basis for MTBF iskilometers instead of operational hours).

𝑖Index for the identification of the FMDR of the single failure mode within
the analyzed equipment.

𝑘Number of different failure modes that are likely to accumulate.

The formula above can be considered a simplified option. It is possible to add the correction
factor 𝜆𝑐𝑜𝑟𝑟 to consider the need for correction (eg, due to environmental conditions which
influence the reliability of the IUA). It is possible to use correlation factor 𝜆𝑀𝐵 to consider

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

different measurement bases for AOR and MTBF. In case corrections or correlations are notnecessary, both factors equal 1.
Note
Within the LSA GC, the customer and contractor must harmonize and determine any
correction or correlation factor to be used in a project.
A more complex formula that takes into account other influence factors allows calculating task
frequency more precisely. The influence factors include:−−−−

no failure found factors (eg, a built-in test cannot duplicate the failure)
if the MTBF is not constant, but is a function of time MTBF(t), it is necessary to use integral
calculationdifferent types of MTBF (eg, predicted, allocated, measured) to be selected
correction required because of induced failures

The MTBF is particularly interesting when analyzing different types of equipment. The
distribution of the MTBF value over the entire life cycle of equipment can have a different
behavior depending on the type of equipment. MTBF values can change over the life cycle ofequipment. For example, a mechanical equipment with deterioration effects shows a different
behavior than an electronic equipment. Reliability analysis activities will perform suchexaminations. Mathematical functions help describing in detail different failure distribution
behaviors as a function of time. In this context, refer to special literature concerning reliability.
In case of multiple installation of equipment, it is recommended to calculate the task frequencies
for each installation location separately. It is possible to summarize the calculated single task
frequencies for a required accumulation of task frequencies (eg, for maintenance tasks being
performed in a special repair shop). Depending on the installation area, the frequency of the
failure of equipment can be significantly different.

6.2

Task frequency for supporting tasks
It is not possible to calculate a task frequency for supporting tasks the same way as forrectifying tasks. Usually, there is not a direct link between supporting tasks and any event likerectifying tasks. However, rectifying tasks normally call supporting tasks by using references. By
adding the task frequencies of the referencing rectifying tasks, it is possible to use the simplified
formula below to calculate an accumulated task frequency of any supporting task:𝑛

𝑇𝐹𝑠𝑢𝑝𝑝 = ∑ 𝜆𝑄 ∙ 𝑇𝐹𝑟𝑒𝑐,𝑖𝑖=1

Table 9 Formula symbols (task frequency of supporting tasks)
Formula symbol

Explanation

𝑇𝐹𝑠𝑢𝑝𝑝Task frequency of the supporting task (1/year)

𝑇𝐹𝑟𝑒𝑐,𝑖Task frequency of the referencing rectifying task (1/year)

𝜆𝑄

Number of "calls" of the rectifying task for the supporting task to be
calculated𝑖

Index for the referencing rectifying tasks𝑛Number of the referencing rectifying task

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

Since different rectifying or operational support tasks can reference a supporting task, thecalculation of a task frequency for the supporting tasks can be interesting for statistical figures
used to:−−identify maintenance drivers to be assessed for potential improvement of design
quantify maintenance tasks depending on the actual use/maintenance of an item

Example: Opening and closing of covers
Different rectifying tasks from many different LSA candidates can reference several times theremove and install tasks of a cover. It can be important to know the frequency of
installation/removal of a cover within one year, because of the potential need for some spareparts after a certain number of remove and install tasks. Inherent failures or actual damage that
require the removal or installation of the cover usually constitute only a small fraction of theactual removal and installation activity. Many cases result from the need to gain access to otherequipment behind the cover.
Because of a frequent removal and installation of a cover, the design must be user friendly (eg,use of quick release fasteners) and damage tolerant.
Note
Different types of events, which potentially can have impact among themselves, can trigger
the referencing tasks. For example, a failure or a PMTRI can trigger the replacement of an
item. As a consequence, a corrective replacement (with the interval being reset after
corrective replacement) influences the task frequency of the preventive replacement. Refer
to Para 6.5.

6.3

Maintenance tasks due to damages or special events
It is not possible to predict equipment failures for other reasons in the same way as described in
Para 6.1. In fact, it is only possible to make an estimate of the task frequency. If there is any
experience concerning the occurrence of damages or special events, for example with the helpof statistical investigations, the results provide an estimate of the frequency of these
unpredictable events and the corresponding maintenance tasks.
However, it is difficult to forecast the frequency of these events, it is important to get an estimatebased on the best information available. All maintenance tasks triggered by these events havetheir corresponding requirements concerning material and personnel. It is necessary to take into
account these unpredictable events to estimate the resources and the capacity utilization.

6.4

Preventive maintenance tasks
In the case of preventive maintenance tasks with repeated time limits (often referred to asinterval), no additional calculation or estimation is required, because the corresponding PMTRIand a later packaging of preventive maintenance tasks (refer to Chap 10) determine the intervalof the maintenance activity.
It is possible to convert repeated time limits to task frequency values based on how often theyoccur per year. It is necessary to relate each interval determined with a specific measurement
basis value to the annual operating requirements. The following simple formula calculates thetask frequency:

𝑇𝐹𝑠𝑐ℎ𝑒𝑑 =

𝐴𝑂𝑅
𝑇𝐿𝑟𝑒𝑝

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

Table 10 Formula symbols (task frequency scheduled maintenance tasks)
Formula symbol

Explanation

𝑇𝐹𝑠𝑐ℎ𝑒𝑑Task frequency of a scheduled task (1/year)

𝐴𝑂𝑅

Annual operating requirements
For equipment in continuous operation, AOR is 8760 hours per year. AOR
can also have a different measurement basis (eg, distances or number ofcycles instead of operating hours).

𝑇𝐿𝑟𝑒𝑝

Repeated time limit (same measurement base as AOR)

Note
Preventive maintenance can use a more complex structure to determine different
thresholds, intervals and triggers for a scheduled maintenance task (refer to Chap 10). In
this case, it is often impossible to calculate a simple task frequency value.

6.5

Task frequency of replacement tasks
A specific situation concerning task frequency can occur if different types of events can trigger atask. A typical example for this situation is the replacement of an equipment, as there can bevarious triggers, including:−−−replacement of equipment with a new one due to a failure or a damage (and due to therequired high availability of the complete Product, which means the Product cannot wait foran equipment repair)
replacement of the equipment because of a limitation by authorized life
replacement of the equipment after a certain time limit due to a PMTRIIn this case, a simple mathematical formula is not suitable to calculate the final task frequency,
because the different characteristics of the replacements can have impact among themselves.
For example, an unscheduled replacement due to an equipment failure will have an impact on
the preventive maintenance task with a fixed interval, because it is necessary to reset thedetermined interval.

7

Task resources

7.1

General aspects
The identification of task resources for all identified tasks is crucial in defining the maintenancesolution and supporting the planning for a timely provisioning of all task resources. Task
resources can be:−−

personnelmaterial•
spare parts•consumables•
raw material•
support equipment (eg, special tools, handling equipment, test equipment, storage ortransport containers, standard hand tools)−−

facility/infrastructure
documentation

During the development of a Product, material task resources such as support equipment andfacility/infrastructure, are often developed in parallel. In this case, the MTA can identify the needfor a resource, which normally leads to the creation of a specification document including therequirements for the identified resource. LSA data can document this to indicate the identified
task resources, and confirm the provisioning process has started by creating a task resource
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

specification (material resource by specification, refer to Chap 19). After the completion of thedevelopment and/or provisioning process for a specified task resource, the concrete material or
facility/infrastructure resource can be documented in the LSA data and it is possible to relate itto the corresponding resource specification.

7.2

Task resource assignment
It is necessary to assign the task resources at the relevant level within the task itself. Generally,a user of a maintenance documentation must be able to identify the need for a resource within
the sequence of the task. With respect to training, it is interesting to determine which personnel
needs appropriate competence to use and/or operate a special support equipment. The
principle of the structure of tasks (refer to Para 5), which can be organized by subtasks
including references to supporting tasks, determines resources allocation. It is recommended tofollow the basic principle that each resource is linked to the activity that requires that resource.
In general, the S3000L data model allows analysts to assign task resources to the complete
task or to a subtask within a task. Refer to Chap 19. However, it is required to determine theconsequences of a resource assigned to the entire task.
−−

Is the resource valid for all subtasks (including subtasks by reference) within the task (eg,assigning personnel resources at task level)?
Is the resource the result of an aggregation and consolidation of resources coming from
subtasks (by definition and by reference)?

For a clear understanding, it is recommended to establish appropriate business rules, forexample within the LSA GD.
Table 11 gives an overview of potentially typical assignment methods for task resources.
Table 11 Assignment of task resources
Task resource

Assignment aspects

Personnel task
resources

Personnel is assigned to the subtasks that require it. If the complete
task requires the same personnel, it is possible to assign it to thetask instead of each single subtask (as determined by specificbusiness rules).

Material task resources - Spare parts and consumables are typically assigned to subtasks,
spare parts andwhere they are required.
consumables
As an alternative, an aggregation and consolidation approachallows spare parts and consumables to be assigned to the completetask. Specific business rules must determine this approach.
Material task resources - Raw material is typically assigned to subtasks, where it is required.
raw material
Often the raw material can be assigned to those subtasks, where
the preparation is performed before finally install the modified raw
component into the Product.
As an alternative, an aggregation and consolidation approachallows raw material to be assigned to the complete task. Specificbusiness rules must determine this approach.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

Task resource

Assignment aspects

Material task resources - Support equipment is typically assigned to the subtask that requires
Support equipment
it. If the complete task requires support equipment, it is possible toassign it to the task instead of each single subtask. Specificbusiness rules must determine this approach.
Note
Support equipment indicates tools or test equipment. However,
it is necessary to consider also support equipment for
operational support like transport or storage containers, fixation
belts or ground-handling devices for an aircraft (eg, a towing
bar for aircraft).
It is also possible to add information about which personnel uses oroperates which support equipment. Within complex subtasks,
different people can use different pieces of support equipment. For
training requirements, it must be possible to associate support
equipment with the relevant personnel resource.
Facilities andinfrastructure task
resources

Facilities and infrastructure are typically assigned to a complete
task.

Document task
resources

A document task resource identifies a document (including digital
documents) to be filled out in the context of a close-up paperwork.
Note
Typical task resources usually do not include the required
technical publications (eg, maintenance manuals) that support
the performance of a task. The document assignment
mechanism must assign those documents to the relevant
task/subtask. Refer to Chap 19.

It is necessary to summarize and harmonize all resources from the subtasks and referenced
supporting tasks at complete task level. LSA data evaluation or reports concerning the different
resources (or even for all resources in one report) can provide this summary. Fig 8 provides anexample.

ICN-B6865-S3000L0054-003-01
Fig 8 Example of task resources assignment at subtask level

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00

Table 12 summarizes the resources of the install procedure from Fig 8 at task level.
Table 12 Aggregation of task resources
Resource type

Resource

Quantity

Spare parts

Seal

1

Washer7

Consumables

Adhesive C

as required

Support equipment

Torque wrench

1Phillips screwdriver, size 2

1Electrician (basic)

2

Personnel

Note
It is necessary to distinguish each individual performing a task from one another. The
simplest differentiation is just indicating the number of persons, for example: person A,
person B, person C, etc. Additionally, it is possible to specify the role of a person within atask, for example the performer, the helper, the supervisor, the auditor. These two
indications can be used together, for example: performer A, performer B, etc. The
corresponding business rules must address the use of role classification. Additionally, thevalue of personnel labor time can exceed the task duration if two or more people work
simultaneously on the same subtask (refer to the first subtask in Fig 8).

7.3

Resources out of references
When using the methodology of referencing supporting tasks, it is necessary to take into
account that the referencing task will include the resources of the referenced tasks. At firstglance, this seems to be an appropriate approach. However, this approach can result in a false
estimate of personnel requirements. Personnel with a lower competence usually performs
simple subtasks (eg, the removal of an access panel). Therefore, simple supporting task usuallyindicate this type of personnel. In case a person with a higher qualification performs an
extended repair or replace task that references the supporting task, it is necessary to consider
that it will be very likely for the person with a higher qualification to perform the referenced
supporting task as well. The corresponding business rules must determine how to handle thissituation and how to document a potential change of personnel within a referenced supportingtask. It is also possible to use the definition of competences, which include other competences.

8

Task location aspects
It is possible to distinguish different location information types to cover all aspects concerning
the location where task performance occurs.

8.1

Location in conjunction with maintenance level
The most general information is the determination of a maintenance level. This indicates
whether a task performance occurs on customer site or on industry site. It is necessary to define
at an early stage the number of maintenance levels valid for the project (especially on customerside), and this information will be later used within a LORA. Refer to Chap 11.

8.2

Location in conjunction with the Product itself
It is possible to align the location of a task in conjunction with the Product with the S1000D data
element Item Location Code (ILC). The terms on- and off- tasks indicate the location of themaintenance activity with regard to the Product. An on-task concerning location means that theactivity is performed directly on the Product (eg, in or directly at an aircraft). A removal task ofan LRU is always an on-task, because the LRU is always removed directly from the Product. A

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00

typical example for an off-task concerning this type of location is the disassemble task after theremoval in a special maintenance shop.

8.3

Location in conjunction with the required facility
The attribute of a required facility is another piece of information concerning location of a task.
In addition to the maintenance level from Para 8.1 and the on- and off- information from
Para 8.2, the required facility is another typical attribute assigned at task level. The selection ofa facility object as the location of a subtask does not automatically fix the location information
concerning on- and off-activities. Examples for facilities are:
−
−
−
−

8.4

individual workshops such as electronic shop or engine shop
maintenance hangar
dockyard
clean room

Location in conjunction with a Product zone
If the Product is divided into physical areas (zones), this information serves as additional
information on the location of task performance. In this case, the location aspect relates to thelayout of the Product. The information helps estimating the amount of activity within each zoneof the Product. This can influence design, for example by making it easier to access a zone
where maintenance tasks frequently occur.
Note
The use of information concerning zones helps documenting the result of a zonal analysis
in conjunction with preventive maintenance. In this case, it is possible to document zones
using non-hardware breakdown elements. The identified PMTRI and the corresponding
tasks can be associated with the zonal breakdown elements (refer to Chap 4 and Chap 10).

9Additional aspects for tasks

9.1

Product availability during maintenance performance
The impact of maintenance tasks on the operability of the Product is another important piece of
information concerning the Product and different systems within the Product. Examples ofimpacts include, but are not limited to:−

Product/system inoperable during equipment maintenanceIn this case, the Product/system cannot be used during, for example, a repair procedure oran inspection. The Product/system must wait until the completion of the maintenance task
before it is available again. A typical situation can be the removal of a defective component
and the repair of the defective component (eg, in a special maintenance shop). After the
successful repair, the repaired component will be reinstalled into the Product. During theentire repair activity on the defective component, the Product/system operation is on hold.

−Product/system operable during equipment maintenance with reduced capability
In this case, it is possible to use the Product/system during, for example, a repair procedureor an inspection with reduced capability (eg, a specific subsystem is not available during
maintenance, but the rest of Product is fully operational).

−

Product/system operable during equipment maintenanceIn this case, it is possible to use the Product/system with full capability during a repair
procedure or an inspection. A typical example can be a visual inspection task of someequipment during full operation. For the inspection, there is no need to interrupt theoperation or the mission.

Note
The data element taskOperabilityImpact in Chap 22 provides concrete examples forclassification values to describe Product availability during maintenance tasks.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00

9.2

Tasks and applicability
Maintenance or operational support tasks can vary depending upon the conditions during task
performance. The task itself can be nearly the same but require different or additional support
equipment, or it can be slightly different from the original one. In this case, it is recommended tocreate different tasks to document the different "solutions" for the different conditions in whichtask performance occurs. It is possible to assign the different solutions to specific applicability
statements. The following list gives a set of examples for the creation of corresponding
applicability statements for different solutions for specific tasks:
−
−
−
−
−

performance of the task under different environmental conditions (eg, under tropicalconditions or under arctic conditions)performance of the task at a different location (eg, out of the area or in a workshop)
performance of the task for another customer with different preconditions concerning
personnel and equipment available at the operational site
performance of a repair task to provide a permanent repair or a temporary repair
performance of a task under peace time or war time scenarios

Note
LSA data can include applicability statements as described above, which can also be
forwarded to technical publications. Refer to S1000D.

9.3

Task duration
Information on the duration of the task provides an overview about the capacity utilization of
personnel and material resources. Within the task, it is necessary to separate the duration of atask and the working time of the personnel (also called labor time). Table 13 explains thedifference between task duration and labor time.
Table 13 Task duration and labor timeTime

Description

Task duration

Duration of the entire task. The duration documentation can relate toeither the entire task or the single subtasks. It is possible to calculate
the duration of the entire task as a proper accumulation of durations
coming from the subtasks including referenced supporting tasks andtaking into account parallel activities. Refer to Para 9.4.
Note
The term Mean Elapsed Time (MET) is also commonly used fortask duration.

Labor time

Accumulated time of personnel work. It is possible to document thistime in relation to either the entire task or the single subtasks. If morethan one person is working at the same time on a task/subtask, it isnecessary to sum the labor time of all persons, taking into account thedifferent competences of each individual.
For example, three people with the same level of competence areworking in parallel on a subtask, which takes 20 minutes. In this case,the documentation includes the following data:
Subtask duration: 20 minutes
Labor time:

60 minutes

Regarding times/durations of tasks, it is necessary to consider the type of documented duration.
The time doing the job is often the only documented type of duration. This means that all nonproductive activities (eg, paperwork) are usually not included. To take into consideration nonproductive times, it is possible to make an estimate in the LSA data.
Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

Another aspect is the consideration of logistics delay times. LSA usually does not document any
delay caused by waiting times for support resources (eg, support equipment or facilities not
immediately available, waiting for personnel, waiting for material). To take into consideration
logistics delay times, it is possible to make an estimate outside the LSA.
Note
Task duration must include the waiting times caused by integral parts of a maintenancetask (eg, the curing of material or the drying of paint), which are therefore not considered
the same way as non-productive times or logistics delay times. The same holds for an
authorized inspection which is mandatory before moving to the next step of the completetask. These easily predictable task portions can be documented within a task as a subtask
with its specific duration and support resources.

9.4

Parallel activities within tasks
It is necessary to consider the simultaneous performance of subtasks in more complex
maintenance or operational support tasks that contain many subtasks performed by different
people. Activities occurring simultaneously influence the duration of the complete task, as wellas the task resources concerning support equipment and personnel. Refer to the example in Fig
9:

ICN-B6865-S3000L0055-002-01
Fig 9 Parallel activities and their resources/durations
Subtask ST5 is simultaneous to ST3/ST4 and requires the support equipment SE A and SE B.
For subtask ST5, it is possible to use the same support equipment as in subtask ST2, because
these activities are not performed in parallel. The consequence for the complete task is therequirement of one piece of support equipment SE A. The situation is different for support
equipment SE B. Subtasks ST4 and ST5 occur simultaneously and both require SE B. Thismeans two pieces of support equipment SE B are needed for the complete maintenance task.
The situation is similar for personnel as well. The person with the basic mechanic qualification isrequired for subtasks ST3 and ST5, occurring simultaneously, as well as for ST7 and ST8. Thisrequires an additional person P3 with the same qualification as person P1.
Table 14 shows the differences between a simple approach using a sequential methodology (ie,one subtask after the other) or the possibility of simultaneous activities.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 26

S3000L-B6865-03000-00

Table 14 Comparison of resources for sequential or parallel subtasks
Step by step sequence

Parallel activities

Task duration: 35 min

Task duration: 20 min

Support equipment requirements:
SE A: 1

SE A: 1

SE B: 1

SE B: 2

Personnel requirements:
Mechanic basic:

1 (P1)

Mechanic basic:

2 (P1 and P3)

Mechanic advanced:

1 (P2)

Mechanic advanced:

1 (P2)The S3000L data model allows documenting both the parallel and sequential performance ofsubtasks. Refer to Chap 19. In addition to the simple attribute of a subtask duration, it ispossible to use a timeline construct to document parallel activities, with a clear indication of thestart and the end of each subtask. Additionally, a timeline leg is defined, for example, for waitingtimes before the dependent subtask can start. In this context, LSA data evaluation can help
create a draft version of a working plan, for example by obtaining a graphic schedule of amaintenance task directly from the LSA data.

9.5

Training requirements
Information on the level of competence of personnel performing any task documented in the
LSA data can provide the basis for the identification of training requirements. In this context, it
must be distinguished between special training needs and training needs covered by normal
professional education. However, especially in many international projects, education andpotential certification in each nation can make it difficult to identify general training needs valid
for each individual customer and/or Product operator.
To support TNA there is a need to document special training requirements to perform amaintenance or operational support task. For this reason, the task analysis must consider therequirements at subtask level (eg, the use of a complex support equipment that requires
training), as well as at task level, to assess the complexity of the task as a whole. The aspects
under consideration are:
−
−
−
−
−
−
−
−

the section or department in charge of the task
the selected skill level of personnel performing the subtask
the need for team training due to the complexity of the task
the use of special support equipment that requires training
required special training to perform the task/subtask
required training methods
required experience to perform the task/subtask
the complexity of the task as a whole

The information concerning training can be collected at task or subtask level. At subtask level, it
is possible to analyze each activity in detail and to assign special support equipment to theperson performing the activity. Training information collected at task level is valid for all
subtasks (eg, determination of a general competence required for the task).

9.6

Circuit breaker settings
The correct setting of circuit breakers is often an important part of a subtask, or even a subtask
in itself. It can be necessary to set several circuit breakers in a specific sequence. In the
S3000L data model (refer to Chap 19), it is possible to assign the circuit breakers and thecorresponding settings (including the sequence) to a concrete subtask. This helps inApplicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 27

S3000L-B6865-03000-00

determining the important preconditions concerning circuit breakers to perform the subtask in asafe condition.

10

Examples for different maintenance solutions
The following examples provide a better understanding on how to assign tasks to thecorresponding LSA candidates and how to document the different maintenance solutions. The
equipment (control computer) which is used for the examples is illustrated in Fig 10. The
complete control computer is installed in a land vehicle and is represented by a breakdown
element within the Product breakdown of the vehicle. The realization of the breakdown element(BEI = PRD-A-46-01-01) is done by the installation of the control computer with a part identifier
A-001.

ICN-B6865-S3000L0050-002-01
Fig 10 General equipment example
The following examples also provide a better understanding about how different frame
conditions or requirements given by operational needs of the operator can influencemaintenance tasks. The examples illustrate the diversity of maintenance solutions and thecorresponding tasks. They go from a rather simple situation like an equipment replacement toan extended situation with several activities at several maintenance levels.

10.1

Example 1: Major failure, computer case broken
Event:
Complete malfunction of the control computer due to a broken computer case after a heavy
shock. No repair possible, the complete control computer must be replaced.
Special operational requirements:
None
LSA candidate:

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 28

S3000L-B6865-03000-00

Control computer (breakdown element)
Rectifying maintenance task for the event:Replace the control computer at its installation location. Refer to Table 15.
Table 15 Subtasks for example 1
Step

Description

Maintenance level/task location

1

Remove the faulty control computer

Customer's vehicle workshop

2

Install a new control computer

Customer's vehicle workshop

3

Test the new control computer

Customer's vehicle workshop

Potential follow-on tasks after the rectifying task:− disassemble faulty control computer to recycle reusable components− disposal of all components which cannot be recycled

10.2

Example 2: Failure of the mainboard, case 1
Event:
Failure of the mainboard, the specific failure is not repairable by changing components on the
mainboard.
Special operational requirements:
None
LSA candidate:
Control computer (part)
Rectifying maintenance task for the event:Repair control computer by replacement of mainboard. Refer to Table 16.
Table 16 Subtasks for example 2
Step

Description

Maintenance level/task location

1

Remove the faulty control computer

Customer's vehicle workshop

2

Disassemble the faulty control computer

Customer's computer workshop

3

Remove the faulty mainboard

Customer's computer workshop

4

Install a new mainboard

Customer's computer workshop

5

Assemble the control computer

Customer's computer workshop

6

Test the control computer in the workshop

Customer's computer workshop

7

Install the repaired control computer on vehicle

Customer's vehicle workshop

8

Test the function of control computer after
installation on a vehicle

Customer's vehicle workshop

Potential follow-on tasks after the rectifying task:− disposal of the mainboard

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 29

S3000L-B6865-03000-00

Note
It is also possible to include only subtasks 2 to 5 in the repair task, as the other subtasks do
not relate directly to the pure repair activity. All tasks related to preparation or close-up canbe regarded as not being relevant for repair. In this case, it is necessary to document the
preparation (eg, remove equipment) and close-up activities (eg, test in workshop,
installation, further test at the installation location) as separate tasks, and link them to acorresponding task requirement. The adopted methodology will determine how to organize
the different types of tasks. This is also valid for all examples in Para 10.

10.3

Example 3: Failure of the mainboard, case 2
Event:
Failure of the mainboard, the specific failure is repairable by replacing a component (eg,processor) on the mainboard. The replacement of the processor can occur at customer site.
Special operational requirements:
None
LSA candidate:
Control computer (part)
Rectifying maintenance task for the event:Repair the control computer by repair of the faulty mainboard (ie, replace the faulty processor).
Refer to Table 17.
Table 17 Subtasks for example 3
Step

Description

Maintenance level/task location

1

Remove the faulty control computer

Customer's vehicle workshop

2

Disassemble the faulty control computer

Customer's computer workshop

3

Remove the faulty mainboard

Customer's computer workshop

4

Repair the faulty mainboard by replacement of
the faulty processor

Customer's computer workshop

5Install the repaired mainboard on the control
computer

Customer's computer workshop

6

Assemble the control computer

Customer's computer workshop

7

Test the control computer in workshop

Customer's computer workshop

8

Install the repaired control computer on vehicle

Customer's vehicle workshop

9

Test the function of control computer after
installation on a vehicle

Customer's vehicle workshop

Potential follow-on tasks after the rectifying task:− disposal of processor
The solution described above has an impact on the availability of the Product. The Product is
not used before the completion of the repair activities. During repair time, the Product is notoperable. A possible alternative solution is replacing the complete control computer andrepairing the faulty unit later, when the Product is already in use again. Table 18 describes thetwo corrective maintenance solutions and their corresponding consequences.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 30

S3000L-B6865-03000-00

Table 18 Influence of corrective maintenance options on Product's availability
Product waiting situation

Consequence

Case A:The entire equipment is not needed as a spare part, because
the same equipment will be reinstalled, after a successful
repair, into the ProductProduct is waiting for repairof equipment

Spare parts to repair the faulty equipment are required.
Product availability is reduced due to the waiting time.
Case B:
Product is not waiting forrepair of equipment

The entire equipment is needed as a spare part because a newequipment will be installed to repair the Product and allow
reusing the Product as soon as possible.
The repair of the equipment will occur later when the Product isalready in use. Spare parts are necessary to repair the faulty
equipment.
Availability of the Product is better than the availability incase A. There is no extended waiting time for the completion of
the equipment repair.

10.4

Example 4: Failure of the mainboard, case 3
Event:The specific failure of the mainboard is repairable by replacing a component (processor). The
replacement of the processor can only occur at industry level. The customer does not want towait until the mainboard is repaired at industry level.
Special operational requirements:
The vehicle must be available again as soon as possible. No acceptable waiting time for thecontrol computer repair.
LSA candidate:
Control computer (breakdown element)
Rectifying maintenance task for the event:Replace the control computer. Refer to Table 19.
Table 19 Subtasks for example 4
Step

Description

Maintenance level/task location

1

Remove the faulty control computer

Customer's vehicle workshop

2

Install a new control computer

Customer's vehicle workshop

3

Test the new control computer

Customer's vehicle workshop

Potential follow-on tasks after the rectifying task:− repair the faulty control computer by replacement of the mainboard
LSA candidate for the follow-on task: the control computer (part), refer to example 3 inPara 10.3−

prepare for transportation and transport the faulty mainboard to industry
LSA candidate for the follow-on task: mainboard (part), the task will be described in the
LSA as an operational support task

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 31

S3000L-B6865-03000-00−

repair faulty mainboard by replacement of the processor at industry (industry task  noneed to include this task in the LSA data)

Note
Example 4 is more extended and shows more follow-on tasks. It is obvious that the
distribution of activities influences the requirements for task resources, the means to makeavailable spare parts, support equipment and competent personnel at the corresponding
facilities where the different tasks are performed. For example, after a successful repair of
the mainboard at industry, it will be sent back to the customer and will be available again asa spare part for further repair tasks. Different maintenance solutions have a significant
impact on spare part life cycle.

10.5

Example 5: Complex maintenance procedure on several levels
Event:
Failure of the power supply. The faulty part is repairable at operational site by replacing thecomponent (transformer). The replaced component is repairable at an industry site or at a
special maintenance facility of the customer.
LSA candidate:
Control computer (part)Special operational requirements:
None, Product can wait for the corrective maintenance of the equipment.
Rectifying maintenance task for the event:Repair the control computer by replacement of power supply. Refer to Table 20.
Table 20 Subtasks for example 5
Step

Description

Maintenance level / task location

1

Remove the faulty control computer

Customer's vehicle workshop

2

Disassemble the faulty control computer

Customer's computer workshop

3

Remove the faulty power supply

Customer's computer workshop

4

Install a new power supply

Customer's computer workshop

5

Assemble the control computer

Customer's computer workshop

6

Test the control computer in workshop

Customer's computer workshop

7

Install the repaired control computer on vehicle

Customer's vehicle workshop

8

Test function of control computer within thevehicleCustomer's vehicle workshop

Potential follow-on tasks after the rectifying task:− repair of power supply by replacement of the transformer at customer site
LSA candidate for the follow-on task: power supply (part). Task will be included in the LSA
as a rectifying task.
−

prepare for transportation and transport faulty transformer to industry or to specificmaintenance facility of the customer (both tasks are possible, as described above).
LSA candidate for the follow-on task: transformer (part). The task will be included in the
LSA as an operational support task.

Applicable to: All

S3000L-A-12-00-0000-00A-040A-A
Chap 12DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 32

S3000L-B6865-03000-00

10.6

−

repair faulty transformer at specific maintenance facility of the customer.
LSA candidate for the follow-on task: transformer (part). Task will be included in the LSA asa rectifying tasks.

−

repair faulty transformer at industry (industry task  no need to be included in the LSA)

Summary of examples
The examples within Para 10 show a variety of maintenance solutions/scenarios. The examples
are just a part of the possible scenarios and solutions. The aim of these examples is to highlightthat there are, in general, different possibilities to implement maintenance solutions.
Considerations on the most effective maintenance solution for the specific usage scenario for
an individual customer always take part in the choice of the specific maintenance task, at a
specific maintenance level or at a specific facility. Several criteria can influence this selection
and can be, but are not limited to:
−
−
−
−
−
−
−

11

the dominating aspect is the availability of the Product, need to minimize down timethe dominating aspect is cost, maintenance must use the most cost-effective approachthe degree of capacity utilization concerning customer-operated maintenance facilities mustbe high or at least on a specific level
the need to minimize dependency from industry support (this aspect can be especiallyrelevant for military products)
the need to preserve on establish competence on customer side
the maintenance strategy is pre-assigned, no foreseen repair activities at customer site
the lack of capabilities on customer side

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:
−
−
−
−
−
−
−
−
−
−
−
−
−
−

S3000L UoF Change Information
S3000L UoF Circuit Breaker
S3000L UoF Competence Definition
S3000L UoF Environment Definition
S3000L UoF Facility
S3000L UoF LSA Candidate
S3000L UoF Location
S3000L UoF Performance Parameter
S3000L UoF Resource Specification
S3000L UoF Task
S3000L UoF Task Requirement
S3000L UoF Task Resource
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-12-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-12-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 122021-04-30 Page 33

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
Purpose ........................................................................................................................... 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
Software support analysis process - commonality with the LSA process ....................... 7
4.2
Software support analysis candidate selection ............................................................... 8
4.2.1
Selection of physical candidates ..................................................................................... 8
4.2.2
Selection of functional candidates ................................................................................... 8
4.3
Task requirements for software ....................................................................................... 8
4.3.1
Operational events .......................................................................................................... 9
4.3.2
Technical events .............................................................................................................. 9
4.3.3
Software improvement requirements............................................................................... 9
4.3.4
Software failures .............................................................................................................. 9
4.4
FMEA/FMECA aspects .................................................................................................. 10
4.5
Preventive maintenance analysis for software .............................................................. 11
4.6
LORA aspects................................................................................................................ 11
4.7
Software support tasks .................................................................................................. 11
5
Software support concept framework ............................................................................ 12
5.1
Software support profile ................................................................................................. 12
5.1.1
Support levels ................................................................................................................ 13
5.1.2
Support roles ................................................................................................................. 13
5.1.3
Support scenario............................................................................................................ 14
5.2
Software support classes .............................................................................................. 14
5.2.1
Processes ...................................................................................................................... 14
5.2.2
Product .......................................................................................................................... 14
5.2.3
Environment................................................................................................................... 15
5.3
Software support tasks .................................................................................................. 15
5.3.1
Operational support tasks .............................................................................................. 15
5.3.2
Management support tasks ........................................................................................... 18
5.3.3
Software modification tasks ........................................................................................... 19
5.4
Software support concept framework - summary .......................................................... 21
6
Supportability factors ..................................................................................................... 22
6.1
Compatibility matrix ....................................................................................................... 22
6.2
Deployment.................................................................................................................... 22
6.3
Documentation............................................................................................................... 22
Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
7

Loading/unloading and installation ................................................................................ 23
Transportation on hardware carriers ............................................................................. 23
Expansion capability ...................................................................................................... 23
Modular software design ............................................................................................... 24
Modification frequency ................................................................................................... 24
Recovery ........................................................................................................................ 24
Safety integrity ............................................................................................................... 24
Security .......................................................................................................................... 25
Size ................................................................................................................................ 25
Competence .................................................................................................................. 25
Software distribution ...................................................................................................... 26
Standardization .............................................................................................................. 26
Technology .................................................................................................................... 26
Associated parts of the S3000L data model .................................................................. 26

List of tables
1
2
3
4
5
6
7
8

References ...................................................................................................................... 2
Failure classes ............................................................................................................... 10
Examples for software support level definitions ............................................................ 13
Tasks for the provision of new functionality and/or capability ....................................... 16
Tasks for Product recovery and for problem reporting .................................................. 16
Organizational tasks ...................................................................................................... 18
Management support tasks ........................................................................................... 18
Software modification tasks ........................................................................................... 20

List of figures
1
2

Software support analysis in the different project phases ............................................... 4
Aspects of an SSC framework ....................................................................................... 12

References
Table 1 References
Chap No./Document No.

Title

Chap 3

LSA process

Chap 4

Product structures and change management in LSA

Chap 10Development of a preventive maintenance program

Chap 11

Level of repair analysis

Chap 12

Task requirements and maintenance task analysis

Chap 19

Data model

S4000PInternational specification for developing and continuously
improving preventive maintenance

RTCA/DO-178B

Software Considerations in Airborne Systems andEquipment Certification

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Chap No./Document No.

Title

SAE JA1004

Software Supportability Program

SAE JA1005

Software Supportability Implementation Guide

SAE JA1006

Software Support Concept1

General1.1

Introduction
In modern products, supportability aspects for software have become increasingly important.
Complex software packages support or realize functionality more and more. Concepts andprocesses for hardware components are established to guarantee full Product supportability
during its entire life cycle. The appropriate tool to achieve this goal for hardware is the LSA
process. In principle, the same requirements apply for software. Hardware and software are ofequal importance for a Product's proper operation. For this reason, it is possible to apply ananalysis methodology called Software Support Analysis (SSA) to develop an adequate Software
Support Concept (SSC). SSA is a methodology that analyzes software with the purpose of
supplying the customer with all necessary information to establish an effective SSC. This
comprises at least the identification of required support equipment, software tools, andpersonnel with corresponding competence, technical documentation, facilities andinfrastructure.
An SSC takes into account all activities to enable a continuous usage of software within a
Product. To find a common understanding of software support, it is recommended that thecustomer and the contractor harmonize a standardized concept for software support
documentation and include it in an LSA PP.
Analysis activities for software are like those for hardware, and they take into account software
operational and maintenance requirements. Special operational aspects are of particularinterest for Product users because of the influence on the day-to-day business. It is also
necessary to take into account aspects covering software modification, such as bug-fixing andsoftware improvement (eg, software upgrades).

1.2

PurposeThe means of LSA and SSA establish an appropriate support concept for such equipment. The
results of the various analyses allow to ensure the customer's needs on supportability,
readiness, and operability of hardware that contains software. The target readers of this chapter
are IPS managers and/or LSA analysts who analyze Products containing software, whether
they work for the contractors or the customers.

1.3

Scope
This chapter provides the supportability analyst with guidelines for handling the specificrequirements concerning software with respect to maintenance and operation. This chapter
clearly defines the interrelation between software and hardware, and explains the method tointegrate software aspects into the overall LSA process.
With respect to software, it is necessary to make a distinction between operational/maintenanceaspects and real software modification. For example, operational aspects can include thesimple act of loading working software or required data to equipment within the Product,
whereas software modification covers aspects that deal with the update 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.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

2

Software support analysis in the different project phases
Like the application of LSA, SSA is an analysis activity, which can be applied throughout theentire life cycle of a Product containing software. In the different life cycle phases various
analysis activities must be performed. Refer to Fig 1. Depending on the phase, the importanceof some activities can increase, while the importance of other activities decreases. For example,
during the design and development phase, SSA is of high importance as it can influence
software architecture and design in terms of supportability requirements for future needs toload, service, or modify the software packages. In an early concept phase, SSA helps to identify
basic software support requirements. During the in-service phase, aspects like those for
hardware are valid. Technical modifications will force the analyst to reassess the support
solutions for the affected hardware/software. For this reason, the depth of an iterative SSA/IPS
process will depend on the extent of the technical modifications. Basically, these activities are
the same as those in the design and development phase, and in the production and introduction
phase, but they are normally less extensive.

ICN-B6865-S3000L0062-002-01
Fig 1 Software support analysis in the different project phases
In the disposal phase, it is important to handle software and/or data during the disposal of
hardware. It is necessary to ensure data handling complies with the project's requirements andit is mandatory to erase sensitive data from scrapped hardware.
For archiving purposes, it is necessary to preserve existing data from disposed hardware
components. In case existing data is needed for further operation of a new Product, it isessential to analyze feasibility of data migration and establish a concept for data migration.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

3

Breakdown concept
Chap 4 provides guidance on the development and assignment of a BEI for hardware andsoftware with physical and functional breakdown examples. It is recommended to follow thisguidance and the examples for the development of breakdown relationships between softwareand hardware.
It is possible to obtain a BEI for software like the BEI for hardware by following the concepts ofphysical or functional breakdowns. However, due to different characteristics, it can be difficult toassociate software within the traditional physical/functional breakdown. This applies to complex
systems (eg, modular avionics), where the physical location of a specific software can be
unclear. Often, software is not a clearly defined physical entity, therefore it can be difficult to
identify the appropriate indenture level for the software item within a physical or functional
breakdown. Even in the case of a clear assignment of software to hardware, the question canarise as to where the software can 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 is installed?

In this context, the breakdown is different from the traditional physical/functional hardware
breakdown and it is important to establish a consistent approach. The physical breakdown canbe used to identify software within a Product breakdown for operational purposes, and provide
the necessary software view for traditional maintenance purposes. The functional breakdown isa software engineering view that shows the modifications and integrations to the software, andprovides the relationships between the different software elements to be considered in case ofredesign.

3.1

Functional and physical breakdown principles
Normally, operators can handle the software items identified within a physical breakdown. This
software must be considered for operational aspects such as loading/unloading. The software
can be documented at different indenture levels of the Product breakdown.
The allocation of physical software to a specific indenture level is driven by the need to maintainan adequate configuration control of the Product and to underline the supportability impact thatsaid software can have on standard operation and maintenance. Traditionally, software was
assigned to a hardware element. New configuration management issues and approaches havechanged this concept and now, software can be represented by a (BE and/or a part/component
within the LSA data. Refer to Para 3.3.
Software items identified within a functional breakdown are used to describe thefunctional/design aspects that are important for software designers, especially since this type of
breakdown usually indicates the need for integration with other software, and it must be
considered for software modification support. Therefore, it is important that the functional
breakdown follows the software design as closely as possible.

3.2

Physical software categories
There are three categories of physical software:−−−

Field Loadable Software (FLS)
Shop-Loadable Software (SLS)
resident software (also called firmware)

The concept for the three categories is established in the configuration management principles
that control the configuration of a specific Product.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

3.2.1

Field loadable software
FLS is any software that can be installed on one or several pieces of equipment in a
Product/system without the need to remove the equipment from its installation location. FLS is
considered as an item within the Product breakdown. Therefore, FLS modification results in achange of the FLS part identifier and configuration of the system or Product where it is installed.
FLS loading does not cause a change in the part identifier of the hardware. FLS loading affects
the Product configuration because the function of the Product can change when using a
different piece of software.

3.2.2

Shop-loadable software
SLS is any software that can be loaded into an LRU, but requires the removal of the LRU fromits installation location on the Product. Replacing any hardware component is not required. A
modification of the SLS changes not only the part identifier of the SLS, but can also change thepart identifier of the LRU to which it is loaded. The same happens when a Shop Replaceable
Unit (SRU) is replaced by a different one, to maintain the form, fit and function principle thatdrives configuration management (ie, the function changes when replacing software by different
software). In this case, the change in the hardware part identifier affects the Productconfiguration.

3.2.3

Resident software/firmware
Resident software is any software that can be loaded into an LRU or SRU but requires theremoval of LRU/SRU from its installation location on the Product and can also require thereplacement of a component where the firmware is installed. Although resident software canhave its own part identifier. When it is installed on a component or loaded onto an SRU, the part
identifier for the component or SRU will change. This can also entail a change to the part
identifier of the LRU at the next higher level.

3.3

LRU and SRU aspects
The recommended way to handle software within an LSA Product breakdown is to identify
software as LRU, SRU or part/component, depending on the software category. This not only
simplifies the overall Product configuration management, but it also clarifies how to handle theProduct configuration when using FLS and there are no tags on the target hardware regarding
the software it contains. This is not an issue when the configuration is handled at the next
higher level.
Similarly, a software loading task due to a hardware repair can be integrated into the overall
maintenance tasks because a specific software SRU or LRU is affected. In principle, it is notdifferent from performing a task on a hardware SRU/LRU and subsequently performing
additional tasks at the next higher breakdown level. Therefore, a software loading task after ahardware repair is similar to, for example, replacing a consumable.

3.4

Functional software categories
The functional software breakdown follows the software design requirements, as it is mainly
oriented towards software modification. It is possible to use the classic Computer Software
Configuration Item (CSCI), Computer Software Configuration (CSC) and unit level views.
However, contrary to “traditional” software engineering, it is also necessary to provide the higher
levels of abstraction (subsystem and system level), as they indicate 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 using the same principle as that for assemblies within physicalbreakdowns. It is possible to use said assemblies to provide a helpful additional level ofabstraction without changing the overall structure and functionality of the software design.
It is recommended to use a BE revision identifier in the event of a release of a software version
that significantly changes the software structure, functionality or supportability elements (eg,change of programming language of a specific module) that can entail a modification of the
support tasks and/or support infrastructure. It does not provide any benefit to full analysis

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

performance because there is just a change in an algorithm, but it can be essential if thesoftware class is likely to change.

3.5

Data
It is possible to handle data in a similar way to software, considering them from both thephysical and functional point of view. The peculiarity of physical data is that they can beloaded/unloaded but also prepared, so it is not a pure software aspect. Software modification isa design activity, while data preparation can be considered an operational activity. However, thedifference between the two activities is not always obvious.
In general, data can be included within the LSA data in the same way as software, including
preparation, if applicable. They can also be included in the functional breakdown to ensure
retention of configuration and dependencies. For example, a software modification can entail amodification to the mission preparation systems.
Together with the customer, it is necessary to discuss and decide whether to consider data as asoftware element, or as a special category within the LSA data. Though standards such as
RTCA/DO-178B include data in the software definition. Treating data as a separate element for
supportability purposes offers some benefits, eg, data is available as a BE to assign
loading/unloading tasks.

4

Software support analysis
SSA is a consistent methodology to guarantee proper software supportability throughout therequirements, specification and design phases, to define the most cost-effective support
concept that meets the operational and software modification requirements. It is necessary toestablish an adequate support infrastructure before the Product enters the in-service phase.
The main goals of an SSA are to establish supportability requirements concerning software in
the early program phases, and to influence the software design to ensure supportability for both
Product operation and later modification processes. The standard SAE JA1004 (Software
Supportability Program) outlines a stand-alone software supportability program.

4.1

Software support analysis process - commonality with the
LSA process
In general, the SSA process covers supportability aspects that are like those for the LSA
process, as described in Chap 3. For Products that contain software as a basic element within
one or many pieces of equipment, it is necessary to apply a number of software support
activities, depending on the situations that trigger the need for support. In this area, there are
two main categories of analysis:−−

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 the
two task categories, and the types of software items in the functional or physical Productbreakdowns. Typically, support activities not involving any modification are analyzed against
physical breakdown items. In all cases, LSA data include the analysis results concerning
operational aspects, including the description of tasks such as the loading of data and/or
software to the corresponding hardware element within the Product breakdown. After a change
in the equipment, for example, it can be necessary to reload software and/or data to the new
equipment or to configure it after or before installation into the Product. The use of hardware for
special purposes can require special software or data packages to support this kind ofoperation. There are no changes to the software itself.
Normally, a software modification directly influences the software source code and involves
modifications to the source code. Since the requirements for these activities differ from theApplicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

operational aspects concerning software, the relevant documentation is normally separated
from the support/operational aspects. In case software packages are analyzed to determine
their requirements for real software modification tasks, it is possible to treat said packages as
SSA candidates similar to LSA candidates for hardware.

4.2

Software support analysis candidate selection
In general, SSA candidates are either physical or functional BE that are subject to any kind of
SSA. Supportability significance drives the candidate selection. Due to the two main categories
of software support activities, candidate selection occurs separately for each support category.

4.2.1
4.2.1.1

Selection of physical candidates
Software
SSA candidate selection must take into consideration all software items that the operator canload and/or install separately. The hardware item carrying the software can be a candidate item,too.
For distributed software, the candidate can be a subsystem or a system within the Productbreakdown. Typically, loading and/or installation tasks are documented against thecorresponding hardware. It is possible to document other operational tasks against a software
BE as well (eg, transportation or distribution of software).

4.2.1.2

Data
Data are usually electronic in nature, and handled similar to the corresponding software.
Therefore, it is possible to analyze together the support of software and dependent data(although not in the same way). It is necessary to analyze each SSA candidate for special
support aspects for data. The analysis includes, but is not limited to:
−
−
−
−
−
−

4.2.2

Selection of functional candidates
An SSA candidate identified in a functional breakdown must take into consideration all software
items that are subject to software modification activities. It is possible to use the following
questions to analyze each software item to decide whether it is subject to a software
modification activity:
−
−
−
−
−
−
−

4.3

Does the required data preparation process need special software or hardware?
Is a data validation process required?
Are special transmission media or networks required?
Are there special security aspects to data loading?
Are there special compatibility requirements with the existing executable software?
Are there special requirements concerning size and format (eg, databases, file formats)?

Are any support initiators expected for the software items that require a modification of thesoftware source code?
Does the software item in the breakdown include all software within a functional system or
only within a physical equipment?
Does the software item use a separate design?
Does the development of the software item require special hardware and/or software tools?
Does the software item contain proprietary software, such as run-time libraries or COTS
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?

Task requirements for software
Like the LSA methodology for hardware, the identification of any task requirement that initiates
maintenance activities is the starting point to document the relevant maintenance aspects. It is
possible to describe these events as "software support initiators" and to apply the event-driven
methodology to SSA. However, the events concerning software are somewhat different from theevents for hardware. They can be grouped according to the implications of:Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

−
−
−
−
4.3.1

4.3.2

operational events
technical events
software improvement requirements
software failures

Operational events
This type of event relates to operational requirements. Operational events can be documented
within the related hardware item. The same applies to the corresponding operational task.
Typically, the covered aspects are:−

Corrective or preventive maintenance tasks relevant for the computing hardware
After hardware maintenance, different types of tasks can be necessary (eg, reloading ofdata and/or software, installation and configuration of software packages on new installed
equipment).

−

Use (mission) preparation
Besides the installation of additional hardware, the preparation for use of a Product canrequire the installation of supporting software packages or loading of special mission data.

−

Post mission requirements
After Product use, it is necessary to unload or archive the data created during the mission.
Moreover, it is necessary to uninstall software packages required for a special mission, andreconfigure the Product to a standard configuration.

Technical events
Besides hardware maintenance, other technical events can trigger software support activities.
These events normally require adaption of the existing software packages to the modified
environmental preconditions. Typically, the covered aspects are:−−−−changes to the parent hardware
changes to the parent software (eg, upgrade of operating systems, corresponding databasesystems or firmware)changes in the technology of interoperating systems
changes in the technology of network interconnectivity

4.3.3

Software improvement requirements
Typically, software undergoes a constant improvement process. Normally, software releasechanges take place at regular intervals, depending on the complexity and size of the software
package. Besides fixes to real software failures, the primary inputs for new releases are
dedicated user requirements or changes in the environmental preconditions. In this context,
improvement means the introduction of new features that improve or extend functionality, or theusage comfort of an existing software package.

4.3.4

Software failures
Failures initiated by software are main support initiators. The reaction to these failures depends
on their severity. Not every failure caused by software will initiate an immediate software
modification activity.
For software failures, it is recommended that a classification concerning severity be introduced.
Refer to Table 2. For each failure class, it is possible to define a sequence of activities within an
SSC. In every case, proper documentation is required to support later diagnosis.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Table 2 Failure classes
Class

Description

Minor

In general, these failures concern user comfort. In many cases, these events
are not real failures, but rather a deficiency in the design of software features.
In some cases, these minor failures can be actual failures, but other softwarefeatures, or an alternative handling can solve them.
However, it is recommended to collect, document and report these minor
events to the software support organization. This information can support theincorporation of improvements into a future release of the software package.
Especially the correction of marginal insufficiency can considerably increaseuser comfort and acceptance.

MediumThese events cause decreased Product functionality. If this type of event
occurs, the user is not able to continue using the Product as expected.
However, the Product as a whole works without severe disturbance (eg, noneed for shutdown). It is possible to continue using the Product with reduced
performance or even with no restrictions at all.
These events normally need a timely correction, or at least a defined
workaround to deal with the failure until it is finally corrected. Normally, asoftware modification is necessary.

Major

A major software failure is an unacceptable event. This failure causes the
shutdown of the entire Product, or the necessity to operate the Product underrestricted conditions. The normal capability of the Product is significantly
degraded.
These events need correction as soon as possible. In case of emergencies,
the software support organization must react as soon as possible to restore
the entire Product to full operation. It is necessary to discuss and determine
the reaction times together with the customer.

It is not possible to treat software failure exactly like hardware failure. In the case of a hardware
failure, it is possible to clearly define any relevant maintenance activity, such as a repair byreplacement of components or a replacement of the LRU itself. In case of a software failure, it isnormally not possible to identify the required activity immediately. For example, a restart of the
Product can be sufficient, and the failure will not occur again. However, other types of failure
can be severe and lead to Product shutdown. In this case, it is better not to restart the Product,
to avoid the repetition of the failure and a further corruption of the entire Product.
Corruption of data or the executable code can be another important aspect. A virus infection or
corrupted carrying hardware (eg, the loss of functionality of a hard disk) can lead to thecorruption of data and code. In this case, there is no real inherent failure in the software sourcecode. This event is handled as an external damage.

4.4

FMEA/FMECA aspects
Since FMEA or FMECA, respectively represents an analysis method for the complete Product(covering hardware and software aspects), the results of a technical FMEA/FMECA are relevant
for software. For any identified failure mode, it is necessary to determine whether the
associated functionality depends on or is provided completely by software. During thedesign/development of the software, it is possible to use the information on this failure mode to
design a software architecture that eliminates, or at least mitigates, the possibility of software
failure that can cause a specific functional failure of the Product. In addition, the design can bearranged to ensure that any such potential software failure is detected and recorded, including
its associated information, and that the Product continues operation in a safe mode.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

During the in-service phase, Product downtimes due to software failures drive the software
modification activities. A principle of the failure mode grouping (refer to Chap 7) is to group
together all software failures that lead to a specific system failure and to group together all
specific system failures that lead to the same request for software modification. The analysis
depends on the function that the software performs.
During the in-service phase, it is necessary to provide information to the software engineers on
specific failures, and to avoid unnecessary maintenance tasks due to software failures. The
possibility to identify and localize a software-specific failure for example by built-in-test capability
can avoid an unnecessary hardware removal/replacement (eg, a software failure cannot berectified by replacing the equipment) and cases of "no failure found" related to hardware.

4.5

Preventive maintenance analysis for software
PMA methods such as S4000P or Reliability Centered Maintenance (RCM) are not applicable tosoftware packages in the same way as those for hardware. Software failures are the result of
unintended effects of the software design. PMA is not effective in avoiding such failures, since
they result from design shortcomings. However, some software failures can affect safety. The
results of PMA carried out for a piece of hardware containing software can identify preventive
maintenance tasks that are operational in nature and concern software (eg, a mandatory
software test before a mission). However, it is still a preventive maintenance analysis for
hardware taking into account software elements as potential failure causes.
A PMA on the software itself can result in a periodic assessment of the software during its lifeand not in preventive maintenance tasks performed on the relevant hardware. Software showsa bathtub curve for failure, with many failures, initially. Bugs are fixed with successive software
releases leading to a stable behavior. During later releases, failure rates can increase again due
to the increasing degradation of the software, modified beyond its initial scope. A periodic
assessment of the failure rate can determine whether the software is reaching its end of life:
−
−

4.6

due to increasing software failures because of too many modifications and alterations
due to failure of the underlying hardware or operating system to process the addedfunctionality. This can lead to either a software rewrite or perhaps a complete equipment oreven system redesign.

LORA aspects
A LORA procedure (refer to Chap 11) can identify a proper maintenance level for a software
related support task. With respect to operation, the performance of support tasks related tosoftware or data loading can be covered within a LORA for the hardware-related tasks, or atleast by a similar process.
For software modification, detailed information about equipment (software development
environment concerning hardware and software developer tools) and adequate personnel
competence is required. In addition, contractual warranty and software ownership can influence
the identification of an appropriate support level for software modification activities. For
management tasks, the process also becomes important to determine the best location to
perform tasks such as the production of software or data media.

4.7

Software support tasks
After the identification of the relevant task requirements (software support initiators), it isnecessary to identify the appropriate tasks (operational support/maintenance tasks ormodification tasks). The goal is to define all operational, maintenance or modification tasks,
their related resources, and additional task characteristics such as duration, manpower
requirements, preconditions or safety conditions.
SAE JA1005, Software Supportability Implementation Guide, provides guidelines to the analyst
regarding which type of software support tasks can occur depending on different task
requirements. Refer to Para 5.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

5

Software support concept framework
Achieving a proper supportability framework is one of the most important design principles forsoftware, in a similar way as for hardware. To this end, it is required to establish an SSC at an
early stage of the software design process. The earlier the design pays attention to support
requirements, the better the supportability will be.
It is recommended to give a guideline to the supportability analyst using this specification. The
guideline must cover all the important areas concerning software support and must consider
contractual agreements between the customer and the contractor. All aspects can be tailored to
the required extent of the project.
Note
An SSC can have different perspectives, all interconnected and influenced by each other.
Refer to Fig 2.

ICN-B6865-S3000L0063-002-01
Fig 2 Aspects of an SSC framework
The extent of a software development or procurement project determines whether the process
to establish an SSC can be included in the overall LSA process (refer to Chap 3). The
procedures of the general LSA process can cover the aspects of software support. Relevant
documents such as an ORD or CRD can also cover software support aspects concerning therequired usage information. The LSA GC also covers the software support aspects and therelevant contractual agreements, documented in the LSA PP and/or LSA GD. The candidates
for a detailed SSA can be added to the CIL. It is also possible to include the rules for SSA
candidate selection in the LSA GD.
For complex Products with a considerable amount of software, it is recommended that software
supportability be treated as a separate topic. It is possible to create and implement a separate
SSA program plan, and to hold a separate GC for software aspects. However, it is necessary toconsider the interaction between hardware and software development. Software is designed toaddress functionality of hardware components. Therefore, both must work together, and it isnecessary to harmonize, document, review and put into practice processes that guarantee
proper cooperation. Refer to SAE JA1006, Software Support Concept.

5.1

Software support profile
The software support profile (refer to Fig 2) takes into consideration the location of the software
support, the organizations and individuals that are the relevant stakeholders in a software

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

support environment. Additionally, it is necessary to discuss and agree with the customer theprocesses regarding how the different instances work together in an integrated way.
5.1.1

Support levels
For software, the levels of support can be addressed in a way similar to the maintenance levels
for hardware within the LSA. The support levels for software can differ from the hardware
support levels and can be used as input to the LORA decision process for software. In addition,
classification is similar to the maintenance levels for hardware, but some special aspects
concerning software can be considered additionally. Table 3 provides examples for software
support level definitions.
Table 3 Examples for software support level definitions

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 typicallycovered by the operational support.

Level 2(intermediate support level)

An intermediate support level can cover all support activities
which are related to operational support but also to
management support. User support in the form of a help deskor a hotline can also be covered by an intermediate support
level. Activities can be software upload/download, firmware
update or installation of patches. Typically, the intermediate
support level for software 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. It cancover activities from the management support andmodification support. Software packages characteristics (eg,complexity, size, modularity, programming techniques) andavailable equipment (eg, tools, personnel, facilities andinfrastructure) of support sites determine the extent of thecapability to modify software packages.

Level 4(software vendor and/or
original developer)

Vendor level is normally the highest qualified support level for
demanding tasks concerning software modification. In manycases, the vendor is the original developer of the software,and has competent personnel and all necessary developer
tools available. This level is often selected for modification
support because the user itself does not have the required
capabilities for these complex support tasks. Additionally, it isnecessary to consider aspects of responsibility and liability,
which can force the user to address software modification tothe original vendor.

Support roles
As a first step to define software support roles, it is necessary to clarify customer (buying
department and users) and supplier (vendor and technical support personnel) roles. As asecond step, it is required to allocate the roles concerning software usage and support topersonnel who can offer the required services. These roles can be:−

simple users without any rights to modify or recover any software system (not a real
support role, but in general only a service receiver). The main task of a simple user is tokeep the software operationally running and report any software-related failure.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

−

−

−
−

power users with some basic knowledge and the ability to perform a system recovery. With
respect to software support, this role can perform simple operational support actions tokeep the software running, such as loading mission data. Normally, a power user does not
perform any software modification activity.
system administrators, who are power users on a higher level. They must be able to cover
all activities concerning operational support and eventually management support. Systemadministrators handle direct support for simple users or power users who work with thesoftware packages. Normally, a system administrator is not involved in any software
modification activity. Typical system administrator activities include software configuration,for example changing performance parameters, granting of user access rights, loading
additional software packages, or installing updates.
service providers, who can provide qualified operational support and additional services,such as a hotline. Service providers can be located onsite with the customer and vendor,
and in some cases, are able to provide modification support.
vendors or original software developers, who can provide modification support up to thehighest support level. Vendor support is normally located off site.

All these roles must be equipped with the required competence and access rights necessary to
carry out their tasks. The SSC describes all roles, including their profile. It is necessary to define
and document the limits of competence clearly, and all affected personnel must accept them.
5.1.3

Support scenario
For an appropriate planning of a software support scenario, it is advisable to describe use cases
for the different support roles and support levels, indicating how the different resources atdifferent locations work together, and which processes are the basis for the cooperation. The
customer and contractor must agree, implement, and control this support scenario.

5.2

Software support classes
The quality aspect of an SSC includes all objectives involved. The software support classes
ensure compliance with the rules by means of implemented and used quality standards.

5.2.1

Processes
The customer/user and the software support provider must discuss all established processes
and provide written documentation on the implementation of these processes. The
documentation must clearly address process characteristics including inputs, outputs, controls,
and resources:
−
−
−
−

5.2.2

Is there any written documentation of the process (eg, flowcharts, descriptions,requirements, responsibilities)?
Is there an accepted standard to describe the relevant processes (eg, international orcompany internal)?
Are there any measurable parameters for performance control, and how is performance
control measured?
Are inputs and outputs, procedures, requirements and effective control mechanisms
defined and documented?

Product
It is advisable to address supportability aspects as early as possible in the software Productcharacteristics. Inherent quality characteristics of software depend on the level of quality ofsoftware design. Requirements for a good software design include many aspects, starting withthe software specification and ending with a perfect user handling, supported by a propergraphical user interface. Typical quality aspects are:−−−−modularity
changeability and expandability
simplicity and easy handlingstability and consistency

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00−−

performance concerning processing speed
instrumentation (in the sense that the software is purposely instrumented for anunderstanding of how it is operating)If the software development process considers these aspects in detail, it will be easier to handle
and support the software package during operation. However, even well-designed software cancause problems if the implemented support concept is insufficient.
5.2.3

Environment
Environmental aspects affecting quality start with the personnel involved in software use and/or
support. To implement proper software support, it is essential to address personnel
characteristics thoroughly:
−
−
−
−
−

Who is the right person for a software support job?
What are the required skill levels and experience?
How many persons are required to guarantee a trouble-free software support?
What is the level of motivation of the personnel?
What employee turnover can be expected?

Not only personnel aspects influence the quality of the environment. Simple aspects such as thequality of facilities and infrastructure, computer workplace equipment and size of offices canaffect the quality of the support services.

5.3

Software support tasks
Support tasks related to software fall into categories depending on:−−−−

Is the task a simple software loading/unloading task, or a simple software transfer task (eg,from a device A to a device B)?
Is it necessary to remove hardware from a Product to load/unload software?
Is the maintenance task associated with any case of failure recovery or documentation ofsoftware problems?
Is any case of software modification involved?

Note
Software modification leads to a wide area of specific activities, which software design anddevelopment activities must address in detail.
5.3.1

Operational support tasks
The operational support tasks describe all activities associated with the day-by-day operation of
the Product. However, the quality and depth of impact of these tasks on the usage of the
Product (eg, downtime, test requirements) can vary. In general, these are rather simple tasks
carried out by a simple user or a power user on a low support level, which only require thesoftware package to be available on a compatible medium, plus a corresponding user manual. It
is necessary to take into account different methods of installation. For stand-alone Products,
system administrators will have different requirements compared to those of large computer
network systems. In modern network architectures, software and data installation and loading iscarried out with the help of software deployment tools.
Table 4, Table 5 and Table 6 give an overview of the types of tasks that can occur, including
further definition of some terms concerning the handling of software packages. These tasks fallunder three subcategories:−−−

tasks for the provision of new functionality and/or ability
tasks for Product recovery and for problem reporting in case of software failureorganizational tasks

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

Table 4 Tasks for the provision of new functionality and/or capability
Type of task

Description

Softwareinstallation

Software installation indicates an installation routine for a software
package, leading to the provision of a possible functionality by means ofsoftware.

Software deinstallation

De-installation of a software package indicates a de-installation routine
or deletion of files from a storage device, leading to the definite removalof a possible functionality realized by the mean of software by carryingout a de-installation routine or by simple deleting of files from a storage
device.

Software loading

Software loading is a task that goes beyond installation and therefore, it
is more complex in many cases. In addition to the installation routine,
which is part of the software loading, it is necessary to consider software
configuration.

Softwareconfiguration

In this context, the term configuration means the change of internalparameters (eg, operational or performance parameters, editing ofconfiguration files, granting of user access rights, path information,
database connections) for software operation. These activities do not
require any new installation of the software package. The functionality ofthe software package is sufficient to change the configuration
parameters of the software. For the configuration, it is important to havesufficient access rights (eg, administrator account to log into a software)to introduce the changes.

Data loading

To provide special capabilities to the Product, data will be normallyloaded using the existing functionality of an installed software package.
In this case, there is a fine line between software and data, dependingon the type and format of the data to be loaded. Typically, data loadingtasks are used to prepare operations or missions.
Data do 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 these
data, for example, for the graphical representation of a city map. Whenloading another data set (eg, package of another country), thefunctionality of the navigation system will not change.

A particular 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 capabilities can be moredemanding. Transferring new software code or new data to the storage devices of theembedded software (eg, resident storage chips on a computer main board) normally requires
some special tools and support equipment (eg, to gain access). The MTA of the installation or
loading tasks for embedded software or firmware identifies the relevant requirements.
After each change of software by means of an installation/loading procedure, it is recommended
to define the methods that will ensure proper Product functioning. It is necessary to investigate
thoroughly and, if required, document (eg, in the installation instructions) the need to haveadequate competent specialists available to perform a functional test and confirm proper work.
Table 5 Tasks for Product recovery and for problem reporting
Type of task

Description

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

Type of task

Description

Software recovery Software recovery includes all basic diagnostic activities and simple
recovery actions, such as system reboot/restart after a system orsoftware shutdown. Normally, low-skilled personnel can carry out these
activities safely. Even in case of a successful recovery to full operational
capability, it is strongly recommended to perform a diagnosis of all
potentially relevant components of the Product.
Documenting thoroughly all available data concerning the problem
occurrence and the recovery actions can be useful for evaluation
purposes. This can lead to several outcomes to rectify the cause of the
problem immediately, or to ensure full operational capability byalternative means. In case it is not possible to solve the underlying
problem within a short time, a temporary downgrading of operational
capability can be considered.
RecoveryIn the event of a failure involving software, it is recommended toproblem reporting generate a problem report, even after a successful simple recovery (eg,restart or reload). This problem report contains at least:−

Product condition/configuration/version (software and hardware
platform) at the time of failure. This information is important withrespect to fault investigation on transitory effects, as it can benecessary to be able to reproduce the failure effect in an
appropriate test environment or reference system.

−

type of software failure−

outcome of software recovery task (successful, negative, partial)−

classification of failure severity

It is necessary to transmit problem reports to the responsible personnel
who can analyze the problem to establish its priority, and determine any
workaround or need for temporary operational limitations.
Post operational
data extraction

Software support tasks carried out immediately after operation are often
associated with data extraction (eg, for operational and/or engineering
analysis) or fault investigation.
With respect to data-related functions, a range of data administration
tasks can be required (eg, provision and upkeep of data as routinely
needed by a software program to fulfill its operational role). Fault
investigation tasks will relate to activities on the primary system and to
the deeper-level testing on remote reference systems, which replicate or
simulate the primary system’s environment.

All tasks related to recovery of a Product after a software failure do not normally contain any
software modification activities. However, recovery of a Product can require the involvement ofan updated software package.
Problem reporting can be a starting point to identify the need for modification. Even if recovery
tasks were successful, it can be necessary to modify software to rectify the failures that
occurred, thus avoiding future repetition of the failure.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

Table 6 Organizational tasks
Type of task

Description

Software delivery

Software delivery indicates new software received by the user fromsoftware suppliers. Receipt of new software implies several activities
including quality and validation aspects:

Operational
configuration
control

5.3.2−

checking condition and completeness of delivery−

checking configuration status information−

checking license information−

checking compatibility between delivered software and impacted
Product components

This task takes into consideration the compatibility of software withspecial hardware. Sometimes, a specific software package only works
on certain variants of a hardware item. On the other hand, it can be
possible to install/load different software packages to equipment,
depending on the required functionality. The user must know what iscompatible. It is mandatory to avoid configurations that are not tested oreven not allowed.

Management support tasks
The management support tasks cannot be considered as pure operational support tasks.
Software modification is not part of these tasks either. This kind of support is locatedsomewhere between the operational support and the real software modification tasks. Usersand technical support organizations can perform these activities across all levels of support.
Refer to Table 7.
Table 7 Management support tasks
Type of task

Description

Problem reporting This type of problem reporting covers more aspects than the recovery
problem report. In this area, it is essential to implement and upkeep a
management system for failure reporting and corrective actions (eg, abug tracker system). Within this system, all actions are monitored andorganized:−

prioritization related to the severity of problems−

request for software modification−

monitoring of software modification and bug fixing procedures

Potential additional aspects are the continuous monitoring of systemeffectiveness and the development of support costs. To ensure 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_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

Type of task

Description

Systemconfiguration
control

In addition to the operational configuration control, the system
configuration control is becoming increasingly important. Theinterconnection of many computer systems in large networks within acomplex Product requires configuration control at a higher level. The
first step is to ensure that software packages are only installed oncompatible hardware equipment. Operational configuration control
covers this step.
The second step is to ensure that all Product components carrying
software/data and connected to each other work together properly.
System configuration control covers this step. In modern Products, thiscan become a complex challenge. It is strongly recommended toestablishing a compatibility matrix for software/hardware. Only tested
configurations of 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, the contractor or the
supporting organization carries out these activities. In particular, after
the modification of software and the creation of a new software release,the modifying organization will focus on the best way of providing the
new software Product to the affected users, whether they are a single
client or thousands of clients in case of widespread Products. Packaging
and distribution paths are of special interest in the case of sensitive or
security-relevant software.

User support

User support covers a wide range of activities carried out by the
supporting organization. The interactions between the technical support
organization and the user can be:−support for installation, set-up or operation of software−

user help desk/hotline−

user queries, which are answered by the supporting organization by
providing result reports−

user training

Software modification tasks
These tasks refer to a longer-term process that implements changes to software. Normally, a
supporting organization of the contractor at a high level of support (manufacturer or software
vendor) carries out these activities. However, also a customer can modify software, particularly
lower-criticality changes. This requires corresponding equipment, as well as the appropriatecompetent personnel. Software modification tasks cover the software modification activity itself,
which includes coding, change implementation, and testing, as well as the related tasks, suchas problem investigation and configuration control. Refer to Table 8.
Depending on the reasons suggesting the need for software change, said changes can be:−−−corrective changes
adaptive changes
perfective changes

In general, the most critical reason for software change is the occurrence of real failures, whichleads to an unacceptable situation within the operation of the entire Product. Such a failure will
normally lead to a corrective modification of software. Adaptive changes can be necessary due
to a critical situation. However, predicting and planning this kind of changes is usually easierthan performing corrective activities due to a real software failure. The time schedule forApplicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

adaptive changes is not normally as critical as that for a corrective task. However, in modern
Products, it becomes more and more difficult to predict the adaption needs for software over alonger period.
Perfective changes aim to increase the user-friendly properties of the software or software
functionality. Normally, the implementation of these changes occurs through an upgradeconcept. The requirements of the users will be collected during a certain period andimplemented 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
to further operate the affected software taking into account the actual
failure (eg, with lower capability). It is necessary to detect the presenceof a real software bug or a real technical problem. For example,
triggering any real software modification because of user mishandlingmust not occur. After identifying the problem correctly and putting inplace any appropriate interim solution, an analysis will follow on possible
changes to software to solve the problem permanently.
For a proper problem investigation, adequate resources and tools for
failure finding and documentation must be available. This can be asimple programming environment with certain compilers and debuggers,
and/or a complex environment that allows simulation and failure
reproduction.

Changeimplementation

The implementation of changes into software packages must consider
some crucial aspects. The supporting organization usually hosts acomplete repository of the entire software development process, fromthe beginning to the actual status. Coding, compilation and testing ofsoftware requires special tools, which must be available. Additional
personnel with appropriate competence is necessary.
It is necessary to take into account that any basic change in technology
can cause support problems. Examples can be obsolescence or thesuperseding of tools that are required for software modification, or thechange of basic operating systems on computers. This can have a large
impact on costs or even require the upgrade of entire software
packages in case the former software package is not compatible with
the new environment.
In the SSC, it is required to define and document the relevant standards
and procedures that are used.

Change release

A new release of a software package marks the end of its change
implementation process. At this point, after the installable andexecutable files/code have been tested and certified, it is possible todeliver them to the customer/user. All additional information is alsoavailable for the user, such as installation instructions and modified
documentation.
The supporting organization must ensure that the distribution ofmodified software releases is well organized. This is part of the overall
SSC.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

Type of task

Description

Configuration
control

Configuration control of software during modification includes managing
individual change development and controlling different software
versions and documentation. For this reason, it is strongly
recommended to use a software development repository to ensurecompatibility between the new software packages and the existing
hardware/software configuration.
In the SSC, it is mandatory to define and document the relevant
standards and procedures.

5.4

Software support concept framework - summary
In the frame of maintenance (corrective and preventive) and operational support for hardware,
there is a clear understanding that all identified support tasks in this context do not modify the
Product design. Typical maintenance tasks like repair, replace, calibrate, clean, or lubricate canbe performed by the operator of a Product and which do not include any change in Productdesign. The same holds, for example, for inspection, test, fault location, remove/install,
disassemble/assemble, transportation or storage tasks.
Any change in hardware design must be considered in the context of Product design anddevelopment, and in the context of Product support.
The situation is similar for software. However, the activities described in Para 5.1 to Para 5.3 fallunder both software support activities, and software development activities. Those tasks areprimarily relevant for supportability analyses for software, and usually they are maintenance oroperational support tasks performed by the customer/operator. Those tasks are:−In the context of operational support tasks, refer to Para 5.3.1•
tasks for the provision of new functionality and/or ability•
tasks for recovery of a Product and for problem reporting in case of failures•organizational tasks−

In the context of management support tasks, refer to Para 5.3.2
If customers/operators carry out the management support tasks, they must be consideredin the support concept for software. Therefore, it is necessary to include those tasks in theanalysis process for maintenance (corrective and preventive) and operational support (eg,identification of corresponding task requirements and MTA), and finally include them into atechnical publication.

−

In the context of software modification tasks, refer to Para 5.3.3
In this context, modification always relates to changes in the source code. Usually,customers/operators do not perform these software modification tasks. Therefore, thosetasks do not fall under the scope of the analysis process for maintenance (corrective andpreventive) and operational support. For example, a software bug fixing activity is not a"repair" of software in the context of maintenance. It is a software design activity because
the source code will undergo modification.
Note
In some cases, and under project-specific circumstances, software modification
activities can also involve customer personnel. In these cases, the customer mustensure the availability of all required resources and know-how (eg, competentpersonnel, IT-infrastructure, databases, network connectivity, software development
environment, test tools, well known software development processes).

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

6Supportability factors
To establish proper software supportability, the analyst must consider a range of factors that
can influence software supportability, and consider all of them when determining the projectrequirements. Some of the factors relate more to operational support, while some others relate
to software modification support. Generally, these supportability factors are associated with both
software and its associated development process, or to the environment for software operationand support. Special projects can have additional aspects only partially covered by thesefactors. However, this is a good starting point for any analysis concerning supportability aspectsof software. The supportability factors are:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

6.1

Compatibility matrix (refer to Para 6.1)
Deployment (refer to Para 6.2)
Documentation (refer to Para 6.3)
Loading/unloading and installation (refer to Para 6.4)
Transportation on hardware carriers (refer to Para 6.5)
Expansion capability (refer to Para 6.6)
Modularity (refer to Para 6.7)
Modification frequency (refer to Para 6.8)
Recovery (refer to Para 6.9)
Safety integrity (refer to Para 6.10)
Security (refer to Para 6.11)
Size (refer to Para 6.12)
Competence (refer to Para 6.13)
Software distribution (refer to Para 6.14)
Standardization (refer to Para 6.15)
Technology (refer to Para 6.16)

Compatibility matrix
In systems where multiple equipment elements containing software work together in a network,
it is important that equipment compatibility is guaranteed. It is necessary to ensure that different
versions of software on different hardware items can interoperate properly in a networked
system. On the other hand, the compatibility of different versions of a software package withdifferent hardware items is also of interest. It is recommended that these compatibilities be
included in the following documents:

6.2−

Software to hardware compatibility can be documented within the LSA data within the
Product breakdown containing corresponding software parts and hardware parts. The
relationship between hardware parts and software parts can be established by the usage ofparts lists (Bill of Material, BoM). The possibility to install different issues of the same
software package can be covered by the substitute part approach.

−

A compatibility matrix concerning networked equipment carrying software packages, whichmust document the allowed configurations of the complete Product concerning compatibilityof software versions/issues is required. It is recommended to establish this matrix outside of
any LSA/SSA data.

Deployment
Software deployment is a crucial aspect for software supportability. It is necessary to provide
sufficient support to each location where software packages are in use. The customer and the
support organization must address in detail and agree on the methods to link the locations to
support capabilities (eg, installation support, user helpdesk, troubleshooting, and recovery
support).

6.3

Documentation
In general, documentation refers to two main aspects:

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00−−

supporting documentation for the software developer
supporting documentation for the software user••

end user documentation (user handbook)administrator documentation (installation/update and configuration handbook foradministrative purposes)

To ensure software supportability for the developers, documentation must conform to an agreed
standard and be available to the organization responsible for delivering software support. It isnecessary to document any software tool (eg, software development repository, compiler, bugtracker, test tools) used for software development and arrange their life cycle support.
For operational aspects, the documentation for an administrator or for a power user is ofparticular interest. The documentation must contain installation and configuration manuals, aswell as troubleshooting instructions in case of malfunctions that can be rectified easily. In caseof more severe malfunctions, the documentation must contain the relevant data for the
supporting organization that must be contacted.

6.4

Loading/unloading and installation
The duration of software loading or installation is an important aspect. Therefore, it is necessary
to optimize the software and corresponding loading devices for a proper and fast-loading
process to take place. The same applies for the unloading of data or software after special
missions or Product use. If it is necessary to download a large amount of data from a Productafter a mission, a fast and easy download procedure must be available.
Safety is an additional aspect of software/data loading. Appropriate test procedures mustensure that loading or installation was successful, and that the Product works properly.

6.5

Transportation on hardware carriers
There are aspects that must be addressed if it is necessary to transport software using
hardware devices. The type of carrier that will be selected depends on the type, size and safety
requirements of the software. Aspects can be, but not limited to:
−
−
−

6.6

Is it possible to transport the software on chip cards or USB sticks?
Do you need a DVD or even a hard disk to carry the software?
What are the safety aspects (eg, is it allowed to transport the software on a carrier, where itis easy to modify the files)?

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 to beconsidered within the overall system design. It deals with the extent to which it is possible tomodify software without being limited by restrictions on computing resources.
Examples of such constraints on computing resources are:
−
−
−
−
−
−

available memory
processor performancemass storage capacity
input/output bandwidth
database capacity
network performance

It is necessary to consider expansion capability in detail, otherwise software modification will belimited, modification costs will significantly increase and/or additional activities will be required.
Expansion capability is important in systems with fixed hardware configurations or embedded
real-time applications.

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00

6.7

Modular software design
Modularity is an attribute of the structure of a software design. A modular approach can help
structuring different areas of functionality within a software package. The choice of design
method, programming tools and programming language determine the possibilities to apply
modularity to a software design. However, in general, the optimum approach to achieve
modularity will balance functional and performance requirements against the need to provide acomprehensible and serviceable design.
Insufficient modularity can result in increased modification effort and costs because of the needto implement consequential modifications in different parts of the software.

6.8

Modification frequency
Modification frequency (also called change traffic) measures the rate at which software
modification is necessary. Before the software is in use, estimates of the modification frequency
are possible by comparing it with similar applications (eg, any data available from comparable
in-service Products on change traffic and effort will be of significant value). It is possible to usesome calculation methods based on the characteristic properties of the software to estimate thechange traffic. Investigations can also include the experience earned during test and trial
phases. Modification frequency influences stability, software integrity, and Product availability.
Change traffic significantly affects the volume of software support activity.
High modification frequency involves a higher risk of downtimes of the entire Product becauseof implementation problems or even because of bugs from new software releases. It is essential
to find a balance between the frequency of new software releases and the needs from adaptive,
perfective, or corrective requirements.

6.9

RecoveryIn case of any Product downtime caused by a software failure, it must be possible to reset theProduct to full functionality or at least to an acceptable level of degraded functionality in an
acceptable amount of time. It is necessary to consider this aspect in the early phases ofsoftware development to provide a proper instrumentation for recovery purposes. This can
include, but not limited to:−−−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 distant systems, it is crucial to have a potential recovery capability using
the available instrumentation for real-time operational upgrade (eg, download updated software
and/or data).
It is necessary to document recovery procedures completely, and the responsible users andadministrators must know them well. Testing of recovery procedures must take place before areal emergency occurs. In this case, a clear understanding of what to do and how (eg, critical
data can be restored from a data backup) must be in place. The best backup is worth nothing if
it is not possible to retrieve stored data during an emergency because of unforeseen
circumstances. It is recommended that personnel be trained to react properly, and that proper
function of recovery be regularly simulated.

6.10

Safety integrity
The safety criticality of the functions that a software package provides determine the required
safety integrity for the software package. It is recommended that the overall safety criticality of asystem be analyzed by means of an appropriate hazard analysis technique. The partitioning ofsystem functions in the system design derives from the criticality of software items. Design mustensure to minimize software items that implement critical functions, or at least segregate themfrom other parts of the software. System requirements must define safety criticality categories

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00

and the levels of software safety integrity. Constraints and requirements 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 software transportation,
installation, and operation, some activities can be necessary to achieve a sufficient safety level.
Activities such as granting of user access rights to users based on allowed software
functionalities or data areas, and transporting critical or secure data properly are important andrelevant to safety.

6.11

Security
Security is an important aspect with respect to software. There are several methods to meet
security requirements for software usage, such as:−−−−

cyclic redundancy checkencryption
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 can limit access to the software and introduce design requirements thatemphasize the importance of specific software support tasks and equipment. The security
classification of a software item will depend on its application and equipment design. Wherever
possible, software design must ensure that highly classified software parts are physicallysegregated from all other software within the Product. Security requirements provide criteria for
security classification of software items and specify modification and handling constraints
associated with such classifications.
Another aspect of security relates to operation. It is necessary to ensure that a software
package can operate in a secure environment. This means internal security concerning a proper
control policy for user access, as well as external security. Therefore, security must effectively
block intruders from outside, and limit and control the activities of internal users (eg, via theinternet). These operational security requirements can cause several support activities, such as:−−−

network administration activities (eg, granting of user access rights to specific data areas,
file servers or application services)
firewall administration activities
virus detection and defense activities

Note
Software in defense Products can contain operational data that third parties must notaccess. In this case, it must be possible for the crew to erase all software and data as fast
as possible, to prevent further use of the Product and/or access to the data.

6.12

Size
The size of software packages influences supportability parameters, in terms of expected levelof change traffic and resources required to implement modifications. The size of the software
depends on the application and the design solution. Software requirements must state any
constraints on the size of run-time software as imposed by the software design. Many software
support and supportability projections will be based on software size and complexity. Softwaredevelopment requirements must define aspects for data collection and analysis to measuresoftware size and to verify models or estimates of supportability parameters, which aredependent on software size.

6.13

Competence
It is necessary to consider the required competence for personnel involved in software-related
activities from several perspectives. The simple user must be able to handle the functions of the

Applicable to: All

S3000L-A-13-00-0000-00A-040A-A
Chap 13

DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

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. Software modification requires the highest level of competence. In this case,personnel must have appropriate software engineering knowledge. Requirements for
qualification are associated with the application domain, and the technology or methods used.
The hardware and software design, as well as the applicable software support policy will
determine competence requirements.

6.14

Software distribution
It is possible to distribute software on a variety of media, for example the internet or othernetwork solutions, such as Local Area Network (LAN) or Wide Area Network (WAN) structures.
If it is necessary to transport software using hardware devices, the type of storage medium andaccess restrictions to that medium must be taken into account.

6.15

Standardization
It is possible to apply standardization to the computing environment within which the software isoperated. The same applies to 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 personnel training, andthe costs for the required equipment at support facilities. Standardization can be helpful for
operational aspects as well (eg, standardization of loading/unloading or backup procedures toconform to existing standards).

6.16

Technology
Software engineering methods and tools used in development and implementation must
consider some technology aspects, including:
−
−
−
−
−
−

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 methods

Technology also influences operational aspects. For example, the technology of storage
devices can significantly influence support activities, and the use of network-based technologies
can dramatically ease the maintenance of client computers in a client-server application
environment.

7

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:
−
−
−
−
−
−

S3000L UoF Applicability Statement
S3000L UoF LSA Candidate
S3000L UoF Part Definition
S3000L UoF Task Requirement
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-13-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-13-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 132021-04-30 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
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Different views on costs over the Product life cycle ........................................................ 3
2.1
Life cycle cost .................................................................................................................. 3
2.2
Total cost of ownership .................................................................................................... 3
2.3
Whole life cost ................................................................................................................. 43Life cycle cost analysis process ...................................................................................... 4
3.1
General approach ............................................................................................................ 4
3.2
Aim and objective of the study ......................................................................................... 5
3.3
Develop the life cycle cost framework ............................................................................. 53.3.1
Life cycle cost breakdown structure ................................................................................ 5
3.3.2
Data and assumptions definitions document ................................................................... 6
3.3.3
Methods, models and tools .............................................................................................. 6
3.3.4
Risk and uncertainties analysis ....................................................................................... 6
3.4
LCC analysis outputs and reports ................................................................................... 6
4Life cycle cost analysis in the LSA process ..................................................................... 6
4.1
Interactions ...................................................................................................................... 6
4.2
Life cycle cost aspects during early LSA activities .......................................................... 7
4.3
Life cycle cost analysis during LSA process ................................................................... 8
4.3.1
Influence on design ......................................................................................................... 8
4.3.2
Configuration assessment ............................................................................................... 8
4.3.3
Level of repair analysis .................................................................................................... 85
Associated parts of the S3000L data model .................................................................... 8

List of tables
1

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

List of figures
1
2
3
4

Acquisition costs versus O&S costs (iceberg effect) ....................................................... 2
Relation between LCC, TCO and WLC ........................................................................... 4
Life cycle cost framework ................................................................................................ 5
Interactions between LCC and LSA ................................................................................ 7

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

References
Table 1 References
Chap No./Document No.

Title

Chap 19

Data model

NATO RTO Technical Report 028

Cost Structure and Life Cycle Costs for Military Systems

1

General1.1

Introduction
In most cases, Operating and Support (O&S) costs significantly exceed all costs of acquisition.
Therefore, the Product's initial cost (acquisition cost), its O&S costs, and disposal costs should
influence the decision to purchase a Product. Fig 1 indicates the relation between acquisition
cost and support-related cost for buying decision.

ICN-B6865-S3000L0070-002-01
Fig 1 Acquisition costs versus O&S costs (iceberg effect)
LSA identifies the support system required to meet the customer’s performance objectives interms of product usage (eg, availability, safety). In that context, LSA requirements support theminimum LCC by meeting requirements in areas such as the number of maintenance levels,
staff involved in maintenance support, maintenance training limitations, technical manuals
limitations, reliability, and Mean Time To Repair (MTTR) at each maintenance level. The LCC
analysis process can be used to estimate the cost impact of LSA requirements. Therefore, LCC
analysis results can be used as decision criteria in the LSA process to:−−−−select Candidate Items (CI)identify analysis activities for each CI
influence the design
assess the configuration

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00−

perform Level of Repair Analysis (LORA)

To the same extent, the LCC analysis process benefits from LSA as the data generated for the
related support requirements are an input for the LCC model. Therefore, it is vital to maintain acoherency between the LSA results and the Data and Assumptions Definitions Document(DADD) used for the LCC analysis. Refer to Para 3.3.

1.2

PurposeThe purpose of this chapter is to provide LSA focal points and analysts an understanding of
LCC, its use and interactions with the LSA business process. LSA focal points and analysts
must share information with LCC experts on a regular basis, to ensure that their analysis anddecisions take into consideration the economical factor.

1.3

Scope
This chapter provides an overview of the LCC aspects and indicates which information
developed by LSA processes can be used to support LCC analysis activities.

2

Different views on costs over the Product life cycle
Several terms are used to define the cumulative costs of a Product and its support environment
over its life cycle from design to disposal:
−
−
−

LCC
Total Cost of Ownership (TCO)
Whole Life Cost (WLC)

These terms have different scopes (refer to NATO RTO Technical Report 028), described in
Para 2.1, Para 2.2 and Para 2.3 respectively.
For LCC analysis activities, there is a relationship to LSA activities and results. Refer to Para 4.

2.1

Life cycle cost
LCC consists of all the direct costs plus any indirect-variable cost associated with theprocurement, operations, support and disposal of the Product. Costs depending on indirect
variables include linked costs, such as additional common support equipment, additional
administrative personnel and non-linked costs, such as new recruiters to recruit additional
personnel. LCC also includes marginal costs (both direct and indirect) for new equipment,
configuration, or capability.
LCC does not include notional allocation of costs, whereas TCO and WLC can. In addition tothat, LCC does not include any indirect-variable costs related to activities or resources notaffected by the introduction of the Product.
Note
LCC is used as the starting point to analyze alternatives and to compare options ofalternatives, and often for economic analyses.

2.2

Total cost of ownership
TCO consists of all elements that are part of LCC plus the indirect, fixed and linked costs.
These can include items such as common support equipment, common facilities, personnel
required for unit command, administration, supervision, operations planning and control, fueland munitions handling.
TCO represents all costs associated with the ownership of a system, except non-linked fixed
costs related to managing the organization.
Note
TCO is used for budgeting and optimization purposes, for the definition of services used indifferent systems, and for financial analysis.

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

2.3

Whole life cost
WLC consists of all elements that are part of TCO plus indirect, fixed, non-linked costs. These
can include items such as family housing, medical services, ceremonial units, basic training,
headquarters and staff, training academies and recruiters.
In WLC, all costs or expenses borne by the organization are linked to the relevant Products.
As WLC represents the total budget provision including elements such as headquarters costs, it
provides an overview of the allocation of all funds.
Note
WLC is used for a strategic view and high-level studies.
Fig 2 shows the relationship between the different cost classes described in Para 2.1, Para 2.2
and Para 2.3.

ICN-B6865-S3000L0071-003-01
Fig 2 Relation between LCC, TCO and WLC

3Life cycle cost analysis process

3.1

General approach
Although some changes to the LCC analysis process can be necessary based on the Product,
all LCC analysis processes have some essential steps in common. The depth of the analysis forevery step needs to be tailored to the requirements of each project.
The approach varies depending on the issues to address, the cost requirements, and theavailability of suitable data. With some variation to the details, it is possible to apply the same
LCC analysis approach to all projects, regardless of their specific requirements. This approachrequires the following steps to achieve a successful LCC analysis:−−

definition of aims and objectives of the study. Refer to Para 3.2.
development of the LCC framework. Refer to Para 3.3.
•
•
•
•

−

definition of the program content and budget within the LCC breakdown structure
identification of methods and models for the objective and the life cycle phase
identification, collection and documentation of data and assumptions necessary to
populate the LCC model
analysis of risks and uncertainties

report and presentation of the results. Refer to Para 3.4.

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

3.2

Aim and objective of the study
A clear definition of the object of study is essential to understand what the estimates will be
used for (eg, setting budgets, support options evaluation, trade-off decisions, pricing). Examplesof the range and variety of objectives are:−−−the acquisition of a new transport aircraft to fill a capability gap
the acquisition of an information management system for a medium-sized company
the modification of a large fleet of vehicles due to obsolescence

The aim and the objectives of the study will have a major impact how an LCC analysis isconducted. A different type of question will result in a different way of conducting the study. This
will often be implicit in the type of study, nevertheless it is necessary to define aim and objectiveof LCC studies clearly and unambiguously to provide useful and meaningful results.

3.3

Develop the life cycle cost framework
Fig 3 shows the different components of an LCC framework.

ICN-B6865-S3000L0072-002-01
Fig 3 Life cycle cost framework
3.3.1

Life cycle cost breakdown structure
The LCC Breakdown Structure (LCCBS) identifies all cost items affecting the total LCC of the
Product. It is necessary to define cost items in a specific way to avoid ambiguity. For that
purpose, there are five dimensions that help when defining a cost item:−−−

resources
activity
product

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

−
−

time
location

Example:Cost of technicians (resources) to maintain (activity) the engine (Product) for 25 years (time) atcompany X (location).
3.3.2

Data and assumptions definitions document
The Data and Assumptions Definitions Document (DADD) records the LCC analysis groundrules and assumptions. This includes organizational, program, technical and economic data.
The LSA can provide technical and organizational data regarding support. For this purpose, it isnecessary to keep and maintain LSA data during the in-service phase to enable LCC analysts
to use the LSA data as a dependable information source.

3.3.3

Methods, models and tools
There are many software packages for LCC analysis, but it is recommended to select the mostappropriate tools depending on:−−−

the specific Product to be analyzed
the objectives of the LCC analysis
the life cycle phase

Given the availability of several methods, it is useful to compile all results in an aggregation tool
to maintain an overview of the LCC. In particular, government customers often use a single
standard software to manage every kind of national project. Contractor and customer tools must
synchronize their LCC analyses. In some cases, tailored LCC models are more advisable.
3.3.4

Risk and uncertainties analysis
Risk and uncertainties analysis can be included within the model to provide a clear illustration of
possible cost variations in the program estimates.

3.4

LCC analysis outputs and reports
A variety of reports and graphs is available to illustrate the results of the LCC analysis andprovide a clear explanation to users/customers on the analysis outcomes and implications.
The final LCC analysis report must contain at least the purpose and scope, a summary of the
LCC framework, the results and their analysis, including sensitivity and trade-off analysis,
conclusions and recommendations.

4Life cycle cost analysis in the LSA process

4.1

Interactions
LCC analysis work starts in the early phases, before LSA begins. Therefore, LCC results are
already available once the LSA activities start. LCC results can serve as criteria to set up the
LSA program plan and framework, support the selection of LSA CI, and the identification ofanalysis activities for each LSA candidate. Refer to Fig 4.
During the LSA process, the different types of analysis, for example corrective maintenanceanalysis, Preventive Maintenance Analysis (PMA), damage and special events analysis,
Maintenance Task Analysis (MTA), or Software Support Analysis (SSA) will generate a large
amount of data. These inputs are vital for the update of the DADD of the LCC framework,
particularly with regard to resources. At the same time, LCC analysis also serves as critera to
make decisions during activities such as influence on design, configuration assessment, andLORA.

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

ICN-B6865-S3000L0073-002-01
Fig 4 Interactions between LCC and LSA

4.2Life cycle cost aspects during early LSA activities
Before LSA work starts, there are many reasons to provide LCC analysis, such as:−−−affordability analysis
business caseevaluation of alternatives

Those analyses include some useful data and assumptions, for example:−−−

Organizational and program data, such as support and maintenance organization,
operation and the quantity of the Product. ORD and CRD usually contain these data.
Technical data, such as Product breakdown structure, including physical, functional or any
other kind of Product breakdown structure as applicable, maintenance and support
characteristics of the breakdown elements based on existing analysis results (eg, weight,
reliability and testability information, duration of maintenance, periodicity of preventive
maintenance, scrap rate).
Economic data (eg, man-hour costs for different activities like design, development,
production, operation or maintenance, costs of other resources)

At this early stage, LCC models are usually based on parametric or analogy methods, with acorresponding degree of uncertainty. However, the LCC model developed identifies cost drivers
based on the breakdown elements and the corresponding support activities. This identification
serves as one decision criterion during the LSA preparation for CI and analysis selections, suchas:Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

−
−

4.3

LCC analysis can support the selection of LSA CI from the Product breakdown that are cost
drivers and have many uncertainties
For each CI selected, LCC analysis can identify the activity driver. For example, if
corrective maintenance is the activity driver, it is advisable to assess in-depth technicalFailure Modes and Effects Analysis (FMEA) results and perform MTA.

Life cycle cost analysis during LSA process
During the LSA process, it is possible to update the LCC analysis with the results of different
analysis activities. It is vital to maintain a coherency between LSA data and the DADD used for
the LCC analysis.
LCC analysis also serves as a decision criterion for other activities, such as influence on design,configuration assessment, and LORA.

4.3.1

Influence on design
For influence on design, the following steps can help in the decision-making process. However,
it is recommended to use these steps in combination with other criteria, such as safety andavailability. The steps are:
−
−
−
−
−
−

4.3.2

use the LCC model to identify breakdown element drivers (high LCC)
perform LSA to decrease the LCC support cost for these drivers and to identify LSA
requirements
analyze whether these requirements justify a design change
analyze all necessary changes together with the design department, collect data andassumptions for design, development, production and disposal activities
update LCC analysis taking into consideration new design, including LSA requirements
compare with initial LCC to quantify benefits

Configuration assessment
If any other reason, other than those stated at Para 4.3.1, requires a design change, LCC
analysis serves as decision criteria during the configuration assessment. Certain steps can help
in the decision-making process. However, these steps need to be combined with other criteriasuch as safety and availability. The steps are:−−−identify the data and assumptions in the change request
perform LSA and identify LSA requirements if the change concerns CI
update LCC analysis with all the data above

4.3.3

Level of repair analysis
LORA uses LCC analysis to evaluate alternatives in terms of levels of repair from an
economical perspective. LCC aspects that are taken into account are maintenance, spares
provisioning, training maintainers, support equipment and facilities, non-recurring and recurringcosts.

5

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:−

S3000L UoF Product and Project

Conversely, the LSA process generates data that are useful for LCC analysis. Corresponding
LSA data are included in the following UoF:−−−−

S3000L UoF Breakdown Structure
S3000L UoF Damage Definition
S3000L UoF LSA Candidate
S3000L UoF LSA Failure Mode

Applicable to: All

S3000L-A-14-00-0000-00A-040A-A
Chap 14

DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

−
−
−
−
−
−
−

S3000L UoF Part Definition
S3000L UoF Performance Parameter
S3000L UoF Product Usage Context
S3000L UoF Special Event
S3000L UoF Task
S3000L UoF Task Resources
S3000L UoF Task Usage

S3000L-A-14-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-14-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 142021-04-30 Page 9

S3000L-B6865-03000-00

Chapter 15
Obsolescence analysis
Table of contents

Page

Obsolescence analysis .................................................................................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Obsolescence strategy .................................................................................................... 3
2.1
Reactive obsolescence management ............................................................................. 3
2.2
Proactive obsolescence management ............................................................................ 4
2.3
Combination of reactive and proactive obsolescence management ............................... 4
2.4
Obsolescence monitoring ................................................................................................ 5
2.5
Strategy tools ................................................................................................................... 5
3
Develop an obsolescence management plan ................................................................. 5
3.1
Obsolescence specifications ........................................................................................... 6
3.2
Budget and life-cycle cost for obsolescence management ............................................. 6
3.3
Linking obsolescence to the risk management activity ................................................... 6
3.4
Stakeholder identification ................................................................................................ 6
3.5
Scheduling ....................................................................................................................... 7
3.6
Standards and tools ......................................................................................................... 7
3.7
Supply chain .................................................................................................................... 7
3.8
Obsolescence data .......................................................................................................... 7
4
Implementation of obsolescence solutions ...................................................................... 7
5
Ensuring obsolescence planning and management........................................................ 7
6
Associated parts of the S3000L data model .................................................................... 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

Chap 19

Data model

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_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

1

General1.1

Introduction
Obsolescence occurs due to the length of time it takes to develop and launch a Product andtheir subsequent long life cycles (refer to Fig 1). Obsolescence affects all Products andsystems, hardware and components, as well as test and support equipment, software, tools,
processes, IPS elements, standards, specifications, and expertise.

ICN-C0419-S3000L0093-003-01
Fig 1 Life cycle phases
Note
In many cases, the different life cycle phases overlap.
Obsolescence occurs for a number of reasons:
−
−

−
−

−

The life span of Product components decrease, especially in the case of electronic
components (approximately 5 years or less per innovation cycle)
The manufacturing base (eg, subcontractors and vendors) are subject to market forces.
Manufacturers can go out of business and essential parts or sub-assemblies can become
unavailable. This phenomenon is also known as Diminishing Manufacturing Sources andMaterial Shortages (DMSMS) or Diminishing Manufacturing Sources (DMS). Morespecifically, DMSMS and DMS indicate the loss or impending loss of manufacturers or
suppliers of items or raw materials. DMSMS/DMS and obsolescence are often usedinterchangeably. However, obsolescence refers to a lack of availability due to statutory orprocess changes and new designs, whereas DMSMS is a lack of sources or materials.
The loss of design and technical know-how can have a big impact on long-life cycle Productsupportability, particularly if bespoke software and components were used in the original
designThe pace of obsolescence has increased due to the ever-growing number of environmental
regulations. Those regulations determine specific chemicals (eg, Registration, Evaluation,
Authorization and Restriction of Chemicals known as REACH) or materials (eg, beryllium,
copper) can be used. It is recommended that this aspect be considered from the earliest
phases of a project.
As a result of the costs of scarce materials, production facilities and support services (eg,software maintenance), Product support can become unaffordable

The pace of technological innovation, coupled with prolonged use of Products and services,makes it almost inevitable for the obsolescence to impact the Product life cycle at some point.
Despite this, it is possible to manage and mitigate obsolescence. However, the cost ofApplicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

mitigation increases significantly as the system, Product, or service moves closer to becoming
obsolete. Therefore, it is recommended that Obsolescence Management (OM) be undertaken
as early as possible. OM must be an integral part of the preparation, development, production
and in-service support phases to minimize potential remedial expenditure and overall Life Cycle
Cost (LCC).

1.2

Purpose
The relationship between LSA and obsolescence is that both processes occur repetitively in the
Product life cycle. Obsolescence must be an integral part of the LSA process, as it affects
supportability, operability and LCC. Therefore, it is necessary to manage obsolescence andLSA closely until the disposal phase. This chapter provides a description of obsolescenceanalysis and the implementation of the associated activities. It offers guidance on obsolescenceplanning to mitigate the risk of obsolescence and minimize the LCC of long-life cycle Products.
Note
The information in this chapter gives an introduction and an overview of the issues related
to OM. Although only applicable to software, the European standard EN 62402:2007,
Obsolescence management - Application guide, provides authoritative guidance on thesubject.

1.3

Scope
The target readers of this chapter are engineering, quality, support and supply chainorganizations. It provides guidance on:
−
−
−
−
−
−
−
−

2

defining an obsolescence strategy
implementing obsolescence solutions
developing 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
identifying necessary data

Obsolescence strategy
Reactive and proactive strategies are the basic approach to managing obsolescence, and areoutlined below.

2.1

Reactive obsolescence management
Reactive OM implies that there is either no specific provision to manage obsolescence or solve
obsolescence issues when they occur. Unless occurring at the same time, each issue ishandled separately, and there is no link with the risk management activity. The budget for issue
resolution either comes from budget allocated to other activities, or from additional funds. Table
2 lists all reactive management options:
Table 2 Options for reactive obsolescence management
OptionDescription

Do nothing

This is a valid choice. The decision could be 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 can be unavoidable. Limited
design transparency can mitigate costs.

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

2.2

OptionDescription

Alternative partprocurement

This activity usually results in a search for spare parts, including theremoval of serviceable parts from an unserviceable Product to repair
another unserviceable Product and make it serviceable. This is
known as cannibalization.

Proactive obsolescence management
Proactive OM implies specific resource provision and a maintenance plan for obsolescenceissues. It is part of the risk management activities and budget is allocated to it. A group ofidentified stakeholders address the issues as they arise. Product monitoring creates time toreview resolution options and justify decisions. It is recommended that all programs consider theproactive strategy at their start. Table 3 lists all proactive OM options:
Table 3 Options for proactive obsolescence management

2.3

OptionDescription

Do nothing

As for reactive obsolescence management

Lifetime or end of lifebuy

A valid approach, which can offer the best value. However, it isnecessary to consider possible equipment life extension, changes in
consumption rates and costs of ownership (eg, storage, handling,transportation).

Planned upgrades

With planned upgrades, multiple issues can be addressed at thesame time. However, they must be coupled to obsolescencemonitoring activities whether the upgrade is required or due toobsolescence. It is also necessary to ensure sufficient spares areavailable between upgrades and budgets strictly controlled.

Obsolescencemonitoring

A key component of any OM strategy. If implemented correctly, it willat least ensure that enough time is available for planning and finding
a solution. Once the obsolescence strategy is established, it ispossible to select the preferred solution from the available options.

Design out
obsolescenceThis approach needs to be implemented in the earliest phases of a
project. The intention is to design the equipment so that asubassembly capability is not linked to a particular solution.

Combination of reactive and proactive obsolescence management
A combination of reactive and proactive OM proves to be the most suitable approach for someprojects.
This can be particularly appropriate when there is a large number of components, some ofwhich are identified as low risk. This option reduces the management cost of the OM task andfocuses on high-risk items. However, this approach entails an increased risk. In proactive OM,
costs can increase with the number of components considered and monitored. It is necessary toweigh these costs against the possible impact on availability and obsolescence rectification
costs. The cost of OM influences the choice of the strategy.
It is necessary to evaluate thoroughly the use of reactive OM in the early phases of a project. In
fact, it can be impossible to recover important information to support proactive OM later in the
project.

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

2.4

Obsolescence monitoring
There are various options available to implement the obsolescence monitoring solution. The useof the Design Authority (DA) to manage obsolescence is an obvious choice. The DA is the best
choice to develop a list of parts, identify solutions and modify the design plan. This is particularly
the case during the early phases of the project, when obsolescence analysis can influence thedesign. During the in-service phase in particular, an alternative solution is the use of a thirdparty contractor with a dedicated OM portfolio of skills. Many companies offer an OM service.
The advantages of this approach are the access to specialized skill sets and experience in theimplementation of OM. Overheads can cover many other projects, and therefore offer better
value. These companies do not have a vested interest in identifying obsolescence issues unlessthey are also contracted to identify solutions. A further option would be to employ a combinationof DA and third parties. DA can take care of the bulk of the work, while third parties can offer
specialist skills and, because of their independence, verify DA obsolescence claims, as the DA
can have a vested interest in such claims.

2.5

Strategy tools
Impact, probability and cost are essential elements in the decision-making process for OM
strategies. At first, the data supporting this process can be based solely on the judgment andexperience of the team, but this must be improved as the project progresses. The process
considers:−−−

The impact of an event on the capability of the system. It is necessary to evaluate it withthe customer or user, including all reliability, maintainability and availability aspects.
The probability of the event occurring, including possible environmental and safety
legislation aspects
The cost of an obsolescence event. This includes the total Product life cycle costaddressing the design, production and implementation elements of the system and any rework or support activity costs (total ownership cost).

These three elements are considered together to determine the classification of theobsolescence event. This classification is useful to determine the obsolescence strategy, thelevel of monitoring, the need for further investigation, and the periodicity of review.

3

Develop an obsolescence management plan
The first step in managing obsolescence is to formulate and document a comprehensive OM
plan. This document will implement the relevant strategy for the life of the Product or project. It
is recommended that this be developed at the earliest phase of the project and reviewed atleast at the end of each phase for applicability. It often starts as quite a small document but willdevelop and be refined as the lessons and decisions made during the design and development
phases are incorporated. As the project progresses, the plan will develop into a through-liferecord of the strategies employed, options considered, and decisions made. It can incorporate
the contractor's OM plan, to be provided in response to the invitation to tender and contract.
The OM plan must:
−
−
−
−
−
−

achieve the optimum compromise between life cycle cost, performance, availability andmaintainability for the entire Productcover all material, including hardware, software, tools, test equipment, human resources
and training
be compatible with the customer’s current support arrangements
provide a clear basis for obsolescence management requirement negotiation with suppliers
and partners
take into account the need for component or equipment requalification/re-certification
following component or module substitution
identify the linkages and interfaces to the risk and life cycle cost program activities

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

The OM project team defines the scope and content of the OM plan, which must reflect thescope, complexity and cost of the project. The OM plan must contain at least the aspects
covered by Para 3.1 through Para 3.8.

3.1

Obsolescence specifications
The obsolescence planning document is used to identify obsolescence issues in the Product,
record the chosen strategy, provide details of plans and OM decisions, document the reasons
why options were considered, analyses carried out and the trade-off decisions made. It is
recommended that subsidiary documentation contains a full record of the details.

3.2

Budget and life-cycle cost for obsolescence management
It is essential that budgetary provision be made for the OM task itself. OM carries its own
resource cost, that must be included in the project budget. In addition, costs for obsolescenceissues must be included as issues arise. It is necessary to review the costs regularly since theissues will vary as the project progresses. Cost forecasting must be linked to the project risk
activity to ensure a consolidated approach and avoid items are considered twice or notconsidered at all.
Obsolescence can lead to major changes in design, support concept and organization. As
obsolescence can impact all phases of a project, any option review must consider the
implications for the Product life. Therefore, OM must be linked to the LCC activities. The correct
approach to identify cost issues to be included in the appropriate management plans is anapproach that takes into consideration the complete Product life cycle.

3.3

Linking obsolescence to the risk management activity
This part considers the operational risks associated with obsolescence over the life of theequipment:−−−

What would be the impact of the Product being unavailable due to lack of spares ordegraded performance 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 on technology
advancement and new legislations)?

Obsolescence is a key contributor to any risk assessment. It is recommended that the strategy
for addressing obsolescence in risk processes be established as early as possible in the project
and be reflected in the appropriate management plans. Having good visibility of theobsolescence risks is the first essential step to minimize negative effects. This way, the project
management team will identify and implement the most appropriate action to deal with issues in
the most cost-effective way. It is essential to acknowledge that the Product user is affected themost during the in-service phase in terms of readiness, supportability, and life cycle costs.
Obsolescence is always a risk, but it can create opportunities when alternative parts offer
enhanced performance.

3.4

Stakeholder identification
This part is used to record the details of the stakeholder community personnel authorized totake decisions on trade-offs between cost and impact. OM requires input from customers, OEM,
subcontractors and, in some cases, suppliers. It is necessary to form a team with theappropriate stakeholders. Team members will vary based on the Product and potentially the
Product life cycle. The team must establish a good working relationship to gather informationand take decisions quickly. The longer it takes to implement a solution, the less chance of it
having success.

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

3.5

SchedulingThis part is used to arrange a schedule and strategy to renew Product components and allow
capability upgrades, including future Product support. The strategy will depend on the Productand can be broken down into electrical/electronic parts, systems or subsystems and nonelectrical/electronic parts, systems or subsystems. Scheduling also determines how often thescanning of the Product breakdown must occur. If scanning occurs frequently, an obsolescencealert will less likely become a serious issue. However, performing this activity more often will
result in a more expensive process.

3.6

Standards and tools
This part is used to identify obsolescence standards and to set a tool used to predict the life
cycle of electronic components, enable a review of bill of materials and predict when support for
an electronic component will no longer be available. The tool must be able to read all levels of a
Product breakdown and to predict when a component or assembly can become obsolete.

3.7

Supply chain
This part is used to maintain a record of DMSMS or DMS notices received from suppliers.
DMSMS or DMS notices alert customers that production is either stopped or limited for a
specific part. The notices usually contain part numbers, last order and shipment dates, andminimum order quantities. In OM, it is essential that DMSMS or DMS notices be collected
proactively.

3.8

Obsolescence data
This part defines a secure data repository for obsolescence data. It is essential to establish asecure area to exchange and store information. This protects the intellectual property of allparties. These data can be used again for similar Products at the same stage of their life cycle.

4

Implementation of obsolescence solutions
When obsolescence occurs, the chosen solution depends completely on the project and market
circumstances at that time. Therefore, it is necessary to treat each occurrence an individual
event and consider at least these aspects:
−
−
−
−
−
−
−
−

5

reclamation
last time buys
lifetime buys
re-manufactureuse of an interchangeable item
adaptive solutions
reverse engineering
new design

Ensuring obsolescence planning and management
Industry must develop a plan for obsolescence as early as the beginning of the design process.
Supportability engineering and logistics activities must include “obsolescence prevention”
among their objectives. This objective covers all the phases of the project. Industry must:−−−

produce an OM plan
conduct obsolescence critical analysis in the project, to identify the Product items with thehighest risk of obsolescence and, based on some predefined criteria, use similar
methodologies for safety hazard and mission critical analyses
adopt 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 on
the project

Applicable to: All

S3000L-A-15-00-0000-00A-040A-A
Chap 15

DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

−
−
−
−

−

prepare and include obsolescence risk mitigation strategies in the Statement Of Work
(SOW) for all provisioning contracts during the Product life cycle
detail OM data requirements clearly within the SOW and discuss rights of access duringcommercial negotiations
determine the obsolescence status of parts before their procurement
ensure that all stakeholders plan the most cost-effective time scales for in-service
technology updates/upgrades or technology road maps, and manage obsolescence inexisting equipment to extend its service life in line with the logistics and necessary
qualification/certification processes
apply practices already established in other projects for obsolescence mitigation wheneverdeemed convenient and cost-effective

It is essential that the invitation to tender include the requirement for an OM plan for all project
phases. Contractor’s best practices can provide the format and contents of the plan. However,the plan must at least conform to the requirements of a recognized standard. It is necessary toconsider intellectual property rights with regard to OM, to ensure access to required data to
support the OM strategy. The requirements of OM must also be considered in the context of anexit strategy, to ensure that all the data needed to manage obsolescence are available in theevent of a contract termination.
Note
One commercial strategy is to place full responsibility for obsolescence management to thecontractor. The simplest form of this hands-off solution consists of a fixed-price payment tosolve any future obsolescence issue. This solution is not optimal from a technical point ofview, but rather a more commercial or contractual approach, as it passes all liability for
future obsolescence issues to industry during a specified period. In some cases, aredistribution of the payment plan may occur by bringing forward some payments to coverpotential obsolescence issues arising during a specified period. However, this approach
has some drawbacks. Although a fee is paid to “transfer the risk to the contractor”, caremust be taken to ensure that, at a minimum, there is limited visibility from the customer side
so that he can see where action is being deferred or risk carried. These decisions canaffect the customer’s decision on whether to close the contract. Alternatively, it isrecommended that provision be made to address obsolescence risks towards contract
completion, if applicable. In addition, during the fixed-price negotiation, it can be difficult tojustify or investigate costs unless the contractor proposal includes a detailed risk-based
obsolescence cost analysis.

6

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:−

S3000L UoF Part Definition

S3000L-A-15-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-15-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 152021-04-30 Page 8

S3000L-B6865-03000-00

Chapter 16
Disposal
Table of contents

Page

Disposal 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 3
1.1
Introduction ...................................................................................................................... 3
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 42
Disposal tasks during Product life cycle phases ............................................................. 5
2.1
Concept definition phase ................................................................................................. 5
2.2
Development phase ......................................................................................................... 5
2.3
In-service phase .............................................................................................................. 6
2.4
Disposal phase ................................................................................................................ 63
Disposal analysis ............................................................................................................. 6
3.1
Disposal analysis activities .............................................................................................. 7
3.1.1
Define a disposal strategy ............................................................................................... 7
3.1.2
Integration of disposal requirements in design ................................................................ 7
3.1.3
Disposal method analysis ................................................................................................ 8
3.1.4
Hazards ........................................................................................................................... 9
3.1.5
Configuration management ............................................................................................. 9
3.1.6
Monitor and control of sub-suppliers ............................................................................... 9
3.1.7
Task input ........................................................................................................................ 9
3.1.8
Task output .................................................................................................................... 10
3.2
Disposal operation task identification ............................................................................ 10
3.2.1
Disposal process breakdown analysis .......................................................................... 10
3.2.2
Task identification .......................................................................................................... 11
3.2.3
Disposal hazard analysis ............................................................................................... 11
3.2.4
Activity input................................................................................................................... 12
3.2.5
Activity output ................................................................................................................ 12
3.3
Level of disposal analysis .............................................................................................. 12
3.4
Disposal task analysis ................................................................................................... 12
3.4.1
Task description............................................................................................................. 12
3.4.2
Task input ...................................................................................................................... 13
3.4.3
Task output .................................................................................................................... 13
4
Product disposal file ...................................................................................................... 14
4.1
Product disposal file content .......................................................................................... 14
4.2
Product disposal file compilation process ..................................................................... 15
4.3
Product disposal file data elements ............................................................................... 15
5
List of regulations........................................................................................................... 20
5.1
European Union directives ............................................................................................ 20
5.2
Transportation regulations ............................................................................................. 20
5.3
Ground vehicles ............................................................................................................. 20
5.4
Navy equipment ............................................................................................................. 21
5.5
Air equipment ................................................................................................................. 21
5.6
Ammunition .................................................................................................................... 21
5.7
Nuclear waste ................................................................................................................ 21
6
Associated parts of the S3000L data model .................................................................. 22

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

List of tables
1
2
3
4
5
6

References ...................................................................................................................... 2
Residual product .............................................................................................................. 9
Risk score examples ..................................................................................................... 11
Proposed PDF data elements ....................................................................................... 16
Environment aspect codes ............................................................................................ 18
Websites for additional information concerning disposal of nuclear waste ................... 22

List of figures
1
2
3
4

LSA aspects of disposal analysis process ...................................................................... 7
Disposal analysis activities .............................................................................................. 7
PDF compilation process ............................................................................................... 15
Example of a PDF (for a given subsystem of a Product) .............................................. 19

References
Table 1 References
Chap No./Document No.

Title

Chap 19

Data model

Chap 22

Data element list

European Community Directive 2000/53/EC

Directive on End-of Life Vehicles (ELV)

European Community Directive 2002/95/EC

Restriction of The Use of Certain Hazardous Substancesin Electrical and Electronic Equipment (RoHS)

European Community Directive 2002/96/EC

Waste Electrical and Electronic Equipment (WEEE)

European Community Directive 2006/121/EC

Registration, Evaluation, Authorization and Restriction ofChemicals (REACH)

European Union Directive 67/548/EEC

Directive on the approximation of laws, regulations andadministrative provisions relating to the classification,
packaging and labelling of dangerous substances

Regulation (EU) No 517/2014

Fluorinated Greenhouse Gases and Repealing (F-Gas)

Regulation (EU) No 850/2004

Persistent Organic Pollutants (POP)Regulation (EU) No 528/2012

Biocidal Products (BPR)

Regulation (EC) No 1907/2006, article 31
and ANNEX II

Requirements for the Compilation of Safety Data Sheets(SDS)

IAEA RS-G-1.8

Environmental and Source Monitoring for Purposes ofRadiation Protection Safety Guide

IAEA WS-G-2.7

Management of Waste from the Use of Radioactive
Material in Medicine, Industry, Agriculture, Research and
Education Safety Guide

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Chap No./Document No.

Title

IAEA INFCIRC/386

Code of Practice on the International Transboundary
Movement of Radioactive Waste

NR528 DT R03 E

Green Passport (Bureau Veritas)

IAEA SSR-5

Disposal of Radioactive Waste (2011)

IMO Resolution A.962(23)Guidelines on Ship Recycling

Resolution A.980(24)Amendments to the IMO Guidelines on Ship Recycling(Resolution A.962(23))

STANAG 4518 Edition 1 (2001)

Safe Disposal of Munitions, Design Principles andRequirements, and Safety Assessment

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.
The establishment of a procedure for disposal of hardware or software is required to ensure thatappropriate care is taken to dismantle and dispose of an individual Product (at the end of its life
cycle) and its equipment, components, structural parts and consumables in the context of
Product usage or maintenance during the whole in-service phase. It is necessary to perform
dismantling and disposal in a safe, sustainable, and environment-friendly manner.
Disposable items include hardware used for recycling purposes and to avert air, water or soil
pollution, as well as unsafe handling and dumping of hazardous materials, but also software
used to store or delete classified, confidential, or proprietary software or data.
For the purpose of an S3000L implementation, it is necessary to consider:−−−that disposal occurs only once for a complete Product during a Product life cycle. Once
disposed, the Product no longer exists
it is necessary to consider disposal constantly for all Product components, consumables orsupport equipment that are no longer usable because they are broken, damaged, expired
or at the end of their lifetime, as applicable
the probability that disposal will occur is 100%, at some point and in some manner

As a consequence, design must implement disposal requirements from the very beginning of adevelopment program. The general disposal principles to be applied are:−−to recycle as much material as possible
to minimize landfill waste resulting from the Product’s life cycle

Therefore, it is necessary to consider disposal as an important business process implemented
within the framework of an IPS/LSA program development strategy.
Disposing of a Product means phase it out at the end of the Product's service life. Typically, thedisposal of Products occurs during the last phase of their life cycle. However, it is necessary toconsider disposal from the earliest phases of every project that acquires a Product.

1.2

PurposeThis chapter provides guidance for developing disposal procedures that are proved to be safe,
efficient, environmentally acceptable, and cost effective.

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

It also provides guidance on required operations and disposal tasks for the Product to:
−
−
−
−
−
−
−

1.3

identify support resource requirements for each task
identify new or critical 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 support resource requirements
provide guidelines on the actions needed during each project phase and the methods tomeasure the effort properly
provide source data for the preparation of required IPS documents (eg, disposal
instructions, training program, manpower and personnel lists)

Scope
Disposal for hardware must consider the following aspects:−−−

the destruction/neutralization of toxic substances such as carcinogenic, mutagenic or
reprotoxic substances that can harm humans or the environment for short or long periods oftime (eg, chemicals, radioactive substances)
the sustainable development by recycling (eg, re-use of assemblies, raw material) or
converting materials into energy (eg, burning with toxic gas processing)the demilitarization of defense Products to avoid weapons proliferation and use by terroristgroups, for example

This applies to:−−

Product disposal at the end of the service life
waste generated throughout the Product operation life cycle including, but not limited to:
•
•
•
•
•
•
•
•
•
•
•
•
•
•

−

ozone depleting substances (eg, Chlorofluorocarbon (CFC), Hydro chlorofluorocarbon(HCFC), halon)
global warming effect (sustainable development)
healthcare 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
electronic scrap
complete equipment and equipment components
solid waste (eg, glass, paper, plastics)
exhaust emissions (eg, nitric oxide (NOx), sulfur oxide (SOx), carbon oxide (COx))
spares and consumables (eg, batteries, nuclear sources, oils)

all the resources deployed and used to operate and support the Product (eg, infrastructure,facilities, support equipment)

Disposal activity for software must consider specific aspects. Software/data are always
embedded in a piece of hardware. For that reason, the disposal of software requires appropriate
methods to be successful and sustainable. Those methods include, but are not limited to:−

the removal of the software from the hardware (eg, tools to clean/clear memory). It isnecessary to ensure that remaining bit structure within the hardware does not allow runningor rebuilding the software by reverse engineering.

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00−−

the corruption of the software embedded in a piece of hardware, for example by physicaldestruction of junctions in a Field Programmable Gate Array (FPGA), or in a Read-Only
Memory (ROM) module
irrevocable destruction of the hardware carrying the software, by using sustaining hardware
disposal methods like shredding, melting or etching

The disposal process influences the following project phases:−

In-service phase••

necessary provisions to design safe disposal tasks against dangerous substances
contained in the Productdisposal process of consumables and items removed as a result of operation andmaintenance tasks (limiting their impact on health and environment)

LSA data and the Product's technical publication must include this information as disposal
tasks.
−

Disposal phase•••dismantling and disassembling
demilitarization
disposal of complete Product (eg, energetic recovery, material recovery, re-use, landfill
waste)

This information is available within the Product breakdown (information for parts) and
Product Disposal 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 address the following matters appropriately:
−
−
−
−
−

2.2

a sustainable design to limit the use of scarce resources, and the environmental impact of
Product disposal
the identification of applicable health and environmental regulations (refer to Para 5)
a continuous survey (regulation watch) of list of black substances (refer to REACH
regulation, appendix 17) and grey substances (refer to REACH regulation, appendix 14)
that will be respectively forbidden and limited in use and quantity
the method definition for recording and tracking dangerous substances that can be present
in house and passed on to suppliers
an estimate of Product disposal costs

Development phase
During development phase, the disposal activity is twofold:−

Design the disposal: This includes all plans made during the Product design with asustainable development approach, such as limiting the use of scarce resources, andreducing the environmental impact of Product disposal (eg, no toxic substances,
identification of materials for easy recycling). For this, a PDF is compiled (refer to Para 4).
As part of Product data and configuration management, the Product breakdown records
carcinogenic, mutagenic or reprotoxic substances used in the Product design. Chemical
substances are identified by their Chemical Abstract Substance (CAS) code (or equivalent),
according to the REACH European regulation requirements. As the Product design
matures, the information in the PDF is updated.

−

Dispose of the design: This includes all plans made during development to prepare
further for the Product disposal phase including:Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

•

•

•

2.3

perform a Product dismantling task analysis to identify and characterize the tasks
required for Product disposal (eg, tasks duration, required resources). This can beconsidered as an extension of the Maintenance Task Analysis (MTA), using the samestructured approach.
assessing the impact of disposal on supportability elements, such as additional support
equipment required to perform Product disposal, description of disposal tasks intechnical publications, training courses to teach operators how to dispose of the
Product (including health and safety precaution)
estimate the cost of Product disposal. This can be a part of the Product global Life
Cycle Cost (LCC) analysis, using the same structured approach.

In-service phase
During this phase:−the PDF is updated to take into account:
•
•

−
−

design changes in the Product during operation and support phases
evolution of applicable regulations (eg, new banned substances, strengthening ofhealth and safety regulations)

resources required for Product disposal are produced and delivered
disposal demonstration can be performed on Product prototypes to validate:••

the relevance and completeness of information compiled in the PDF
dismantling and disposal operations (eg, people skills, technical publications contents,
adequacy of support equipment)

Disposal of equipment to be replaced (eg, batteries, oils) according to the maintenance plan
must occur in compliance with 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 to disposeof 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 to perform Product disposal (dispose of thedesign)collecting all lessons learned (eg, cost, best practice, things to avoid) to provide feedbackfor other projects

Disposal analysis
Disposal analysis needs to be tailored to the project needs (refer to Fig 1), and is the starting
point of the LSA activities logic that determines the disposal process, disposal tasks, andsupport resources required.
This analysis applies to:−−

Product components to be disposed of throughout 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-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

ICN-B6865-S3000L0089-002-01
Fig 1 LSA aspects of disposal analysis process

3.1

Disposal analysis activities
Fig 2 shows the disposal analysis logic that indicates which LSA activities to consider and tailor
for the disposal at the end of a Product’s life.

ICN-B6865-S3000L0090-001-01
Fig 2 Disposal analysis activities
3.1.1

Define a disposal strategy
Define the disposal criteria for each relevant item in the Product breakdown and establish adesign solution.

3.1.2

Integration of disposal requirements in design
Upon the development of a new Product, the disposal requirements must be balanced against
performance, reliability, safety and life cycle cost requirements.

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Design principles must be a guide for design work and design considerations. To meet planned
service life requirements, it is necessary to select all substances used in the design of the
Product and its packaging.
3.1.2.1

Recommended materials
The selection of materials to be used in the design of the Product and its packaging must aim tominimize:−−−hazards to personnel or property during preparation for disposal
hazards to personnel, property or the environment as a result of disposal processes
residual hazards from the materials which must be handled during the disposal process

It is mandatory to specify all materials and their associated hazards, in their primary state andduring the stages of the disposal process. It is necessary to define material identification andmarking processes, and include this information 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 to access 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 andtheir recyclability. The assessment must consider possible degradation and contamination ofcomponents and materials during their service life to ensure that recovery and/or recycling is
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 involved in the project. The list must include, but is not limited to:
−
−
−
−
−
−
−

3.1.3

components
materials
compatibility
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
Disposal method analysis includes:
−

−
−
−
−
−
−

the identification of potential alternative applications (re-use) for the Product and its
components, including software. The analysis demonstrates that such alternative
applications are technically achievable, environmentally acceptable, and economically
viable.
the identification of components and material that must be recycled
the identification of components and material that must be recovered
the identification of components and material that will be land waste
for each alternative above, definition of the residual products. Refer to Table 2.
a report on the results concerning disposal attributes in the Product breakdown within thepart information
disposal of sensitive information: If Products to be disposed contain proprietary, confidential
or classified software and data, the dismantling procedure includes:

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00••

the transfer of the necessary historical information to a media or other storage device
for proper preservation or historical archiving
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 of the customer / the Product owner
Table 2 Residual product3.1.4

Residual
products

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

providing an estimate of the likely levels of noise, flash, and toxic or corrosive fumes
produced at the time of operation, firing or launchingidentify any disposal hazards associated with the Product design that require additionalsafety arrangements other than the existing disposal resources
identify any residual hazards from the disposal of the Product that require additional safety
arrangement other than the existing disposal resources
considering possible means of fail safe
identify any features that can pose an unexpected hazard to operatives taking care of
explosive ordnance disposal. These features include, for example, antitampering/interference fuses or energetic materials with particularly 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

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 must meet disposal requirements. This effort applies
to equipment obtained from any supplier, regardless of tier. Review all sub-supplier contracts
and perform evaluations of their disposal procedures.
The same requirements for ordinary suppliers apply also in the case of GFE, which iscomparable to ordinary sub-supplier item.
During the subsequent phases of the development program, sub-supplier specifications must
incorporate aspects such as:
−
−
−

3.1.7

disposal requirements
design constraints and requirements
Safety Data Sheet (SDS) for Europe, or Material Safety Data Sheets (MSDS) for USA

Task input
The inputs for the identification of the disposal analysis activities are the:−−disposal strategy
disposal requirements

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00−−−

disposal criteria
Product breakdown
SDS or MSDS detailing:
•
•
•
•
•
•
•
•

•
•
•
•
•

3.1.8

the Product name used on the label, chemical and common names of ingredients thatare known to be health hazards and constitute 1% or more of the composition.
Carcinogens must be listed if their concentration equals or exceeds 0,1%.
the chemical and common names of all ingredients that present a physical hazard
when present in the mixture
relevant physical and chemical characteristics of the hazardous chemical (eg, vapor
pressure, flash point)
relevant physical hazards, including potential fire, explosion, and reactivity hazards
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 way of entry into the bodythe Occupational Safety and Health Administration permissible exposure limit andAmerican Conference of Industrial Hygienists threshold limit value. It is possible to list
additional applicable exposure limits.
whether the hazardous chemical is listed in the National Toxicology Program Annual
Report on Carcinogens (latest edition) or is considered a potential carcinogen by theInternational 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 any other responsible party that prepares or distributes the MSDS, andthat can provide additional information on the hazardous chemical and appropriate
emergency procedures, if necessary

Task output
The outputs for the identification of the disposal analysis activities are:−−scoping the disposal business process to be applied
listing a "disposal Product breakdown", detailing which items are suitable 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 must list the method recommended for disposal of the Product items. Disposal
involves two aspects:−−

dismantling the Productdisposing of materials and contaminated items, including contaminated solvents

As details of the design become available, it is mandatory to update the breakdown of therecommended process.
This requires the use of the following data elements:

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

−
−

3.2.2

disposal task identifierdisposal recovery codes for the Source Maintenance & Recoverability (SMR) code, coding
for the disposal method for the Product (eg, recycling, energy recovery, landfill waste)

Task identification
Identify and document the activities/tasks for Product/component disposal. The level ofidentification of these tasks must be commensurate with design, including disassembly
diagrams, step-by-step procedures, safety precautions and component and material tables,
taking into account possible changes due to aging, and final destination of all Productcomponents. It is mandatory to identify any special tool and equipment required and any
limitation on locations.
A task inventory is necessary for the Product and its components. It is recommended to include
this task inventory in the LSA data. Based on the disposal process breakdown analysis, andscenarios/conditions, the task inventory must identify all tasks that operators, maintainers, or
support personnel must perform with regard to disposal of the equipment/components(hardware and software). The level of detail for tasks must be commensurate with design andthe disposal scenario development. The task inventory must include a task classification thatdefines scenario/conditions, function, job and duty, task and subtasks and task resources. The
task inventory must include task descriptions, each of which consists of:−−an action verb which identifies what is to be accomplished in the task
an object which identifies the task object

Task descriptions must be clear and concise. Moreover, they must identify hazardous materials,
generation of waste, release of air and water pollutants and environmental impacts associatedwith each task. In case the same task pertains to more than one job, and therefore identified ina collective task for training purposes, the task will be identified as a collective task within thetask inventory. Task classification must define all verbs unambiguously.
3.2.3

Disposal hazard analysis
The hazard analysis of the chosen disposal process must identify the hazards related to theprocess and its products, and must classify the associated risks, eg, by defining risk scores andrisk weighing. Examples are given in Table 3.
−−−

2 = Serious
1 = Moderate
0 = Harmless
Table 3 Risk score examples

Risk Type of risk
score

Weight Hazards from planned disposal process

Total (Risk x
Weight)2

Safety3

Detonation of warhead during dismantlingof missile

6

1

Health3

Toxic gases produced by the combustion of 3
launch rocket engine propellant

1

Environmental

2

Environmentally polluting gases producedby the combustion of launch rocket engine
propellant.

2

The hazard analyses of the Product must include a description of the Product with its
configuration. The analyses must list the composition and mass of each material, along with anaggregate mass of all materials in the item. It is necessary to identify the hazards associatedApplicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

with each material, along with any special handling requirements. Analyses must describe bothprimary hazards and secondary hazards (those derived from material changes that occur as aresult of the processes used in disposal). All materials to be transported must be accompanied
by safety data sheets.
Risks to be listed and considered are, for example:
−
−
−
−
−

−

3.2.4

Activity input
The inputs for a task identification analysis for disposal are:
−
−
−
−
−
−

3.2.5

the delivery identification of any data item required (eg, to be documented in the LSA
Guidance Document (LSA GD))
the identification of equipment hardware, software and firmware on which the task will be
performed, and the level of indenture up to which this analysis is performed
the identification of the levels for disposal of hardware, software and firmware analyzed
during this activity, with the aim to identify operations and tasks
documentation requirements over and above the LSA data, such as functional flow
diagrams or drawings
a description of Product concepts under consideration
the disposal methods

Activity output
The outputs for the disposal task identification are:
−

−

3.3

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 physiologicaleffect on personnel or may damage property. The list must indicate the physical form of thematerial, route of entry and the required protection.
Trauma inducing: All non-explosive energy stores such as batteries, electrical andelectromagnetic devices, capacitors, sources of static charge, springs under tension orcompression, and any material that, when released, can transfer an amount of energy
sufficient to cause trauma. The list must indicate the expected energy output and effect,
and the required protection.
Environmental hazard: Any potential environmental hazard not already covered, including
potential damage to the atmosphere, soil and groundwater.

a task inventory documented in the LSA data, or equivalent format approved by the project,
identifying disposal task requirements. Task inventories must include task descriptions on
Product hardware, software and firmware, and must indicate the levels of indenture
specified by the project
the identification of any hazard risks involved in satisfying the requirements for disposal
operational tasks

Level of disposal analysis
Hazardous substances location in the Product breakdown will determine the level of disposal.
The Product must be dismantled and disassembled to a level that allows the use of the samedisposal method as defined in Para 4.

3.4

Disposal task analysis

3.4.1

Task description
The detailed disposal task analysis based on the principles of MTA includes the following
activities:

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00−

conducting a detailed analysis of each operation, maintenance and support task containedin the task inventory and determine:
•
•
•
•

−

−
−
3.4.2

identify new or critical task resources required to perform each task, and the hazardous
materials, hazardous waste and environmental impact requirements associated with thoseresources. New resources require development in order to disassemble the new Product.
These resources can include support and test equipment, facilities, new or specialtransportation products, new computer resources, and new test or inspection techniques.
Critical resources are not new, but the management must pay special attention due toschedule constraints, cost implications, or known scarcities. Unless otherwise required, it isnecessary to document new and modified support resources in the LSA data, or withequivalent documentation approved by the project, in order to provide a description andjustification for the resource requirement.
conduct a transportability analysis on the Product and any section thereof whendisassembling is required for transport
document the results in the LSA data, or in an equivalent format approved by the project

Task input
The inputs for a disposal task analysis are:
−
−
−
−
−
−
−

identification of Product hardware and software on which the analysis will be performed
identification of indenture levels up to which the analysis will be performed
identification of the levels of disposal operations documented during performance of thistask
known or projected shortages of task resources
any requirement for supplemental documentation over and above LSA data (eg,transportability clearance diagrams)delivery identification of any required data item
any information available from the project relative to:
•
•
•
•
•

−
−
−
−
3.4.3

task resources required to perform the task (considering all IPS elements)
elapsed time and man-hours for intended disposal facility/environment for the Productmaintenance 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 competences, capabilities, and training program
lists of standard support and test equipment
available facilities and infrastructure
available training devices
existing transportation products and capabilities

description of personnel capabilities (target audience) intended for Product disposal at eachlevel of disposal
operations and disposal task requirements from the task (disposal operations task
identification)
recommended disposal plan for the Product from the task (level of disposal analysis)
supportability and supportability-related design goals and requirements

Task output
The outputs of the disposal task analysis are:−−completed LSA data or equivalent format approved by the project on Product hardware andsoftware to the level of indenture specified by the project
identification of new or critical support resources required to operate and maintain the new
Product

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

−
−
−
−
−

4

alternative design approaches in case tasks fail to meet established goals and constraints
for the new Product, or there is an opportunity to reduce disposal costs or optimize support
resource requirements
identification of management actions to minimize the risks associated with each new or
critical support resource requirement
validation of key information documented in the LSA data
output summaries and reports as specified by the project, containing all pertinent LSA dataat the time of preparation
LSA data that is updated as soon as better information becomes available and as
applicable input data from other Product engineering programs are updated

Product disposal file
The purpose of PDF is to compile all data information regarding Product disposal. It is
mandatory to update the PDF throughout the Product life cycle, in order to reflect Productchanges (configuration management), evolution of maintenance plans, and health andenvironmental regulations modifications.
This file must allow the Product project management to clarify the operational limits of theauthorized substances over a given period, in order to anticipate the research of alternative
solutions that are more suitable in terms of:
−
−

4.1

sustainable development
health and safety impact on humans and environment

Product disposal file content
Whatever the Product, the PDF can compile information including, but not limited to:−−−−

Product breakdown and associated functional and physical description
identification of components, products or ingredients (eg, containing hydrocarbon,
lubricating, paintings) related to Product breakdown (with illustrations wherever possible)
a list of risks for people and the environment for each dangerous substance identified in the
Product
identification of the possible processing for each type of Product component at disposal,
according to the type of technology (eg, electronic, mechanic, hydraulic and pyrotechnic)
and the contained substances:
•
•

−
−
−
−
−
−
−

components immediately reusable on another Productcomponents containing high value material (eg, gems, precious metals)

methods of elimination that will differentiate potentially harmful substances and harmlessmaterial
conditions for disassembly and the destination of the components (eg, re-use, recycling,energetic valorization)
disassembly procedures down to the required level of depth, to allow all materials (harmfulor hazardous materials in particular) to benefit from the processing and their method of
elimination
rules, instructions, measurements or provisions that guarantee a sufficient level of safe
practicescollection of all safety data for all the harmful or hazardous materials composing the entire
Product
detailed, step-by-step procedures for dismantling and disposal
a list of proposed organizations certified for proper recycling and elimination of thedangerous residues, according to the applicable regulation

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

4.2

Product disposal file compilation process
The flowchart in Fig 3 shows the PDF compilation process.

ICN-B6865-S3000L0091-002-01
Fig 3 PDF compilation process

4.3

Product disposal file data elements
This paragraph presents a proposed list of data elements to be compiled in the PDF. This list is
not restrictive and must be agreed to on a case-by-case basis (eg, within LSA GC), dependingon the context of each specific project and contract.
In the first column of Table 4, text in italics refers to potential data element descriptions within a
PDF (refer to Fig 4).

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

In the second column of Table 4, text in italics refer to S3000L data elements (if applicable)
which can potentially cover the data requirement from a PDF (refer to Chap 22).
Table 4 Proposed PDF data elements
Header in PDF

Meaning

Meaning in PDF

corresponding S3000L data element, if available

Subsystem

Identifies the sub-unit to which the item belongs in the Product.

Assembly identifier

breakdownElementIdentifier

Item

Name of component according to drawing

Part namepartName

Article number

Refers to drawing identifier for unequivocal identification or otherarticle number (for some components such as screws andadhesives).

Part number

partIdentifier

Material denomination

Short description of material in component (if known)

Material description

substanceDescription

CAT

The main substances category

Material category

substanceUsageCategory
Examples:− black (forbidden)− grey (authorized with limitation)− green (authorized with no limitation)CAS

CAS code

Material code

substanceIdentifierPhrase of risk

Phrases of risk (in accordance with REACH regulation (EC) No
1907/2006 on Safety Data Sheet data)

Type of risk

substanceRiskDescription

MSDS ref.

Reference of the associated Material Safety Data Sheet
Document classified as "Material Safety Data Sheet", assigned to
the Material Class as "Reference"

MSDS

Linked as a referred document using the data structures defined in
the Unit of Functionality (UoF) Document, refer to Chap 19.

Service life

Product service life

Service life

hardwarePartOperationalAuthorizedLife

Mass [g]Weight of component (in grams)

MassquantityOfContainedSubstanceReg.

Applicable environmental regulations

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

Header in PDF

Meaning

Meaning in PDF

corresponding S3000L data element, if available

Regulations

Linked as a referred document using the data structures defined in
the UoF Document, refer to Chap 19.

SLA No.

Serial number of components

Serial number

not applicable

Risk factor (SLA)

Judged risk factor (criticality) of component (scale 1 to 4)

Risk criticality

hardwarePartHazardousClass in relation with
substanceRiskFactor

Critical property

The most important property for the function of the component

Justification

containedSubstanceJustification

Proceedings inconnection with use

Describes component disposal during the in-service phase.

Disposal concept in use

Documented in the UoF which cover all the data of a maintenancetask, refer to Chap 19.

Proceedings inconnection withplanned disposal

Describes component disposal during planned disposal.

Disposal concept end oflife

Documented in the UoF which cover all the data of a maintenancetask, refer to Chap 19.

Waste products inconnection with use

Indicates the waste products from component disposal according
to the procedure during use or after use.

Waste products in use

hardwarePartWasteProductsInUseDisposalDescription

Waste products inconnection withplanned disposal

Indicates the waste products from component disposal according
to the procedure for planned disposal.

Waste products disposal

hardwarePartWasteProductsPlannedDisposalDescription

Environmental aspects, Classification of environment aspects during use. Refer to Table 5
use
for the "environment aspect codes".
Environmental aspects in hardwarePartEnvironmentalAspectInUseClassuse
Environmental aspects, Classification of environment aspects at end of life. Refer to Table
planned disposal
5 for "environment aspect codes".
Environmental aspects
end of life

hardwarePartEnvironmentalAspectPlannedDisposalClass

Task

Dismantling tasks characterization and description, identifying
required resources and associated safety cautions to preserve
human beings and the environment.

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

Header in PDF

Meaning

Meaning in PDF

corresponding S3000L data element, if available

Task requirement

Documented in the UoF which cover all the data of a maintenancetask, refer to Chap 19.

Last updated
SLA/environs

Date of latest changes to the environmental part of the SLA

Date

not applicable

Table 5 Environment aspect codes
Code

Meaningtox

Harmful to the environment (toxic, bioaccumulation
and/or difficult to decompose)

acid

Acidification

ozon

Dangerous for the ozone layer

gwp

Greenhouse effectmw

Material waste

pos

Environmental aspects, positiveeneEnergy regaining by burning

mr

Material recycling

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

Applicable to: All

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

Thrown Burned

Stable COx,
NOx

mw ene,
gwp,
acid,
ozon

03/01/30

03/01/30
mw mr
AlThrown Recycling Al

2 Mechanicalstrength368

5,0Connector 2799541 Aluminium EN
1706 AC42000-T6
cover
Chromated Cr
Adhesive 10363883 Loctite 406

4 Adhesion

03/01/30
mw mr
Steel
Thrown Recycling Steel1 Mechanicalstrength

103,06436317 Stainless SteelSlottedISO 1207
screw MCS
M4x25

304/03/27

Thrown Burned/ Stable COx /PC mw ene,
gwp/mrrecycling

4 Mechanicalstrength

426,74113498 PC 10% glass
fibre Black

SupportStand

0,0

04/03/27

Thrown Burned/ Stable COx /PC mw ene,
gwp/mrrecycling

4 Mechanicalstrength2

1,15229068 PC 10% glass
fibre Black

Plug

PlannedPlanned
Use
Disposal
Disposal

04/03/27

Use

Thrown Burned/ Stable COx /PC mw ene,
gwp/mrrecycling

Planned
Disposal

4 Mechanicalstrength

Use

Last updated
Proceedings in Waste products in Environmental
Task SLA/
aspects
connection with connection withEnviron1(important forservice life
qualification)

Critical
Property

58,0

R
C C
SLA SLAPHR MSDS Service Mass
E
A A
No. risk[g]liferisk ref.
G
T S

4113499 PC 10% glass
fibre Black

Material
denomination(specification)

Outsidetube

Item

Articlenumber

S3000L-B6865-03000-00

Fig 4 Example of a PDF (for a given subsystem of a Product)

ICN-B6865-S3000L0092-003-01

S3000L-A-16-00-0000-00A-040A-A

Chap 162021-04-30 Page 19

S3000L-B6865-03000-00

5

List of regulations
This paragraph identifies international regulations for health, safety and environmental
conditions. It is necessary to define the applicability status of the regulations on a case-by-casebasis for each specific project and contract.

5.1

European Union directives
−
−

−

5.2

European Community Directive (2012/19/UE), Waste of Electrical and Electronic
Equipment (WEEE), in force since 2012, can be used as a guideline for target values forrecovery, recycling and re-use
European Community Directive (2006/121/EC), Registration, Evaluation and Authorizationof Chemicals (REACH), concerning the recording, evaluation and authorization of chemical
substances, as well as the restrictions applicable to these substances, and establishing a
European Chemicals Agency
European Community Directive (2002/95/EC) of the European Parliament and the Councilof 27 January 2003 on the restriction of the use of certain hazardous substances inelectrical and electronic equipment

Transportation regulations
National/state-run competent authorities must approve transportation of products recommended
to be returned for safe disposal. The authorities will issue transport certificates stating thecomponent’s transportation classification based on the UN Recommendation on the Transportof Dangerous Goods (known as the "orange book"). This international recommendation
classifies dangerous goods based on the type of risk, UN classification code, product category
codes, and UN number.
The UN number defines the packing group and packing instruction for the Product, maximum
weight of the package, and how to label the package based on the mode of conveyance. Notethat the packing itself needs to have type approval issued by a competent authority.
The recommendations need to be tailored for transportation by road, railway, sea and air,including:−−−−an agreement on Dangerous Goods by Road (Europe)
regulations concerning the International Carriage of Dangerous Goods by Rail (European
law)
IATA Dangerous Goods Regulations - international recommendation for air transports
International Maritime Dangerous Goods Code (United Nations) for sea transports

Transport certificates are often valid at a national level and they are normally valid for a
maximum of 10 years. At the time for disposal, new certificates must be applied for at thecompetent authorities concerned.

5.3

Ground vehicles
Directive 2000/53/EC of the European Parliament and of the Council on end-of-life vehicles
serves as the base for the PDF.
This directive is valid only for civilian vehicles weighing 3.5 tons or less. This directive is thebasis for the development of a future regulation that will include all civilian and military vehicles.
This directive envisages certain measures and incentives so that the dismantling phase is taken
into account from the beginning of the Product design. In particular, it will be based upon new
standards deriving from scientific progress. The principal objective of this directive is to protect
humans, animals and the environment through a better management of vehicle use. A disposal
file ensures improved vehicle management by providing adequate solutions for the assumptionof the waste responsibility or the use of replacement materials that are less harmful to theenvironment.

Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

5.4

Navy equipment
The PDF must comply with the requirements of the "green passport". These principles arestated in IMO Resolution No A.962(23), dated December 5, 2003, as amended by Resolution
No A.980(24) and Resolution A981(24), dated December 1, 2005. The latter is included ininternational texts currently in force, such as the Basel Convention on transboundary
movements of Hazardous Wastes and Their Disposal.
The A.962(23) resolution is applicable to any maritime equipment including components with a"green passport". The green passport is an instrument that aims to facilitate dismantling andrecycling operations for any ship that arrives at the end of its lifetime. This is possible byadopting good practices for the entire life cycle of the ship (respectful of environment on thelevel of the dismantling site and making safe for the personnel carrying out this work), with anaim at reducing progressively the use of any dangerous materials throughout the ship servicelife.
In order to have further information on the "green passport", refer to document NR528 publishedby Bureau Veritas.
The directives are intended to provide the flag states, port states and re-user states, owners ofships, manufacturers of ships, suppliers of navy material and recycling installations with several
indications on the "best practices", which take into account the ship recycling process
throughout the ship life cycle.
They take into account certain codes and protocols relating to environmental protection.
The list of the substances to be tracked is based on Directive 67/548/CEE of the European
Parliament and the Council, and the States can suggest adding other substances for thedrafting of the convention.

5.5

Air equipment
Currently, there are no regulations or guidelines accepted worldwide for aircraft disposal at theend of their service life.

5.6

Ammunition
The PDF will comply with the STANAG 4518 edition 1 (2001), Safe Disposal of Munitions,
Design Principles and Requirements, and Safety Assessment.
The goal of this NATO standardization agreement is to provide the NATO members with ashared source of principles and requirements of safety for the design and the evaluation
procedures, to ensure safe disposal of munitions.

5.7

Nuclear waste
Each member state of the International Atomic Energy Agency (IAEA) has its own standards tomanage nuclear waste.
However, the IAEA released the 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,
Agriculture, Research 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 on geologicaldisposal (SSR-5), co-sponsored by the Organization for Economic Co-operation andDevelopment/Nuclear Energy Agency (OECD/NEA).
Applicable to: All

S3000L-A-16-00-0000-00A-040A-A
Chap 16

DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

For further information, refer to Table 6, which includes a list of international websites.
Table 6 Websites for additional information concerning disposal of nuclear waste

6Site address

Organization

http://www.nea.fr/

Nuclear Energy Agency with 28 member states

http://www.iaea.org/

International Agency Energy Atomic with 144 member states

https://www.unscear.org/

United Nations Scientific Committee on the effects of atomic
radiation

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:
−
−
−
−
−

S3000L UoF LSA Candidate
S3000L UoF Part Definition
S3000L UoF Task Requirement
S3000L UoF Task Usage
S3000L UoF Time Limit

S3000L-A-16-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-16-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 162021-04-30 Page 22

S3000L-B6865-03000-00

Chapter 17
In-service LSA
Table of contents

Page

In-service LSA ................................................................................................................................ 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Purpose ........................................................................................................................... 3
1.2
Scope ............................................................................................................................... 3
2
Core principles of in-service LSA performance ............................................................... 4
2.1
Product modification requirements .................................................................................. 4
2.2
In Service Support Optimization (ISSO) .......................................................................... 5
2.2.1
Optimization requirements following operator's decisions .............................................. 6
2.2.2
Optimization requirements following the analysis of actual support solutions ................ 6
2.2.3
The ISSO analysis object ................................................................................................ 7
2.2.4
Data collection for ISSO analysis .................................................................................... 7
3
ISSO process................................................................................................................... 9
3.1
General assumptions ....................................................................................................... 9
3.2
ISSO phases .................................................................................................................. 10
3.3
Preparation phase ......................................................................................................... 10
3.3.1
Scope of the preparation phase .................................................................................... 10
3.3.2
Preparation phase process logic ................................................................................... 11
3.4
Analysis phase............................................................................................................... 15
3.4.1
Scope of the analysis phase .......................................................................................... 15
3.4.2
Analysis phase process logic ........................................................................................ 16
3.4.3
Overall analysis logic diagram ....................................................................................... 16
3.4.4
Detailed analysis logic diagrams for different task classes ........................................... 17
3.4.5
Example for a detailed analysis logic ............................................................................ 26
3.4.6
Evaluation of ISSO analysis results............................................................................... 30
3.5
ISSO follow-up phase .................................................................................................... 31
3.5.1
Scope of the follow-up phase ........................................................................................ 31
3.5.2
Follow-up phase aspects ............................................................................................... 31
4
Associated parts of the S3000L data model .................................................................. 32

List of tables
1
2
3
4
5
6
7
8
9
10
11
12

References ...................................................................................................................... 2
Process steps and decisions from ISSO preparation phase I ....................................... 12
Process steps and decisions from ISSO preparation phase II ...................................... 14
Process steps and decisions from overall ISSO analysis logic ..................................... 17
Process steps and decisions for corrective maintenance tasks .................................... 18
Process steps and decisions for servicing tasks ........................................................... 19
Process steps and decisions for test, fault location or inspection tasks........................ 20
Process steps and decisions for preventive maintenance packages ............................ 22
Process steps and decisions for PHST tasks ................................................................ 23
Process steps and decisions for disposal tasks ............................................................ 24
Process steps and decisions for software or data loading tasks ................................... 25
Process steps and decisions for finalization of ISSO analysis phase ........................... 30

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

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

In-service LSA process .................................................................................................... 4
ISSO preparation phase I .............................................................................................. 12
ISSO preparation phase II ............................................................................................. 14
Overall logic diagram of the ISSO analysis phase ........................................................ 16
ISSO analysis logic diagram for corrective maintenance tasks .................................... 18
ISSO analysis logic diagram for servicing tasks ............................................................ 19
ISSO analysis logic diagram for test, fault location or inspection tasks ........................ 20
ISSO analysis logic diagram for preventive maintenance packages ............................ 21
ISSO analysis logic diagram for PHST tasks ................................................................ 23
ISSO analysis logic diagram for disposal tasks ............................................................. 24
ISSO analysis logic diagram for software or data loading tasks ................................... 25
Classification of disposal tasks to prepare detailed analysis logics .............................. 26
Overarching selection logic for disposal tasks analysis ................................................ 28
Detailed logic to analyze disposal tasks for explosive materials (class 1) .................... 29
Finalization of ISSO analysis phase .............................................................................. 30

References
Table 1 References
Chap No./Document No.

Title

Chap 12Maintenance task analysis

Chap 19

Data model

S4000PInternational specification for developing and continuously
improving preventive maintenance

S5000F

International specification for operational and maintenancedata feedback

1

GeneralAny support solution developed and implemented using the LSA methodology during the earlyphases of the Product life cycle and during the design and development phase, usually meets
customer requirements concerning Product availability and Logistic Support Costs (LSC). The
solution must be effective and sustainable. However, especially for technically complex
Products with a long operating life, many different aspects will influence the support solution
implemented during the in-service phase of a Product. The support solution must consider allthese aspects to guarantee a proper support during the complete life cycle of the operated
Product.
In-service LSA takes into consideration the:−−handling of design changes (engineering changes) of the Product itself, for example
changes driven by Product improvements implemented by industry, due to obsolescence oradditional/modified technical functionality requested by the customer
handling of changes of the support scenario (eg, driven by a role change for the Product ora deployment to a different climatic environment) or of the operator's support capabilities(eg, reduced availability or even closure of maintenance facilities, changes in the customer
organization, reduction of staff)

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00−

identification of required optimization of the support solution following the operator's
feedback (eg, significant increase of LSC, supportability KPI are not met, problems during
the performance of support tasks)

The in-service LSA activities are part of the Product life cycle activities. After the Product enters
into service, it is recommended to collect, document, and prepare for a later evaluation all thein-service data that are relevant to evaluate the efficiency of the support solution. Those data
will be subject to an analysis process against defined support requirements. Those support
requirements can change several times during Product life cycle, and problems or shortcomings
appearing at later stages can influence such requirements. The LSA methodology for the inservice phase must be adapted accordingly, to ensure a continuous improvement of the support
solution for any Product, and taking into consideration all potential changes and the operator's
feedback.
As it is possible to conduct several in-service LSA iterations throughout the in-service phase, it
is vital to put in place a Configuration Management (CM) process for the results of the LSA
activities. This includes a thorough configuration control, accounting and audit. In addition, thein-service LSA relies on an operation and maintenance feedback system that needs to be inplace when the Product enters into service.

1.1

PurposeThis chapter aims to provide a methodology for defining the necessary in-service LSA activities.
This includes a process to monitor, evaluate and adapt a support solution during the in-service
period of the Product life cycle. This process is described as the In-Service Support
Optimization (ISSO) process.
Prior to a Product’s entry into service, it is necessary to define all support tasks and theresources required to support operation and maintain the Product. Reviews of the support
solution help monitoring the technical applicability and the cost-effectiveness of the current
support solution. In case of inadequacy in technical or economic terms based on suitable inservice data, it is necessary to identify, recommend and implement potential modifications to the
support solution, if applicable. All these activities contribute to ensure that:
−
−
−
−
−
−
−

the Product and its support solution are properly maintained and can therefore satisfy any
support contracts
the Product availability can be sustained or enhanced
the logistic footprint and the LSC can be kept within reasonable limits
the Product availability and LSC are reasonably balanced
the support solution is periodically reviewed and optimized, taking into account any
changes to capability, operational or environmental requirements
the support solution continues to meet the operator's capability requirements
the support solution is routinely reviewed to ensure it meets all applicable legislativerequirements

Implementing LSA activities during the in-service phase is a win-win approach for bothcustomer and contractor, because:
−
−

1.2

the contractors will have a deeper knowledge on the actual Product use, and will be able toanticipate Product support issues, therefore improving their ability to solve support issues
effectively
the operator will benefit from the continuous improvement brought by the contractor on the
Product supportability and on the support system efficiency

Scope
This chapter is applicable to the Products that enter into service and for which LSA has been
performed prior to their entry into service. It is necessary to determine on a case-by-case basis
the in-service LSA activities for the Products for which LSA has not been performed inaccordance with S3000L. The depth and extent of the in-service LSA activities will depend on

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

the depth and quality of in-service data/information available and on the scale of changes. The
drivers of these changes can be:
−

−

−
−

Product modification and mid-life updates, sometimes referred to as "technology insertion".
This option predetermines specific points during the Product life that, when reached, willprompt an update of the Product design or of some Product parts, as well as an update of
the corresponding support solution. Replacement of obsolete items will also occur.
changes to operational or environmental requirements, or changes to the operational andenvironmental conditions. It is necessary to assess those changes to identify their impact
on the current support solution. The analysis can result in changes to the Product or to the
support solution.
operator's feedback on the effectivity of the current support solution (eg, problem reports,
relevant support data to evaluate the as-is against the as-predicted situation)a need to review changes in the legislation. It is necessary to assess any impact on thecurrent support solution.

Taking into consideration all the aspects listed above, the consequence can be a potential
modification within the support solution. It is necessary to document such modifications. LSA
data provide the baseline information concerning the support solution. The first step is toanalyze any potential changes. In case the changes lead to a modified support solution, it isnecessary to implement the changes into the LSA data. Consequently, the IPS elements
forming the support solution require an update according to the changes within the LSA data.
Following this approach, it is possible to trace the IPS elements throughout the Product life
cycle. Fig 1 shows the top-level in-service IPS process.

ICN-B6865-S3000L0109-001-01
Fig 1 In-service LSA process

2

Core principles of in-service LSA performance

2.1

Product modification requirements
The main aspects already mentioned in Para 1.1 have different characteristics. The first aspect
is to implement modifications to the support solution, based on engineering changes to the
Product itself. Usually, supportability aspects do not initiate those changes. The requirementsthat can initiate those changes include, but are not limited to:Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00−

a decision to implement new equipment into the Product, due to:
•
•
•

−

requirements coming from the customer for new or improved functionality of the
Productneed for equipment or equipment components replacement due to obsolescence or
due to changed legislative requirements (eg, the use of specific substances is
prohibited)
improvement driven by industry due to technological progressa decision to modify/improve the Product in any other way, for example:
•
•
•
•
•

modification of software for equipment within the Productmodified installation location of equipment within the Productdecommission of equipment within a Productnew or improved surface protection
modification of structural components (eg, strengthening, modified material)

The implementation of modifications such as those listed above occurs after customer andcontractor agree on implementing the changes. Typically, those modifications occur during
Product retrofit or overhaul activities. Product optimization by design changes of hardware orsoftware can require some adjustments to the support solution. The LSA process accompanies
the initial design and development process, and it indicates how to identify a proper support
solution for the modified Product. New or modified equipment can lead to new or modified
support tasks and to relevant changes within the IPS elements.
It is necessary to harmonize the effort to update LSA data and the corresponding IPS elements
during the in-service phase with the design process, which considers the existing support
solution when developing a new design solution. The process follows the regular IPS process,except for potential design constraints coming from the existing in-service support solution.
The LSA data must document the consequences that Product engineering changes have on the
support solution. This includes documenting the changes to the Product breakdown, new or
modified task requirements, and new or modified support tasks following changes in the design
and the relevant MTA. The configuration management of LSA data must be a basic principle tokeep under control the different potential variants/revisions of breakdown elements (including
their realizations by different parts), task requirements, maintenance tasks and operational
support tasks.
All the changes in the LSA data must be incorporated to the IPS elements accordingly.
Note
Apart from the consequences of Product modification on corrective maintenance andoperational support tasks, and on the performance of preventive maintenance tasks, it isnecessary to evaluate whether there is a general impact on the preventive maintenanceprogram for the Product. Are there any additional PMTR? Is there a need to modify theexisting PMTR? Refer to S4000P, which covers initial PMA and the ISMO process.

2.2

In Service Support Optimization (ISSO)
The second aspect of the core principles is handling issues requiring a deeper analysis basedon the operator's experience and capability in the context of Product maintenance andoperational support. These issues can lead to reduced availability, to extended effort for
maintenance or operational support and, in this context, to increasing costs and customer
dissatisfaction.
Whenever the customer realizes and accepts an ongoing evaluation process of the actual
support solution, this triggers the performance of an ISSO process. It is possible to perform theanalysis after specific time intervals of Product use. The customer can contact the industry toanalyze the actual maintenance and operational support concept and to provide
recommendation on how to update the support solution for a better performance.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

The currently implemented support solution provides the base for any subsequent issues. This
support solution needs a task-by-task evaluation concerning its effectivity and applicability. The
evaluation process is called the ISSO process. It offers a structured approach to optimize thesupport solution of a Product after the design and development phase, and it aims to obtain therequired balance between costs and availability of the Product during a specified period of timeor use phase. It is possible to use the process for every phase of the Product’s life, after thecreation of the initial support solution. This includes the possibility to cover the end of the
Product's life or even during its disposal. A run-down plan to put a Product out of service canchange policies. Some systems must be kept in running condition while the entire Product isbeing dismantled.
The ISSO process is different from the ISMO process, which is described in S4000P. The ISMO
process deals with the preventive maintenance activities. In this context, the evaluation of
PMTR determines whether the PMTR is still valid or can/must be modified. Refer to S4000P.
2.2.1

Optimization requirements following operator's decisions
Beside the modification of the Product itself, changes initiated by the customer, and/or theoperator, can influence the support solution. Examples of decisions that can lead to amodification of the support solution include, but are not limited to:
−
−
−
−
−
−

role/functionality change for the Product in usechange in use environment, including deployment and change in geographical location or
distribution of Products
changes to task resources (eg, use of new support equipment or consumables, change ofstaff structure due to obsolescence of competences, closure of maintenance facilities)
strategic decision of the customer/operator to change the maintenance strategy (eg, no
repair activities for specific Product components on customer site any longer  selected
repair tasks shifted to industry)
strategic decision of the customer/operator to modify other parts of the in-service support
solution with respect to operational support (eg, a shipping company is in charge of specifictransport tasks for Product components, and the operator no longer performs them)
modification of the maintenance concept by including new technologies (eg, including or
removing sensors for condition-based maintenance)

Typically, the customer/operator initiates those modifications and industry/supplier does not
influence this type of decision. The consequence is often a modification of the support solution.
This means that support tasks change and require an update and/or integration in the LSA data.
The configuration management of LSA data must be a basic principle to control the different
potential variants/revisions of breakdown elements (including their realizations by different
parts), task requirements, maintenance tasks and operational support tasks. It is necessary toincorporate all the changes in the LSA data into the IPS elements accordingly.
2.2.2

Optimization requirements following the analysis of actual support solutions
In general, the second goal of an ISSO process is to identify a potential for optimization and toresolve any shortfalls in Product maintenance and operational tasks performance. Below aresome examples that show the need for optimization:−

Increasing costs:
It is necessary to determine which costs can be attributed reasonably to Product support,
and to identify cost drivers. Request data/information from operators and/or maintainers.

−

Insufficient availability of the Product:
It is necessary to clearly define the relevant type of Product availability, the calculation
method, and the equipment which significantly reduce availability. Request data/informationfrom operators and/or maintainers.

−

Are there any serious support problems relating to:

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00•••

task frequency?
significant deviations from the predicted values of supportability KPI (eg, task duration,planned and real lead times)?
success rate of a maintenance task below the required level (eg, repair tasks fail due
to a lack of competence of maintenance personnel)?

The ISSO activities generate a set of recommendations about how to optimize the support
solution or, if required, how to modify the Product.
The customer and contractor must determine in detail the goals of the ISSO process withrespect to support optimization. The customer usually indicates the focus of an ISSO process(eg, the main goal of the ISSO process is cost reduction). It is recommended that customer andcontractor prepare an ISSO Guidance Document (ISSO GD) to determine the detailed ISSO
goals and the way to monitor and verify such goals.
2.2.3

The ISSO analysis object
ISSO analysis activities focus on the analysis object task in the following context:
−
−
−
−
−

corrective maintenance tasks in terms of task performance problems and relevant
supportability KPI
operational support tasks in terms of task performance problems and relevant supportability
KPI, including servicing activities
preventive maintenance tasks in terms of task performance problems and relevant
supportability KPI. The ISSO analysis process does not include all aspects already coveredby the ISMO process of S4000P.
disposal tasks
software/data loading tasks in terms of maintenance or operational support activities

Note
Typically, the industry (both, integrator and supplier companies) is the first to perform
supportability analysis activities to accompany the design and development process.
Analysis like FMEA or PMA are often complex and need a deep technical knowledge about
the Product and/or equipment/components installed in the Product. For this reason, it is notpossible to expect feedback on this type of analysis from the operator. However, theexperience gained by the maintainers/operators in performing daily support activities to the
Product, and the support data collected systematically provide all necessary informationthat allows Product manufacturers or suppliers to perform ISSO analysis activities (sameprinciple as for the ISMO process).
The ISSO analysis effort must be limited to a reasonable extent. For this purpose, it is strongly
recommended to preselect the tasks to be analyzed. Those tasks are called the ISSO
candidates. For the selection of analysis candidates, it is necessary to define the criteria andestablish a candidate selection process. Typically, ISSO candidates are selected from therectifying tasks, which usually resolve a task requirement (refer to Chap 12). However,supporting tasks can also be relevant for ISSO analysis. For example, a complex installation
procedure for an equipment can be included in the ISSO analysis, whereas the referencing
replace procedure is not relevant, because there are no problems with removal, test after
installation, gain access or exit. However, as an ISSO principle, the supporting tasks will beanalyzed in the context of the referencing rectifying task.
It is important to consider all ISSO analysis results for supporting tasks carefully within thereferencing rectifying tasks.
2.2.4

Data collection for ISSO analysis
The success of an ISSO analysis is dependent on the possibility and on the willingness of thecustomer/operator to provide feedback to industry or to suppliers. This feedback derives fromthe experience of the operators/maintainers collected and documented during Product operationand during the performance of maintenance and operational support tasks. Documenting theApplicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

selected KPI and other data/information relevant for supportability are key to enabling acomparison between the predicted and the current situation, or to evaluating problems insupport task performance.
Each type of task will have a corresponding set of questions for the ISSO analysis phase. If nodata and/or information is available from the in-service use and support, in most cases it will be
impossible to perform an ISSO process, because the in-service information is crucial to answer
the questions related to the different types of tasks. Also refer to Para 3.3.
Note
It is recommended to consider the use and support feedback as part of an overall process
to support risk and opportunity management.
To determine the amount and accuracy of supportability information obtained from the Productin its operational environment, it is advisable to make use of the available standard reporting
systems of the customer. It is necessary to identify any shortfalls in measuring theachievements against the supportability goals established for the Product, and to verify
supportability factors not tested during the procurement phases of the Product's life cycle.
Additionally, it must be ensured to obtain the required field supportability data, which are notavailable through standard reporting systems.
For example, it is possible to implement a Data Reporting and Corrective Action System(DRACAS). DRACAS is a documented closed loop system for reporting, collecting, recording,analyzing, categorizing, investigating and taking timely effective corrective action on all
discrepancies and failures relating to design, manufacturing and test processes. DRACAS canbe viewed as a component function in the greater scheme of in-service IPS\LSA data. Even if
there is a dedicated DRACAS system and it is relatively stand-alone, the data collected canbecome part of the overall data set beneficial for IPS. It is possible to integrate suitable
opportunities for reporting into the usual maintenance practices. Facilities for reporting problems
can be part of the following systems:−−

maintenance scheduling and maintenance recording systems
Interactive Electronic Technical Publications (IETP)

Whenever possible, it is recommended to use electronic Health and Usage Monitoring Systems(HUMS) and Data Loggers (DL) to reduce the risk of human errors.
Note
A DRACAS strategy can affect the Product design and the DRACAS/HUMS/DL technicalrequirement specification, as well as the selection process for an adequate Product with aproper support system.
Upon discovering or rectifying the problem, the maintenance personnel collects the data. It ispreferable to use an approach that avoids multiple reviews or approvals of the reported
problems. The reporting person must make data traceable, to verify information or obtain moredetails. The detailed approach and the IT solution implemented for data collection must be as
user-friendly as possible. Whenever integrated into other systems, the data recording elements
usually consider the context and avoid re-entering data. For example, when reporting a new
problem encountered during a maintenance task, the option to report the problem must provide
as much information as possible.
Additionally, the in-service data collection process will include, but will not be limited to:
−
−
−
−
−

type of data
actual date and update frequency
exchange method
need for confidentiality (especially in a military environment)
intellectual property rights

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

The performance of a trade-off analysis between cost, data collection frequency and number ofoperational units to collect data from must aim to identify the best data collection plan, andensure statistical relevance. To support the provision of the capability through the in-service
phase, it is necessary to maintain supportability related data/information, which must include atleast:
−
−
−
−
−
−
−
−
−
−

Product use (eg, operating hours, distances)
operating conditions
occurrence of unknown symptoms leading to new troubleshooting procedures
unexpected failurestask frequency for corrective maintenance and operational support tasks
performance of preventive and corrective maintenance activities (including problem reports,
duration, lead times, success rate, personnel inadequacy)
consumption of spares and consumables
periods of unavailability due to maintenance activities
capacity utilization of maintenance facilities
cost factors

This determines the extent of in-service achievement of reliability and maintainability
requirements, and identifies any shortfalls in the support solution. Analyzing these data will
clarify the cause of shortfalls and, where appropriate, develop solutions and modifications for
implementation.
All available information can be used for the ISSO process. During re-evaluation, it is important
to document the reasons and assumptions made during the initial analyses and subsequentchanges to be able to trace their origin. This includes, but is not limited to, Product/systemdescriptions, safety analyses, and requirements from all sources, trails reports, any form of user
feedback, maintainer and user interviews, any changes or adaptations to technicaldocumentation, number of man-hours, price and cost evaluations, obsolescence notices andexpectance reports, and configuration baseline information.
Any product support solution should have a process in place to collect ideas from all layers of
the involved organizations to optimize the solution and provide feedback to the persons who
submitted the idea, thus ensuring a continuous process. The ISSO process must include theseideas.
Note
As an option, S5000F provides a specification to identify, document and exchange suitable
feedback data and/or information. The data/information subject to documentation must be
tailored to the concrete needs of the ISSO process. As an option, it is possible to combine
the ISSO data/information requirements with other in-service feedback requirements to
support further in-service analysis processes, for example ISMO, Failure Reporting andCorrective Action System (FRACAS) or Life Cycle Cost (LCC) analysis.

3

ISSO process

3.1

General assumptions
Several aspects determine the best way to establish an ISSO process, for example:
−
−
−
−
−
−
−

the type of Productfleet size
different use scenarios
available data/information on the operator's sidedata/information quality
required resources (personnel and budget) to perform the ISSO processchances for improvement

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

It is necessary to consider the costs and expected effectiveness of the ISSO process before
defining the process. The final decision must also include the specific phase of life of the
Product. The support solution developed for a new system is likely to be based on a set ofassumptions and estimations, and the expected life of the system is long. A Product that has
been in use for some time is likely to have many deviations from the original support concept
because of pragmatic alternative solutions based on the experience gained by the support
organization. A Product that is reaching the end of its life is likely to have a well-establishedsupport solution. The optimization effort must match the expected benefits.
Tracking KPI and reporting support problems ensure an ongoing optimization. The main driverof this optimization is the detection of deviations from previous figures, for example unexpecteddifferences in spares consumption, man-hours or failure data. This requires an in-depth
knowledge of the Product, its use and operating environment, as well as detailed information on
the origin and calculation method of the figures used for tracking. The fleet size affects thestatistical relevance of the figures and must be considered when establishing the calculation
methods.
Various situations can make it necessary to re-evaluate the support solution, thus prompting arecurrent optimization process. The initial assumptions behind the decision are likely to havechanged (eg, new use scenario, obsolete support resources on operator side, modified
maintenance concept).
The optimization after hardware or software design changes can require the optimization of the
support solution, too. This effort must be integrated in the design process, where the existingsupport solution is taken into consideration when designing the new solution. The process
follows the regular IPS process, with the exception of additional design constraints coming fromthe existing in-service support solution.

3.2

ISSO phases
The ISSO process consists of three phases:−

Preparation phase:
Definition of the framework for the ISSO effort and selection of ISSO candidates.

−

Analysis phase:In-depth analysis of ISSO candidates, and development of recommendations for
optimization.

−

Follow-up phase:
Together with the customer, evaluation of the recommendations generated during theanalysis phase and recording of the final decision. If required, further activities will bedefined and specified in order to contribute to the ongoing monitoring of the support
solution, which will be implemented as a result of the ISSO process.

3.3

Preparation phase

3.3.1

Scope of the preparation phase
The first step of the ISSO process defines the scope of the optimization:−−−

Which Products/product variants are affected?
Which maintenance and/or operational support tasks are affected?
What aspects can be improved (eg, optimization of support costs, Product availability,
reduction of resources, reduction of logistics footprint or development of skills)?

In addition, it is necessary to define a budget in terms of time and resources before
commencing the work. The corresponding ISSO GD must include all methods used for
optimization. When ordering the ISSO, the ISSO GD must be included in a contract, to ensure
all stakeholders understand and agree on the activities.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

Note
The document including the binding implementation rules for an ISSO process can be an
ISSO GD or ISSO Process and Procedure Handbook (ISSO PPH). The term PPH is also
well established, and is used for the implementation rules within S4000P, for example.
Furthermore, the term ISSO GD is used.
After signing and agreeing on the ISSO GD, the stakeholders use the selected goals toorganize the work. As a starting point, it is recommended to rank the items in such a way as tomaximize the effect on the overall Product support solution (eg, top cost drivers or availability
killers). This will reduce the risk of wasting resources. During the process, other possibilities of
optimization can appear. Any possibility for optimization must be used, provided the required
time and effort are taken into consideration. If the possible improvements have been rejected
because of time or budget constraints, it is also necessary to include previously rejected ideas
and then collected in an "idea box". When included in an overall update, the calculation canshow different results.
Fig 2 illustrates the first part of the ISSO preparation phase. It is necessary to use this firstphase to provide the general preconditions to start an ISSO process. For example, it does notmake any sense to resume the ISSO activities if the ISSO GD is not available in any form
(including as a draft that provides a basis for discussion).
3.3.2

Preparation phase process logic
The following logic diagrams present the decisions and steps necessary to set up a proper
ISSO process. After all decisions are taken and the preconditions to start the ISSO analysis aremet, specific analysis activities for the tasks selected as ISSO candidates can start.
The logic diagrams show the individual process steps (S) and decisions (D), numberedconsecutively. Each process step and decision has an alphanumeric code PXYY, where:−−−

Digit 1 : P
Digit 2 : X
Digit 3,4 : YY

Code for the ISSO preparation phase (always "P" for Preparation)
Code for the type of logic diagram element ("S"= step, "D"= decision)
Number, ascending from 01 to 99

Table 2 and Table 3 provide details on the process steps and decisions.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

ICN-B6865-S3000L0130-001-01
Fig 2 ISSO preparation phase I
When all preconditions are met to a sufficient extent, it is possible to close ISSO preparation
phase I. Table 2 illustrates all the decisions and steps included in this phase.
Table 2 Process steps and decisions from ISSO preparation phase I
CodeDescription

PD01

An ISSO GD is crucial for an ISSO program. After establishing clear implementation
rules, it is possible to start the process.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

Code

Description

PS01

The customer and contractor must define, agree to and sign clear implementation
rules. If this precondition is not given, the customer must indicate how to proceed.

PD02

LSA data is a source of information useful in selecting the ISSO candidates anddocumenting the results of the ISSO program. This includes documenting all required
support solution changes within the LSA data, and coordinating all the corresponding
changes required within the IPS elements.

PS02

If no LSA data is available, it is necessary to determine an alternative methodology to
document the changes of the support solution. LSA data is a perfect option, because
LSA data typically include information about, for example, Product breakdown, task
requirements and support tasks (including the complete MTA).

PD03

Determining the extent of the in-service experience earned is vital to take decisions. It
is of crucial relevance to make available any piece of information that can help evaluate
any issues about the existing maintenance or operational support tasks. This type of
information is necessary to analyze everything that has occurred during repair
activities, operational support and Product servicing, as well as to analyze problems or
unexpected deviations of the KPI detected by the maintainer or operator.
In addition to databases or tools populated during the Product operation and support,
the experience of the operators/maintainers provides a lot of valuable information. It isnecessary to consider this source of information during this phase, to interview all
relevant personnel and document the result of the interviews carefully. It is strongly
recommended to use this input during the ISSO candidate selection and the ISSO
analysis phase.

PD04

It is necessary to decide whether to continue the ISSO process despite non-existent orvery limited in-service data/information. In most cases, it is better to postpone the ISSO
cycle until a better information basis is available.

PS03

Consequence of unavailable in-service data/information.

PD05

It is necessary to evaluate the available in-service data/information to ensure the best
possible quality and validity. A large collection of data can be useless if the data it
contains is outdated, unreliable, incomplete, or invalid with respect to the last operating
conditions of the Product, last Product configuration, etc.

PS04

If available in-service data/information seem insufficient, it is necessary to seek
additional information sources or possibilities to update/improve the existingdata/information.

PD06

Evaluate the results of PS04. If the updated in-service data/information show asignificant improvement, and if the currently available data/information are suitable for
an ISSO program, continue with the ISSO candidate selection as the second part of the
ISSO preparation phase. Otherwise, go to PS05.

PS05

The update/improvement of the in-service data was not successful. In this case, it isnecessary to analyze the data again. This determines whether it makes sense to start
the ISSO program with the available data/information, bearing in mind that theconditions are not ideal. Try to activate additional information sources. However, if it is
not possible to establish a satisfying data/information basis, move to PS03 andpostpone the ISSO program.

PS06

Go to ISSO preparation phase II for the ISSO candidate selection.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

After the ISSO preparation phase I, the scope concerning the ISSO candidates is determined,
as illustrated in Fig 3. Table 3 illustrates all the decisions and steps included in ISSO
preparation phase II.

ICN-B6865-S3000L0131-001-01
Fig 3 ISSO preparation phase II
Table 3 Process steps and decisions from ISSO preparation phase II
Code

Description

PD07

If the ISSO GD illustrates the scope of the ISSO program in detail, it is not necessary to
go through a detailed selection process based on defined criteria for the tasks.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

Code

Description

PS07

Based on the actual support solution, it is necessary to include all potential support
activities in the ISSO candidate selection process. The criteria justifying when a task
becomes an ISSO candidate will be applied to each task. The result will be a list oftasks relevant for the ISSO analysis phase. The ISSO candidate selection is limited torectifying tasks only. The reason for this approach is the structuring of tasks given in
Chap 12. Rectifying tasks (eg, a replace task) reference the supporting tasks (eg, aremoval of an equipment) as subtasks of the rectifying tasks. Normally, all supportingtasks documented in the LSA data are referenced at least by one rectifying task.
Consequently, the ISSO analysis automatically includes all supporting tasks referenced
by rectifying tasks selected as ISSO candidates.

PS08

If required, it is necessary to prepare the results of PS07 to assign the analysis
activities to the different stakeholders involved. For example, the different companies
taking part in a project can bear the responsibility of the data. Especially in multinational projects, it is necessary to define clearly who is responsible for LSA data,technical publication, spare part supply, or training. In the context of the complete
LSA/IPS scope, the same applies to the ISSO program.

PD08

Are there any additional tasks not documented in the LSA data or in the IPS elements,
but which were performed, for example, based on individual decisions made by theoperators/maintainers? If yes, it is necessary to determine whether those activities canalso become an ISSO candidate, which must be analyzed within an ISSO program,
especially if those activities caused problems.

PS09

Determine additional tasks to include in the ISSO program.

PS10

With the results from the ISSO candidate selection from PS07/PS08, combined with theadditional identified ISSO candidates from PS09, prepare an initial ISSO candidate list
including all identified tasks to be analyzed.

PD09

The customer must receive and approve the initial ISSO candidate list. If not approved,
continue with PS11.

PS11

If the customer has any questions on the initial ISSO candidate list, clarify them before
the customer and contractor determine the final ISSO candidate list.

PS12

After the customer and contractor reached an agreement, prepare the final ISSO
candidate list, which constitutes the binding baseline for the ISSO program.

3.4

Analysis phase

3.4.1

Scope of the analysis phase
Within the ISSO analysis phase, the maintenance and operational support tasks selected as
ISSO candidates are analyzed against a set of criteria. To ensure the best possible analysis
result, there is a classification of tasks to assign the most suitable analysis criteria to each typeof task. For each ISSO candidate, the corresponding classification leads to the specific "box ofcriteria".
Fig 4 illustrates the overall logic diagram for the complete ISSO analysis phase. As the result of
the ISSO preparation phase, the list of the ISSO candidates serves as the input to the ISSO
analysis phase. First, when starting the analysis, it is necessary to determine the correct
analysis block (marked from A to G) for the task. Table 4 illustrates all the decisions and steps
included in this phase.
The general classification of the ISSO candidates comprises the following:−corrective maintenance tasks (eg, repair, replace)

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

−
−
−
−
−
−
3.4.2

servicing tasks
test, fault location or inspection tasks
preventive maintenance packages (including single tasks within the package)
PHST tasks
disposal tasks
software or data loading tasks

Analysis phase process logic
The following logic diagrams (from Fig 4 to Fig 11) show the decisions and steps, which arenecessary to perform the required analysis activities. Table 4 to Table 11 illustrate all thedecisions and steps.
The logic diagrams show the individual process steps (S) and decisions (D) numberedconsecutively. Each process step and decision has an alphanumeric code PXYY, where:
−
−
−

3.4.3

Digit 1 : P
Digit 2 : X
Digit 3,4 : YY

Code for the ISSO analysis phase (always "A" for Analysis)
Code for the type of logic diagram element ("S"= step, "D"= decision)
Number, ascending from 01 to 99

Overall analysis logic diagram
The ISSO candidates belonging to different rectifying tasks are clustered in different analysis
areas. First, it is necessary to determine to which analysis block the task belongs. The single
logic diagrams include this decision for the different task classes.

ICN-B6865-S3000L0132-001-01
Fig 4 Overall logic diagram of the ISSO analysis phase
Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

At the end of each ISSO analysis block, it is necessary to document the analysis result for eachanalyzed task (block H). The result can be a proposal on how to resolve the identified orreported problems, for example by changing the analyzed task or suggesting that there is noneed for any change. If required, it is also possible to include an explanation for any proposal.
After block H, the analysis cycle for the next task from the ISSO candidate list starts. Finally, all
ISSO results will be evaluated to decide whether to implement the optimization proposals. For
all agreed changes, LSA data must be updated accordingly (block J).
Table 4 Process steps and decisions from overall ISSO analysis logic
Code

Description

AD01

Determine the end of the analysis phase following the analysis of the last task from the
ISSO candidate list.

AS01

Continue with the next task from the ISSO candidate list, classify the task in order tochoose the appropriate analysis block (A to G).

3.4.4

Detailed analysis logic diagrams for different task classes
The general ISSO analysis flowcharts which are presented in the following paragraphs should
be considered as the baseline for an individual ISSO process dependent on project/Productspecific requirements, for example ISSO triggers, specific assumptions for the ISSO program
given by the customer, or specific ISSO goals determined by the customer. The general logic
diagrams need to be detailed, complemented or tailored as required. The ISSO GD must
document the detailed logic diagrams that can be significantly extended. Moreover, thecustomer and the contractor who performs the ISSO program must harmonize and agree on thedetailed logic diagrams in the ISSO GD. Para 3.4.5 shows an example of detailed logic diagramfor one of the task classes. The relevant regulatory authority must harmonize and agree on any
aspects, which must be considered in the context of Product certification.

3.4.4.1

ISSO analysis logic diagram for corrective maintenance tasks
The following logic diagram represents the ISSO analysis baseline for corrective maintenancetasks:

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

ICN-B6865-S3000L0133-001-01
Fig 5 ISSO analysis logic diagram for corrective maintenance tasks
Table 5 Process steps and decisions for corrective maintenance tasks
Code

Description

AD02

Decide to start performing the activities of the analysis block for the corrective
maintenance tasks

AS02

It includes a list of potential analysis questions for corrective maintenance tasks. The
list can be complemented or tailored as required. The questions must be arranged ina logic diagram, structured in an adequate sequence, preferably with the indication ofpotential interdependencies.

AD03

Determine whether the corrective maintenance task under analysis requires any
changes/optimization (or other proposals).

AS03

If there are any recommendations about how to modify/optimize the corrective
maintenance task based on the analysis steps performed in block A, draft and justify
the proposals, as required.

AD01

After completing the analysis and documenting its result (block H), return to theoverall logic diagram to continue with the next task or to finish the ISSO analysis
phase, if all tasks of the ISSO candidate list have been analyzed.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

Note
A corrective maintenance task is not limited to repair or replace activities. Also, otheractivities, (eg, calibrations, adjustments or lubrication) can be classified as corrective
maintenance tasks.
3.4.4.2

ISSO analysis logic diagram for servicing tasks
The following logic diagram represents the ISSO analysis baseline for servicing tasks:

ICN-B6865-S3000L0134-001-01
Fig 6 ISSO analysis logic diagram for servicing tasks
Table 6 Process steps and decisions for servicing tasks
Code

Description

AD04

Decide to start performing the activities of the analysis block for the servicing tasks.

AS04

It includes a list of potential analysis questions for servicing tasks. The list can becomplemented or tailored as required. The questions must be arranged in a logic
diagram, structured in an adequate sequence, preferably with the indication of potential
interdependencies.

AD05

Determine whether the servicing task under analysis requires any changes/optimization(or other proposals).

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

3.4.4.3

Code

Description

AS05

If there are any recommendations about how to modify/optimize the servicing task
based on the analysis steps performed in block B, draft and justify the proposals, as
required.

AD01

After completing the analysis and documenting its result (block H), return to the overalllogic diagram to continue with the next task or to finish the ISSO analysis phase, if alltasks of the ISSO candidate list have been analyzed.

ISSO analysis logic diagram for test, fault location or inspection tasks
The following logic diagram represents the baseline for ISSO analysis for test, fault location or
inspection tasks:

ICN-B6865-S3000L0135-001-01
Fig 7 ISSO analysis logic diagram for test, fault location or inspection tasks
Table 7 Process steps and decisions for test, fault location or inspection tasks
Code

Description

AD06

Decide to start performing the activities of the analysis block for the test, fault location
or inspection tasks.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

3.4.4.4

Code

Description

AS06

It includes a list of potential analysis questions for test, fault location or inspection
tasks. The list can be complemented or tailored as required. The questions must be
arranged in a logic diagram, structured in an adequate sequence, preferably with theindication of potential interdependencies.

AD07

Determine whether the test, fault location or inspection task under analysis requires
any changes/optimization (or other proposals).

AS07

If there are any recommendations about how to modify/optimize the test, fault location
or inspection task based on the analysis steps performed in block C, draft and justify
the proposals, as required.

AD01

After completing the analysis and documenting its result (block H), return to the overalllogic diagram to continue with the next task or to finish the ISSO analysis phase, if alltasks from the ISSO candidate list have been analyzed.

ISSO analysis logic diagram for preventive maintenance packages
The following logic diagram represents the baseline for ISSO analysis for preventive
maintenance packages:

ICN-B6865-S3000L0136-001-01
Fig 8 ISSO analysis logic diagram for preventive maintenance packages

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

Table 8 Process steps and decisions for preventive maintenance packages

3.4.4.5

Code

Description

AD08

Decide to start performing the activities of the analysis block for the preventive
maintenance packages.

AS08

It includes a list of potential analysis questions for preventive maintenance packages.
The list can be complemented or tailored as required. The questions must be arranged
in a logic diagram, structured in an adequate sequence, preferably with the indication ofpotential interdependencies.

AD09

Determine whether the preventive maintenance package under analysis or activities
within the preventive maintenance packages require any changes/optimization (or otherproposals).

AS09

If there are any recommendations about how to modify/optimize the preventive
maintenance package or activities within the preventive maintenance package basedon the analysis steps performed in block D, draft and justify the proposals, as required.

AD01

After completing the analysis and documenting its result (block H), return to the overalllogic diagram to continue with the next task or to finish the ISSO analysis phase, if alltasks from the ISSO candidate list have been analyzed.

ISSO analysis logic diagram for PHST tasks
The following logic diagram represents the baseline for ISSO analysis for PHST tasks:

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00

ICN-B6865-S3000L0137-001-01
Fig 9 ISSO analysis logic diagram for PHST tasks
Table 9 Process steps and decisions for PHST tasks
Code

Description

AD10

Decide to start performing the activities of the analysis block for the PHST tasks.

AS10

It includes a list of potential analysis questions for PHST tasks. The list can becomplemented or tailored as required. The questions must be arranged in a logic
diagram, structured in an adequate sequence, preferably with the indication of potential
interdependencies.

AD11

Determine whether the PHST task under analysis requires any changes/optimization(or other proposals).

AS11

If there are any recommendations about how to modify/optimize the PHST task basedon the analysis steps performed in block E, draft and justify the proposals for the task
under analysis, as required.

AD01

After completing the analysis and documenting its result (block H), return to the overalllogic diagram to continue with the next task or to finish the ISSO analysis phase, if alltasks from the ISSO candidate list have been analyzed.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00

3.4.4.6

ISSO analysis logic diagram for disposal tasks
The following logic diagram represents the baseline for ISSO analysis of disposal tasks:

ICN-B6865-S3000L0138-001-01
Fig 10 ISSO analysis logic diagram for disposal tasks
Table 10 Process steps and decisions for disposal tasks
Code

Description

AD12

Decide to start performing the activities of the analysis block for the disposal tasks.

AS12

It includes a list of potential analysis questions for disposal tasks. The list can becomplemented or tailored as required. The questions must be arranged in a logic
diagram, structured in an adequate sequence, preferably with the indication of potential
interdependencies.

AD13

Determine whether the disposal task under analysis requires any changes/optimization(or other proposals).

AS13

If there are any recommendations about how to modify/optimize the disposal task
based on the analysis steps performed in block F, draft and justify the proposals, as
required.

AD01

After completing the analysis and documenting its result (block H), return to the overalllogic diagram to continue with the next task or to finish the ISSO analysis phase, if alltasks from the ISSO candidate list have been analyzed.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00

3.4.4.7

ISSO analysis logic diagram for software or data loading tasks
The following logic diagram represents the baseline for ISSO analysis for software or dataloading tasks:

ICN-B6865-S3000L0139-001-01
Fig 11 ISSO analysis logic diagram for software or data loading tasks
Table 11 Process steps and decisions for software or data loading tasks
Code

Description

AD14

Decide to start performing the activities of the analysis block for software or dataloading tasks.

AS14

It includes a list of potential analysis questions for software or data loading tasks. The
list can be complemented or tailored as required. The questions must be arranged in a
logic diagram, structured in an adequate sequence, preferably with the indication ofpotential interdependencies.

AD15

Determine whether the software or data loading task under analysis requires any
changes/optimization (or other proposals).

AS15

If there are any recommendations about how to modify/optimize the software or dataloading task based on the analysis steps performed in block G, draft and justify the
proposals, as required.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

3.4.5

Code

Description

AS16

If the answer to decision point AD14 is "NO", this means it was not possible to include
the task from the ISSO candidate list in one of the given categories. It is thennecessary to reassess the task and integrate the missing or change the misleading
category, to be able to choose the right analysis block (refer to Fig 4).

AD01

After completing the analysis and documenting its result (block H), return to the overalllogic diagram to continue with the next task or to finish the ISSO analysis phase, if alltasks from the ISSO candidate list have been analyzed.

Example for a detailed analysis logic
The generic analysis logics given in Para 3.4.4.1 to Para 3.4.4.7 are the baseline for thedevelopment of more detailed analysis logics, which typically depend on the specific Productand/or project. An ISSO GD must document those specific analysis logics. These logics are
typically more complex, and experienced personnel must prepare and adapt them to the needsof the tasks included in the ISSO activities.
In the example below, the task category "disposal task" illustrates the difference between thegeneric logic in Para 3.4.4.6 and a detailed, project-specific logic. A first step is to provide afurther classification of a disposal task based on the material that requires disposal (refer to Fig
12).

ICN-B6865-S3000L0140-001-01
Fig 12 Classification of disposal tasks to prepare detailed analysis logics

The classification of disposal tasks above allows the development of specific analysis logics foreach material that needs to be disposed within the project.
The following logic flowcharts (Fig 13 and Fig 14) are examples to show a typical structure of adetailed analysis logic documented within an ISSO GD.
Fig 13 shows the subdivision of the disposal task. The first step is to distinguish between
dangerous goods and "simple" waste. It is evident that these different types of material must
answer to different analysis questions, which determine whether a task is efficient andapplicable, and whether there can be problems during the task performance. There is a set ofquestions for the "Simple waste ready for disposal." Additionally, the different types ofdangerous goods require different analysis logics. The different types of goods shown in theexample are included the "UN Recommendations on the Transport of Dangerous Goods."

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 26

S3000L-B6865-03000-00

Fig 14 provides an example of a detailed disposal task logic for class 1 (explosive materials). It
is possible to handle all other material classes in a similar way. The analysis logic can vary foreach class, because each class has specific aspects that must be taken into consideration forthe disposal of the specific material.
The result of the analysis must always be the same. Finally, there can be a recommendation not
to change the task, there can be proposals to optimize/improve the task, or even themaintenance and support concept if the optimization/improvement of the concept proves to be
useful.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 27

S3000L-B6865-03000-00

ICN-B6865-S3000L0141-001-01
Fig 13 Overarching selection logic for disposal tasks analysis

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 28

S3000L-B6865-03000-00

ICN-B6865-S3000L0142-001-01
Fig 14 Detailed logic to analyze disposal tasks for explosive materials (class 1)

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 29

S3000L-B6865-03000-00

3.4.6

Evaluation of ISSO analysis results
After having analyzed all tasks from the ISSO candidate list, there will be a documented
analysis result for each task. In principle, there are two general categories of analysis results:−

the task can remain unchanged, because the ISSO analysis (block A to H) did not generate
any need or recommendations to modify the task or to perform other activities to improvetask performance (eg, additional training of personnel, or update of the maintenanceconcept by changing the maintenance level at which the task is performed)−

the ISSO analysis (block A to H) generated needs or recommendations to modify the task
or to perform other activities to optimize the task performance.

To complete the ISSO analysis phase, it is necessary to evaluate the task that have showed apotential for optimization. Refer to Fig 15.

ICN-B6865-S3000L0143-001-01
Fig 15 Finalization of ISSO analysis phase
Table 12 Process steps and decisions for finalization of ISSO analysis phase
Code

Description

AS17

The adequate preparation of the outcome of the ISSO analysis phase must consider
all analyzed tasks that have showed a potential for optimization. It is necessary to
divide the analyzed tasks in the Optimization Proposal List (OPL) in clusters (eg,
Product systems), and sort them based on their significance with respect to Productuse/maintenance. This ensures an effective evaluation and discussion of the issues
together with the customer.

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 30

S3000L-B6865-03000-00

Code

Description

AS18

Start the evaluation of the ISSO analysis result with the first optimization proposal
from the prepared list.

AS19

In the analysis block J, it is necessary to determine the decision logic at the basis of
ISSO results evaluation. Before starting the ISSO process, the ISSO GD must include
and document all the criteria for the evaluation of the optimization proposals. The logic
can start, but is not limited to, the questions in Fig 15, which provide a good starting
point. Using the determined logic, each optimization proposal will be "closed" by afinal decision concerning the implementation (yes/no) and identification of theactivities required to obtain the desired optimization.

AD16

If the last optimization proposal from the OPL has been evaluated and the actions totake have been decided, the ISSO analysis phase is finished.

AS20

Go to the next optimization proposal (end of OPL not reached yet)At the end of the ISSO analysis phase, it is possible to plan the implementation of all actions
resulting from the analysis performed in blocks A to J.

3.5

ISSO follow-up phase

3.5.1

Scope of the follow-up phase
In the follow-up phase, the actual implementation of modifications is one of the main activities.
Additionally, it is possible to perform further analysis and/or activities to cover specific aspects.
In this phase, it is possible to determine how to continue after performing all agreed actions.

3.5.2

Follow-up phase aspects
The follow-up phase can have different characteristics depending on the Product and theProduct use scenario. For this reason, the ISSO GD must also plan and document the follow-up
phase with all its activities.
The following list illustrates a series of aspects that can be part of the ISSO follow-up phase:
−
−
−
−
−
−
−
−

Which activities must be planned and performed to monitor the success of the implementedchanges within the tasks?
Which activities must be planned and performed to monitor the success of additional
training?
Is there a significant change in the expected Product use scenario, which requires areassessment of the support scenario (eg, maintenance scenario during a deployment or
during operation under stressful conditions)?
Were there any issues reported as in-service feedback from the customer whichsignificantly exceeded the predicted/expected values of supportability KPI?
Are there additional data/information reported by the customer/operator during the ISSO
analysis phase that must be taken into consideration also for tasks already analyzed?
Could it be beneficial to reassess some selected tasks for which no optimization potential
was detected during the first ISSO analysis? This can have a significant impact, especially
if the operators provided additional feedback during the ISSO analysis phase.
Was there an unacceptable and excessive increase of cost caused by specifictasks/equipment/systems?
Was there an unacceptable and excessive decrease of mission availability caused by
specific tasks/equipment/systems?

For the severe problem initiators:−

Is it possible to improve the situation by including industry support in the corrective and/or
preventive maintenance for a Product?

Applicable to: All

S3000L-A-17-00-0000-00A-040A-A
Chap 17

DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 31

S3000L-B6865-03000-00−−

4

Is it possible to improve the situation by introducing additional preventive maintenancetasks? Trigger PMA activities, for example based on the principles of S4000P.
Is it possible to improve the situation by making changes to the design? Is a design change
applicable, reasonable and affordable to overcome problem situations with Productoperational support and/or Product maintenance?

Associated parts of the S3000L data model
The documentation of the associated data to this chapter is supported by the following Units ofFunctionality (UoF), refer to Chap 19:−−−

S3000L UoF Decision Tree Template Definition
S3000L UoF In Service Optimization Analysis
S3000L UoF Change Information

S3000L-A-17-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-17-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 172021-04-30 Page 32

S3000L-B6865-03000-00

Chapter 18
Interrelations to other S-Series IPS specifications
Table of contents

Page

Interrelations to other S-Series IPS specifications......................................................................... 1
References ..................................................................................................................................... 2
1
General ............................................................................................................................ 2
1.1
Introduction ...................................................................................................................... 2
1.2
Purpose ........................................................................................................................... 3
1.3
Scope ............................................................................................................................... 3
2
Benefits of using the S-Series IPS specifications ............................................................ 3
2.1
Conceptual background ................................................................................................... 3
2.2
Integrated concept of operation ....................................................................................... 5
3Interrelation to engineering and supportability engineering ............................................ 5
4Interrelation to S1000D .................................................................................................... 5
4.1
Purpose of S1000D ......................................................................................................... 5
4.2
S3000L/S1000D .............................................................................................................. 6
5Interrelation to S2000M ................................................................................................... 6
5.1
Purpose of S2000M ......................................................................................................... 6
5.2
S3000L/S2000M .............................................................................................................. 7
6Interrelation to S4000P .................................................................................................... 7
6.1
Purpose of S4000P ......................................................................................................... 7
6.2
S3000L/S4000P............................................................................................................... 7
7Interrelation to S5000F .................................................................................................... 8
7.1
Purpose of S5000F .......................................................................................................... 8
7.2
S3000L/S5000F ............................................................................................................... 88Interrelation to S6000T .................................................................................................... 8
8.1
Purpose of S6000T .......................................................................................................... 88.2
S3000L/S6000T ............................................................................................................... 89Interrelation to SX000i ..................................................................................................... 9
9.1
Purpose of SX000i ........................................................................................................... 99.2
S3000L/SX000i ................................................................................................................ 9

List of tables
1

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

List of figures1
2

Acquisition logistics main business processes (1) .......................................................... 3
Acquisition logistics main business processes (2) .......................................................... 4

Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

References
Table 1 References
Chap No./Document No.

Title

Chap 1Introduction to the specification

Chap 10Development of a preventive maintenance program

Chap 17

In-Service LSA

Chap 20

Data exchange

S1000DInternational specification for technical publications using a common
source database

S1000X

Input data specification for S1000D

S2000M

International specification for material management

S2000X

Input data specification for S2000M

S3000X

Input data specification for S3000L

S4000PInternational specification for developing and continuously improving
preventive maintenance

S4000X

Input data specification for S4000P

S5000F

International specification for operational and maintenance data
feedback

S6000TInternational specification for training analysis and design

S6000X

Input data specification for S6000T

SX000iInternational guide for the use of the S-Series Integrated Logistics
Support (ILS) specifications

SX001G

Glossary for the S-Series IPS specifications

SX002D

Common data model for the S-Series IPS specifications

ASD-STE100

ASD Simplified Technical English

1

General1.1

Introduction
The S3000L specification should not be considered a standalone entity. In the environment of
the S-Series IPS specifications, there is a set of existing specifications. ASD-STE100 (Simplified
Technical English) describes the coherent usage of English language within technicalpublication. S1000D describes the development and management of technical publication.
S2000M describes the material management processes and procedures used for Productsupport. S4000P describes the analysis methodologies for Preventive Maintenance Analysis(PMA). ASD-STE100, S1000D and S2000M represent the first generation of the S-Series IPS
specifications, S3000L and S4000P represent the second generation.
The third and latest generation of S-Series IPS specifications comprises S5000F, S6000T and
SX000i. S5000F describes the exchange of in-service data and information, S6000T describes
the training needs analysis and training design activities, and finally, SX000i, as an overarchingspecification, provides a guide how to use the S-Series IPS specifications in the context of an

Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

IPS process. The S-Series IPS specifications covers the most important areas of Productsupportability.

1.2

PurposeThis chapter provides an overview about how to harmonize the existing S-Series IPS
specifications and S3000L. It illustrates the common ground and benefits of combining S3000L
together with the S-Series IPS specifications S1000D, S2000M, S4000P, S5000F, S6000T and
SX000i.

1.3

Scope
The target readers for this chapter are, for example, Integrated Product Support (IPS)
managers, Logistics Support Analysis (LSA) managers and any other personnel involved insupportability analysis activities. This chapter also highlights the interdisciplinary character of
product support development.

2

Benefits of using the S-Series IPS specifications

2.1

Conceptual background
The idea to develop a suite of ASD specifications to support said processes dates back to early
1993. High-level industrial and government stakeholders took part in an international NATOacquisition logistics workshop in Paris in 1993, defining and networking the major fields of
Product support during an acquisition phase, usually for new products and major retrofit
campaigns. The principle outcome of this workshop is illustrated in Fig 1. These fields provided
the framework for the subsequent development of specifications, with the goal of covering thecomplete Product life cycle.
These major fields were:
−
−
−
−
−

Logistics Support Analysis (LSA)
scheduled maintenance analysis
provisioning
order administration
technical publications

ICN-B6865-S3000L0064-004-01
Fig 1 Acquisition logistics main business processes (1)Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

At the time of the NATO workshop in Paris in 1993, S1000D already covered the technicalpublications domain, while S2000M covered the provisioning and order administration fields.
At that time no ASD specification existed for LSA and for scheduled maintenance analysis. In
2005, the ASD together with the Aerospace Industries Association of America (AIA) started thedevelopment of S3000L, a global specification for LSA. Refer to Chap 1.
It soon became clear that additional specifications would be necessary to satisfy therequirements for the support of the full Product life cycle. Those requirements are:−−−analysis of preventive maintenance requirements (including the scheduled maintenanceanalysis field), covered by S4000P first published in May 2014
in-service data/information feedback, covered by S5000F first published in September 2016
identification of required training needs and develop training for Product operation andmaintenance, covered by S6000T first published in February 2020

Additionally, the SX000i specification provides guidelines for the complete IPS process.
Development started in September 2011 under the supervision of a team of operators,
manufacturers and regulatory authorities. SX000i was first published in December 2015.
Today, the S-Series IPS specifications comprise seven main specifications covering the major
support functions of the Product life cycle, as illustrated in Fig 2. This figure also relates back to
Fig 1 to illustrate how the main fields identified in the past are covered today by the S-Series
IPS specifications, including the fields which were added.

ICN-B6865-S3000L0065-003-01
Fig 2 Acquisition logistics main business processes (2)Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

Additional supplements that describe the data and information exchange processes (input data
specifications, for example S3000X), an overall IPS glossary SX001G and a common data
model SX002D (covering all data elements included in at least two specifications) continuously
improve and complete the S-Series IPS specifications.
Note
Certification and qualification can also require inputs from IPS disciplines (eg, technicaldocumentation, material support, support/test equipment).
Note
Fig 2 focuses on engineering support and IPS activities. However, in-service feedback canalso be provided to other stakeholders (eg, customers or certification authorities).

2.2

Integrated concept of operation
The individual specifications of the S-Series IPS specifications are not stand-alone entities. In
acquisition product support, the functional specifications serve as a coherent set of common
data definitions and integrated data exchange. This integrated concept ensures all major
functionalities are covered effectively and without any overlap. The specifications areinternationally accepted and are broadly used for example in the aerospace and defense
business, but are not limited to these areas.
S3000L plays a central role with respect to other specifications of the S-Series IPS
specifications. It is the principal tool to:−−−support the Product design relevant to reliability, maintainability, testability and support
optimization of Life Cycle Costs (LCC)
define all required resources to support the Product in its intended use and during the entire
life cycle of the Product, focusing mainly on in-service operation
maintain and update the basic Product support data and the Product maintenance concept
during the entire service life

Because of the interfaces and overlap of data elements, it is highly recommended that all IPS
guidance documents for all specifications are created in a harmonized way. This will prevent
different definitions and interpretations, and will prevent missing or superfluous data.

3

Interrelation to engineering and supportability engineering
Each of the S-Series IPS specifications are closely linked to engineering, reliability,
maintainability, testability, system safety and engineering change management. They do notcover these areas, which provide substantial input to the areas already covered by
specifications. It is necessary to document both these interfaces and the processes that definebaselines. A baseline is a configuration of a Product at a given time. This configuration is thebasis for any IPS deliverable.

4

Interrelation to S1000D

4.1

Purpose of S1000D
S1000D satisfies the need for an international specification about the production and distributionof technical publication and learning content. This specification can cover the documentation of
any type of military and civil Products.
Note
Since 2007, ASD, AIA and Air Transport Association of America (ATA) have jointly
developed, maintained and promoted S1000D at a global level.
Note
The trade organization Airlines for America (A4A) took on the role of former Air Transport
Association of America (ATA).

Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

4.2

S3000L/S1000D
The LSA process develops information/data on corrective and preventive maintenance, as well
as operational support tasks. Said information/data is the baseline for the data modules
produced in accordance with S1000D. LSA data are also the input for the maintenance planning
information.
The maintenance and operational tasks information/data must include, but is not limited to:−−task description
preliminary requirements••

required conditions
required resources (personnel, material, support equipment)

Maintenance publications use these data as a direct input for the relevant procedure.
Depending on the publication production process, procedures can include some of these data
directly.
If a full set of maintenance planning data is developed in the LSA process, it is possible totransfer these data to the maintenance planning data modules.
Note
Since it is possible to group tasks into one procedural data module or split them into several
reusable procedural data modules, there is not always a one-to-one relation between a task
originated in the LSA process and a procedural data module.
Issue 1.0 of S3000L, DEX1A&D, DEX3A&D and Issue 1.0 of the S1003X specification(S1000D, Issue 4.0 to S3000L, Issue 1.0 interchange specification) provided the original detailsof the data set to be exchanged. Chap 20 defines data exchange principles for Issue 2.0 of
S3000L.
Note
S1003X was the first interchange specification between S1000D and S3000L and has now
been replaced by S1000X which defines all inputs into S1000D from each of the S-Series
IPS specifications. To continue this level of harmonization, a step-by-step re-organization of
input specifications to develop data input requirements for each of the S-Series IPS
specifications has been started. S3000X (based on the S3000L XML schema) will be theinterface specification for S3000L and will describe the data/information requirements takenfrom other specifications (S1000D, S2000M, S4000P, S5000F and S6000T). Refer toPara 2.1.
Some of the other IPS Specifications will soon have their own input documents as well,which will include: S2000X, S4000X, S6000X.

5Interrelation to S2000M

5.1

Purpose of S2000M
S2000M originally defined the material management processes and procedures for support
activities for airborne and ground equipment used in the military field. The current issue of
S2000M includes the business processes and data applicable to both military and commercial
Products.
Widely used Enterprise Resource Planning (ERP) software (eg, SAP, Oracle) can cover the
S2000M processes to a large extent. It is possible to use S2000M as an interchange
specification to exchange material master data between two ERP systems.
The processes described within S2000M cover the interfaces between the contractor and thecustomers. Pursuant to the contractual terms, customers can be provided with the typicaldeliverables of material management, such as:

Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

−
−
−
−
−
−

5.2

provisioning
NATO codification (as a special military requirement)
procurement planningorder administration
invoicing
repair administration

S3000L/S2000M
Information/data generated during S3000L LSA activities determine the range and depth of the
Product corrective and preventive maintenance, as well as the required material resources
during in-service operation. S2000M provisioning functionality best suits interfacing with
S3000L. According to S2000M, the term “provisioning” indicates the process of selecting
support items, spare parts and consumables necessary for all Product support activities.
The prime objective of that phase is provisioning data compilation for items identified as
relevant for customer's maintenance and support activities.
Provisioning data are compiled according to the compilation rules specified in S2000M. Usually,
these rules are confirmed or modified/specified during a relevant Guidance Conference (GC).
The GC takes place at the start of any project that involves S2000M procedures and determines
to what extent LSA data will be used to support the provisioning process.
All data that is developed via S3000L that is utilized by S2000M will be defined in the S2000X
specification.
Note
It is recommended that data common to both S2000M and S3000L (eg, the name of apart/equipment) are harmonized. The IPS GC must determine the leading discipline fortechnical values (eg, a part identifier).

6Interrelation to S4000P

6.1

Purpose of S4000P
S4000P provides methodologies to develop Preventive Maintenance Task Requirements(PMTR). These PMTR are the precondition to determine which preventive maintenance tasks
will be applicable and effective for operators/manufacturers and will be accepted by regulatory
authorities (if applicable). Experts from manufacturers and/or system integrating companies will
jointly develop the PMTR and corresponding threshold details (eg, intervals, triggers).
Specifically, S4000P outlines the general organization and decision processes to define theinitial PMTR for the Product life, as well as an ongoing improvement of preventive maintenancethroughout the Product in-service phase, covered by In-Service Maintenance Optimization(ISMO).

6.2

S3000L/S4000P
Preventive maintenance focuses on the prevention of critical and catastrophic functional failuresduring operation and an adequate "reaction" on special events. S4000P provides structured andapproved methodologies to define PMTR that allows operators to use a Product safely during its
entire life cycle. It is important to mitigate identified issues as early as possible, with a view tolimiting re-design efforts and designing an applicable and effective preventive maintenanceprogram at acceptable costs. PMTR are the outcome of the S4000P process and are further
detailed during task identification and Maintenance Task Analysis (MTA) within the LSA
process.
It is possible to associate an interval with a PMTR, which is named Preventive Maintenance
Task Requirement Interval (PMTRI). Chap 10 describes the packaging process to adapt PMTRI.
A PMTR associated with a special event is named Preventive Maintenance Task Requirement
Event (PMTRE). LSA considers all these PMTR as corresponding task requirements that are

Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

associated with the corresponding rectifying preventive maintenance tasks. This workflow from
S4000P to S3000L constitutes a strong relationship between S3000L and S4000P and will bedefined within the upcoming S3000X input specification.
During the in-service phase, it is necessary to continuously scrutinize the efficiency of thecurrent preventive maintenance program, and optimize/adapt as required. For this purpose, it isrecommended that the ISMO process from S4000P be used.
A close configuration management of Product breakdown and part information between thespecifications is required to support the Product safely and effectively. Refer to Chap 10.

7Interrelation to S5000F

7.1

Purpose of S5000F
S5000F provides the in-service feedback to all relevant stakeholders with respect to in-service
data and information collected and prepared by operators/customers, with a view to supportingand improving Product maintenance and operations (refer to Fig 2).

7.2

S3000L/S5000F
It is necessary that the in-service data/information (resulting from an S5000F process) andmaintenance concept/tasks and Product support requirements (resulting from an S3000L LSA
process) be compared on a regular basis to identify any need for re-evaluation or adaptation ofcurrent support solutions. Such a comparison clarifies whether the predictions of supportability
analysis processes reflect the daily experience of the Product operators. It is necessary tocollect and compare in-service data and the existing maintenance solution, in order to optimize
the support solutions. The In-Service Support Optimization (ISSO) process in S3000L is therecommended process to structure the optimization, refer to Chap 17.
The required information for optimization differs on a case-by-case basis. S5000F has defined aset of common use cases that require the exchange of information. The definition of a data
model supports these use cases in exchanging data/information in a standardized way. S5000F
provides the unfiltered data/information without processing or condensing it. Feedback
data/information evaluation is part of the requiring processes, for S3000L for example the ISSO
process.
S3000X will identify the use cases and data required as inputs from S5000F to support S3000L
requirements.

8Interrelation to S6000T

8.1

Purpose of S6000T
S6000T defines all levels of analysis and training design to deliver relevant and effective
Product training. This includes the Training Situation Analysis (TSA) and Training Needs
Analysis (TNA), respectively.

8.2

S3000L/S6000T
LSA data provide an overview of all maintenance and support tasks, and how they must be
performed, as a result of the MTA. This LSA data is a key input to perform TSA and TNA,
respectively. In particular, the TNA requires information to decide whether a task needs specifictraining and if so, how the training can be provided. Each support task identified and analyzed
during the LSA process is checked concerning training needs.
Typically, LSA data already contain information about required competence of themaintainer/operator performing the task. Additionally, LSA data contain details how to performthe task (including warnings and cautions) and which material resources are required (eg,support equipment, spare parts, consumables).
S3000L LSA data is the main information source to support the initial analysis activities in theframe of S6000T and will be documented as S6000T inputs via S6000X.

Applicable to: All

S3000L-A-18-00-0000-00A-040A-A
Chap 18

DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

9Interrelation to SX000i

9.1

Purpose of SX000i
SX000i aims to establish a common understanding of IPS and defines a common and generic
IPS process throughout the life cycle of a Product.
SX000i provides an explanation how to apply the S-Series IPS specifications in an IPS
program. It provides a set of suitable IPS activities to enable a standard-based communicationand information/data exchange among involved stakeholders to achieve the main IPS
objectives:−−−

design the Product for optimal support
initiate the most cost-effective support solution
acquire and provide the support for the Product

An LSA program based on S3000L is a part of an IPS program and is a binding data/information
source for processes defined by the other S-Series IPS specifications.

9.2

S3000L/SX000i
LSA and IPS are closely related. As described in this specification, the LSA process is thecentral tool to achieve an integrated development of deliverables of the IPS elements in close
relation to the design of the supported Product. SX000i describes the connection between LSA,
as a central supportability analysis process, and IPS as an effective management process overthe entire lifetime of complex and durable Products.

S3000L-A-18-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-18-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 182021-04-30 Page 9

S3000L-B6865-03000-00

Chapter 19
Data model
Table of contents

Page

Data model ..................................................................................................................................... 1
References ..................................................................................................................................... 5
1
General ............................................................................................................................ 6
1.1
Introduction ...................................................................................................................... 6
1.2
Scope ............................................................................................................................... 6
1.3
Out of scope .................................................................................................................... 6
2
Data model overview ....................................................................................................... 6
3
Data model units of functionality...................................................................................... 9
3.1
S3000L UoF Aggregated Element................................................................................... 9
3.1.1
Description ....................................................................................................................... 9
3.1.2
Graphical description ....................................................................................................... 9
3.1.3
Class definition .............................................................................................................. 10
3.2
S3000L UoF Applicability Statement ............................................................................. 12
3.2.1
Description ..................................................................................................................... 12
3.2.2
Graphical description ..................................................................................................... 13
3.2.3
Class definition .............................................................................................................. 14
3.3
S3000L UoF Breakdown Structure ................................................................................ 22
3.3.1
Description ..................................................................................................................... 22
3.3.2
Graphical description ..................................................................................................... 23
3.3.3
Class definition .............................................................................................................. 23
3.4
S3000L UoF Change Information .................................................................................. 29
3.4.1
Description ..................................................................................................................... 29
3.4.2
Graphical description ..................................................................................................... 29
3.4.3
Class definition .............................................................................................................. 30
3.5
S3000L UoF Circuit Breaker .......................................................................................... 31
3.5.1
Description ..................................................................................................................... 31
3.5.2
Graphical description ..................................................................................................... 32
3.5.3
Class definition .............................................................................................................. 32
3.6
S3000L UoF Competence Definition ............................................................................. 33
3.6.1
Description ..................................................................................................................... 33
3.6.2
Graphical description ..................................................................................................... 34
3.6.3
Class definition .............................................................................................................. 34
3.7
S3000L UoF Damage Definition .................................................................................... 36
3.7.1
Description ..................................................................................................................... 36
3.7.2
Graphical description ..................................................................................................... 36
3.7.3
Class definition .............................................................................................................. 37
3.8
S3000L UoF Decision Tree Template Definition ........................................................... 39
3.8.1
Description ..................................................................................................................... 39
3.8.2
Graphical description ..................................................................................................... 40
3.8.3
Class definition .............................................................................................................. 40
3.9
S3000L UoF Design Change Request .......................................................................... 44
3.9.1
Description ..................................................................................................................... 44
3.9.2
Graphical description ..................................................................................................... 45
3.9.3
Class definition .............................................................................................................. 45
3.10
S3000L UoF Digital File ................................................................................................. 47
3.10.1 Description ..................................................................................................................... 47
3.10.2 Graphical description ..................................................................................................... 47
3.10.3 Class definition .............................................................................................................. 49
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 1

S3000L-B6865-03000-00

3.11
3.11.1
3.11.2
3.11.33.12
3.12.1
3.12.2
3.12.33.13
3.13.1
3.13.2
3.13.33.14
3.14.1
3.14.2
3.14.33.15
3.15.1
3.15.2
3.15.33.16
3.16.1
3.16.2
3.16.33.17
3.17.1
3.17.2
3.17.33.18
3.18.1
3.18.2
3.18.33.19
3.19.1
3.19.2
3.19.33.20
3.20.1
3.20.2
3.20.33.21
3.21.1
3.21.2
3.21.33.22
3.22.1
3.22.2
3.22.33.23
3.23.1
3.23.2
3.23.33.24
3.24.1
3.24.2
3.24.3
3.25

S3000L UoF Document ................................................................................................. 52
Description ..................................................................................................................... 52
Graphical description ..................................................................................................... 53
Class definition .............................................................................................................. 54
S3000L UoF Environment Definition ............................................................................. 60
Description ..................................................................................................................... 60
Graphical description ..................................................................................................... 60
Class definition .............................................................................................................. 61
S3000L UoF Facility ...................................................................................................... 63
Description ..................................................................................................................... 63
Graphical description ..................................................................................................... 64
Class definition .............................................................................................................. 64
S3000L UoF Failure Mode ............................................................................................ 67
Description ..................................................................................................................... 67
Graphical description ..................................................................................................... 68
Class definition .............................................................................................................. 68
S3000L UoF Failure Mode Isolation .............................................................................. 73
Description ..................................................................................................................... 73
Graphical description ..................................................................................................... 73
Class definition .............................................................................................................. 73
S3000L UoF Failure Mode Symptom ............................................................................ 74
Description ..................................................................................................................... 74
Graphical description ..................................................................................................... 74
Class definition .............................................................................................................. 75
S3000L UoF Hardware Element .................................................................................... 78
Description ..................................................................................................................... 78
Graphical description ..................................................................................................... 79
Class definition .............................................................................................................. 79
S3000L UoF In Service Optimization Analysis .............................................................. 82
Description ..................................................................................................................... 82
Graphical description ..................................................................................................... 83
Class definition .............................................................................................................. 83
S3000L UoF Location .................................................................................................... 87
Description ..................................................................................................................... 87
Graphical description ..................................................................................................... 88
Class definition .............................................................................................................. 88
S3000L UoF Logistics Support Analysis Message Content .......................................... 91
Description ..................................................................................................................... 91
Graphical description ..................................................................................................... 92
Class definition .............................................................................................................. 93
S3000L UoF LSA Candidate ......................................................................................... 99
Description ..................................................................................................................... 99
Graphical description ................................................................................................... 100
Class definition ............................................................................................................ 100
S3000L UoF LSA Failure Mode Group ....................................................................... 102
Description ................................................................................................................... 102
Graphical description ................................................................................................... 102
Class definition ............................................................................................................ 102
S3000L UoF Message ................................................................................................. 106
Description ................................................................................................................... 106
Graphical description ................................................................................................... 107
Class definition ............................................................................................................ 107
S3000L UoF Organization Assignment ....................................................................... 110
Description ................................................................................................................... 110
Graphical description ................................................................................................... 110
Class definition ............................................................................................................ 110
S3000L UoF Part Definition ......................................................................................... 114

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 2

S3000L-B6865-03000-00

3.25.1
3.25.2
3.25.33.26
3.26.1
3.26.2
3.26.33.27
3.27.1
3.27.2
3.27.33.28
3.28.1
3.28.2
3.28.33.29
3.29.1
3.29.2
3.29.33.30
3.30.1
3.30.2
3.30.33.31
3.31.1
3.31.2
3.31.33.32
3.32.1
3.32.2
3.32.33.33
3.33.1
3.33.2
3.33.33.34
3.34.1
3.34.2
3.34.33.35
3.35.1
3.35.2
3.35.33.36
3.36.1
3.36.2
3.36.33.37
3.37.1
3.37.2
3.37.33.38
3.38.1
3.38.2
3.38.33.39
3.39.1

Description ................................................................................................................... 114
Graphical description ................................................................................................... 115
Class definition ............................................................................................................ 115
S3000L UoF Performance Parameter ......................................................................... 124
Description ................................................................................................................... 124
Graphical description ................................................................................................... 125
Class definition ............................................................................................................ 125
S3000L UoF Product and Project ................................................................................ 127
Description ................................................................................................................... 127
Graphical description ................................................................................................... 128
Class definition ............................................................................................................ 128
S3000L UoF Product Design Configuration ................................................................ 133
Description ................................................................................................................... 133
Graphical description ................................................................................................... 133
Class definition ............................................................................................................ 133
S3000L UoF Product Usage Context .......................................................................... 139
Description ................................................................................................................... 139
Graphical description ................................................................................................... 140
Class definition ............................................................................................................ 140
S3000L UoF Product Usage Phase ............................................................................ 143
Description ................................................................................................................... 143
Graphical description ................................................................................................... 143
Class definition ............................................................................................................ 143
S3000L UoF Remark ................................................................................................... 144
Description ................................................................................................................... 144
Graphical description ................................................................................................... 145
Class definition ............................................................................................................ 145
S3000L UoF Resource Specification........................................................................... 148
Description ................................................................................................................... 148
Graphical description ................................................................................................... 149
Class definition ............................................................................................................ 149
S3000L UoF Security Classification ............................................................................ 151
Description ................................................................................................................... 151
Graphical description ................................................................................................... 152
Class definition ............................................................................................................ 152
S3000L UoF Software Element ................................................................................... 154
Description ................................................................................................................... 154
Graphical description ................................................................................................... 155
Class definition ............................................................................................................ 155
S3000L UoF Special Event ......................................................................................... 158
Description ................................................................................................................... 158
Graphical description ................................................................................................... 159
Class definition ............................................................................................................ 159
S3000L UoF Task ........................................................................................................ 162
Description ................................................................................................................... 162
Graphical description ................................................................................................... 163
Class definition ............................................................................................................ 163
S3000L UoF Task Requirement .................................................................................. 174
Description ................................................................................................................... 174
Graphical description ................................................................................................... 175
Class definition ............................................................................................................ 175
S3000L UoF Task Resource ....................................................................................... 178
Description ................................................................................................................... 178
Graphical description ................................................................................................... 179
Class definition ............................................................................................................ 179
S3000L UoF Task Usage ............................................................................................ 184
Description ................................................................................................................... 184

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 3

S3000L-B6865-03000-00

3.39.2
3.39.33.40
3.40.1
3.40.2
3.40.33.41
3.41.1
3.41.2
3.41.3Graphical description ................................................................................................... 184
Class definition ............................................................................................................ 184
S3000L UoF Time Limit ............................................................................................... 187
Description ................................................................................................................... 187
Graphical description ................................................................................................... 188
Class definition ............................................................................................................ 188
S3000L UoF Zone Element ......................................................................................... 193
Description ................................................................................................................... 193
Graphical description ................................................................................................... 194
Class definition ............................................................................................................ 194

List of tables
1

References ...................................................................................................................... 5

List of figures
1
2
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
29
30
31
32

S3000L UoF overview ..................................................................................................... 9
S3000L UoF Aggregated Element................................................................................... 9
S3000L UoF Applicability Statement ............................................................................. 13
S3000L UoF Applicability Statement - Applicability Statement Items ........................... 14
S3000L UoF Breakdown Structure ................................................................................ 23
S3000L UoF Change Information .................................................................................. 29
S3000L UoF Circuit Breaker .......................................................................................... 32
S3000L UoF Competence Definition ............................................................................. 34
S3000L UoF Damage Definition .................................................................................... 36
S3000L UoF Decision Tree Template Definition ........................................................... 40
S3000L UoF Design Change Request .......................................................................... 45
S3000L UoF Digital File ................................................................................................. 47
S3000L UoF Digital File - Digital File Referenced Item ................................................. 48
S3000L UoF Digital File - Digital File Referencing Item ................................................ 49
S3000L UoF Document ................................................................................................. 53
S3000L UoF Environment Definition ............................................................................. 60
S3000L UoF Facility ...................................................................................................... 64
S3000L UoF Failure Mode ............................................................................................ 68
S3000L UoF Failure Mode Isolation .............................................................................. 73
S3000L UoF Failure Mode Symptom ............................................................................ 74
S3000L UoF Hardware Element .................................................................................... 79
S3000L UoF In Service Optimization Analysis .............................................................. 83
S3000L UoF Location .................................................................................................... 88
S3000L UoF Logistics Support Analysis Message Content .......................................... 92
S3000L UoF LSA Candidate ....................................................................................... 100
S3000L UoF LSA Failure Mode Group ....................................................................... 102
S3000L UoF Message ................................................................................................. 107
S3000L UoF Organization Assignment ....................................................................... 110
S3000L UoF Part Definition ......................................................................................... 115
S3000L UoF Performance Parameter ......................................................................... 125
S3000L UoF Product and Project ................................................................................ 128
S3000L UoF Product Design Configuration ................................................................ 133

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 4

S3000L-B6865-03000-00

33
34
35
36
37
38
39
40
41
42
43
44
45

S3000L UoF Product Usage Context .......................................................................... 140
S3000L UoF Product Usage Phase ............................................................................ 143
S3000L UoF Remark ................................................................................................... 145
S3000L UoF Resource Specification........................................................................... 149
S3000L UoF Security Classification ............................................................................ 152
S3000L UoF Software Element ................................................................................... 155
S3000L UoF Special Event ......................................................................................... 159
S3000L UoF Task ........................................................................................................ 163
S3000L UoF Task Requirement .................................................................................. 175
S3000L UoF Task Resource ....................................................................................... 179
S3000L UoF Task Usage ............................................................................................ 184
S3000L UoF Time Limit ............................................................................................... 188
S3000L UoF Zone Element ......................................................................................... 194

References
Table 1 References
Chap No./Document No.

Title

Chap 3

LSA process

Chap 4

Product structures and change management in LSA

Chap 7

Corrective maintenance analysis

Chap 8

Damage and special event analysis

Chap 9Operational support analysis

Chap 10Development of a preventive maintenance program

Chap 11

Level of repair analysis

Chap 12

Task requirements and maintenance task analysis

Chap 15

Obsolescence analysis

Chap 16

Disposal

Chap 17

In-service LSA

Chap 20

Data exchange

Chap 22

Data element list

S4000PInternational specification for developing and continuously
improving preventive maintenance

SX002D

Common data model for the S-Series IPS specifications

SX004G

Unified Modeling Language (UML) model reader's guide

SX005G

S-Series IPS specifications XML schema implementation
guidancewww.uml.org

Unified Modeling Language

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 5

S3000L-B6865-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 business processes(refer to Chap 20).
The S3000L data model is described using the UML 2.0™ (Unified Modeling Language) classmodel diagrams (www.uml.org) and is based on SX002D Common Data Model (CDM)
issue 2.1. Conventions used for the data model are described in SX004G, including descriptionsof the data types that are used for the respective class attributes.
Each class and attribute in the S3000L data model is defined in Chap 22.

1.2

Scope
The following areas are in scope of the data model:
−
−
−
−
−
−
−
−
−

1.3

Definition of the LSA program and the Products to be supported (refer to Chap 3)
Document the breakdown structure for the Product and its Product variants (refer toChap 4)
Support the early phases of the LSA program in terms of selecting the LSA candidate items
and identification of analysis activities to be performed for each LSA candidate (refer toChap 3)
Support the identification of task requirements resulting from eg, corrective maintenanceanalysis (refer to Chap 7), damage and special event analysis (refer to Chap 8) andoperational support analysis (refer to Chap 9)
Document the preventive maintenance program and the packaging of preventive
maintenance tasks (refer to Chap 10)
Document the outcome from the Level of Repair Analysis (LORA) (refer to Chap 11)
Document the results from the task requirements and Maintenance Task Analysis (MTA)(refer to Chap 12)
Document the results from obsolescence and disposal analysis (refer to Chap 15 andChap 16)
Support the In-Service Support Optimization (ISSO) process (refer to Chap 17)

Out of scope
The data model has been defined to support one project (LSA program) at a time. Any
implementations of the data model in a software application that will support multiple projects
need to define how data can be reused between projects as part of the software development.
The data model does not provide full support for all the identified candidate item analysis
activities, but focuses on Product breakdown definition (refer to Chap 4), corrective
maintenance analysis (refer to Chap 7), damage and special event analysis (refer to Chap 8),
task requirements and maintenance task analysis (refer to Chap 12) and in-service LSA (refer
to Chap 17). Results from other analysis activities, eg, LORA, can be referenced bysummarized data, descriptions and/or by inclusion of digital document files or document
references.
The data model does not cover all data elements needed to support the LSA process, but justthose data elements that will typically be exchanged between a contractor and subcontractors,
partners and customers.

2

Data model overview
The S3000L data model is organized into a set of Unit of Functionalities (UoF) which divides theoverall data model for S3000L into a set of smaller data models. Each UoF defines classes,
relationships and attributes required to document a specific aspect of LSA. The purpose ofdividing the data model into a set of UoFs is to present small and coherent portions of the data
model, and to gradually give the reader an understanding of the complete data model.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 6

S3000L-B6865-03000-00

The order in which the respective UoF is presented in Para 3 does not follow the chapters of
S3000L, but is organized in an alphabetical order. However, there is a suggested order ofreading that support the LSA process as laid out in Chap 3 and the rest of this specification. The
suggested reading order is:−

Overall product, project, operational and maintenance context data
•
•
•
•
•

−

Product structure and part characteristics
•
•
•
•
•
•
•

−

UoF Task Requirement, Refer to Para 3.37
UoF Time Limit, Refer to Para 3.40
UoF Design Change Request, Refer to Para 3.9

Maintenance task analysis
•
•
•
•
•
•

−

UoF Product Usage Phase, refer to Para 3.30
UoF Special Event, refer to Para 3.35
UoF Damage Definition, refer to Para 3.7

Task requirements and influence on design
•
•
•

−

UoF Failure Mode, refer to Para 3.14
UoF LSA Failure Mode Group, refer to Para 3.22
UoF Failure Mode Symptom, refer to Para 3.16
UoF Failure Mode Isolation, refer to Para 3.15

Damage and special event analysis
•
•
•

−

UoF Performance Parameter, refer to Para 3.26
UoF LSA Candidate, refer to Para 3.21

Corrective maintenance analysis
•
•
•
•

−

UoF Breakdown Structure, refer to Para 3.3
UoF Part Definition, refer to Para 3.25
UoF Aggregated Element, refer to Para 3.1
UoF Hardware Element, refer to Para 3.17
UoF Software Element, refer to Para 3.34
UoF Zone Element, refer to Para 3.41
UoF Product Design Configuration, refer to Para 3.28

LSA candidate selection, requirements and analysis activities••−

UoF Product and Project, refer to Para 3.27
UoF Product Usage Context, refer to Para 3.29
UoF Facility, refer to Para 3.13
UoF Location, refer to Para 3.19
UoF Environment Definition, refer to Para 3.12

UoF Task, refer to Para 3.36
UoF Circuit Breaker, refer to Para 3.5
UoF Task Resource, refer to Para 3.38
UoF Resource Specification, refer to Para 3.32
UoF Competence Definition, refer to Para 3.6
UoF Task Usage, refer to Para 3.39

In-service LSA•

UoF Decision Tree Template Definition, refer to Para 3.8

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 7

S3000L-B6865-03000-00•−

General capabilities
•
•
•
•
•
•
•

−

UoF In Service Optimization Analysis, refer to Para 3.18

UoF Change Information, refer to Para 3.4
UoF Security Classification, refer to Para 3.33
UoF Organization Assignment, refer to Para 3.24
UoF Document, refer to Para 3.11
UoF Digital File, refer to Para 3.10
UoF Remark, refer to Para 3.31
UoF Applicability Statement, refer to Para 3.2

LSA messages••

UoF Message, refer to Para 3.23
UoF Logistics Support Analysis Message Content, refer to Para 3.20

Each UoF contains:−−−

An overall description of the UoF
A graphical representation of the class model for the UoF
Definitions of classes and interfaces identified within the UoF

A complete listing shows that the S3000L data model contains 41 UoFs. Each UoF adds to thecapability to capture and share data relevant to the LSA process.
The suggested reading order follows the process where the first data elements defined arethose required to define the project and the Product in focus for the LSA activities. This is thenfollowed by recording data that is defined during the respective LSA analysis activity leading up
to a set of defined task requirements. The end result of S3000L is a set of detailed task
definitions including subtasks, resources, time limits and information about where the task is tobe performed.
Fig 1 provides an overview of the main UoFs, and how they are interrelated:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 8

S3000L-B6865-03000-00

ICN-B6865-S3000L0214-004-01
Fig 1 S3000L UoF overview

3

Data model units of functionality

3.1

S3000L UoF Aggregated Element

3.1.1

Description
The Aggregated Element UoF provides the capability to specify that an element within abreakdown represents a collection of elements for an identified purpose.

3.1.2

Graphical description

ICN-B6865-S3000L0221-003-01
Fig 2 S3000L UoF Aggregated Element

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 9

S3000L-B6865-03000-00

3.1.3
3.1.3.1

Class definition
AggregatedElement

AggregatedElement is a BreakdownElement (refer to Para 3.3) that is a container
for a collection of BreakdownElements which are grouped for an identified purpose.
3.1.3.1.1

Attribute(s)This class has the following attributes:−

breakdownElementIdentifier (inherited from BreakdownElement), one
or many−

breakdownElementName (inherited from BreakdownElement), zero, one or
many−

breakdownElementEssentiality (inherited from BreakdownElement),
zero or one−
3.1.3.1.2

Associations
This class has the following associations:−3.1.3.1.3

aggregatedElementType, one or many

An aggregate association with one or many instances ofAggregatedElementRevision

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElement). Refer toPara 3.21−

BreakdownElementInZoneItem (inherited from BreakdownElement). Refer
to Para 3.41−

DecisionTreeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from BreakdownElement). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from BreakdownElement). Refer
to Para 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.14−−−

InServiceOptimizationAnalysisItem (inherited fromBreakdownElement). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElement). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited from BreakdownElement). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from BreakdownElement). Refer
to Para 3.33

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 10

S3000L-B6865-03000-00

3.1.3.2

AggregatedElementRevision

AggregatedElementRevision is a BreakdownElementRevision (refer toPara 3.3) representing an iteration applied to an AggregatedElement.
3.1.3.2.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.1.3.2.2

Associations
This class has the following associations:−3.1.3.2.3

breakdownElementRevisionIdentifier (inherited fromBreakdownElementRevision)
breakdownElementDescription (inherited fromBreakdownElementRevision), zero, one or many
maintenanceSignificantOrRelevant (inherited fromBreakdownElementRevision)
breakdownElementRevisionRationale (inherited fromBreakdownElementRevision), zero, one or many
breakdownElementRevisionDate (inherited fromBreakdownElementRevision), zero or one
breakdownElementRevisionStatus (inherited fromBreakdownElementRevision), zero or one

A directed has association with zero, one or many instances ofBreakdownElementRevisionRelationship (inherited fromBreakdownElementRevision). Refer to Para 3.3.

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElementRevision).
Refer to Para 3.21−−

BreakdownElementInZoneItem (inherited fromBreakdownElementRevision). Refer to Para 3.41
ChangeControlledItem (inherited from BreakdownElementRevision).
Refer to Para 3.4

−
−
−
−
−
−
−

DetectionMeansAlarmItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
DigitalFileReferencingItem (inherited fromBreakdownElementRevision). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.14
InServiceOptimizationAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited fromBreakdownElementRevision). Refer to Para 3.26

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 11

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TaskAnalysisItem (inherited from BreakdownElementRevision). Refer toPara 3.39−

TaskRequirementAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.37

3.2

S3000L UoF Applicability Statement

3.2.1

Description
The Applicability Statement UoF provides the capability to define the situation or situations
under which related items are valid.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 12

S3000L-B6865-03000-00

3.2.2

Graphical description

ICN-B6865-S3000L0235-004-01
Fig 3 S3000L UoF Applicability Statement

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 13

S3000L-B6865-03000-00

ICN-B6865-S3000L0266-002-01
Fig 4 S3000L UoF Applicability Statement - Applicability Statement Items
3.2.3
3.2.3.1

Class definition
ApplicabilityStatement

ApplicabilityStatement is a <<class>> that defines the situation or situations
under which related items are valid.
3.2.3.1.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 14

S3000L-B6865-03000-00−−−
3.2.3.1.2

Associations
This class has the following associations:−3.2.3.1.3

applicabilityStatementIdentifier
applicabilityStatementDescription, zero, one or many
applicabilityStatementDateRange, zero or one

An aggregate association with zero or one instance of EvaluationCriteria

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ApplicabilityStatementItem

ApplicabilityStatementItem is an <<extend>> interface that provides its
associated data model to those classes which can have restricted validity as defined by anassociated ApplicabilityStatement.
3.2.3.2.1

Class members
Classes that implement the ApplicabilityStatementItem <<extend>>
interface are:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

AllocatedTaskLocation. Refer to Para 3.39
AlternatePartAsDesigned. Refer to Para 3.25
AnalysisActivity. Refer to Para 3.21
AnalysisCandidateItemSelectionData. Refer to Para 3.21
AuthorizedLife. Refer to SX004G
BreakdownElementInZone. Refer to Para 3.41
BreakdownElementRevisionRelationship. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3
BreakdownElementUsageRelationship. Refer to Para 3.3
CircuitBreakerLocation. Refer to Para 3.5
CircuitBreakerSetting. Refer to Para 3.36
CircuitBreakerSettings. Refer to Para 3.36
ClassificationType. Refer to SX004G
ContainedSubstance. Refer to Para 3.25
DamageImpact. Refer to Para 3.7
DescriptorType. Refer to SX004G
FailureMode. Refer to Para 3.14
FailureModeEffect. Refer to Para 3.14
FailureModeSymptom. Refer to Para 3.16
HardwareElementPartRealization. Refer to Para 3.17
IdentifiedTaskRequirement. Refer to Para 3.37
IdentifierType. Refer to SX004G
NameType. Refer to SX004G
PartAsDesignedPartsListEntry. Refer to Para 3.25

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 15

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
3.2.3.2.2

PerformanceParameterValueGroup. Refer to Para 3.26
PropertyType. Refer to SX004G
ReferencedDigitalFile. Refer to Para 3.10
ReferencedDocument. Refer to Para 3.11
ReferencedOrganization. Refer to Para 3.24
ResourceRealization. Refer to Para 3.32
SecurityClassification. Refer to Para 3.33
SoftwareElementPartRealization. Refer to Para 3.34
SpecialEventProductUsagePhaseOccurrence. Refer to Para 3.35
Subtask. Refer to Para 3.36
SubtaskAcceptanceParameter. Refer to Para 3.36
SubtaskInZone. Refer to Para 3.36
SubtaskTimeline. Refer to Para 3.36
SubtaskWarningCautionNote. Refer to Para 3.36
TaskFrequency. Refer to Para 3.39
TaskPersonnelResourceCompetence. Refer to Para 3.38
TaskResource. Refer to Para 3.38
TaskResourceRelationship. Refer to Para 3.38
TaskRevisionWarningCautionNote. Refer to Para 3.36
TaskUsage. Refer to Para 3.39
ThresholdDefinition. Refer to Para 3.40
TimeLimit. Refer to Para 3.40

Associations
The ApplicabilityStatementItem <<extend>> interface has the following
associations:−

A directed definedBy association with zero or one instance ofApplicabilityStatement
3.2.3.3

ClassInstanceAssertItem

ClassInstanceAssertItem is a <<select>> interface that identifies classes fromwhich an instance can be used as the

EvaluationByAssertionOfClassInstance assert item.
3.2.3.3.1

Class members
This <<select>> interface includes the following class members:−

AllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28

−
−
−
−
−
−
−
−
−
−
−

BreakdownElement. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3
ChangeAuthorization. Refer to Para 3.4
Contract. Refer to Para 3.27
Country. Refer to Para 3.19
EnvironmentDefinition. Refer to Para 3.12
Facility. Refer to Para 3.13
GeographicalArea. Refer to Para 3.19
HardwareElementPartRealization. Refer to Para 3.17
MaintenanceLevel. Refer to Para 3.29
OperatingLocationType. Refer to Para 3.29

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 16

S3000L-B6865-03000-00

−
−
−
−
−
−
3.2.3.4

Organization. Refer to Para 3.24
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductUsagePhase. Refer to Para 3.30
ProductVariant. Refer to Para 3.27
SoftwareElementPartRealization. Refer to Para 3.34

ConditionDefinitionItem

ConditionDefinitionItem is a <<select>> interface that identifies classes fromwhich an instance can be used as the EvaluationByAssertionOfCondition
assert condition.
3.2.3.4.1

Class members
This <<select>> interface includes the following class members:−−

3.2.3.5

ConditionInstanceConditionType

ConditionInstanceConditionInstance is a <<class>> that defines an individual concept or object
having the characteristics of a generic ConditionType.
Example(s)− Uniquely identified service bulletin
3.2.3.5.1

Attribute(s)This class has the following attributes:−−−

3.2.3.5.2

conditionInstanceIdentifier, one or many
conditionInstanceName, one or many
conditionInstanceDescription, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ConditionType

ConditionType is a <<class>> that defines a concept or an object that needs to be
included in applicability statements where the concept or object is not already represented in
the data model.
Example(s)−Environmental conditions
3.2.3.6.1

Attribute(s)This class has the following attributes:−−

conditionTypeName, one or many
conditionTypeDescription, zero, one or many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 17

S3000L-B6865-03000-00

3.2.3.6.2

Associations
This class has the following associations:−−3.2.3.6.3

An aggregate association with zero, one or many instances of ConditionInstanceAn aggregate association with one or many instances ofConditionTypeAssertMember

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ConditionTypeAssertMember

ConditionTypeAssertMember is <<class>> that defines a member for a given
ConditionType which can be mapped to a Boolean expression and be evaluated to beeither TRUE or FALSE.
3.2.3.7.1

Attribute(s)This class has the following attributes:−−−−

conditionTypeAssertMemberName, one or many
conditionTypeAssertMemberDescription, zero, one or many
conditionTypeAssertMemberAssertValue, zero or one
conditionTypeAssertMemberAssertValueComparisonOperator,
zero or one

3.2.3.7.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EvaluationByAssertionOfClassInstance

EvaluationByAssertionOfClassInstance is an EvaluationCriteriathat identifies a class instance to be used as an assert item and be mapped to a Boolean
expression which can be evaluated to be either TRUE or FALSE.
3.2.3.8.1

Attribute(s)This class has the following attributes:−

3.2.3.8.2

evaluationByAssertionRole, zero or one

Associations
This class has the following associations:−

A directed assertItem association with one instance ofClassInstanceAssertItem
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 18

S3000L-B6865-03000-00

3.2.3.8.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.9

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EvaluationByAssertionOfCondition

EvaluationByAssertionOfCondition is an EvaluationCriteria that
identifies a combination of a defined condition and a defined value to be used as an assert item
and be mapped to a Boolean expression which can be evaluated to be either TRUE or FALSE.
3.2.3.9.1

3.2.3.9.2

Associations
This class has the following associations:−

A directed assertValue association with one instance of−ConditionTypeAssertMember
A directed assertCondition association with one instance ofConditionDefinitionItem

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.10

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EvaluationByAssertionOfSerializedItems

EvaluationByAssertionOfSerializedItems is an
EvaluationCriteria that identifies a class instance together with an associated serial
number range to be used as an assert item and be mapped to a Boolean expression which canbe evaluated to be either TRUE or FALSE.
3.2.3.10.1

Attribute(s)This class has the following attributes:−

3.2.3.10.2

applicableSerialNumberRange

Associations
This class has the following associations:−

A directed assertItem association with one instance ofSerializedAssertItem
3.2.3.10.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 19

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.11

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EvaluationByNestedApplicabilityStatement

EvaluationByNestedApplicabilityStatement is an
EvaluationCriteria that enables an ApplicabilityStatement to be reusedas part of this EvaluationCriteria.
NoteThis class enables the definition of nested applicability statements.
3.2.3.11.1

Associations
This class has the following associations:−3.2.3.11.2

A directed referencedApplicabilityStatement association with one
instance of ApplicabilityStatement

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.12

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EvaluationCriteria

EvaluationCriteria is a <<class>> that defines conditions that can be mapped toa Boolean expression which can be evaluated to be either TRUE or FALSE.
3.2.3.12.1

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.13

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LogicalAND

LogicalAND is an EvaluationCriteria that defines a Boolean operation where theresults of all its associated EvaluationCriteria must be TRUE for the result to be
TRUE, otherwise the result is FALSE.
3.2.3.13.1

Associations
This class has the following associations:−

An aggregate operand association with two or more instances of

EvaluationCriteria
3.2.3.13.2

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 20

S3000L-B6865-03000-00−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.14

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LogicalNOT

LogicalNOT is an EvaluationCriteria that defines a Boolean operation where theresult from its associated EvaluationCriteria must be FALSE for the result to be
TRUE, otherwise the result is FALSE.
3.2.3.14.1

Associations
This class has the following associations:−3.2.3.14.2

An aggregate operand association with one instance of EvaluationCriteria

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.15

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LogicalOR

LogicalOR is an EvaluationCriteria that defines a Boolean operation where theresult from at least one of its associated EvaluationCriteria must be TRUE for the
result to be TRUE, otherwise the result is FALSE.
3.2.3.15.1

Associations
This class has the following associations:−

An aggregate operand association with two or more instances of

EvaluationCriteria
3.2.3.15.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.16

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LogicalXOR

LogicalXOR is an EvaluationCriteria that defines a Boolean operation where theresult from one and only one of its associated EvaluationCriteria must be TRUE forthe result to be TRUE, otherwise the result is FALSE.
3.2.3.16.1

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 21

S3000L-B6865-03000-00−

An aggregate operand association with exactly two instances of

EvaluationCriteria
3.2.3.16.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.2.3.17

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SerializedAssertItem

SerializedAssertItem is a <<select>> interface that identifies classes fromwhich an instance can be used as the

EvaluationByAssertionOfSerializedItems assert item.
3.2.3.17.1

Class members
This <<select>> interface includes the following class members:−−−

PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

3.3

S3000L UoF Breakdown Structure

3.3.1

Description
The Breakdown Structure UoF provides the capability to define any number of hierarchicalstructures for a specific Product or Product variant.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 22

S3000L-B6865-03000-00

3.3.2

Graphical description

ICN-B6865-S3000L0217-004-01
Fig 5 S3000L UoF Breakdown Structure
3.3.3
3.3.3.1

Class definition
Breakdown
Breakdown is a <<class>> that identifies a specific partitioning of a Product (refer toPara 3.27) to form a parent-child structure of related instances of BreakdownElement.

3.3.3.1.1

Attribute(s)This class has the following attributes:−

3.3.3.1.2

Associations
This class has the following associations:−3.3.3.1.3

breakdownType

An aggregate association with one or many instances of BreakdownRevision

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 23

S3000L-B6865-03000-00

3.3.3.2

BreakdownElement

BreakdownElement is a <<class>> defining a partition of a Product that is used in
one or many instances of Breakdown.
3.3.3.2.1

Attribute(s)This class has the following attributes:−−−

3.3.3.2.2

Associations
This class has the following associations:−3.3.3.2.3

breakdownElementIdentifier, one or many
breakdownElementName, zero, one or many
breakdownElementEssentiality, zero or one

An aggregate association with one or many instances ofBreakdownElementRevision

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−
−
−
−
−

AnalysisCandidateItem. Refer to Para 3.21
BreakdownElementInZoneItem. Refer to Para 3.41
DecisionTreeAnalysisItem. Refer to Para 3.8
DetectionMeansAlarmItem. Refer to Para 3.16
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem. Refer to Para 3.14
InServiceOptimizationAnalysisItem. Refer to Para 3.18
MeasurementPointDefinitionItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem. Refer to Para 3.26
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.3.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

BreakdownElementRevision

BreakdownElementRevision is a <<class>> representing an iteration applied to a
BreakdownElement.
3.3.3.3.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.3.3.3.2

breakdownElementRevisionIdentifier
breakdownElementDescription, zero, one or many
maintenanceSignificantOrRelevant
breakdownElementRevisionRationale, zero, one or many
breakdownElementRevisionDate, zero or one
breakdownElementRevisionStatus, zero or one

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 24

S3000L-B6865-03000-00−

A directed has association with zero, one or many instances ofBreakdownElementRevisionRelationship3.3.3.3.3

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−
−
−
−
−

AnalysisCandidateItem. Refer to Para 3.21
BreakdownElementInZoneItem. Refer to Para 3.41
ChangeControlledItem. Refer to Para 3.4
DetectionMeansAlarmItem. Refer to Para 3.16
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem. Refer to Para 3.14
InServiceOptimizationAnalysisItem. Refer to Para 3.18
MeasurementPointDefinitionItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem. Refer to Para 3.26
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−−3.3.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TaskAnalysisItem. Refer to Para 3.39
TaskRequirementAnalysisItem. Refer to Para 3.37

BreakdownElementRevisionRelationshipBreakdownElementRevisionRelationship is a <<relationship>>where one BreakdownElementRevision relates to another BreakdownElement
or BreakdownElementRevision.
3.3.3.4.1

Attribute(s)This class has the following attributes:−

3.3.3.4.2

breakdownElementRevisionRelationshipType

Associations
This class has the following associations:−

A directed with association with one instance ofBreakdownElementRevisionRelationshipItem
3.3.3.4.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.3.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

BreakdownElementRevisionRelationshipItem

BreakdownElementRevisionRelationshipItem is a <<select>> interface
that provides the capability to be associated with a BreakdownElementRevision.
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 25

S3000L-B6865-03000-00

3.3.3.5.1

Class members
This <<select>> interface includes the following class members:−−

3.3.3.6

BreakdownElement
BreakdownElementRevision

BreakdownElementStructure

BreakdownElementStructure is a <<relationship>> that establishes ahierarchical structure between two usages of BreakdownElement that belong to the same
BreakdownRevision.
3.3.3.6.1

Attribute(s)This class has the following attributes:−

3.3.3.6.2

breakdownElementChildSequenceNumber, zero or one

Associations
This class has the following associations:−

A directed definedBy association with one instance ofBreakdownElementUsageInBreakdown
3.3.3.6.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.3.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

BreakdownElementUsageInBreakdown

BreakdownElementUsageInBreakdown is a <<class>> that represents a
member of a BreakdownRevision.
Note
A BreakdownElementRevision can belong to multiple
BreakdownRevisions.
3.3.3.7.1

Attribute(s)This class has the following attributes:−−−

3.3.3.7.2

breakdownElementUsageIdentifier, one or many
breakdownElementUsageQuantity, zero, one or manyreferenceDesignator, zero, one or many

Associations
This class has the following associations:−

A directed definedBy association with one instance of−BreakdownElementRevision
A directed hasChild association with zero, one or many instances ofBreakdownElementStructure

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 26

S3000L-B6865-03000-00−

A directed has association with zero, one or many instances ofBreakdownElementUsageRelationship3.3.3.7.3

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−

ApplicabilityStatementItem. Refer to Para 3.2
BreakdownElementInZoneItem. Refer to Para 3.41
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EffectiveOnProductConfigurationItem. Refer to Para 3.28
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.3.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31
UsableOnItem. Refer to Para 3.28

BreakdownElementUsageRelationshipBreakdownElementUsageRelationship is a <<relationship>> where one
usage of a BreakdownElement relates to the usage of another BreakdownElement.
Note
Both related instances of BreakdownElementUsageInBreakdown must residewithin the same BreakdownRevision.
Example(s)− Version C of a radio is restricted to the use of software version B in breakdown revision 2
3.3.3.8.1

Attribute(s)This class has the following attributes:−

3.3.3.8.2

breakdownElementUsageRelationshipType

Associations
This class has the following associations:−

A directed with association with one instance ofBreakdownElementUsageInBreakdown
3.3.3.8.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.3.3.9

RemarkItem (inherited from BaseObject). Refer to Para 3.31

BreakdownItem

BreakdownItem is an <<extend>> interface that provides its associated data model tothose classes that implement it.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 27

S3000L-B6865-03000-00

3.3.3.9.1

Class members
Classes that implement the BreakdownItem <<extend>> interface are:−−3.3.3.9.2

Associations
The BreakdownItem <<extend>> interface has the following associations:−3.3.3.10

Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

An aggregate association with zero, one or many instances of Breakdown

BreakdownRevision

BreakdownRevision is a <<class>> representing an iteration applied to a
Breakdown.
Note

BreakdownRevision is used to document design iterations and not breakdown
variants.
3.3.3.10.1

Attribute(s)This class has the following attributes:−−−−

3.3.3.10.2

Associations
This class has the following associations:−−3.3.3.10.3

breakdownRevisionIdentifier
breakdownRevisionRationale, zero, one or many
breakdownRevisionDate, zero or one
breakdownRevisionStatus, zero or one

An aggregate association with one or many instances ofBreakdownElementUsageInBreakdown
A directed has association with zero, one or many instances ofBreakdownRevisionRelationship

Implementations
This class implements the following <<extend>> interfaces:−−−−

ChangeControlledItem. Refer to Para 3.4
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.3.3.11

RemarkItem (inherited from BaseObject). Refer to Para 3.31

BreakdownRevisionRelationshipBreakdownRevisionRelationship is a <<relationship>> where one
BreakdownRevision relates to another BreakdownRevision.
3.3.3.11.1

Attribute(s)This class has the following attributes:−

breakdownRevisionRelationshipType

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 28

S3000L-B6865-03000-00

3.3.3.11.2

Associations
This class has the following associations:−3.3.3.11.3

A directed definedBy association with one instance of BreakdownRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.4

S3000L UoF Change Information

3.4.1

Description
The Change Information UoF provides the capability to identify that an item has been affectedby a change authorization.

3.4.2

Graphical description

ICN-B6865-S3000L0291-001-01
Fig 6 S3000L UoF Change Information

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 29

S3000L-B6865-03000-00

3.4.3
3.4.3.1

Class definition
ChangeAuthorization

ChangeAuthorization is a <<class>> that is the record of the permission to modify
product design, its procedures and/or associated product support data.
3.4.3.1.1

Attribute(s)This class has the following attributes:−

3.4.3.1.2

changeAuthorizationIdentifier, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.4.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ChangeControlledItem

ChangeControlledItem is an <<extend>> interface that provides its associateddata model to those classes that can be affected by a ChangeAuthorization.
3.4.3.2.1

Class members
Classes that implement the ChangeControlledItem <<extend>> interface are:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

AlternatePartAsDesigned. Refer to Para 3.25
AnalysisActivityRevision. Refer to Para 3.21
BreakdownElementInZone. Refer to Para 3.41
BreakdownElementRevision. Refer to Para 3.3
BreakdownElementStructure. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3
BreakdownRevision. Refer to Para 3.3
CircuitBreakerLocation. Refer to Para 3.5
DocumentIssue. Refer to Para 3.11
EffectiveOnProductConfiguration. Refer to Para 3.28
FailureModeSymptom. Refer to Para 3.16
HardwareElementPartRealization. Refer to Para 3.17
PartAsDesignedPartsListEntry. Refer to Para 3.25
PartAsDesignedPartsListRevision. Refer to Para 3.25
PerformanceParameterRevision. Refer to Para 3.26
ResourceRealization. Refer to Para 3.32
ResourceSpecificationRevision. Refer to Para 3.32
SoftwareElementPartRealization. Refer to Para 3.34
SubstitutePartAsDesigned. Refer to Para 3.25
TaskRequirementRevision. Refer to Para 3.37
TaskResource. Refer to Para 3.38
TaskRevision. Refer to Para 3.36
TimeLimit. Refer to Para 3.40
UsableOnProductVariant. Refer to Para 3.28

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 30

S3000L-B6865-03000-00

3.4.3.2.2

Associations
The ChangeControlledItem <<extend>> interface has the following associations:−

A directed has association with zero, one or many instances of

ChangeNotification
3.4.3.3

ChangeNotification

ChangeNotification is a <<relationship>> that identifies an item changed dueto the associated ChangeAuthorization.
3.4.3.3.1

Attribute(s)This class has the following attributes:−−

3.4.3.3.2

changeNotificationDescription, zero, one or manychangeNotificationType, zero or one

Associations
This class has the following associations:− A directed justifiedBy association with one instance of
ChangeAuthorization
3.4.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.5

S3000L UoF Circuit Breaker

3.5.1

Description
The Circuit Breaker UoF provides the capability to define circuit breakers and their locations.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 31

S3000L-B6865-03000-00

3.5.2

Graphical description

ICN-B6865-S3000L0284-001-01
Fig 7 S3000L UoF Circuit Breaker
3.5.3
3.5.3.1

Class definition
CircuitBreakerCircuitBreaker is a <<class>> that represents an individual circuit breaker identified
in the context of a defined Product (refer to Para 3.27).
3.5.3.1.1

Attribute(s)This class has the following attributes:−−−

3.5.3.1.2

circuitBreakerIdentifier, one or many
circuitBreakerName, one or many
circuitBreakerType

Associations
This class has the following associations:−

A directed has association with zero, one or many instances of

CircuitBreakerLocation
3.5.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 32

S3000L-B6865-03000-00

3.5.3.2

CircuitBreakerLocation

CircuitBreakerLocation is a <<relationship>> that identifies the item on
which the CircuitBreaker is placed.
3.5.3.2.1

Attribute(s)This class has the following attributes:−

3.5.3.2.2

circuitBreakerLocationDescription, zero, one or many

Associations
This class has the following associations:−

A directed definedBy association with one instance ofCircuitBreakerLocationItem
3.5.3.2.3

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.5.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

CircuitBreakerLocationItem

CircuitBreakerLocationItem is a <<select>> interface that identifies items
which can be selected in order to determine the location for a CircuitBreaker.
3.5.3.3.1

Class members
This <<select>> interface includes the following class members:−−

BreakdownElementUsageInBreakdown. Refer to Para 3.3
HardwareElement. Refer to Para 3.17

3.6

S3000L UoF Competence Definition

3.6.1

Description
The Competence Definition UoF supports the definition of abilities, craft, profession, andproficiency.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 33

S3000L-B6865-03000-00

3.6.2

Graphical description

ICN-B6865-S3000L0286-001-01
Fig 8 S3000L UoF Competence Definition
3.6.3
3.6.3.1

Class definition
CompetenceDefinitionItem

CompetenceDefinitionItem is a <<select>> interface that identifies items which
define measurable or observable possession of knowledge and skills.
3.6.3.1.1

Class members
This <<select>> interface includes the following class members:−−−−

3.6.3.2

CompetencyDefinition
Skill
SkillLevel
Trade

CompetencyDefinition

CompetencyDefinition is a <<class>> that represents the specification of
measurable or observable knowledge, skills, and/or abilities necessary for successful
performance by a person in a given context.
Note
Competency definition is broadly defined to include assertions of academic, professional,
occupational, vocational and life goals, outcomes, and standards, however labeled
3.6.3.2.1

Attribute(s)This class has the following attributes:−−−

competencyDefinitionIdentifier, one or many
competencyDefinitionName, one or many
competencyDefinitionType

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 34

S3000L-B6865-03000-00−
3.6.3.2.2

competencyDefinitionDescription, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.6.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

Skill

Skill is a <<class>> that represents human cognitive, psychomotor, and affective
abilities.
3.6.3.3.1

Attribute(s)This class has the following attributes:−

3.6.3.3.2

skillCode

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.6.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

SkillLevel

SkillLevel is a <<class>> that represents a defined proficiency of a Trade.
3.6.3.4.1

Attribute(s)This class has the following attributes:−−

3.6.3.4.2

skillLevelName, one or manyskillLevelDescription, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.6.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Trade

Trade is a <<class>> that represents a craft or profession which requires specific skills.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 35

S3000L-B6865-03000-00

3.6.3.5.1

Attribute(s)This class has the following attributes:−

3.6.3.5.2

Associations
This class has the following associations:−3.6.3.5.3

tradeName, one or many

An aggregate association with zero, one or many instances of SkillLevel

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

3.7

S3000L UoF Damage Definition

3.7.1

Description
The Damage Definition UoF provides the capability to define damages that can be induced on a
Product during its in-service phase.

3.7.2

Graphical description

ICN-B6865-S3000L0282-001-01
Fig 9 S3000L UoF Damage Definition
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 36

S3000L-B6865-03000-00

3.7.3
3.7.3.1

Class definition
DamageAnalysis

DamageAnalysis is an AnalysisActivity (refer to Para 3.21) that represents theobjective for, and outcome of, a damage analysis carried out for the
AnalysisCandidateItem (refer to Para 3.21).
3.7.3.1.1

Attribute(s)This class has the following attributes:−

3.7.3.1.2

Associations
This class has the following associations:−3.7.3.1.3

analysisActivityType (inherited from AnalysisActivity)

An aggregate association with zero, one or many instances ofDamageAnalysisRevision

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from AnalysisActivity). Refer
to Para 3.2−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from AnalysisActivity). Refer
to Para 3.33

3.7.3.2

DamageAnalysisRevision

DamageAnalysisRevision is an AnalysisActivityRevision (refer toPara 3.21) representing an iteration applied to a DamageAnalysis.
3.7.3.2.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−

3.7.3.2.2

analysisActivityRevisionIdentifier (inherited from
AnalysisActivityRevision)
analysisActivityDecision (inherited from
AnalysisActivityRevision)
analysisActivityDecisionRationale (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityStatusDescription (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityRevisionRationale (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityRevisionDate (inherited from
AnalysisActivityRevision), zero or one
analysisActivityRevisionStatus (inherited from
AnalysisActivityRevision), zero or one

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 37

S3000L-B6865-03000-00−−
3.7.3.2.3

An aggregate association with one or many instances of DamageDefinition
An aggregate association with zero, one or many instances of theTechnologyBehaviorRating <<attributeGroup>>

Implementations
This class implements the following <<extend>> interfaces:−

ChangeControlledItem (inherited from AnalysisActivityRevision).
Refer to Para 3.4−−−

DigitalFileReferencingItem (inherited from
AnalysisActivityRevision). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.7.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DamageCause

DamageCause is a <<relationship>> where a DamageDefinition relates to aSpecialEventDefinition (refer to Para 3.35) that in some way is associated with thedamage.
3.7.3.3.1

Associations
This class has the following associations:−3.7.3.3.2

A directed definedBy association with one instance ofSpecialEventDefinition. Refer to Para 3.35

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.7.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DamageDefinition

DamageDefinition is a <<class>> that represents a loss or reduction of functionality
due to external causes or use outside specified limits.
3.7.3.4.1

Attribute(s)This class has the following attributes:−−−

3.7.3.4.2

damageDefinitionName, one or many
damageDefinitionFamily, zero or one
damageDefinitionDescription, zero, one or many

Associations
This class has the following associations:−−

A directed has association with zero, one or many instances of DamageCause
A directed has association with zero, one or many instances of DamageImpact

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 38

S3000L-B6865-03000-00

3.7.3.4.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.7.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DamageImpact

DamageImpact is a <<relationship>> that defines a consequence resulting fromthe defined DamageDefinition.
3.7.3.5.1

Attribute(s)This class has the following attributes:−

3.7.3.5.2

Associations
This class has the following associations:−3.7.3.5.3

damageImpactRatio, zero, one or many

A directed damageMode association with one instance of FailureMode. Refer toPara 3.14

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.7.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TechnologyBehaviorRating

TechnologyBehaviorRating is an <<attributeGroup>> that collects
attributes which categorizes the AnalysisCandidateItem (refer to Para 3.21) basedon knowledge on technology sensitivity and behavior perspective.
3.7.3.6.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

technologyBehaviorKnowledgeRating, zero, one or manytechnologySensitivityRating, one or many

3.8

S3000L UoF Decision Tree Template Definition

3.8.1

Description
The Decision Tree Template Definition UoF provides the capability to represent the definition ofdecision processes which must be followed when performing an actual analysis.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 39

S3000L-B6865-03000-00

3.8.2

Graphical description

ICN-B6865-S3000L0289-001-01
Fig 10 S3000L UoF Decision Tree Template Definition
3.8.3
3.8.3.1

Class definition
ApplicableDecisionTreeTemplate

ApplicableDecisionTreeTemplate is a <<relationship>> that identifies a
DecisionTreeTemplate which can be used for theDecisionTreeAnalysisItem.
3.8.3.1.1

Associations
This class has the following associations:− A directed definedBy association with one instance of DecisionTreeTemplate
3.8.3.1.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DecisionTreeAnalysisItem

DecisionTreeAnalysisItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 40

S3000L-B6865-03000-00

3.8.3.2.1

Class members
Classes that implement the DecisionTreeAnalysisItem <<extend>> interface
are:
−
−
−
−
−

3.8.3.2.2

BreakdownElement. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27

Associations
The DecisionTreeAnalysisItem <<extend>> interface has the following
associations:−

A directed has association with zero, one or many instances ofApplicableDecisionTreeTemplate
3.8.3.3

DecisionTreeTemplate

DecisionTreeTemplate is a <<class>> that enables the representation of adecision process including a set of defined steps and binary decisions.
3.8.3.3.1

Attribute(s)This class has the following attributes:−−

3.8.3.3.2

Associations
This class has the following associations:−

3.8.3.3.3

decisionTreeTemplateIdentifier, one or manydecisionTreeTemplateName, one or many

An aggregate association with one or many instances ofDecisionTreeTemplateRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DecisionTreeTemplateActionDefinition

DecisionTreeTemplateActionDefinition is a <<class>> that specifies
actions and/or measures that must be taken as part of the decision process.
3.8.3.4.1

Attribute(s)This class has the following attributes:−−−

decisionTreeTemplateActionDefinitionIdentifier
decisionTreeTemplateActionDefinitionName, one or manydecisionTreeTemplateActionDefinitionDescription, zero, one ormany

3.8.3.4.2

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 41

S3000L-B6865-03000-00−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DecisionTreeTemplateEndActionDefinition

DecisionTreeTemplateEndActionDefinition is a
DecisionTreeTemplateActionDefinition that defines an end action for thedecision process.
3.8.3.5.1

Attribute(s)This class has the following attributes:−−−

3.8.3.5.2

decisionTreeTemplateActionDefinitionIdentifier (inherited from
DecisionTreeTemplateActionDefinition)
decisionTreeTemplateActionDefinitionName (inherited from
DecisionTreeTemplateActionDefinition), one or manydecisionTreeTemplateActionDefinitionDescription (inherited from
DecisionTreeTemplateActionDefinition), zero, one or many

Associations
This class has the following associations:−

A directed followOnAnalysis association with zero or one instance ofDecisionTreeTemplate
3.8.3.5.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DecisionTreeTemplateFollowOnItem

DecisionTreeTemplateFollowOnItem is a <<select>> interface that
identifies items which can be selected to define the next step in the decision process.
3.8.3.6.1

Class members
This <<select>> interface includes the following class members:−−

3.8.3.7

DecisionTreeTemplateActionDefinition
DecisionTreeTemplateQuestionDefinition

DecisionTreeTemplateFurtherAnalysisActionDefinition

DecisionTreeTemplateFurtherAnalysisActionDefinition is a
DecisionTreeTemplateActionDefinition that will be followed by anotherquestion or action.
3.8.3.7.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 42

S3000L-B6865-03000-00−−−

3.8.3.7.2

decisionTreeTemplateActionDefinitionIdentifier (inherited from
DecisionTreeTemplateActionDefinition)
decisionTreeTemplateActionDefinitionName (inherited from
DecisionTreeTemplateActionDefinition), one or manydecisionTreeTemplateActionDefinitionDescription (inherited from
DecisionTreeTemplateActionDefinition), zero, one or many

Associations
This class has the following associations:−

A directed followedBy association with one instance ofDecisionTreeTemplateFollowOnItem
3.8.3.7.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DecisionTreeTemplateQuestionDefinition

DecisionTreeTemplateQuestionDefinition is a <<class>> that specifies
a question that result in a YES or NO answer.
3.8.3.8.1

Attribute(s)This class has the following attributes:−−−

decisionTreeTemplateQuestionDefinitionIdentifier
decisionTreeTemplateQuestionDefinitionName, one or manydecisionTreeTemplateQuestionDefinitionDescription, zero, one
or many

3.8.3.8.2

Associations
This class has the following associations:− A directed yesAnswer association with one instance ofDecisionTreeTemplateFollowOnItem− A directed noAnswer association with one instance ofDecisionTreeTemplateFollowOnItem
3.8.3.8.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.8.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Selects
This class is a member of the following <<select>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 43

S3000L-B6865-03000-00−−
3.8.3.9

DecisionTreeTemplateFollowOnItem
DecisionTreeTemplateStartItem

DecisionTreeTemplateRevision

DecisionTreeTemplateRevision is a <<class>> representing an iteration
applied to a DecisionTreeTemplate.
3.8.3.9.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.8.3.9.2

Associations
This class has the following associations:−

An aggregate association with one or many instances of−An aggregate association with one or many instances of−

3.8.3.9.3

decisionTreeTemplateRevisionIdentifier
decisionTreeTemplateAnalysisDomain, zero, one or manydecisionTreeTemplateDescription, zero, one or manydecisionTreeTemplateRevisionRationale, zero, one or manydecisionTreeTemplateRevisionDate, zero or one
decisionTreeTemplateRevisionStatus, zero or one

DecisionTreeTemplateActionDefinition
DecisionTreeTemplateQuestionDefinition
A directed startItem association with one instance ofDecisionTreeTemplateStartItem

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.8.3.10

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DecisionTreeTemplateStartItem

DecisionTreeTemplateStartItem is a <<select>> interface that identifies
items which can be selected as the starting point for the decision process.
3.8.3.10.1

Class members
This <<select>> interface includes the following class members:−−

DecisionTreeTemplateFurtherAnalysisActionDefinition
DecisionTreeTemplateQuestionDefinition

3.9

S3000L UoF Design Change Request

3.9.1

Description
The Design Change Request UoF provides the capability to identify proposed changes against
items including the rationale for this change.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 44

S3000L-B6865-03000-00

3.9.2

Graphical description

ICN-B6865-S3000L0283-001-01
Fig 11 S3000L UoF Design Change Request
3.9.3
3.9.3.1

Class definition
ChangeRequest

ChangeRequest is a <<class>> that represents a formal proposal for a modification toa configuration item upon a given baseline.
Note
Typical configuration items are eg, Product, PartAsDesigned, andBreakdownElement.
3.9.3.1.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 45

S3000L-B6865-03000-00−−−−
3.9.3.1.2

changeRequestIdentifier, one or manychangeRequestDescription, one or manychangeRequestIntendedEffect, zero, one or manychangeRequestStatus

Associations
This class has the following associations:−−

A directed has association with one or many instances of ChangeRequestTarget
A directed has association with zero, one or many instances of

ChangeRequestRationale
3.9.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.9.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ChangeRequestRationale

ChangeRequestRationale is a <<relationship>> that associates a
ChangeRequest with a ChangeRequestRationaleItem.
3.9.3.2.1

Associations
This class has the following associations:−

A directed definedby association with one instance of

ChangeRequestRationaleItem
3.9.3.2.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.9.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ChangeRequestRationaleItem

ChangeRequestRationaleItem is a <<select>> interface that identifies analysis
items which can support a ChangeRequest.
3.9.3.3.1

Class members
This <<select>> interface includes the following class members:
−
−
−
−
−

AnalysisActivity. Refer to Para 3.21
AnalysisActivityRevision. Refer to Para 3.21
Task. Refer to Para 3.36
TaskRequirement. Refer to Para 3.37
TaskRequirementRevision. Refer to Para 3.37

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 46

S3000L-B6865-03000-00−
3.9.3.4

TaskRevision. Refer to Para 3.36

ChangeRequestTarget

ChangeRequestTarget is a <<relationship>> that associates a
ChangeRequest with a ChangeRequestTargetItem.
3.9.3.4.1

Associations
This class has the following associations:−

A directed definedBy association with one instance of

ChangeRequestTargetItem
3.9.3.4.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.9.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ChangeRequestTargetItem

ChangeRequestTargetItem is a <<select>> interface that identifies items which
can be the subject for a ChangeRequest.
3.9.3.5.1

Class members
This <<select>> interface includes the following class members:
−
−
−
−
−

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

3.10

S3000L UoF Digital File

3.10.1

Description
The Digital File UoF provides the capability to both reference a digital file from the exchanged
data as well as to exchange the digital file itself.

3.10.2Graphical description

ICN-B6865-S3000L0292-001-01
Fig 12 S3000L UoF Digital File

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 47

S3000L-B6865-03000-00

ICN-B6865-S3000L0293-001-01
Fig 13 S3000L UoF Digital File - Digital File Referenced Item

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 48

S3000L-B6865-03000-00

ICN-B6865-S3000L0294-001-01
Fig 14 S3000L UoF Digital File - Digital File Referencing Item
3.10.33.10.3.1

Class definition
DigitalFile

DigitalFile is a <<class>> that provides the identification of data stored on anelectronic device that can be interpreted by a computer.
3.10.3.1.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.10.3.1.2

digitalFileLocator, one or many
digitalFileType
digitalFileContentClass, zero, one or many
digitalFileContentDescription, zero, one or many
digitalFileRepresentation, zero or one

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 49

S3000L-B6865-03000-00−

A directed has association with zero, one or many instances ofDigitalFileReference
3.10.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.10.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

DigitalFileReference

DigitalFileReference is a <<relationship>> that allows a DigitalFile
to reference a DigitalFileReferencedItem.
3.10.3.2.1

Attribute(s)This class has the following attributes:−

3.10.3.2.2

digitalFileReferenceJustification, zero, one or many

Associations
This class has the following associations:−

A directed definedBy association with one instance ofDigitalFileReferencedItem
3.10.3.2.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.10.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DigitalFileReferencedItem

DigitalFileReferencedItem is a <<select>> interface that identifies an item
which in some way is associated with the content of the DigitalFile.
3.10.3.3.1

Class members
This <<select>> interface includes the following class members:−

AllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28

−
−
−
−
−
−
−

BreakdownElement. Refer to Para 3.3
CircuitBreaker. Refer to Para 3.5
DamageDefinition. Refer to Para 3.7
DetectionMeansAlarm. Refer to Para 3.16
Document. Refer to Para 3.11
DocumentIssue. Refer to Para 3.11
Facility. Refer to Para 3.13

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 50

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
3.10.3.4

FailureMode. Refer to Para 3.14
GlobalPosition. Refer to Para 3.19
MeasurementPointDefinition. Refer to Para 3.16
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27
ResourceSpecification. Refer to Para 3.32
StreetAddress. Refer to Para 3.19
SubstanceDefinition. Refer to Para 3.25
Task. Refer to Para 3.36

DigitalFileReferencingItem

DigitalFileReferencingItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.10.3.4.1

Class members
Classes that implement the DigitalFileReferencingItem <<extend>> are:
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

AnalysisActivityRevision. Refer to Para 3.21
Breakdown. Refer to Para 3.3
BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
BreakdownRevision. Refer to Para 3.3
ChangeAuthorization. Refer to Para 3.4
ChangeRequest. Refer to Para 3.9
CircuitBreaker. Refer to Para 3.5
CompetencyDefinition. Refer to Para 3.6
Contract. Refer to Para 3.27
DamageDefinition. Refer to Para 3.7
DetectionMeansAlarm. Refer to Para 3.16
Document. Refer to Para 3.11
DocumentIssue. Refer to Para 3.11
Facility. Refer to Para 3.13
FailureMode. Refer to Para 3.14
GeographicalArea. Refer to Para 3.19
InServiceOptimizationAnalysisStep. Refer to Para 3.18
MeasurementPointDefinition. Refer to Para 3.16
Organization. Refer to Para 3.24
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27
Remark. Refer to Para 3.31
ResourceSpecificationRevision. Refer to Para 3.32
SecurityClassification. Refer to Para 3.33
SpecialEventDefinition. Refer to Para 3.35
StreetAddress. Refer to Para 3.19
SubstanceDefinition. Refer to Para 3.25
Subtask. Refer to Para 3.36
Task. Refer to Para 3.36

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 51

S3000L-B6865-03000-00

3.10.3.4.2

Associations
The DigitalFileReferencingItem <<extend>> interface has the following
associations:−

A directed has association with zero, one or many instances ofReferencedDigitalFile
3.10.3.5

ReferencedDigitalFile

ReferencedDigitalFile is a <<relationship> that allows an item to refer to a
DigitalFile.
3.10.3.5.1

Attribute(s)This class has the following attributes:−

3.10.3.5.2

Associations
This class has the following associations:−3.10.3.5.3

referencedDigitalFileJustification, zero, one or many

A directed refersTo association with one instance of DigitalFile

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.11

S3000L UoF Document

3.11.1

Description
The Document UoF provides the capability to identify a physical document or a digital file andtheir associated metadata.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 52

S3000L-B6865-03000-00

3.11.2Graphical description

ICN-B6865-S3000L0233-004-01
Fig 15 S3000L UoF Document

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 53

S3000L-B6865-03000-00

3.11.33.11.3.1

Class definition
Document
Document is a <<class>> that represents a compiled set of information that serves a
purpose.
Example(s)− Drawing− Manual− Report

3.11.3.1.1

Attribute(s)This class has the following attributes:−−−

3.11.3.1.2

Associations
This class has the following associations:−3.11.3.1.3

documentIdentifier, one or many
documentType, zero or one
documentTitle, zero, one or many

An aggregate association with zero, one or many instances of DocumentIssue

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject)
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.11.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

DocumentIssue

DocumentIssue is a <<class>> that represents a specific release of a Document
3.11.3.2.1

Attribute(s)This class has the following attributes:−−

3.11.3.2.2

documentIssueIdentifier
documentIssueDate, zero or one

Implementations
This class implements the following <<extend>> interfaces:−−−−

ChangeControlledItem. Refer to Para 3.4
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject)
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 54

S3000L-B6865-03000-00

3.11.3.3

DocumentItem

DocumentItem is a <<select>> interface that identifies items which can be selected asDocument.
3.11.3.3.1

Class members
This <<select>> interface includes the following class members:−−

3.11.3.4

Document
DocumentIssue

DocumentReferencingItem

DocumentReferencingItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.11.3.4.1

Class members
Classes that implement the DocumentReferencingItem <<extend>> interface are:−−

AllocatedTaskLocation. Refer to Para 3.39
AllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

AnalysisActivity. Refer to Para 3.21
AnalysisActivityRevision. Refer to Para 3.21
ApplicabilityStatement. Refer to Para 3.2
AuthorityToOperate. Refer to Para 3.28
Breakdown. Refer to Para 3.3
BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3
BreakdownRevision. Refer to Para 3.3
ChangeAuthorization. Refer to Para 3.4
ChangeRequest. Refer to Para 3.9
CircuitBreaker. Refer to Para 3.5
CircuitBreakerSetting. Refer to Para 3.36
CircuitBreakerSettings. Refer to Para 3.36
CompetencyDefinition. Refer to Para 3.6
ConditionInstance. Refer to Para 3.2
ConditionType. Refer to Para 3.2
ConditionTypeAssertMember. Refer to Para 3.2
Contract. Refer to Para 3.27
Country. Refer to Para 3.19
DamageDefinition. Refer to Para 3.7
DecisionTreeTemplate. Refer to Para 3.8
DecisionTreeTemplateActionDefinition. Refer to Para 3.8
DecisionTreeTemplateQuestionDefinition. Refer to Para 3.8
DecisionTreeTemplateRevision. Refer to Para 3.8
DetectionMeansAlarm. Refer to Para 3.16
DigitalFile. Refer to Para 3.10
Document. Refer to Para 3.11
DocumentIssue. Refer to Para 3.11
EnvironmentDefinition. Refer to Para 3.12
EnvironmentDefinitionCharacteristic. Refer to Para 3.12

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 55

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

EnvironmentDefinitionRevision. Refer to Para 3.12
EvaluationCriteria. Refer to Para 3.2
Facility. Refer to Para 3.13
FailureMode. Refer to Para 3.14
FailureModeAnalysis. Refer to Para 3.14
FailureModeAnalysisRevision. Refer to Para 3.14
FailureModeCause. Refer to Para 3.14
FailureModeEffect. Refer to Para 3.14
FailureModeSymptomsSignature. Refer to Para 3.16
GeographicalArea. Refer to Para 3.19
GlobalPosition. Refer to Para 3.19
InServiceOptimizationAnalysis. Refer to Para 3.18
InServiceOptimizationAnalysisRevision. Refer to Para 3.18
InServiceOptimizationAnalysisStep. Refer to Para 3.18
LSAFailureModeGroup. Refer to Para 3.22
MaintenanceLevel. Refer to Para 3.29
MeasurementPointDefinition. Refer to Para 3.16
Message. Refer to Para 3.23
OperatingLocationType. Refer to Para 3.29
Organization. Refer to Para 3.24
PartAsDesigned. Refer to Para 3.25
PartAsDesignedPartsList. Refer to Para 3.25
PartAsDesignedPartsListEntry. Refer to Para 3.25
PartAsDesignedPartsListRevision. Refer to Para 3.25
PerformanceParameter. Refer to Para 3.26
PerformanceParameterRevision. Refer to Para 3.26
Product. Refer to Para 3.27
ProductUsagePhase. Refer to Para 3.30
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27
RepeatDefinition. Refer to Para 3.40
ResourceSpecification. Refer to Para 3.32
ResourceSpecificationRevision. Refer to Para 3.32
SecurityClass. Refer to Para 3.33
Skill. Refer to Para 3.6
SkillLevel. Refer to Para 3.6
SpecialEventDefinition. Refer to Para 3.35
StreetAddress. Refer to Para 3.19
SubstanceDefinition. Refer to Para 3.25
Subtask. Refer to Para 3.36
Task. Refer to Para 3.36
TaskRequirement. Refer to Para 3.37
TaskRequirementRevision. Refer to Para 3.37
TaskResource. Refer to Para 3.38
TaskRevision. Refer to Para 3.36
ThresholdDefinition. Refer to Para 3.40
TimeLimit. Refer to Para 3.40
Trade. Refer to Para 3.6

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 56

S3000L-B6865-03000-00−
3.11.3.4.2

WarningCautionNote. Refer to Para 3.36

Associations
The DocumentReferencingItem <<extend>> interface has the following
associations:−

A directed has association with zero, one or many instances ofReferencedDocument
3.11.3.5

ReferencedDocument

ReferencedDocument is a <<relationship>> where one
DocumentReferencingItem relates to a DocumentItem.
3.11.3.5.1

Attribute(s)This class has the following attributes:−−

3.11.3.5.2

Associations
This class has the following associations:−3.11.3.5.3

referencedDocumentRolereferencedDocumentPortion, zero, one or many

A directed definedBy association with one instance of DocumentItem

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject)
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.11.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

S1000DDataModule

S1000DDataModule is a Document that is written in accordance with an S1000D
schema.
3.11.3.6.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−
−
−
−
−
−
−

documentIdentifier (inherited from Document), one or many
documentType (inherited from Document), zero or one
documentTitle (inherited from Document), zero, one or manymodelIdentificationCode
systemDifferenceCodematerialItemCategoryCode, zero or one
systemsubSystem
subSubSystemassembly
disassemblyCode
disassemblyCodeVariant
informationCode

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 57

S3000L-B6865-03000-00

−
−
−
−
−
−
3.11.3.6.2

Associations
This class has the following associations:−3.11.3.6.3

informationCodeVariant
itemLocationCodelearnCode, zero or one
learnEventCode, zero or one
extensionProducer, zero or one
extensionCode, zero or one

An aggregate association with zero, one or many instances of

S1000DDataModuleIssue

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem (inherited from Document). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.11.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Document). Refer to Para 3.33

S1000DDataModuleIssue

S1000DDataModuleIssue is a DocumentIssue that identifies a specific issue of adata module produced in accordance with S1000D.
3.11.3.7.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.11.3.7.2

documentIssueIdentifier (inherited from DocumentIssue)
documentIssueDate (inherited from DocumentIssue), zero or one
dataModuleIssueNumber
dataModuleIssueInWorkNumber, zero or one
dataModuleIssueLanguage, zero or one
dataModuleIssueLanguageCountry, zero or one

Implementations
This class implements the following <<extend>> interfaces:−−

ChangeControlledItem (inherited from DocumentIssue). Refer to Para 3.4
DigitalFileReferencingItem (inherited from DocumentIssue). Refer toPara 3.10−−

DocumentReferencingItem (inherited from BaseObject)
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 58

S3000L-B6865-03000-00

3.11.3.8

S1000DPublicationModule

S1000DPublicationModule is a Document that identifies a publication published inaccordance with S1000D.
3.11.3.8.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−
−
−

3.11.3.8.2

Associations
This class has the following associations:−3.11.3.8.3

documentIdentifier (inherited from Document), one or many
documentType (inherited from Document), zero or one
documentTitle (inherited from Document), zero, one or manymodelIdentificationCode
publicationModuleIssuer
publicationModuleNumber
publicationModuleVolume
extensionProducer, zero or one
extensionCode, zero or one

An aggregate association with zero, one or many instances of

S1000DPublicationModuleIssue

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem (inherited from Document). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject)
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.11.3.9

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Document). Refer to Para 3.33

S1000DPublicationModuleIssue

S1000DPublicationModuleIssue is a DocumentIssue that identifies a specificissue of a publication module published in accordance with S1000D.
3.11.3.9.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.11.3.9.2

documentIssueIdentifier (inherited from DocumentIssue)
documentIssueDate (inherited from DocumentIssue), zero or one
publicationModuleIssueNumber
publicationModuleIssueInWorkNumber, zero or one
publicationModuleIssueLanguage, zero or one
publicationModuleIssueLanguageCountry, zero or one

Implementations
This class implements the following <<extend>> interfaces:−−

ChangeControlledItem (inherited from DocumentIssue). Refer to Para 3.4
DigitalFileReferencingItem (inherited from DocumentIssue). Refer toPara 3.10

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 59

S3000L-B6865-03000-00−−

DocumentReferencingItem (inherited from BaseObject)
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.12

S3000L UoF Environment Definition

3.12.1

Description
The Environment Definition UoF provides the capability to define circumstances, objects, events
and/or conditions by which something can be surrounded and that influence the performance ofan associated item.

3.12.2Graphical description

ICN-B6865-S3000L0272-001-01
Fig 16 S3000L UoF Environment Definition

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 60

S3000L-B6865-03000-00

3.12.33.12.3.1

Class definition
AssociatedEnvironmentDefinition

AssociatedEnvironmentDefinition is a <<relationship>> thatassociates an EnvironmentDefinitionItem with an
EnvironmentDefinition relevant to its existence, operation and/or support.
3.12.3.1.1

Associations
This class has the following associations:−

A directed definedBy association with one instance ofEnvironmentDefinition
3.12.3.2

EnvironmentDefinition

EnvironmentDefinition is a <<class>> that specifies the circumstances, objects,
events and/or conditions by which something can be surrounded and that influence theperformance of an associated item.
3.12.3.2.1

Attribute(s)This class has the following attributes:−

3.12.3.2.2

Associations
This class has the following associations:−−3.12.3.2.3

environmentDefinitionIdentifier, one or many

An aggregate association with zero, one or many instances ofEnvironmentDefinitionRevision
A directed has association with zero, one or many instances ofEnvironmentDefinitionRelationship

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.12.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EnvironmentDefinitionCharacteristic

EnvironmentDefinitionCharacteristic is a <<class>> that represents a
measurable or observable characteristic for a circumstance, object, event or condition that issignificant to the EnvironmentDefinition.
3.12.3.3.1

Attribute(s)This class has the following attributes:−−−−

environmentDefinitionCharacteristicName, one or manyenvironmentDefinitionCharacteristicValue, one or manyenvironmentDefinitionCharacteristicValueComparisonOperator, zero or one
environmentDefinitionCharacteristicDescription, zero, one or
many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 61

S3000L-B6865-03000-00

3.12.3.3.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.12.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EnvironmentDefinitionItem

EnvironmentDefinitionItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.12.3.4.1

Class members
Classes that implement the EnvironmentDefinitionItem <<extend>> interface
are:
−
−
−
−
−
−
−
−
−

3.12.3.4.2

Country. Refer to Para 3.19
Facility. Refer to Para 3.13
GeographicalArea. Refer to Para 3.19
GlobalPosition. Refer to Para 3.19
MaintenanceLevel. Refer to Para 3.29
OperatingLocationType. Refer to Para 3.29
StreetAddress. Refer to Para 3.19
Task. Refer to Para 3.36
TaskRevision. Refer to Para 3.36

Associations
The EnvironmentDefinitionItem <<extend>> interface has the following
associations:−

A directed has association with zero, one or many instances of

AssociatedEnvironmentDefinition
3.12.3.5

EnvironmentDefinitionRelationship

EnvironmentDefinitionRelationship is a <<relationship>> where one
EnvironmentDefinition relates to another EnvironmentDefinition.
3.12.3.5.1

Attribute(s)This class has the following attributes:−

3.12.3.5.2

environmentDefinitionRelationshipType

Associations
This class has the following associations:−

A directed definedBy association with one instance ofEnvironmentDefinition
3.12.3.6

EnvironmentDefinitionRevision

EnvironmentDefinitionRevision is a <<class>> representing an iteration
applied to an EnvironmentDefinition.
3.12.3.6.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 62

S3000L-B6865-03000-00

−
−
−
−
−
−
3.12.3.6.2

Associations
This class has the following associations:−3.12.3.6.3

environmentDefinitionRevisionIdentifierenvironmentDefinitionName, zero, one or manyenvironmentDefinitionDescription, zero, one or manyenvironmentDefinitionRevisionRationale, zero, one or manyenvironmentDefinitionRevisionDate, zero or one
environmentDefinitionRevisionStatus, zero or one

An aggregate association with zero, one or many instances ofEnvironmentDefinitionCharacteristic

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.13

S3000L UoF Facility

3.13.1

Description
The Facility UoF provides the capability to identify a facility and to declare to what extent it
fulfills a set of identified infrastructure requirements.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 63

S3000L-B6865-03000-00

3.13.2Graphical description

ICN-B6865-S3000L0270-001-01
Fig 17 S3000L UoF Facility
3.13.33.13.3.1

Class definition
Facility
Facility is a <<class> that represents a physically limited infrastructure which exists, or isintended to be built or installed, and is established to serve a particular purpose.

3.13.3.1.1

Attribute(s)This class has the following attributes:−−−

3.13.3.1.2

3.13.3.1.3

facilityIdentifier, one or many
facilityName, zero, one or many
facilityDescription, zero, one or many

Associations
This class has the following associations:−

A directed has association with zero, one or many instances of−FacilityRelationshipA directed isAt association with one instance of LocationItem. Refer to Para 3.19

Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
InfrastructureCompliantItem. Refer to Para 3.13

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 64

S3000L-B6865-03000-00−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.13.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

FacilityRelationship

FacilityRelationship is a <<relationship>> where one Facility relates
to another Facility.
3.13.3.2.1

Attribute(s)This class has the following attributes:−

3.13.3.2.2

Associations
This class has the following associations:−3.13.3.2.3

facilityRelationshipType

A directed with association with one instance of Facility

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.13.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

InfrastructureCompliance

InfrastructureCompliance is a <<relationship>> that documents how theInfrastructureCompliantItem fulfills requirements stated in the associatedResourceSpecification.
3.13.3.3.1

Attribute(s)This class has the following attributes:−−−

3.13.3.3.2

Associations
This class has the following associations:−3.13.3.3.3

infrastructureComplianceLevel
infrastructureComplianceDate, zero or one
infrastructureComplianceDescription, zero, one or many

A directed definedBy association with one instance ofResourceSpecification. Refer to Para 3.32

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 65

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.13.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

InfrastructureCompliantItem

InfrastructureCompliantItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.13.3.4.1

Class members
Classes that implement the InfrastructureCompliantItem <<extend>>
interface are:−3.13.3.4.2

Associations
The InfrastructureCompliantItem <<extend>> interface has the following
associations:−3.13.3.5

Facility

A directed association with zero, one or many instances ofInfrastructureCompliance

MaintenanceFacility

MaintenanceFacility is a Facility that is mainly established for providing productsupport.
3.13.3.5.1

Attribute(s)This class has the following attributes:−−−−

3.13.3.5.2

Associations
This class has the following associations:−−−3.13.3.5.3

facilityIdentifier (inherited from Facility), one or many
facilityName (inherited from Facility), zero, one or many
facilityDescription (inherited from Facility), zero, one or many
maintenanceFacilityType, zero or one

A directed has association with zero, one or many instances ofFacilityRelationship (inherited from Facility)
A directed isAt association with one instance of LocationItem (inherited fromFacility)
A directed maintenanceCapability association with zero or one instances of
MaintenanceLevel. Refer to Para 3.29

Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem (inherited from Facility). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem (inherited from Facility). Refer to Para 3.12
InfrastructureCompliantItem (inherited from Facility). Refer toPara 3.13−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 66

S3000L-B6865-03000-00−
3.13.3.6

SecurityClassificationItem (inherited from Facility). Refer to Para 3.33

OperatingBase

OperatingBase is a Facility that is mainly established for providing support for
operations.
3.13.3.6.1

Attribute(s)This class has the following attributes:−−−−

3.13.3.6.2

Associations
This class has the following associations:−−−3.13.3.6.3

facilityIdentifier (inherited from Facility), one or many
facilityName (inherited from Facility), zero, one or many
facilityDescription (inherited from Facility), zero, one or many
operatingBaseType, zero or one

A directed has association with zero, one or many instances ofFacilityRelationship (inherited from Facility)
A directed isAt association with one instance of LocationItem (inherited fromFacility)
A directed operatingCapability association with zero or one instances ofOperatingLocationType. Refer to Para 3.29

Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem (inherited from Facility). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem (inherited from Facility). Refer to Para 3.12
InfrastructureCompliantItem (inherited from Facility). Refer toPara 3.13−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Facility). Refer to Para 3.33

3.14

S3000L UoF Failure Mode

3.14.1

Description
The Failure Mode UoF provides the capability to define the failure modes, their causes andeffects.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 67

S3000L-B6865-03000-00

3.14.2Graphical description

class S3000L UoF Failure Mode«class»FailureModeAnalysis«extend»
FailureModeAnalysisItem«class»
S3000L UoF Breakdown Structure::
BreakdownElement

0..* «compositeKey»+ failureModeAnalysisType :ClassificationType«class»
S3000L UoF Breakdown Structure::
BreakdownElementRevision1..*«class»FailureModeAnalysisRev ision«class»
S3000L UoF Part Definition::
PartAsDesigned«compositeKey»+ failureModeAnalysisRevisionIdentifier :IdentifierType [1..*]«characteristic»+ failureModeAnalysisDescription :DescriptorType [0..*]+ failureModeAnalysisRevisionRationale :DescriptorType [0..*]+ failureModeAnalysisRevisionDate :DateType [0..1]+ failureModeAnalysisRevisionStatus :StateType [0..1]«class»
S3000L UoF Part Definition::
PartAsDesignedPartsListEntry

1..*«class»FailureMode«class»FailureModeCause«compositeKey»+ failureModeCauseIdentifier :IdentifierType [1..*]«characteristic»+ failureModeCauseDescription :DescriptorType [1..*]+ failureModeCauseRatio :PropertyType [0..*]«compositeKey»+ failureModeIdentifier :IdentifierType [1..*]0..*«characteristic»+ failureModeName :NameType [0..*]+ failureModeDescription :DescriptorType [0..*]+ failureModeRatio :PropertyType [0..*]1
0..*«select»
FailureModeCauseItem+definedBy
1

+has

0..*

«relationship»
FailureModeCauseItemRelationship«class»FailureModeEffect

0..* «characteristic»+ failureModeCauseItemRelationshipType :ClassificationType«compositeKey»+ failureModeEffectName :NameType [1..*]«characteristic»+ failureModeEffectLevel :ClassificationType+ failureModeEffectDescription :DescriptorType [o..*]+ failureModeCriticality :ClassificationType [0..*]1+has«select»
FailureModeEffectItem

1

0..*

«relationship»
FailureModeEffectItemRelationship+definedBy0..*

ICN-B6865-S3000L0276-001-01
Fig 18 S3000L UoF Failure Mode
3.14.33.14.3.1

Class definition
FailureMode

FailureMode is a <<class>> that defines a functional consequence of an unacceptablestate of the FailureModeAnalysisItem.
Example(s)− No output from electrical circuit.
3.14.3.1.1

Attribute(s)This class has the following attributes:−−−−

failureModeIdentifier, one or many
failureModeName, zero, one or many
failureModeDescription, zero, one or many
failureModeRatio, zero, one or many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 68

S3000L-B6865-03000-00

3.14.3.1.2

Associations
This class has the following associations:−−3.14.3.1.3

An aggregate association with zero, one or many instances of FailureModeCauseAn aggregate association with zero, one or many instances of FailureModeEffect

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−

ApplicabilityStatementItem. Refer to Para 3.2
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeIsolationItem. Refer to Para 3.15
FailureModeSymptomsSignatureItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.14.3.1.4

Selects
This class is a member of the following <<select>> interfaces:−−−

3.14.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DigitalFileReferencedItem. Refer to Para 3.10
FailureModeCauseItem
LSAFailureModeGroupItem. Refer to Para 3.22

FailureModeAnalysis

FailureModeAnalysis is a <<class>> that represents failure modes, effects andcriticality identified for the associated FailureModeAnalysisItem.
3.14.3.2.1

Attribute(s)This class has the following attributes:−

3.14.3.2.2

Associations
This class has the following associations:−3.14.3.2.3

failureModeAnalysisType

An aggregate association with one or many instances ofFailureModeAnalysisRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.14.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeAnalysisItem

FailureModeAnalysisItem is an <<extend>> interface that provides its
associated data model to those classes that can have an associatedFailureModeAnalysis.
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 69

S3000L-B6865-03000-00

3.14.3.3.1

Class members
Classes that implement the FailureModeAnalysisItem <<extend>> are:−−−3.14.3.3.2

Associations
The FailureModeAnalysisItem <<extend>> interface has the following
associations:−3.14.3.4

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25

An aggregate association with zero, one or many. instances ofFailureModeAnalysis

FailureModeAnalysisRevision

FailureModeAnalysisRevision is a <<class>> representing an iteration
applied to a FailureModeAnalysis.
3.14.3.4.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.14.3.4.2

Associations
This class has the following associations:−3.14.3.4.3

failureModeAnalysisRevisionIdentifier, one or many
failureModeAnalysisDescription, zero, one or many
failureModeAnalysisRevisionRationale, zero, one or many
failureModeAnalysisRevisionDate, zero or one
failureModeAnalysisRevisionStatus, zero or one

An aggregate association with one or many instances of FailureMode

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.14.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeCause

FailureModeCause is a <<class>> that specifies the physical or chemical
process(es) that is the reason for the FailureMode.
3.14.3.5.1

Attribute(s)This class has the following attributes:−−−

3.14.3.5.2

failureModeCauseIdentifier, one or many
failureModeCauseDescription, one or many
failureModeCauseRatio, zero, one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 70

S3000L-B6865-03000-00−

A directed has association with zero, one or many instances ofFailureModeCauseItemRelationship3.14.3.5.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.14.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeCauseItem

FailureModeCauseItem is a <<select>> interface that identifies items which canbe selected as being associated with a FailureModeCause.
3.14.3.6.1

Class members
This <<select>> interface includes the following class members:−−−−

3.14.3.7

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
FailureMode
PartAsDesignedPartsListEntry. Refer to Para 3.25

FailureModeCauseItemRelationship

FailureModeCauseItemRelationship is a <<relationship>> where a
FailureModeCause relates to the FailureModeCauseItem that in some way is
associated with the FailureModeCause.
3.14.3.7.1

Attribute(s)This class has the following attributes:−

3.14.3.7.2

Associations
This class has the following associations:−3.14.3.7.3

failureModeCauseItemRelationshipType

A directed definedBy association with one instance of FailureModeCauseItem

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.14.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeEffectFailureModeEffect is a <<class>> that defines the consequences of an identified
FailureMode on the operation, function, or status for the referred item.
3.14.3.8.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 71

S3000L-B6865-03000-00−−−−
3.14.3.8.2

failureModeEffectName, one or many
failureModeEffectLevel
failureModeEffectDescription
failureModeCriticality, zero, one or many

Associations
This class has the following associations:−

A directed has association with zero, one or many instances ofFailureModeEffectItemRelationship3.14.3.8.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.14.3.9

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeEffectItem

FailureModeEffectItem is a <<select>> interface that identifies items which canbe selected as being affected by a FailureMode.
3.14.3.9.1

Class members
This <<select>> interface includes the following class members:−−−

3.14.3.10

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesignedPartsListEntry. Refer to Para 3.25

FailureModeEffectItemRelationship

FailureModeEffectItemRelationship is a <<relationship>> where a
FailureModeEffect relates to the FailureModeEffectItem that is affected by
the FailureMode.
3.14.3.10.1 Associations
This class has the following associations:−

A directed definedBy association with one instance ofFailureModeEffectItem
3.14.3.10.2 Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 72

S3000L-B6865-03000-00

3.15

S3000L UoF Failure Mode Isolation

3.15.1

Description
The Failure Mode Isolation UoF provides the capability to collect data which describes theability to determine that it the associated failure mode that have occurred.

3.15.2Graphical description

ICN-B6865-S3000L0279-001-01
Fig 19 S3000L UoF Failure Mode Isolation
3.15.33.15.3.1

Class definition
FailureModeIsolationCharacteristics

FailureModeIsolationCharacteristics is an <<attributeGroup>>that collects data which describes the ability to determine that it is the associated failure modethat has occurred.
3.15.3.1.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−−

3.15.3.2

failureModeIsolationAbilityRating
failureModeIsolationAbilityDescription, zero, one or many
failureModeIsolationRate, zero, one or many

FailureModeIsolationItem

FailureModeIsolationItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.15.3.2.1

Class members
Classes that implement the FailureModeIsolationItem <<extend>> interface
are:
−
−

3.15.3.2.2

FailureMode. Refer to Para 3.14
LSAFailureModeGroup. Refer to Para 3.22

Associations
The FailureModeIsolationItem <<extend>> interface has the following
associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 73

S3000L-B6865-03000-00−

An aggregate association with zero or one instance ofFailureModeIsolationCharacteristics

3.16

S3000L UoF Failure Mode Symptom

3.16.1

Description
The Failure Mode Symptom UoF provides the capability to identify measurable or visible
parameters whose appearance can be related, directly or indirectly, to the occurrence of theassociated failure mode.

3.16.2Graphical description

ICN-B6865-S3000L0278-001-01
Fig 20 S3000L UoF Failure Mode Symptom

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 74

S3000L-B6865-03000-00

3.16.33.16.3.1

Class definition
DetectionMeansAlarm

DetectionMeansAlarm is a <<class>> that supports the definition and description ofan alarm being implemented by a DetectionMeansAlarmItem.
3.16.3.1.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.16.3.1.2

detectionMeansAlarmIdentifier, one or manydetectionMeansAlarmType
detectionMeansAlarmPresentation, one or manydetectionMeansAlarmDescription, zero, one or manydetectionMeansAlarmFalseAlarmRate, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.16.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

DetectionMeansAlarmItem

DetectionMeansAlarmItem is an <<extend>> interface that provides its
associated data model to those classes that can have an associatedDetectionMeansAlarm.
3.16.3.2.1

Class members
Classes that implement the DetectionMeansAlarmItem <<extend>> interface are:
−
−
−
−
−

3.16.3.2.2

Associations
The DetectionMeansAlarmItem <<extend>> interface has the following
associations:−3.16.3.3

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

An aggregate association with zero, one or many instances ofDetectionMeansAlarm

FailureModeSymptom

FailureModeSymptom is a <<relationship>> that identifies a measurable orvisible parameter whose appearance can be related, directly or indirectly, to the occurrence of
the associated failure mode.
3.16.3.3.1

Attribute(s)This class has the following attributes:−

failureModeSymptomRatio, zero, one or many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 75

S3000L-B6865-03000-00

3.16.3.3.2

Associations
This class has the following associations:−

A directed definedBy association with one instance ofFailureModeSymptomItem
3.16.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.16.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeSymptomItem

FailureModeSymptomItem is a <<select>> interface that identifies items which
can provide a measurable or visible parameter whose appearance can be related, directly or
indirectly, to the occurrence of the associated failure mode.
3.16.3.4.1

Class members
This <<select>> interface includes the following class members:−−

3.16.3.5

DetectionMeansAlarm
MeasurementPointDefinition

FailureModeSymptomsSignature

FailureModeSymptomsSignature is a <<class>> that identifies a set of failuremode symptoms and effects which can be associated with a failure mode.
Note
Failure mode symptoms can be human observable as well as alarms and measurements.
3.16.3.5.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.16.3.5.2

failureModeSymptomsSignatureIdentifier, one or many
failureModeSymptomsDescription, zero, one or many
failureModeEffectSummaryDescription, zero, one or many
failureModeDetectionAbilityRatio
failureModeDetectionAbilityDescription, zero, one or many

Associations
This class has the following associations:−

A directed has association with zero, one or many instances ofFailureModeSymptom
3.16.3.5.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 76

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.16.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FailureModeSymptomsSignatureItem

FailureModeSymptomsSignatureItem is an <<extend>> interface thatprovides its associated data model to those classes that can have an associatedFailureModeSymptomsSignature.
3.16.3.6.1

Class members
Classes that implement the FailureModeSymptomsSignatureItem<<extend>> interface are:−−3.16.3.6.2

Associations
The FailureModeSymptomsSignatureItem <<extend>> interface has thefollowing associations:−3.16.3.7

FailureMode
LSAFailureModeGroupAn aggregate association with zero, one or many instances ofFailureModeSymptomsSignature

MeasurementPointDefinition

MeasurementPointDefinition is a <<class>> that specifies a characteristic
which can be observed for a MeasurementPointDefinitionItem.
3.16.3.7.1

Attribute(s)This class has the following attributes:−−−−

3.16.3.7.2

3.16.3.7.3

measurementPointDefinitionIdentifier, one or manymeasurementPointDefinitionName, zero, one or manymeasurementPointDefinitionType, zero or one
measurementPointDefinitionDescription, zero, one or many

Associations
This class has the following associations:−

An aggregate association with zero or one instance of−An aggregate association with zero or one instance of

MeasurementPointFaultStateDefinition
MeasurementPointDegradedStateDefinition. Refer to Para 3.40

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 77

S3000L-B6865-03000-00

3.16.3.8

MeasurementPointDefinitionItem

MeasurementPointDefinitionItem is an <<extend>> interface that provides
its associated data model to those classes that can have an associatedMeasurementPointDefinition.
3.16.3.8.1

Class members
Classes that implement the MeasurementPointDefinitionItem <<extend>>
interface are:
−
−
−
−
−

3.16.3.8.2

Associations
The MeasurementPointDefinitionItem <<extend>> interface has thefollowing associations:−3.16.3.9

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

An aggregate association with zero, one or many instances of

MeasurementPointDefinition

MeasurementPointFaultStateDefinition

MeasurementPointFaultStateDefinition is an <<attributeGroup>>that specifies a measurable condition which, when met, can identify that a failure has occurred.
3.16.3.9.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

measurementPointFaultStateDefinitionAssertValue, one or manymeasurementPointFaultStateDefinitionAssertValueCompariso
nOperator

3.17

S3000L UoF Hardware Element

3.17.1

Description
The Hardware Element UoF provides the capability to specify that an element within abreakdown is hardware and can be associated with the hardware part(s) that fulfill therequirement.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 78

S3000L-B6865-03000-00

3.17.2Graphical description

class S3000L UoF Hardw are Element«class»Hardw areElement«class»
S3000L UoF Breakdown Structure::
BreakdownElement«characteristic»+ hardwareElementType :ClassificationType [1..*]1..*{local}«class»Hardw areElementRev ision1..*«class»
S3000L UoF Breakdown Structure::
BreakdownElementRevision{redefines the BreakdownElement toBreakdownElementRevision composition
association}«characteristic»+ hardwareElementStructuralIndicator :ClassificationType+ hardwareElementReplaceability :ClassificationType+ hardwareElementReplaceabilityStrategy :ClassificationType [0..*]+ hardwareElementRepairability :ClassificationType+ hardwareElementRepairabilityStrategy :ClassificationType [0..*]
1
+has

0..*

«relationship»
Hardw areElementPartRealization0..*+definedBy

1«class»
S3000L UoF Part Definition::
Hardw arePartAsDesigned

ICN-B6865-S3000L0273-001-01
Fig 21 S3000L UoF Hardware Element
3.17.33.17.3.1

Class definition
HardwareElement

HardwareElement is a BreakdownElement (refer to Para 3.3) that is realized as a
HardwarePartAsDesigned (refer to Para 3.25).
3.17.3.1.1

Attribute(s)This class has the following attributes:−

breakdownElementIdentifier (inherited from BreakdownElement), one
or many−

breakdownElementName (inherited from BreakdownElement), zero, one or
many−

breakdownElementEssentiality (inherited from BreakdownElement),
zero or one−
3.17.3.1.2

hardwareElementType, one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 79

S3000L-B6865-03000-00−
3.17.3.1.3

An aggregate association with one or many instances of

HardwareElementRevision

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElement). Refer toPara 3.21−

BreakdownElementInZoneItem (inherited from BreakdownElement). Refer
to Para 3.41−

DecisionTreeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from BreakdownElement). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from BreakdownElement).
Para 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.14−−−

InServiceOptimizationAnalysisItem (inherited fromBreakdownElement). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElement). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited from BreakdownElement). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from BreakdownElement). Refer
to Para 3.33

3.17.3.2

HardwareElementPartRealization

HardwareElementPartRealization is a <<relationship>> where a
HardwareElementRevision relates to an instance ofHardwarePartAsDesigned which fulfills the HardwareElement specification.
3.17.3.2.1

Associations
This class has the following associations:−3.17.3.2.2

A directed association with one instance of HardwarePartAsDesigned. Refer toPara 3.25

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EffectiveOnProductConfigurationItem. Refer to Para 3.28
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 80

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−3.17.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
UsableOnItem. Refer to Para 3.28

HardwareElementRevision

HardwareElementRevision is a BreakdownElementRevision (refer toPara 3.3) representing an iteration applied to a HardwareElement.
3.17.3.3.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−
−
−
−
−

3.17.3.3.2

breakdownElementRevisionIdentifier (inherited fromBreakdownElementRevision)
breakdownElementDescription (inherited fromBreakdownElementRevision), zero, one or many
maintenanceSignificantOrRelevant (inherited fromBreakdownElementRevision)
breakdownElementRevisionRationale (inherited fromBreakdownElementRevision), zero, one or many
breakdownElementRevisionDate (inherited fromBreakdownElementRevision), zero or one
breakdownElementRevisionStatus (inherited fromBreakdownElementRevision), zero or one
hardwareElementStructuralIndicator
hardwareElementReplaceability
hardwareElementReplaceabilityStrategy, zero, one or many
hardwareElementRepairability
hardwareElementRepairabilityStrategy, zero, one or many

Associations
This class has the following associations:−−

A directed has association with zero, one or many instances ofBreakdownElementRevisionRelationship (inherited fromBreakdownElementRevision). Refer to Para 3.3
A directed has association with zero, one or many instances of

HardwareElementPartRealization
3.17.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElementRevision).
Refer to Para 3.21−−

BreakdownElementInZoneItem (inherited fromBreakdownElementRevision). Refer to Para 3.41
ChangeControlledItem (inherited from BreakdownElementRevision).
Refer to Para 3.4−−

DetectionMeansAlarmItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
DigitalFileReferencingItem (inherited fromBreakdownElementRevision). Refer to Para 3.10

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 81

S3000L-B6865-03000-00

−
−
−
−
−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.14
InServiceOptimizationAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem (inherited fromBreakdownElementRevision). Refer to Para 3.26
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TaskAnalysisItem (inherited from BreakdownElementRevision). Refer toPara 3.39−

TaskRequirementAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.37

3.18

S3000L UoF In Service Optimization Analysis

3.18.1

Description
The In Service Optimization Analysis UoF provides the capability to represent the result from an
actual analysis carried out for the analyzed item and in accordance with a defined decision tree
template.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 82

S3000L-B6865-03000-00

3.18.2Graphical description

ICN-B6865-S3000L0290-001-01
Fig 22 S3000L UoF In Service Optimization Analysis
3.18.33.18.3.1

Class definition
FinalInServiceOptimizationAnalysisStep

FinalInServiceOptimizationAnalysisStep is an
InServiceOptimizationAnalysisStep that specifies final actions and measurestaken together with the decision process conclusion and recommendations.
3.18.3.1.1

Attribute(s)This class has the following attributes:−−

3.18.3.1.2

inServiceOptimizationAnalysisStepIdentifier (inherited fromInServiceOptimizationAnalysisStep)
inServiceOptimizationAnalysisStepDescription (inherited fromInServiceOptimizationAnalysisStep), one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 83

S3000L-B6865-03000-00

3.18.3.1.3−

A directed has association with zero, one or many instances of−

FollowOnInServiceOptimizationAnalysis
A directed definedBy association with one instance ofDecisionTreeTemplateEndActionDefinition. Refer to Para 3.8

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem (inherited fromInServiceOptimizationAnalysisStep). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.18.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FollowOnInServiceOptimizationAnalysis

FollowOnInServiceOptimizationAnalysis is a <<relationship>>where the outcome from the InServiceOptimizationAnalysis resulted in an
additional InServiceOptimizationAnalysis.
3.18.3.2.1

Attribute(s)This class has the following attributes:−

followOnInServiceOptimizationAnalysisRationale, zero, one ormany

3.18.3.2.2

Associations
This class has the following associations:−

A directed definedBy association with one instance of

InServiceOptimizationAnalysis
3.18.3.2.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.18.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

FurtherAnalysisInServiceOptimizationAnalysisStep

FurtherAnalysisInServiceOptimizationAnalysisStep is an
InServiceOptimizationAnalysisStep that specifies actions and measurestaken before continuing to the next step defined in the associatedDecisionTreeTemplate (refer to Para 3.8).
3.18.3.3.1

Attribute(s)This class has the following attributes:−

inServiceOptimizationAnalysisStepIdentifier (inherited fromInServiceOptimizationAnalysisStep)

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 84

S3000L-B6865-03000-00−

3.18.3.3.2

inServiceOptimizationAnalysisStepDescription (inherited fromInServiceOptimizationAnalysisStep), one or many

Associations
This class has the following associations:−

A directed association with one instance ofDecisionTreeTemplateFurtherAnalysisActionDefinition. Refer
to Para 3.8

3.18.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem (inherited fromInServiceOptimizationAnalysisStep). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.18.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

InServiceOptimizationAnalysis

InServiceOptimizationAnalysis is a <<class>> that represents the result
from an in-service optimization analysis carried out for the
InServiceOptimizationAnalysisItem.
3.18.3.4.1

Attribute(s)This class has the following attributes:−

3.18.3.4.2

Associations
This class has the following associations:−3.18.3.4.3

inServiceOptimizationAnalysisName, one or many

An aggregate association with zero, one or many instances of

InServiceOptimizationAnalysisRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.18.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

InServiceOptimizationAnalysisItem

InServiceOptimizationAnalysisItem is an <<extend>> interface thatprovides its associated data model to those classes that can have an associated
InServiceOptimizationAnalysis.
3.18.3.5.1

Class members
Classes that implement the InServiceOptimizationAnalysisItem<<extend>> interface are:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 85

S3000L-B6865-03000-00

−
−
−
−
−
−
3.18.3.5.2

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27

Associations
The InServiceOptimizationAnalysisItem <<extend>> interface has thefollowing associations:−

An aggregate association with zero, one or many instances of

InServiceOptimizationAnalysis
3.18.3.6

InServiceOptimizationAnalysisRevision

InServiceOptimizationAnalysisRevision is a <<class>> representing an
iteration applied to an InServiceOptimizationAnalysis.
3.18.3.6.1

Attribute(s)This class has the following attributes:−−−

inServiceOptimizationAnalysisRevisionIdentifier
inServiceOptimizationAnalysisRationale, zero, one or many
inServiceOptimizationAnalysisSummaryDescription, zero, one or
many−

inServiceOptimizationAnalysisRevisionRationale, zero, one or
many

−
−
3.18.3.6.2

3.18.3.6.3

inServiceOptimizationAnalysisRevisionDate, zero or one
inServiceOptimizationAnalysisRevisionStatus, zero or one

Associations
This class has the following associations:−

An ordered aggregate association with zero, one or many instances of−

InServiceOptimizationAnalysisStep
A directed definedBy association with one instance ofDecisionTreeTemplateRevision. Refer to Para 3.8

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.18.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

InServiceOptimizationAnalysisStep

InServiceOptimizationAnalysisStep is a <<class>> that represents theresults from an individual step in the associated decision process.
3.18.3.7.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 86

S3000L-B6865-03000-00−−
3.18.3.7.2

inServiceOptimizationAnalysisStepIdentifier
inServiceOptimizationAnalysisStepDescription, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.18.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31

QuestionInServiceOptimizationAnalysisStep

QuestionInServiceOptimizationAnalysisStep is an
InServiceOptimizationAnalysisStep that specifies the answer to a question
defined in the associated DecisionTreeTemplate (refer to Para 3.8).
3.18.3.8.1

Attribute(s)This class has the following attributes:−−−

3.18.3.8.2

inServiceOptimizationAnalysisStepIdentifier (inherited fromInServiceOptimizationAnalysisStep)
inServiceOptimizationAnalysisStepDescription (inherited fromInServiceOptimizationAnalysisStep), one or many
inServiceOptimizationAnalysisStepQuestionAnswer

Associations
This class has the following associations:−

A directed definedBy association with one instance ofDecisionTreeTemplateQuestionDefinition. Refer to Para 3.8
3.18.3.8.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem (inherited fromInServiceOptimizationAnalysisStep). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.19

S3000L UoF Location

3.19.1

Description
The Location UoF provides the capability to define a geographic location.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 87

S3000L-B6865-03000-00

3.19.2Graphical description

ICN-B6865-S3000L0271-001-01
Fig 23 S3000L UoF Location
3.19.33.19.3.1

Class definition
CountryCountry is a self-governing political entity, occupying a particular territory.

3.19.3.1.1

Attribute(s)This class has the following attributes:−

3.19.3.1.2

Associations
This class has the following associations:−3.19.3.1.3

countryCode

An aggregate association with zero, one or many instances of StreetAddress

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 88

S3000L-B6865-03000-00

−
−
−
−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
Location. Refer to Para 3.19
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.19.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

GeographicalArea

GeographicalArea is a <<class>> that represents a particular extent of space.
3.19.3.2.1

Attribute(s)This class has the following attributes:−−−

3.19.3.2.2

geographicalAreaName, one or many
geographicalAreaDescription, zero, one or many
geographicalAreaType

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
Location. Refer to Para 3.19
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.19.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

GlobalPosition

GlobalPosition is a <<class>> that identifies a point in space by a set ofcoordinates.
3.19.3.3.1

Attribute(s)This class has the following attributes:−−−−

3.19.3.3.2

latitudelongitude
altitude
geographicalCoordinateSystem

Implementations
This class implements the following <<extend>> interfaces:−−−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
Location. Refer to Para 3.19
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 89

S3000L-B6865-03000-00−
3.19.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Location

Location is an <<extend>> interface that provides its associated data model to thoseclasses that implement it.
3.19.3.4.1

Class members
Classes that implement the Location <<extend>> interface are:−−−−3.19.3.4.2

Country
GeographicalArea
GlobalPosition
StreetAddress

Associations
The Location <<extend>> interface has the following associations:−

A directed has association with zero, one or many instances ofLocationRelationship3.19.3.5

LocationItem

LocationItem is a <<select>> interface that identifies items which can be selected toprovide the definition of a geographic location.
3.19.3.5.1

Class members
This <<select>> interface includes the following class members:−−−−

3.19.3.6

Country
GeographicalArea
GlobalPosition
StreetAddress

LocationRelationship

LocationRelationship is a <<relationship>> where one LocationItem
relates to another LocationItem
3.19.3.6.1

Attribute(s)This class has the following attributes:−

3.19.3.6.2

Associations
This class has the following associations:−3.19.3.6.3

locationRelationshipType

A directed with association with zero, one or many instances of LocationItem

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 90

S3000L-B6865-03000-00

3.19.3.7

StreetAddress

StreetAddress is a <<class> that represents a locatable position along a road.
3.19.3.7.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.19.3.7.2

streetName
streetNumber
cityNamepostalCode
additionalAddressInformation, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
Location. Refer to Para 3.19
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.20

S3000L UoF Logistics Support Analysis Message Content

3.20.1

Description
The Logistics Support Analysis Message Content UoF defines the collection of information thatcan be exchanged for Logistics Support Analysis in the context of the S-Series IPS
specifications.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 91

S3000L-B6865-03000-00

3.20.2Graphical description

ICN-B6865-S3000L0296-001-01
Fig 24 S3000L UoF Logistics Support Analysis Message Content

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 92

S3000L-B6865-03000-00

3.20.33.20.3.1

Class definition
AllowedProductConfigurationsByConfigurationIdentifier

AllowedProductConfigurationsByConfigurationIdentifier is awrapper element that contains all instances ofAllowedProductConfigurationByConfigurationIdentifier that are inscope for a data exchange.
3.20.3.1.1

Associations
This class has the following associations:−

An aggregate association with zero, one or many instances ofAllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28

3.20.3.2

ApplicabilityDefinitionData

ApplicabilityDefinitionData is a wrapper element that contains all instances ofApplicabilityStatement that are in scope for a data exchange.
3.20.3.2.1

Associations
This class has the following associations:−3.20.3.3

An aggregate association with zero, one or many instances ofApplicabilityStatement. Refer to Para 3.2

BreakdownElements

BreakdownElements is a wrapper element that contains all instances ofBreakdownElement that are in scope for a data exchange.
3.20.3.3.1

Associations
This class has the following associations:−3.20.3.4

An aggregate association with zero, one or many instances of BreakdownElement.
Refer to Para 3.3

ChangeAuthorizations

ChangeAuthorizations is a wrapper element that contains all instances of
ChangeAuthorization that are in scope for a data exchange.
3.20.3.4.1

Associations
This class has the following associations:−3.20.3.5

An aggregate association with zero, one or many instances of
ChangeAuthorization. Refer to Para 3.4

ChangeRequests

ChangeRequests is a wrapper element that contains all instances of ChangeRequestthat are in scope for a data exchange.
3.20.3.5.1

Associations
This class has the following associations:−3.20.3.6

An aggregate association with zero, one or many instances of ChangeRequest. Refer
to Para 3.9

CircuitBreakers

CircuitBreakers is a wrapper element that contains all instances of
CircuitBreaker that are in scope for a data exchange.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 93

S3000L-B6865-03000-00

3.20.3.6.1

Associations
This class has the following associations:−3.20.3.7

An aggregate association with zero, one or many instances of CircuitBreaker. Refer
to Para 3.5

CompetencyDefinitions

CompetencyDefinitions is a wrapper element that contains all instances ofCompetencyDefinition that are in scope for a data exchange.
3.20.3.7.1

Associations
This class has the following associations:−3.20.3.8

An aggregate association with zero, one or many instances ofCompetencyDefinition. Refer to Para 3.6

ConditionTypes

ConditionTypes is a wrapper element that contains all instances of ConditionType
that are in scope for a data exchange.
3.20.3.8.1

Associations
This class has the following associations:−3.20.3.9

An aggregate association with zero, one or many instances of ConditionType. Refer
to Para 3.2

Contracts

Contracts is a wrapper element that contains all instances of Contract that are inscope for a data exchange.
3.20.3.9.1

Associations
This class has the following associations:−3.20.3.10

An aggregate association with zero, one or many instances of Contract. Refer toPara 3.27

Countries

Countries is a wrapper element that contains all instances of Country that are in scopefor a data exchange.
3.20.3.10.1 Associations
This class has the following associations:−3.20.3.11

An aggregate association with zero, one or many instances of Country. Refer toPara 3.19

DecisionTreeTemplates

DecisionTreeTemplates is a wrapper element that contains all instances ofDecisionTreeTemplate that are in scope for a data exchange.
3.20.3.11.1 Associations
This class has the following associations:−3.20.3.12

An aggregate association with zero, one or many instances ofDecisionTreeTemplate. Refer to Para 3.8

DigitalFiles

DigitalFiles is a wrapper element that contains all instances of DigitalFile thatare in scope for a data exchange.
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 94

S3000L-B6865-03000-00

3.20.3.12.1 Associations
This class has the following associations:−3.20.3.13

An aggregate association with zero, one or many instances of DigitalFile. Refer toPara 3.10

Documents

Documents is a wrapper element that contains all instances of Document that are inscope for a data exchange.
3.20.3.13.1 Associations
This class has the following associations:−3.20.3.14

An aggregate association with zero, one or many instances of Document. Refer toPara 3.11

EnvironmentDefinitions

EnvironmentDefinitions is a wrapper element that contains all instances ofEnvironmentDefinition that are in scope for a data exchange.
3.20.3.14.1 Associations
This class has the following associations:−3.20.3.15

An aggregate association with zero, one or many instances ofEnvironmentDefinition. Refer to Para 3.12

Facilities

Facilities is a wrapper element that contains all instances of Facility that are inscope for a data exchange.
3.20.3.15.1 Associations
This class has the following associations:−3.20.3.16

An aggregate association with zero, one or many instances of Facility. Refer toPara 3.13

GeographicalAreas

GeographicalAreas is a wrapper element that contains all instances ofGeographicalArea that are in scope for a data exchange.
3.20.3.16.1 Associations
This class has the following associations:−3.20.3.17

An aggregate association with zero, one or many instances of GeographicalArea.
Refer to Para 3.19

GlobalPositions

GlobalPositions is a wrapper element that contains all instances of
GlobalPosition that are in scope for a data exchange.
3.20.3.17.1 Associations
This class has the following associations:−3.20.3.18

An aggregate association with zero, one or many instances of GlobalPosition. Refer
to Para 3.19

LogisticsSupportAnalysisMessageContent

LogisticsSupportAnalysisMessageContent is a MessageContent (refer
to Para 3.23) that contains data resulting from Logistics Support Analysis activities.
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 95

S3000L-B6865-03000-00

3.20.3.18.1 Associations
This class has the following associations:3.20.3.19−

An aggregate association with zero or one instance of−An aggregate association with zero or one instance ofLogisticsSupportAnalysisPrimaryData
LogisticsSupportAnalysisSupportingData

LogisticsSupportAnalysisPrimaryData

LogisticsSupportAnalysisPrimaryData is a subset of the
LogisticsSupportAnalysisMessageContent <<exchange>> dataset that
include the primary data used in, and resulting from, the Logistics Support Analysis activities.
3.20.3.19.1 Associations
This class has the following associations:
−
−
−
−
−
3.20.3.20

An aggregate association with zero or one instance of BreakdownElements
An aggregate association with zero or one instance of Parts
An aggregate association with zero or one instance of Products
An aggregate association with zero or one instance of TaskRequirements
An aggregate association with zero or one instance of Tasks

LogisticsSupportAnalysisSupportingData

LogisticsSupportAnalysisSupportingData is a subset of the
LogisticsSupportAnalysisMessageContent <<exchange>> dataset that
include the data that support the Logistics Support Analysis activities.
3.20.3.20.1 Associations
This class has the following associations:−

An aggregate association with zero or one instance of−An aggregate association with zero or one instance of

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

An aggregate association with zero or one instance of ChangeAuthorizations
An aggregate association with zero or one instance of ChangeRequests
An aggregate association with zero or one instance of CircuitBreakers
An aggregate association with zero or one instance of CompetencyDefinitions
An aggregate association with zero or one instance of ConditionTypes
An aggregate association with zero or one instance of Contracts
An aggregate association with zero or one instance of Countries
An aggregate association with zero or one instance of DecisionTreeTemplates
An aggregate association with zero or one instance of DigitalFiles
An aggregate association with zero or one instance of Documents
An aggregate association with zero or one instance of EnvironmentDefinitions
An aggregate association with zero or one instance of Facilities
An aggregate association with zero or one instance of GeographicalAreas
An aggregate association with zero or one instance of GlobalPositions
An aggregate association with zero or one instance of MaintenanceLevels
An aggregate association with zero or one instance of OperatingLocationTypes
An aggregate association with zero or one instance of Organizations
An aggregate association with zero or one instance of Projects
An aggregate association with zero or one instance of ResourceSpecifications

AllowedProductConfigurationsByConfigurationIdentifier
ApplicabilityDefinitionData

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 96

S3000L-B6865-03000-00

−
−
−
−
−
3.20.3.21

An aggregate association with zero or one instance of SecurityClasses
An aggregate association with zero or one instance of Skills
An aggregate association with zero or one instance of SubstanceDefinitions
An aggregate association with zero or one instance of Trades
An aggregate association with zero or one instance of WarningCautionNotes

MaintenanceLevels

MaintenanceLevels is a wrapper element that contains all instances of
MaintenanceLevel that are in scope for a data exchange.
3.20.3.21.1 Associations
This class has the following associations:−3.20.3.22

An aggregate association with zero, one or many instances of MaintenanceLevel.
Refer to Para 3.29

OperatingLocationTypes

OperatingLocationTypes is a wrapper element that contains all instances ofOperatingLocationType that are in scope for a data exchange.
3.20.3.22.1 Associations
This class has the following associations:−3.20.3.23

An aggregate association with zero, one or many instances ofOperatingLocationType. Refer to Para 3.29

Organizations

Organizations is a wrapper element that contains all instances of Organizationthat are in scope for a data exchange.
3.20.3.23.1 Associations
This class has the following associations:−3.20.3.24

An aggregate association with zero, one or many instances of Organization. Refer toPara 3.24

Parts

Parts is a wrapper element that contains all instances of PartAsDesigned that are inscope for a data exchange.
3.20.3.24.1 Associations
This class has the following associations:−3.20.3.25

An aggregate association with zero, one or many instances of PartAsDesigned. Refer
to Para 3.25

Products

Products is a wrapper element that contains all instances of Product that are in scopefor a data exchange.
3.20.3.25.1 Associations
This class has the following associations:−

An aggregate association with zero, one or many instances of Product. Refer toPara 3.27

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 97

S3000L-B6865-03000-00

3.20.3.26

Projects

Projects is a wrapper element that contains all instances of Project that are in scopefor a data exchange.
3.20.3.26.1 Associations
This class has the following associations:−3.20.3.27

An aggregate association with zero, one or many instances of Project. Refer toPara 3.27

ResourceSpecifications

ResourceSpecifications is a wrapper element that contains all instances ofResourceSpecification that are in scope for a data exchange.
3.20.3.27.1 Associations
This class has the following associations:−3.20.3.28

An aggregate association with zero, one or many instances ofResourceSpecification. Refer to Para 3.38

SecurityClasses

SecurityClasses is a wrapper element that contains all instances of
SecurityClass that are in scope for a data exchange.
3.20.3.28.1 Associations
This class has the following associations:−3.20.3.29

An aggregate association with zero, one or many instances of SecurityClass. Refer
to Para 3.33

SkillsSkills is a wrapper element that contains all instances of Skill that are in scope for adata exchange.
3.20.3.29.1 Associations
This class has the following associations:−3.20.3.30

An aggregate association with zero, one or many instances of Skill. Refer to Para 3.6

SubstanceDefinitions

SubstanceDefinitions is a wrapper element that contains all instances of
SubstanceDefinition that are in scope for a data exchange.
3.20.3.30.1 Associations
This class has the following associations:−3.20.3.31

An aggregate association with zero, one or many instances of
SubstanceDefinition. Refer to Para 3.25

TaskRequirements

TaskRequirements is a wrapper element that contains all instances of
TaskRequirement that are in scope for a data exchange.
3.20.3.31.1 Associations
This class has the following associations:−

An aggregate association with zero, one or many instances of TaskRequirement.
Refer to Para 3.37

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 98

S3000L-B6865-03000-00

3.20.3.32

Tasks

Tasks is a wrapper element that contains all instances of Task that are scope for a dataexchange.
3.20.3.32.1 Associations
This class has the following associations:−3.20.3.33

An aggregate association with zero, one or many instances of Task. Refer to Para 3.36

TradesTrades is a wrapper element that contains all instances of Trade that are in scope for adata exchange.
3.20.3.33.1 Associations
This class has the following associations:−3.20.3.34

An aggregate association with zero, one or many instances of Trade. Refer to Para 3.6

WarningCautionNotes

WarningCautionNotes is a wrapper element that contains all instances ofWarningCautionNote that are in scope for a data exchange.
3.20.3.34.1 Associations
This class has the following associations:−

An aggregate association with zero, one or many instances ofWarningCautionNote. Refer to Para 3.36

3.21

S3000L UoF LSA Candidate

3.21.1

Description
The LSA Candidate UoF provides the capability to define decisions and results associated with
Logistics Support Analysis (LSA) activities.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 99

S3000L-B6865-03000-00

3.21.2Graphical description

ICN-B6865-S3000L0223-004-01
Fig 25 S3000L UoF LSA Candidate
3.21.33.21.3.1

Class definition
AnalysisActivity

AnalysisActivity is a <<class>> that represents the objective for, and outcome of,an analysis carried out for the AnalysisCandidateItem.
3.21.3.1.1

Attribute(s)This class has the following attributes:−

3.21.3.1.2

Associations
This class has the following associations:−3.21.3.1.3

analysisActivityType

An aggregate association with zero, one or many instances ofAnalysisActivityRevision

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 100

S3000L-B6865-03000-00

3.21.3.2

AnalysisActivityRevision

AnalysisActivityRevision is a <<class>> representing an iteration applied toan AnalysisActivity.
3.21.3.2.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−

3.21.3.2.2

analysisActivityRevisionIdentifier
analysisActivityDecision
analysisActivityDecisionRationale, zero, one or many
analysisActivityStatusDescription, zero, one or many
analysisActivityRevisionRationale, zero, one or many
analysisActivityRevisionDate, zero or one
analysisActivityRevisionStatus, zero or one

Implementations
This class implements the following <<extend>> interfaces:−−−−

ChangeControlledItem. Refer to Para 3.4
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.21.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

AnalysisCandidateItem

AnalysisCandidateItem is an <<extend>> interface that provides its associateddata model to those classes that can have an associated AnalysisActivity.
3.21.3.3.1

Class members
Classes that implement the AnalysisCandidateItem <<extend>> interface are:
−
−
−
−
−

3.21.3.3.2

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

Associations
The AnalysisCandidateItem <<extend>> interface has the following associations:−−

An aggregate association with zero, one or many instances of AnalysisActivity
An aggregate viewDefinition association with zero, one or many instances ofAnalysisCandidateItemSelectionData
3.21.3.4

AnalysisCandidateItemSelectionData

AnalysisCandidateItemSelectionData is an <<attributeGroup>> thatsummarizes decisions made for the AnalysisCandidateItem from a support analysis
activities perspective.
3.21.3.4.1

Attribute(s)This <<attributeGroup>> has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 101

S3000L-B6865-03000-00−−−−
3.21.3.4.2

analysisCandidateItemSelectionIndicatoranalysisCandidateItemSelectionRationale, zero, one or many
analysisCandidateMaintenanceConcept, zero, one or many
analysisCandidateMaintenanceSolution, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem. Refer to Para 3.2

3.22

S3000L UoF LSA Failure Mode Group

3.22.1

Description
The Failure Mode Group UoF provides the capability to group failure modes that result in thesame corrective maintenance activities.

3.22.2Graphical description

ICN-B6865-S3000L0277-001-01
Fig 26 S3000L UoF LSA Failure Mode Group
3.22.33.22.3.1

Class definition
LSACorrectiveMaintenanceAnalysis

LSACorrectiveMaintenanceAnalysis is an AnalysisActivity (refer toPara 3.21) that represents the outcome of corrective maintenance analysis carried out for the
AnalysisCandidateItem (refer to Para 3.21).
3.22.3.1.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 102

S3000L-B6865-03000-00−
3.22.3.1.2

Associations
This class has the following associations:−3.22.3.1.3

analysisActivityType (inherited from AnalysisActivity)

An aggregate association with one or many instances of

LSACorrectiveMaintenanceAnalysisRevision

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from AnalysisActivity). Refer
to Para 3.2−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from AnalysisActivity). Refer
to Para 3.33

3.22.3.2

LSACorrectiveMaintenanceAnalysisRevision

LSACorrectiveMaintenanceAnalysisRevision is an
AnalysisActivityRevision (refer to Para 3.21) representing an iteration applied to
LSACorrectiveMaintenanceAnalysis.
3.22.3.2.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−

3.22.3.2.2

analysisActivityRevisionIdentifier (inherited from
AnalysisActivityRevision)
analysisActivityDecision (inherited from
AnalysisActivityRevision)
analysisActivityDecisionRationale (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityStatusDescription (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityRevisionRationale (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityRevisionDate (inherited from
AnalysisActivityRevision), zero or one
analysisActivityRevisionStatus (inherited from
AnalysisActivityRevision), zero or one

Associations
This class has the following associations:−−

An aggregate association with one or many instances of LSAFailureModeGroupA directed has association with zero, one or many instances of

LSACorrectiveMaintenanceAnalysisSource
3.22.3.2.3

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 103

S3000L-B6865-03000-00−

ChangeControlledItem (inherited from AnalysisActivityRevision).
Refer to Para 3.4−−−

DigitalFileReferencingItem (inherited from
AnalysisActivityRevision). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.22.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LSACorrectiveMaintenanceAnalysisSource

LSACorrectiveMaintenanceAnalysisSource is a <<relationship>>where an LSACorrectiveMaintenanceAnalysisRevision relates to the failuremode related source information which can be used to identify a required corrective
maintenance task.
3.22.3.3.1

Associations
This class has the following associations:−

A directed definedBy association with one instance of

LSACorrectiveMaintenanceAnalysisSourceItem
3.22.3.3.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.22.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LSACorrectiveMaintenanceAnalysisSourceItem

LSACorrectiveMaintenanceAnalysisSourceItem is a <<select>>interface that identifies the failure mode source information to be used to define the required
corrective maintenance task.
3.22.3.4.1

Class members
This <<select>> interface includes the following class members:−−

3.22.3.5

FailureModeAnalysisRevision. Refer to Para 3.14
LSACorrectiveMaintenanceAnalysisRevision

LSAFailureModeGroup

LSAFailureModeGroup is a <<class>> that represents a set of failure modes that
leads to the same set of actions for its detection, isolation and rectifying intervention.
3.22.3.5.1

Attribute(s)This class has the following attributes:−−−−

lsaFailureModeGroupIdentifier
lsaFailureModeGroupName, one or many
lsaFailureModeGroupDescription, zero, one or many
lsaFailureModeGroupDistributionRatio, one or many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 104

S3000L-B6865-03000-00

3.22.3.5.2

3.22.3.5.3

Associations
This class has the following associations:−

A directed include association with zero, one or many instances of−

LSAFailureModeGroupIncludedFailureMode
A directed has association with zero, one or many instances of
LSAFailureModeGroupTaskRequirement

Implementations
This class implements the following <<extend>> interfaces:−−−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeIsolationItem. Refer to Para 3.15
FailureModeSymptomsSignatureItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.22.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LSAFailureModeGroupIncludedFailureMode

LSAFailureModeGroupIncludedFailureMode is a <<relationship>>that identifies a FailureMode (refer to Para 3.14) which is a member of the
LSAFailureModeGroup.
3.22.3.6.1

Associations
This class has the following associations:−

A directed definedBy association with one instance of

LSAFailureModeGroupItem
3.22.3.6.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.22.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

LSAFailureModeGroupItem

LSAFailureModeGroupItem is a <<select>> interface that identifies failure modes
which are included in the LSAFailureModeGroup.
3.22.3.7.1

Class members
This <<select>> interface includes the following class members:−−

3.22.3.8

FailureMode. Refer to Para 3.14
LSAFailureModeGroup

LSAFailureModeGroupTaskRequirement

LSAFailureModeGroupTaskRequirement is a <<relationship>> where an
LSAFailureModeGroup relates to the TaskRequirement (refer to Para 3.37)

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 105

S3000L-B6865-03000-00

needed in the process to detect and isolate a failure, and to restore theAnalysisCandidateItem (refer to Para 3.21).
3.22.3.8.1

Attribute(s)This class has the following attributes:−

3.22.3.8.2

Associations
This class has the following associations:−3.22.3.8.3

lsaFailureModeGroupTaskRequirementPurpose

A directed definedBy association with one instance of TaskRequirement. Refer
to Para 3.37

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.23

S3000L UoF Message

3.23.1

Description
The Message UoF provides the capability to identify a collection of information to becommunicated from one party to another.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 106

S3000L-B6865-03000-00

3.23.2Graphical description

ICN-B6865-S3000L0295-001-01
Fig 27 S3000L UoF Message
3.23.33.23.3.1

Class definition
Message
Message is a <<class>> that represents the collection of information brought together bya message sender for the purpose of communicating it to another party.

3.23.3.1.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.23.3.1.2

messageIdentifier
messageCreationDateTime, zero or one
messageLanguage, zero or one
messageContentStatus, zero or one
messageContentType, zero or one

Associations
This class has the following associations:−−−−

An aggregate association with one instance of MessageContent
A directed has association with one or many instances of MessageParty
A directed has association with zero, one or many instances of MessageContext
A directed has association with zero, one or many instances ofMessageRelationshipApplicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 107

S3000L-B6865-03000-00

3.23.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.23.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

MessageContent

MessageContent is a <<exchange>> definition that represents the collection of
information that is the subject of the Message.
3.23.3.3

MessageContext

MessageContext is a <<relationship>> between a Message and the context for
which it is being provided.
Example(s)− Contract− Product− Project
3.23.3.3.1

Associations
This class has the following associations:−3.23.3.3.2

A directed definedBy association with one instance of MessageContextItem

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.23.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

MessageContextItem

MessageContextItem is a <<select>> interface that identifies items which can beselected as the context for a Message.
3.23.3.4.1

Class members
This <<select>> interface includes the following class members:−−−−

3.23.3.5

Contract. Refer to Para 3.27
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27

MessageParty

MessageParty is a <<relationship>> between a Message and a stakeholder for
the Message.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 108

S3000L-B6865-03000-00

3.23.3.5.1

Attribute(s)This class has the following attributes:−

3.23.3.5.2

Associations
This class has the following associations:−3.23.3.5.3

messagePartyType

A directed definedBy association with one instance of MessagePartyItem

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.23.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

MessagePartyItem

MessagePartyItem is a <<select>> interface that identifies items which can beselected as the party for a Message.
3.23.3.6.1

Class members
This <<select>> interface includes the following class members:−

3.23.3.7

Organization. Refer to Para 3.24

MessageRelationshipMessageRelationship is a <<relationship>> where one Message relates toanother Message.
Example(s)− One Message is a reply to another Message− One Message is an update to another Message
3.23.3.7.1

Attribute(s)This class has the following attributes:−

3.23.3.7.2

Associations
This class has the following associations:−3.23.3.7.3

messageRelationshipType, zero or one

A directed with association with one instance of Message

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 109

S3000L-B6865-03000-00

3.24

S3000L UoF Organization Assignment

3.24.1

Description
The Organization Assignment UoF provides the capability to identify and reference
organizations.

3.24.2Graphical description

ICN-B6865-S3000L0232-004-01
Fig 28 S3000L UoF Organization Assignment
3.24.33.24.3.1

Class definition
Organization

Organization is a <<class>> that represents an administrative structure with aparticular purpose belonging to a legal entity.
Example(s)− Government department− International agency− Company
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 110

S3000L-B6865-03000-00−
3.24.3.1.1

Attribute(s)This class has the following attributes:−−

3.24.3.1.2

Department

organizationIdentifier, one or manyorganizationName, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.24.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

OrganizationReferencingItem

OrganizationReferencingItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.24.3.2.1

Class members
Classes that implement the OrganizationReferencingItem <<extend>>
interface are:−−

AllocatedTaskLocation. Refer to Para 3.39
AllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

AnalysisActivity. Refer to Para 3.21
AnalysisActivityRevision. Refer to Para 3.21
ApplicabilityStatement. Refer to Para 3.2
AuthorityToOperate. Refer to Para 3.28
AuthorizedLife. Refer to SX002D
Breakdown. Refer to Para 3.3
BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3
BreakdownRevision. Refer to Para 3.3
ChangeAuthorization. Refer to Para 3.4
ChangeRequest. Refer to Para 3.9
CircuitBreaker. Refer to Para 3.5
CircuitBreakerSetting. Refer to Para 3.36
CircuitBreakerSettings. Refer to Para 3.36
ClassificationType. Refer to SX002D
CompetencyDefinition. Refer to Para 3.6
ConditionInstance. Refer to Para 3.2
ConditionType. Refer to Para 3.2
ConditionTypeAssertMember. Refer to Para 3.2
Contract. Refer to Para 3.27
Country. Refer to Para 3.19

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 111

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

DamageDefinition. Refer to Para 3.7
DatedClassification. Refer to SX002D
DateRange. Refer to SX002D
DateTimeRange. Refer to SX002D
DateType. Refer to SX002D
DecisionTreeTemplate. Refer to Para 3.8
DecisionTreeTemplateActionDefinition. Refer to Para 3.8
DecisionTreeTemplateQuestionDefinition. Refer to Para 3.8
DecisionTreeTemplateRevision. Refer to Para 3.8
DescriptorType. Refer to SX002D
DetectionMeansAlarm. Refer to Para 3.16
DigitalFile. Refer to Para 3.10
Document. Refer to Para 3.11
DocumentIssue. Refer to Para 3.11
EnvironmentDefinition. Refer to Para 3.12
EnvironmentDefinitionCharacteristic. Refer to Para 3.12
EnvironmentDefinitionRevision. Refer to Para 3.12
EvaluationCriteria. Refer to Para 3.2
Facility. Refer to Para 3.13
FailureMode. Refer to Para 3.14
FailureModeAnalysis. Refer to Para 3.14
FailureModeAnalysisRevision. Refer to Para 3.14
FailureModeCause. Refer to Para 3.14
FailureModeEffect. Refer to Para 3.14
FailureModeSymptomsSignature. Refer to Para 3.16
GeographicalArea. Refer to Para 3.19
GlobalPosition. Refer to Para 3.19
IdentifierType. Refer to SX002D
InServiceOptimizationAnalysis. Refer to Para 3.18
InServiceOptimizationAnalysisRevision. Refer to Para 3.18
InServiceOptimizationAnalysisStep. Refer to Para 3.18
LSAFailureModeGroup. Refer to Para 3.22
MaintenanceLevel. Refer to Para 3.29
MeasurementPointDefinition. Refer to Para 3.16
Message. Refer to Para 3.23
NameType. Refer to SX002D
OperatingLocationType. Refer to Para 3.29
Organization. Refer to Para 3.24
PartAsDesigned. Refer to Para 3.25
PartAsDesignedPartsList. Refer to Para 3.25
PartAsDesignedPartsListEntry. Refer to Para 3.25
PartAsDesignedPartsListRevision. Refer to Para 3.25
PerformanceParameter. Refer to Para 3.26
PerformanceParameterRevision. Refer to Para 3.26
Product. Refer to Para 3.27
ProductUsagePhase. Refer to Para 3.30
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 112

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
3.24.3.2.2

PropertyType. Refer to SX002D
RepeatDefinition. Refer to Para 3.40
ResourceSpecification. Refer to Para 3.32
ResourceSpecificationRevision. Refer to Para 3.32
SecurityClass. Refer to Para 3.33
SerialNumberRange. Refer to SX002D
Skill. Refer to Para 3.6
SkillLevel. Refer to Para 3.6
SpecialEventDefinition. Refer to Para 3.35
StateType. Refer to SX002D
StreetAddress. Refer to Para 3.19
SubstanceDefinition. Refer to Para 3.25
Subtask. Refer to Para 3.36
Task. Refer to Para 3.36
TaskRequirement. Refer to Para 3.37
TaskRequirementRevision. Refer to Para 3.37
TaskResource. Refer to Para 3.38
TaskRevision. Refer to Para 3.36
ThreeDimensional. Refer to SX002D
ThresholdDefinition. Refer to Para 3.40
TimeLimit. Refer to Para 3.40
TimeStampedClassification. Refer to SX002D
Trade. Refer to Para 3.6
umlBoolean. Refer to SX002D
umlInteger. Refer to SX002D
umlReal. Refer to SX002D
umlString. Refer to SX002D
umlUnlimitedNatural. Refer to SX002D
WarningCautionNote. Refer to Para 3.36

Associations
The OrganizationReferencingItem <<extend>> interface has the following
associations:−

A directed definedBy association with zero, one or many instances ofReferencedOrganization
3.24.3.3

ReferencedOrganization

ReferencedOrganization is a <<relationship>> where one
OrganizationReferencingItem relates to an Organization.
3.24.3.3.1

Attribute(s)This class has the following attributes:−

3.24.3.3.2

referencedOrganizationRole

Associations
This class has the following associations:−

A directed definedBy association with zero, one or many instances ofOrganization

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 113

S3000L-B6865-03000-00

3.24.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.25

S3000L UoF Part Definition

3.25.1

Description
The Part Definition UoF provides the capability of defining hardware and software parts, theircharacteristics, and associated parts lists.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 114

S3000L-B6865-03000-00

3.25.2Graphical description

ICN-B6865-S3000L0218-004-01
Fig 29 S3000L UoF Part Definition
3.25.33.25.3.1

Class definition
AlternatePartAsDesigned

AlternatePartAsDesigned is a <<relationship>> that defines an alternate
PartAsDesigned which can replace the base PartAsDesigned in all its usages ie, it
is context independent, and is form, fit and function equivalent.
Note
A part can have one or more alternate parts. The alternate part is interchangeable with thebase part in any/all uses.
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 115

S3000L-B6865-03000-00

3.25.3.1.1

Associations
This class has the following associations:−3.25.3.1.2

A directed definedBy association with one instance of PartAsDesigned

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.25.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ContainedSubstanceContainedSubstance is a <<relationship>> that associates a
HardwarePartAsDesigned with a contained SubstanceDefinition.
3.25.3.2.1

Attribute(s)This class has the following attributes:−−

3.25.3.2.2

Associations
This class has the following associations:−3.25.3.2.3

quantityOfContainedSubstance, zero, one or many
containedSubstanceJustification, zero, one or many

A directed definedBy association with one instance of SubstanceDefinition

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.25.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

HardwarePartAsDesigned

HardwarePartAsDesigned is a PartAsDesigned that is to be realized as physicalitems, including non-countable material.
Note
Examples of non-countable materials are: oil, sealant, paint.
3.25.3.3.1

Attribute(s)This class has the following attributes:−−

partIdentifier (inherited from PartAsDesigned), one or many
partName (inherited from PartAsDesigned), one or many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 116

S3000L-B6865-03000-00

3.25.3.3.2

Associations
This class has the following associations:
−
−
−
−
−
−
−
−

An aggregate viewDefinition association with zero or one instance ofHardwarePartAsDesignedDesignData
An aggregate viewDefinition association with zero or one instance ofHardwarePartAsDesignedSupportData
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedControlledItemData (inherited from PartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedDesignData (inherited from PartAsDesigned)
An aggregate association with zero, one or many instances of
PartAsDesignedPartsList (inherited from PartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedSupportData (inherited from PartAsDesigned)
A directed has association with zero, one or many instances of
AlternatePartAsDesigned (inherited from PartAsDesigned)
A directed has association with zero, one or many instances ofContainedSubstance3.25.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from PartAsDesigned). Refer toPara 3.21−

DecisionTreeAnalysisItem (inherited from PartAsDesigned). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from PartAsDesigned). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from PartAsDesigned). Refer toPara 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from PartAsDesigned). Refer toPara 3.14−−

InServiceOptimizationAnalysisItem (inherited from
PartAsDesigned). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited from PartAsDesigned).
Refer to Para 3.16−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited from PartAsDesigned). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from PartAsDesigned). Refer toPara 3.33−−

TaskAnalysisItem (inherited from PartAsDesigned). Refer to Para 3.39
TaskRequirementAnalysisItem (inherited from PartAsDesigned). Refer
to Para 3.37

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 117

S3000L-B6865-03000-00

3.25.3.4

HardwarePartAsDesignedDesignData

HardwarePartAsDesignedDesignData is an <<attributeGroup>> thatcollects HardwarePartAsDesigned characteristics identified during design activities.
3.25.3.4.1

Attribute(s)This <<attributeGroup>> has the following attributes:
−
−
−
−
−
−
−
−
−
−

3.25.3.5

hardwarePartOperationalAuthorizedLife, zero, one or many
hardwarePartHazardousClass, zero, one or many
hardwarePartFitmentRequirement, zero or one
hardwarePartElectromagneticIncompatible
hardwarePartElectrostaticSensitive
hardwarePartElectromagneticSensitive
hardwarePartMagneticSensitive
hardwarePartRadiationSensitive
hardwarePartSize, zero or one
hardwarePartWeight, zero or one

HardwarePartAsDesignedSupportData

HardwarePartAsDesignedSupportData is an <<attributeGroup>> thatcollects HardwarePartAsDesigned characteristics identified during supportability
analysis activities.
3.25.3.5.1

Attribute(s)This <<attributeGroup>> has the following attributes:
−
−
−
−
−

hardwarePartLogisticsCategory, one or many
hardwarePartRepairability
hardwarePartRepairabilityStrategy, zero, one or many
hardwarePartMaintenanceSchedulingStart, zero or one
hardwarePartWasteProductsInUseDisposalDescription, zero, one
or many−

hardwarePartWasteProductsPlannedDisposalDescription, zero,one or many−−

hardwarePartEnvironmentalAspectInUseClass, zero, one or many
hardwarePartEnvironmentalAspectPlannedDisposalClass, zero,one or many−−−−
3.25.3.6

hardwarePartScrapRate, zero, one or many
hardwarePartConsumptionRate, zero, one or many
hardwarePartTraceabilityClass, zero or one
hardwarePartSupportFamilyClass, zero, one or many

PartAsDesigned

PartAsDesigned is a <<class>> that represents the definitional information for an
artifact fulfilling a set of requirements, which can be produced or realized.
3.25.3.6.1

Attribute(s)This class has the following attributes:−−

3.25.3.6.2

partIdentifier, one or many
partName, one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 118

S3000L-B6865-03000-00−

An aggregate viewDefinition association with zero or one instance of−

PartAsDesignedControlledItemData
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedDesignData−

An aggregate association with zero, one or many instances of−−

3.25.3.6.3

PartAsDesignedPartsList
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedSupportData
A directed has association with zero, one or many instances of
AlternatePartAsDesigned

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−
−
−
−

AnalysisCandidateItem. Refer to Para 3.21
DecisionTreeAnalysisItem. Refer to Para 3.8
DetectionMeansAlarmItem. Refer to Para 3.16
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem. Refer to Para 3.14
InServiceOptimizationAnalysisItem. Refer to Para 3.18
MeasurementPointDefinitionItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem. Refer to Para 3.26
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−−−3.25.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33
TaskAnalysisItem. Refer to Para 3.39
TaskRequirementAnalysisItem. Refer to Para 3.37

PartAsDesignedControlledItemData

PartAsDesignedControlledItemData is an <<attributeGroup>> thatcollects PartAsDesigned characteristics identified during different controlled item analysis
activities.
3.25.3.7.1

Attribute(s)This class has the following attributes:−

3.25.3.8

partDemilitarizationClass, zero, one or many

PartAsDesignedDesignData

PartAsDesignedDesignData is an <<attributeGroup>> that collects
PartAsDesigned characteristics identified during design activities.
3.25.3.8.1

Attribute(s)This class has the following attributes:−

partSpecialHandlingRequirement, zero, one or many

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 119

S3000L-B6865-03000-00

3.25.3.9

PartAsDesignedPartsList

PartAsDesignedPartsList is a <<class>> that represents the definitional
information for the collection of PartAsDesignedPartsListEntry included in theassembly of the parent PartAsDesigned.
Note

PartAsDesignedPartsList is typically referred to as a Bill of Material (BOM).
3.25.3.9.1

Attribute(s)This class has the following attributes:−

3.25.3.9.2

Associations
This class has the following associations:−3.25.3.9.3

partsListType

An aggregate association with zero, one or many instances of

PartAsDesignedPartsListRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.25.3.10

RemarkItem (inherited from BaseObject). Refer to Para 3.31

PartAsDesignedPartsListEntry

PartAsDesignedPartsListEntry is a <<class>> that represents the inclusionof a PartAsDesigned in a PartAsDesignedPartsListRevision.
3.25.3.10.1 Attribute(s)This class has the following attributes:
−
−
−
−
−

partsListEntryIdentifierpartsListEntryQuantity, zero or one
referenceDesignator, zero, one or many
physicalReplaceability, zero or one
physicalReplaceabilityStrategy, zero, one or many

3.25.3.10.2 Associations
This class has the following associations:−

A directed has association with zero, one or many instances of−

SubstitutePartAsDesigned
A directed usedPart association with one instance of PartAsDesigned

3.25.3.10.3 Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EffectiveOnProductConfigurationItem. Refer to Para 3.28

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 120

S3000L-B6865-03000-00−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.25.3.11

RemarkItem (inherited from BaseObject). Refer to Para 3.31
UsableOnItem. Refer to Para 3.28

PartAsDesignedPartsListRelationship

PartAsDesignedPartsListRelationship is a <<relationship>> where
one PartAsDesignedPartsList relates to another
PartAsDesignedPartsList.
3.25.3.11.1 Attribute(s)This class has the following attributes:−

partAsDesignedPartsListRelationshipType

3.25.3.11.2 Associations
This class has the following associations:−

A directed with association with one instance of

PartAsDesignedPartsListRevision
3.25.3.12

PartAsDesignedPartsListRevision

PartAsDesignedPartsListRevision is a <<class>> representing an iteration
applied to a PartAsDesignedPartsList.
3.25.3.12.1 Attribute(s)This class has the following attributes:−−−−

partsListRevisionIdentifierpartsListRevisionRationale, zero, one or many
partsListRevisionDate, zero or one
partsListRevisionStatus, zero or one

3.25.3.12.2 Associations
This class has the following associations:−−

An aggregate association with zero, one or many instances of

PartAsDesignedPartsListEntry
A directed has association with zero, one or many instances of
PartAsDesignedPartsListRelationship3.25.3.12.3 Implementations
This class implements the following <<extend>> interfaces:−−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EffectiveOnProductConfigurationItem. Refer to Para 3.28
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
UsableOnItem. Refer to Para 3.28

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 121

S3000L-B6865-03000-00

3.25.3.13

PartAsDesignedSupportData

PartAsDesignedSupportData is an <<attributeGroup>> that collects
PartAsDesigned characteristics identified during supportability analysis activities.
3.25.3.13.1 Attribute(s)This <<attributeGroup>> has the following attributes:−−
3.25.3.14

partMaturityClass, zero, one or many
partObsolescenceRiskAssessment, zero, one or many

SoftwarePartAsDesigned

SoftwarePartAsDesigned is a PartAsDesigned that is produced as an
executable software or as a data file.
Note
Non-executable software includes eg, maps.
3.25.3.14.1 Attribute(s)This class has the following attributes:−−

partIdentifier (inherited from PartAsDesigned), one or many
partName (inherited from PartAsDesigned), one or many

3.25.3.14.2 Associations
This class has the following associations:
−
−
−
−
−

An aggregate viewDefinition association with zero or one instance of
PartAsDesignedControlledItemData (inherited from PartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedDesignData (inherited from PartAsDesigned)
An aggregate association with zero, one or many instances of
PartAsDesignedPartsList (inherited from PartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedSupportData (inherited from PartAsDesigned)
A directed has association with zero, one or many instances of
AlternatePartAsDesigned (inherited from PartAsDesigned)

3.25.3.14.3 Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from PartAsDesigned). Refer toPara 3.21−

DecisionTreeAnalysisItem (inherited from PartAsDesigned). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from PartAsDesigned). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from PartAsDesigned). Refer toPara 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from PartAsDesigned). Refer toPara 3.14−−

InServiceOptimizationAnalysisItem (inherited from
PartAsDesigned). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited from PartAsDesigned).
Refer to Para 3.16

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 122

S3000L-B6865-03000-00−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited from PartAsDesigned). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from PartAsDesigned). Refer toPara 3.33−−

TaskAnalysisItem (inherited from PartAsDesigned). Refer to Para 3.39
TaskRequirementAnalysisItem (inherited from PartAsDesigned). Refer
to Para 3.37

3.25.3.15

SoftwarePartAsDesignedDesignData

SoftwarePartAsDesignedDesignData is an <<attributeGroup>> thatcollects SoftwarePartAsDesigned characteristics identified during design activities.
3.25.3.15.1 Attribute(s)This <<attributeGroup>> has the following attributes:−−
3.25.3.16

softwarePartType
softwarePartSize, one or many

SubstanceDefinition

SubstanceDefinition is a <<class>> that identifies high concern physical matter.
Example(s)− CAS (Chemical Abstract Substance) Registry− REACH (Registration, Evaluation, Authorisation and Restriction of Chemicals)
3.25.3.16.1 Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−

substanceIdentifier, one or many
substanceName, one or many
substanceDescription, zero, one or many
substanceUsageCategory, zero or one
substanceRiskDescription, one or many
substanceRiskFactor, zero or one
substanceCharacteristicsRecordingDate, zero or one

3.25.3.16.2 Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 123

S3000L-B6865-03000-00

3.25.3.17

SubstitutePartAsDesigned

SubstitutePartAsDesigned is a <<relationship>> that defines a substitute
PartAsDesignedPartsListEntry which can replace the base
PartAsDesignedPartsListEntry in the context of the parent
PartAsDesignedPartsList.
3.25.3.17.1 Associations
This class has the following associations:−

A directed definedBy association with one instance of

PartAsDesignedPartsListEntry
3.25.3.17.2 Implementations
This class implements the following <<extend>> interfaces:−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.26

S3000L UoF Performance Parameter

3.26.1

Description
The Performance Parameter UoF supports the definition of metrics that if changed will have amajor impact on the system performance, schedule, cost and/or risk.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 124

S3000L-B6865-03000-00

3.26.2Graphical description

ICN-B6865-S3000L0275-001-01
Fig 30 S3000L UoF Performance Parameter
3.26.33.26.3.1

Class definition
CorrectionFactor

CorrectionFactor is an <<attributeGroup>> that defines a mathematicaladjustment of a defined value to account for a specified deviation in a given context.
3.26.3.1.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

3.26.3.1.2

correctionFactorValue, one or many
correctionFactorJustification, zero, one or many

Associations
This <<attributeGroup>> has the following associations:−

A directed correctionFactorContext association with one instance ofApplicabilityStatement
3.26.3.2

PerformanceParameter

PerformanceParameter is a <<class>> that represents a metric that if changed, or
not fulfilled, can have a major impact on the performance, schedule, cost and/or risk for the
PerformanceParameterItem.
3.26.3.2.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 125

S3000L-B6865-03000-00−−
3.26.3.2.2

Associations
This class has the following associations:−3.26.3.2.3

performanceParameterType
performanceParameterValueLimitQualifier, zero or one

An aggregate association with one or many instances of

PerformanceParameterRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.26.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

PerformanceParameterItem

PerformanceParameterItem is an <<extend>> interface that provides its
associated data model to those classes that can have an associated
PerformanceParameter.
3.26.3.3.1

Class members
Classes that implement the PerformanceParameterItem <<extend>> interface
are:
−
−
−
−
−

3.26.3.3.2

Associations
The PerformanceParameterItem <<extend>> interface has the following
associations:−3.26.3.4

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

An aggregate association with zero, one or many instances of

PerformanceParameter

PerformanceParameterRevision

PerformanceParameterRevision is a <<class>> that represents an iteration
applied to a PerformanceParameter.
3.26.3.4.1

Attribute(s)This class has the following attributes:−−−−

3.26.3.4.2

performanceParameterRevisionIdentifier
performanceParameterRevisionRationale, zero, one or many
performanceParameterRevisionDate, zero or one
performanceParameterRevisionStatus, zero or one

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 126

S3000L-B6865-03000-00−
3.26.3.4.3

An aggregate association with one or many instances of

PerformanceParameterValueGroup

Implementations
This class implements the following <<extend>> interfaces:−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.26.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

PerformanceParameterValueGroup

PerformanceParameterValueGroup is an <<attributeGroup>> thatorganizes PerformanceParameter values for a defined purpose.
3.26.3.5.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−−

3.26.3.5.2

Associations
This <<attributeGroup>> has the following associations:−3.26.3.5.3

performanceParameterValue, one or many
performanceParameterValueFraction, zero, one or many
performanceParameterCalculationMethod, zero, one or many

An aggregate association with zero, one or many instances of CorrectionFactor

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem. Refer to Para 3.2

3.27

S3000L UoF Product and Project

3.27.1

Description
The Product and Project UoF defines the Product(s) which are in focus for the Integrated
Product Support (IPS) program.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 127

S3000L-B6865-03000-00

3.27.2Graphical description

ICN-B6865-S3000L0215-004-01
Fig 31 S3000L UoF Product and Project
3.27.33.27.3.1

Class definition
Contract
Contract is a <<class>> that represents a binding agreement between two or moreparties.

3.27.3.1.1

Attribute(s)This class has the following attributes:−−

3.27.3.1.2

contractIdentifier, one or many
contractName, zero, one or many

Associations
This class has the following associations:−−−

A directed include association with one or many instances ofContractItemDetails
A directed include association with zero, one or many instances ofContractParty
A directed has association with zero, one or many instances ofContractRelationshipApplicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 128

S3000L-B6865-03000-00

3.27.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.27.3.1.4

Selects
This class is a member of the following <<select>> interfaces:−−

3.27.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

ClassInstanceAssertItem. Refer to Para 3.2
MessageContextItem. Refer to Para 3.23

ContractItemDetails

ContractItemDetails is a <<relationship>> that identifies an item which isthe subject of the Contract.
3.27.3.2.1

Attribute(s)This class has the following attributes:−−

3.27.3.2.2

contractItemDetailsContractQuantity, zero or one
contractItemDetailsBlockOfSerializedItems, zero, one or many

Associations
This class has the following associations:−−

A directed definedBy association with one instance of ProductVariant
A directed userOfContractedItem association with zero or one instance ofOrganization
3.27.3.3

ContractParty

ContractParty is a <<relationship>> that identifies a Contract stakeholder.
3.27.3.3.1

Attribute(s)This class has the following attributes:−

3.27.3.3.2

Associations
This class has the following associations:−3.27.3.3.3

contractPartyRole

A directed signedBy association with one instance of Organization

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 129

S3000L-B6865-03000-00

3.27.3.4

ContractRelationship

ContractRelationship is a <<relationship>> where one Contract relates
to another Contract.
3.27.3.4.1

Attribute(s)This class has the following attributes:−

3.27.3.4.2

Associations
This class has the following associations:−3.27.3.4.3

contractRelationshipType

A directed with association with one instance of Contract

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.27.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Product

Product is a <<class>> that represents a family of items which share the sameunderlying design purpose.
Example(s)− Aegis Class Destroyer− Airbus A340
− Ford Fusion− iPhone 12− Pegasus engine− Stryker
3.27.3.5.1

Attribute(s)This class has the following attributes:−−

3.27.3.5.2

Associations
This class has the following associations:−3.27.3.5.3

productIdentifier, one or many
productName, zero, one or many

An aggregate association with one or many instances of ProductVariant

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−
−

AnalysisCandidateItem. Refer to Para 3.21
BreakdownItem. Refer to Para 3.3
DecisionTreeAnalysisItem. Refer to Para 3.8
DetectionMeansAlarmItem. Refer to Para 3.16
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
InServiceOptimizationAnalysisItem. Refer to Para 3.18

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 130

S3000L-B6865-03000-00−−

MeasurementPointDefinitionItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−−

PerformanceParameterItem. Refer to Para 3.26
ProductUsagePhaseItem. Refer to Para 3.30
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.27.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

ProductVariant

ProductVariant is a <<class>> that defines a member of a Product family whichis configured for a specific purpose and is made available to the market.
Note
A product variant is often known as a model.
Example(s)− Boeing 787-800 vs 787-900− Ford Fusion S vs. SE vs. SEL
3.27.3.6.1

Attribute(s)This class has the following attributes:−−

3.27.3.6.2

Associations
This class has the following associations:−−−3.27.3.6.3

productVariantIdentifier, one or many
productVariantName, zero, one or many

A directed operatedAt association with zero, one or many instances ofContractedProductVariantAtOperatingLocation. Refer to Para 3.29
A directed operatedAt association with zero, one or many instances ofContractedProductVariantAtOperatingLocationType. Refer toPara 3.29
A directed include association with zero, one or many instances of
NestedProductVariant. Refer to Para 3.28

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−
−
−
−
−

AnalysisCandidateItem. Refer to Para 3.21
BreakdownItem. Refer to Para 3.3
DecisionTreeAnalysisItem. Refer to Para 3.8
DetectionMeansAlarmItem. Refer to Para 3.16
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
InServiceOptimizationAnalysisItem. Refer to Para 3.18
MeasurementPointDefinitionItem. Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem. Refer to Para 3.26
ProductUsagePhaseItem. Refer to Para 3.30

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 131

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.27.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

Project

Project is a <<class>> that represents the overall set of Integrated Product Support(IPS) activities defined for a Product.
Note

Project is often referred to as an IPS program.
3.27.3.7.1

Attribute(s)This class has the following attributes:−−

3.27.3.7.2

Associations
This class has the following associations:−3.27.3.7.3

projectIdentifier, one or many
projectName, zero, one or many

A directed has association with zero, one or many instances of ProjectContract

Implementations
This class implements the following <<extend>> interfaces:−−−−

DecisionTreeAnalysisItem. Refer to Para 3.8
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
InServiceOptimizationAnalysisItem. Refer to Para 3.18
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.27.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

ProjectContract

ProjectContract is a <<relationship>> that establishes an association between
a Project and a Contract.
3.27.3.8.1

Associations
This class has the following associations:−3.27.3.8.2

A directed definedBy association with one instance of Contract

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 132

S3000L-B6865-03000-00

3.28

S3000L UoF Product Design Configuration

3.28.1

Description
The Product Design Configuration UoF defines permitted combinations of breakdown elements,
hardware and software, in the context of product variants and allowed product configurations.

3.28.2Graphical description

ICN-B6865-S3000L0222-004-01
Fig 32 S3000L UoF Product Design Configuration
3.28.33.28.3.1

Class definition
AllowedProductConfiguration

AllowedProductConfiguration is an <<extend>> interface that provides its
associated data model to those classes that must define permitted combinations of hardware
and software parts which can or must be installed in specific locations (positions).

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 133

S3000L-B6865-03000-00

Note
One and the same serialized product can adhere to different allowed product configurations
over time.
Note
An allowed product configuration can also include associated engineering instructions thatmust be adhered to during assembly and operation and demonstrates that a productcomplies with applicable regulations.
Example(s)− Applicable regulations may be a type certificate.
3.28.3.1.1

Class members
Classes that implement the AllowedProductConfiguration <<extend>>
interface are:−−3.28.3.1.2

3.28.3.2

AllowedProductConfigurationByConfigurationIdentifier
AllowedProductConfigurationHardwarePartAsDesigned

Associations
The AllowedProductConfiguration <<extend>> interface has the following
associations:−

A directed include association with zero, one or many instances of−

NestedAllowedProductConfiguration
A directed definedFor association with one instance of ProductVariant

AllowedProductConfigurationByConfigurationIdentifier

AllowedProductConfigurationByConfigurationIdentifier is a<<class>> that defines an AllowedProductConfiguration by means other thana part number.
3.28.3.2.1

Attribute(s)This class has the following attributes:−

3.28.3.2.2

allowedProductConfigurationIdentifier, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

AllowedProductConfiguration
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.28.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

AllowedProductConfigurationHardwarePartAsDesigned

AllowedProductConfigurationHardwarePartAsDesigned is a
HardwarePartAsDesigned (refer to Para 3.25) that is managed as an
AllowedProductConfiguration.
3.28.3.3.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 134

S3000L-B6865-03000-00−−
3.28.3.3.2

partIdentifier (inherited from PartAsDesigned), one or many
partName (inherited from PartAsDesigned), one or many

Associations
This class has the following associations:
−

−

−
−
−
−
−
−

An aggregate viewDefinition association with zero or one instance ofHardwarePartAsDesignedDesignData (inherited from
HardwarePartAsDesigned)
An aggregate viewDefinition association with zero or one instance ofHardwarePartAsDesignedSupportData (inherited from
HardwarePartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedControlledItemData (inherited from PartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedDesignData (inherited from PartAsDesigned)
An aggregate association with zero, one or many instances of
PartAsDesignedPartsList (inherited from PartAsDesigned)
An aggregate viewDefinition association with zero or one instance of
PartAsDesignedSupportData (inherited from PartAsDesigned)
A directed has association with zero, one or many instances of
AlternatePartAsDesigned (inherited from PartAsDesigned)
A directed has association with zero, one or many instances ofContainedSubstance
3.28.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−

AllowedProductConfiguration
AnalysisCandidateItem (inherited from PartAsDesigned). Refer toPara 3.21−

DecisionTreeAnalysisItem (inherited from PartAsDesigned). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from PartAsDesigned). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from PartAsDesigned). Refer toPara 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from PartAsDesigned). Refer toPara 3.14−−

InServiceOptimizationAnalysisItem (inherited from
PartAsDesigned). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited from PartAsDesigned).
Refer to Para 3.16−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited from PartAsDesigned). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 135

S3000L-B6865-03000-00−

SecurityClassificationItem (inherited from PartAsDesigned). Refer toPara 3.33−−

TaskAnalysisItem (inherited from PartAsDesigned). Refer to Para 3.39
TaskRequirementAnalysisItem (inherited from PartAsDesigned). Refer
to Para 3.37

3.28.3.4

AllowedProductConfigurationItem

AllowedProductConfigurationItem is a <<select>> interface that identifies
items which can be selected as an allowed product configuration.
3.28.3.4.1

Class members
This <<select>> interface includes the following class members:−−

3.28.3.5

AllowedProductConfigurationByConfigurationIdentifier
AllowedProductConfigurationHardwarePartAsDesigned

AuthorityToOperate

AuthorityToOperate is a <<class>> that represents a certification allowing a
specific configuration of a product to be put into operation.
Note
A design change cannot be put into operation without re-certification.
Note
Type certificate for an aircraft signifies the airworthiness of its design.
3.28.3.5.1

Attribute(s)This class has the following attributes:−

3.28.3.5.2

authorityToOperateIdentifier

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.28.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EffectiveOnProductConfiguration

EffectiveOnProductConfiguration is a <<relationship>> that identifies
that a EffectiveOnProductConfigurationItem, included in the Breakdown(refer to Para 3.3) for the overall Product (refer to Para 3.27), is effective in the associated
AllowedProductConfiguration.
3.28.3.6.1

Attribute(s)This class has the following attributes:−

3.28.3.6.2

applicableSerialNumberRange, zero, one or many

Associations
This class has the following associations:−

An aggregate association with zero, one or many instances of NonConformanceData

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 136

S3000L-B6865-03000-00−

A directed definedBy association with one instance ofAllowedProductConfigurationItem
3.28.3.6.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.28.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

EffectiveOnProductConfigurationItem

EffectiveOnProductConfigurationItem is an <<extend>> interface thatprovides its associated data model to those classes that can be included in one or many
instances of AllowedProductConfiguration.
3.28.3.7.1

Class members
Classes that implement the EffectiveOnProductConfigurationItem<<extend>> interface are:
−
−
−
−
−

3.28.3.7.2

BreakdownElementUsageInBreakdown. Refer to Para 3.3
HardwareElementPartRealization. Refer to Para 3.17
PartAsDesignedPartsListEntry. Refer to Para 3.25
PartAsDesignedPartsListRevision. Refer to Para 3.25
SoftwareElementPartRealization. Refer to Para 3.34

Associations
The EffectiveOnProductConfigurationItem <<extend>> interface has thefollowing associations:−

A directed includedIn association with zero, one or many instances ofEffectiveOnProductConfiguration
3.28.3.8

NestedAllowedProductConfiguration

NestedAllowedProductConfiguration is a <<relationship>> thatdefines that one AllowedProductConfiguration includes a subordinate
AllowedProductConfiguration.
3.28.3.8.1

Associations
This class has the following associations:−

A directed definedBy association with one instance ofAllowedProductConfigurationItem
3.28.3.8.2

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 137

S3000L-B6865-03000-00−
3.28.3.9

RemarkItem (inherited from BaseObject). Refer to Para 3.31

NestedProductVariant

NestedProductVariant is a <<relationship>> that defines that one
ProductVariant (refer to Para 3.27) includes a subordinate ProductVariant.
3.28.3.9.1

Associations
This class has the following associations:−3.28.3.9.2

A directed definedBy association with zero, one or many instances of
ProductVariant. Refer to Para 3.27

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.28.3.10

RemarkItem (inherited from BaseObject). Refer to Para 3.31

NonConformanceData

NonConformanceData is an <<attributeGroup>> that collects information on
how the EffectiveOnProductConfigurationItem does not comply with therequirements of its usage.
3.28.3.10.1 Attribute(s)This <<attributeGroup>> has the following attributes:−−−
3.28.3.11

nonConformanceType
nonConformanceDescription, zero, one or many
nonConformanceRestriction, zero, one or many

UsableOnItem

UsableOnItem is an <<extend>> interface that provides its associated data model tothose classes that can have a limited effectivity with respect to its usage in one or many
instances of ProductVariant(refer to Para 3.27).
3.28.3.11.1 Class members
Classes that implement the UsableOnItem <<extend>> interface are:
−
−
−
−
−

BreakdownElementUsageInBreakdown. Refer to Para 3.3
HardwareElementPartRealization. Refer to Para 3.17
PartAsDesignedPartsListEntry. Refer to Para 3.25
PartAsDesignedPartsListRevision. Refer to Para 3.25
SoftwareElementPartRealization. Refer to Para 3.34

3.28.3.11.2 Associations
The UsableOnItem <<extend>> interface has the following associations:−

A directed includedIn association with zero, one or many instances of

UsableOnProductVariant

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 138

S3000L-B6865-03000-00

3.28.3.12

UsableOnProductVariant

UsableOnProductVariant is a <<relationship>> that defines that a
UsableOnItem, included in the Breakdown (refer to Para 3.3) for the overall Product(refer to Para 3.27), is effective in the associated ProductVariant (refer to Para 3.27).
Note

UsableOnProductVariant is the equivalent of the Usable On Code in GEIA-0007.
3.28.3.12.1 Attribute(s)This class has the following attributes:−

applicableSerialNumberRange, zero, one or many

3.28.3.12.2 Associations
This class has the following associations:−

A directed definedBy association with zero, one or many instances of
ProductVariant. Refer to Para 3.27

3.28.3.12.3 Implementations
This class implements the following <<extend>> interfaces:−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.29

S3000L UoF Product Usage Context

3.29.1

Description
The Product Usage Context UoF defines the context in which the defined Product(s) and
Product variant(s) are to be operated and maintained.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 139

S3000L-B6865-03000-00

3.29.2Graphical description

ICN-B6865-S3000L0216-003-01
Fig 33 S3000L UoF Product Usage Context
3.29.33.29.3.1

Class definition
ContractedProductVariantAtOperatingLocation

ContractedProductVariantAtOperatingLocation is a<<relationship>> that identifies an operating location where a contracted
ProductVariant (refer to Para 3.27) is defined to be operated.
3.29.3.1.1

Attribute(s)This class has the following attributes:−−

3.29.3.1.2

quantityOfProductVariantAtOperatingLocation, zero or one
operatingRequirementAtOperatingLocation, zero, one or many

Associations
This class has the following associations:−

A directed location association with one instance of OperatingBase. Refer toPara 3.13

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 140

S3000L-B6865-03000-00

3.29.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.29.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

ContractedProductVariantAtOperatingLocationType

ContractedProductVariantAtOperatingLocationType is a<<relationship>> that identifies an OperatingLocationType where acontracted ProductVariant (refer to Para 3.27) is defined to be operated.
3.29.3.2.1

Attribute(s)This class has the following attributes:−−

3.29.3.2.2

quantityOfProductVariantAtOperatingLocationType, zero or one
operatingRequirementAtOperatingLocationType, zero, one or many

Associations
This class has the following associations:−

A directed locationType association with one instance ofOperatingLocationType
3.29.3.2.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.29.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

MaintenanceCapabilityAtOperatingLocationType

MaintenanceCapabilityAtOperatingLocationType is a<<relationship>> that identifies maintenance capabilities which are available at thedefined OperatingLocationType.
3.29.3.3.1

Associations
This class has the following associations:−3.29.3.3.2

A directed definedBy association with one instance of MaintenanceLevel

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 141

S3000L-B6865-03000-00

3.29.3.4

MaintenanceLevel

MaintenanceLevel is a <<class>> that represents the definition of a set ofmaintenance capabilities which will be made available to support a defined Product (refer toPara 3.27).
Note

MaintenanceLevel might be established either by a single organization or be
distributed between a set of organizations.
3.29.3.4.1

Attribute(s)This class has the following attributes:−−−

3.29.3.4.2

maintenanceLevelIdentifier, one or many
maintenanceLevelName, zero, one or many
maintenanceLevelCapabilityDescription, zero, one or many

Implementations
This class implements the following <<extend>> interfaces:−−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.29.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

OperatingLocationType

OperatingLocationType is a <<class>> that represents the definition of the natureof the environment in which a product will be operated.
3.29.3.5.1

Attribute(s)This class has the following attributes:−−−−

3.29.3.5.2

operatingLocationTypeIdentifier, one or many
operatingLocationTypeName, zero, one or many
operatingLocationTypeDescription, zero, one or many
numberOfOperatingLocations, zero or one

Associations
This class has the following associations:−

A directed has association with zero, one or many instances of

MaintenanceCapabilityAtOperatingLocationType
3.29.3.5.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 142

S3000L-B6865-03000-00

3.30

S3000L UoF Product Usage Phase

3.30.1

Description
The Product Usage Phase UoF defines periods of time during which a Product is in an
operational state which has specific characteristics that need special considerations.

3.30.2Graphical description

ICN-B6865-S3000L0280-001-01
Fig 34 S3000L UoF Product Usage Phase
3.30.33.30.3.1

Class definition
ProductUsagePhase

ProductUsagePhase is a <<class>> that represents a distinct period of time during
which a ProductUsagePhaseItem is in an operational state which has specificcharacteristics that need special considerations.
Example(s)− Emersion, surface and dock for a submarine.
− Preflight, postflight, cruise, taxiing for an aircraft.
3.30.3.1.1

Attribute(s)This class has the following attributes:−−−

3.30.3.1.2

productUsagePhaseName, one or many
productUsagePhaseDescription, zero, one or many
productUsagePhaseDuration, zero, one or many

Associations
This class has the following associations:−

A directed has association with zero, one or many instances of

ProductUsagePhaseRelationshipApplicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 143

S3000L-B6865-03000-00

3.30.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.30.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

ProductUsagePhaseItem

ProductUsagePhaseItem is an <<extend>> interface that provides its associateddata model to those classes that implement it.
3.30.3.2.1

Class members
Classes that implement the ProductUsagePhaseItem <<extend>> interface are:−−3.30.3.2.2

Associations
the ProductUsagePhaseItem <<extend>> interface has the following associations:−3.30.3.3

Product. Refer to Para 3.27
ProductVariant. Refer to Para 3.27

An aggregate association with zero, one or many instances of ProductUsagePhase

ProductUsagePhaseRelationship

ProductUsagePhaseRelationship is a <<relationship>> where one
ProductUsagePhase relates to another ProductUsagePhase.
3.30.3.3.1

Attribute(s)This class has the following attributes:−

3.30.3.3.2

Associations
This class has the following associations:−3.30.3.3.3

productUsagePhaseRelationshipType

A directed definedBy association with one instance of ProductUsagePhase

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.31

S3000L UoF Remark

3.31.1

Description
The Remark UoF provides the capability to annotate additional information relevant to theassociated item which is not part of the immediate subject.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 144

S3000L-B6865-03000-00

3.31.2Graphical description

ICN-B6865-S3000L0234-004-01
Fig 35 S3000L UoF Remark
3.31.33.31.3.1

Class definition
RemarkRemark is an <<attributeGroup>> that provides additional information about theassociated item.
Note
A remark may be a personal opinion (“I prefer more onions in my soup”) or it may be atechnical fact (“The manufacturer recommends heating the soup to 45 degrees Celsius”).

3.31.3.1.1

Attribute(s)This class has the following attributes:−−

remarkText, one or many
remarkType, zero or one

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 145

S3000L-B6865-03000-00

3.31.3.1.2

Implementations
This class implements the following <<extend>> interfaces:−

3.31.3.2

DigitalFileReferencingItem. Refer to Para 3.10

RemarkItem

RemarkItem is an <<extend>> interface that provides its associated data model tothose classes that implement it.
3.31.3.2.1

Class members
Classes that implement the RemarkItem <<extend>> interface are:−−

AllocatedTaskLocation. Refer to Para 3.39
AllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

AnalysisActivity. Refer to Para 3.21
AnalysisActivityRevision. Refer to Para 3.21
ApplicabilityStatement. Refer to Para 3.2
AuthorityToOperate. Refer to Para 3.28
AuthorizedLife. Refer to SX002D
Breakdown. Refer to Para 3.3
BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3
BreakdownRevision. Refer to Para 3.3
ChangeAuthorization. Refer to Para 3.4
ChangeRequest. Refer to Para 3.9
CircuitBreaker. Refer to Para 3.5
CircuitBreakerSetting. Refer to Para 3.36
CircuitBreakerSettings. Refer to Para 3.36
ClassificationType. Refer to SX002D
CompetencyDefinition. Refer to Para 3.6
ConditionInstance. Refer to Para 3.2
ConditionType. Refer to Para 3.2
ConditionTypeAssertMember. Refer to Para 3.2
Contract. Refer to Para 3.27
Country. Refer to Para 3.19
DamageDefinition. Refer to Para 3.7
DatedClassification. Refer to SX002D
DateRange. Refer to SX002D
DateTimeRange. Refer to SX002D
DateType. Refer to SX002D
DecisionTreeTemplate. Refer to Para 3.8
DecisionTreeTemplateActionDefinition. Refer to Para 3.8
DecisionTreeTemplateQuestionDefinition. Refer to Para 3.8
DecisionTreeTemplateRevision. Refer to Para 3.8
DescriptorType. Refer to SX002D
DetectionMeansAlarm. Refer to Para 3.16
DigitalFile. Refer to Para 3.10
Document. Refer to Para 3.11

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 146

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−

DocumentIssue. Refer to Para 3.11
EnvironmentDefinition. Refer to Para 3.12
EnvironmentDefinitionCharacteristic. Refer to Para 3.12
EnvironmentDefinitionRevision. Refer to Para 3.12
EvaluationCriteria. Refer to Para 3.2
Facility. Refer to Para 3.13
FailureMode. Refer to Para 3.14
FailureModeAnalysis. Refer to Para 3.14
FailureModeAnalysisRevision. Refer to Para 3.14
FailureModeCause. Refer to Para 3.14
FailureModeEffect. Refer to Para 3.14
FailureModeSymptomsSignature. Refer to Para 3.16
GeographicalArea. Refer to Para 3.19
GlobalPosition. Refer to Para 3.19
IdentifierType. Refer to SX002D
InServiceOptimizationAnalysis. Refer to Para 3.18
InServiceOptimizationAnalysisRevision. Refer to Para 3.18
InServiceOptimizationAnalysisStep. Refer to Para 3.18
LSAFailureModeGroup. Refer to Para 3.22
MaintenanceLevel. Refer to Para 3.29
MeasurementPointDefinition. Refer to Para 3.16
Message. Refer to Para 3.23
NameType. Refer to SX002D
OperatingLocationType. Refer to Para 3.29
Organization. Refer to Para 3.24
PartAsDesigned. Refer to Para 3.25
PartAsDesignedPartsList. Refer to Para 3.25
PartAsDesignedPartsListEntry. Refer to Para 3.25
PartAsDesignedPartsListRevision. Refer to Para 3.25
PerformanceParameter. Refer to Para 3.26
PerformanceParameterRevision. Refer to Para 3.26
Product. Refer to Para 3.27
ProductUsagePhase. Refer to Para 3.30
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27
PropertyType. Refer to SX002D
RepeatDefinition. Refer to Para 3.40
ResourceSpecification. Refer to Para 3.32
ResourceSpecificationRevision. Refer to Para 3.32
SecurityClass. Refer to Para 3.33
SerialNumberRange. Refer to SX002D
Skill. Refer to Para 3.6
SkillLevel. Refer to Para 3.6
SpecialEventDefinition. Refer to Para 3.35
StateType. Refer to SX002D
StreetAddress. Refer to Para 3.19
SubstanceDefinition. Refer to Para 3.25
Subtask. Refer to Para 3.36

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 147

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
3.31.3.2.2

Task. Refer to Para 3.36
TaskRequirement. Refer to Para 3.37
TaskRequirementRevision. Refer to Para 3.37
TaskResource. Refer to Para 3.38
TaskRevision. Refer to Para 3.36
ThreeDimensional. Refer to SX002D
ThresholdDefinition. Refer to Para 3.40
TimeLimit. Refer to Para 3.40
TimeStampedClassification. Refer to SX002D
Trade. Refer to Para 3.6
umlBoolean. Refer to SX002D
umlInteger. Refer to SX002D
umlReal. Refer to SX002D
umlString. Refer to SX002D
umlUnlimitedNatural. Refer to SX002D
WarningCautionNote. Refer to Para 3.36

Associations
The RemarkItem <<extend>> interface has the following associations:−

An aggregate association with zero, one or many instances of Remark

3.32

S3000L UoF Resource Specification

3.32.1

Description
The Resource Specification UoF provides the capability to define generic definitions ofresources needed without having to define its actual realization.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 148

S3000L-B6865-03000-00

3.32.2Graphical description

ICN-B6865-S3000L0285-001-01
Fig 36 S3000L UoF Resource Specification
3.32.33.32.3.1

Class definition
ResourceRealization

ResourceRealization is a <<relationship>> where a
ResourceSpecification relates to an instance of PartAsDesigned (refer toPara 3.25) that fulfills the resource specification.
3.32.3.1.1

Associations
This class has the following associations:−3.32.3.1.2

A directed definedBy association with one instance of PartAsDesigned. Refer toPara 3.25

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 149

S3000L-B6865-03000-00

3.32.3.2

ResourceSpecification

ResourceSpecification is a <<class>> that defines a resource by its
characteristics.
Note

ResourceSpecification allows for more generic resource definitions ie, atask/subtask does not need to be changed due to eg, customer specific resource
preferences.
3.32.3.2.1

Attribute(s)This class has the following attributes:−−

3.32.3.2.2

Associations
This class has the following associations:−3.32.3.2.3

resourceSpecificationIdentifier, one or many
resourceSpecificationType

An aggregate association with zero, one or many instances ofResourceSpecificationRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.32.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

ResourceSpecificationRevision

ResourceSpecificationRevision is a <<class>> representing an iteration
applied to a ResourceSpecification.
3.32.3.3.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.32.3.3.2

resourceSpecificationRevisionIdentifier
resourceSpecificationName, one or many
resourceSpecificationDescription, zero, one or many
resourceSpecificationRevisionRationale, zero, one or many
resourceSpecificationRevisionDate, zero or one
resourceSpecificationRevisionStatus, zero or one

Associations
This class has the following associations:−

A directed has association with zero, one or many instances ofResourceRealization
3.32.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−

ChangeControlledItem. Refer to Para 3.4
DigitalFileReferencingItem. Refer to Para 3.10

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 150

S3000L-B6865-03000-00−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.33

S3000L UoF Security Classification

3.33.1

Description
The Security Classification UoF provides the capability to assign security classifications to
objects that need special handling for protection against unauthorized access or distribution.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 151

S3000L-B6865-03000-00

3.33.2Graphical description

ICN-B6865-S3000L0231-004-01
Fig 37 S3000L UoF Security Classification
3.33.33.33.3.1

Class definition
SecurityClass

SecurityClass is a <<class>> that identifies a level of confidentiality which can beused to protect something against unauthorized access.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 152

S3000L-B6865-03000-00

3.33.3.1.1

Attribute(s)This class has the following attributes:−

3.33.3.1.2

securityClassValue

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.33.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SecurityClassification

SecurityClassification is a <<relationship>> that associates a given
SecurityClass with the item that must be protected against unauthorized access or
distribution
3.33.3.2.1

Attribute(s)This class has the following attributes:−−

3.33.3.2.2

Associations
This class has the following associations:−3.33.3.2.3

securityClassificationAuthority
securityClassificationDate, zero or one

A directed definedBy association with one instance of SecurityClass

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.33.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SecurityClassificationItem

SecurityClassificationItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.33.3.3.1

Class members
Classes that implement the SecurityClassificationItem <<extend>>
interface are:−

AllowedProductConfigurationByConfigurationIdentifier. Refer
to Para 3.28−−−

AnalysisActivity. Refer to Para 3.21
AuthorizedLife. Refer to SX004G
Breakdown. Refer to Para 3.3

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 153

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
3.33.3.3.2

BreakdownElement. Refer to Para 3.3
ClassificationType. Refer to SX004G
CompetencyDefinition. Refer to Para 3.6
Contract. Refer to Para 3.27
DatedClassification. Refer to SX004G
DigitalFile. Refer to Para 3.10
Document. Refer to Para 3.11
Facility. Refer to Para 3.13
Message. Refer to Para 3.23
PartAsDesigned. Refer to Para 3.25
PerformanceParameter
Product. Refer to Para 3.27
ProductUsagePhase. Refer to Para 3.30
ProductVariant. Refer to Para 3.27
Project. Refer to Para 3.27
PropertyType. Refer to SX004G
ResourceSpecification. Refer to Para 3.32
Skill. Refer to Para 3.6
Subtask. Refer to Para 3.36
Task. Refer to Para 3.36
TaskRequirement. Refer to Para 3.37
Trade. Refer to Para 3.6

Associations
The SecurityClassificationItem <<extend>> interface has the following
associations:−

A directed has association with zero, one or many instances of

SecurityClassification
3.34

S3000L UoF Software Element

3.34.1

Description
The Software Element UoF provides the capability to specify that an element within abreakdown is software and can be associated with the software part(s) that fulfill therequirement.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 154

S3000L-B6865-03000-00

3.34.2Graphical description

ICN-B6865-S3000L0274-001-01
Fig 38 S3000L UoF Software Element
3.34.33.34.3.1

Class definition
SoftwareElement

SoftwareElement is a BreakdownElement (refer to Para 3.3) that is realized as a
SoftwarePartAsDesigned (refer to Para 3.25).
3.34.3.1.1

Attribute(s)This class has the following attributes:−

breakdownElementIdentifier (inherited from BreakdownElement), one
or many−

breakdownElementName (inherited from BreakdownElement), zero, one or
many−

breakdownElementEssentiality (inherited from BreakdownElement),
zero or one−
3.34.3.1.2

Associations
This class has the following associations:−3.34.3.1.3

softwareElementType, one or many

An aggregate association with one or many instances ofSoftwareElementRevision

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 155

S3000L-B6865-03000-00−

AnalysisCandidateItem (inherited from BreakdownElement). Refer toPara 3.21−

BreakdownElementInZoneItem (inherited from BreakdownElement). Refer
to Para 3.41−

DecisionTreeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from BreakdownElement). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from BreakdownElement).
Para 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.14−−−

InServiceOptimizationAnalysisItem (inherited fromBreakdownElement). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElement). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

PerformanceParameterItem (inherited from BreakdownElement). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from BreakdownElement). Refer
to Para 3.33

3.34.3.2

SoftwareElementPartRealization

SoftwareElementPartRealization is a <<relationship>> where a
SoftwareElementRevision relates to an instance ofSoftwarePartAsDesigned (refer to Para 3.25) which fulfills theSoftwareElement specification.
3.34.3.2.1

Associations
This class has the following associations:−3.34.3.2.2

A directed definedBy association with one instance ofSoftwarePartAsDesigned. Refer to Para 3.25

Implementations
This class implements the following <<extend>> interfaces:
−
−
−
−
−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EffectiveOnProductConfigurationItem. Refer to Para 3.28
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
UsableOnItem. Refer to Para 3.28

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 156

S3000L-B6865-03000-00

3.34.3.3

SoftwareElementRevision

SoftwareElementRevision is a BreakdownElementRevision (refer toPara 3.3) representing an iteration applied to a SoftwareElement.
3.34.3.3.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−
−
−

3.34.3.3.2

breakdownElementRevisionIdentifier (inherited fromBreakdownElementRevision)
breakdownElementDescription (inherited fromBreakdownElementRevision), zero, one or many
maintenanceSignificantOrRelevant (inherited fromBreakdownElementRevision)
breakdownElementRevisionRationale (inherited fromBreakdownElementRevision), zero, one or many
breakdownElementRevisionDate (inherited fromBreakdownElementRevision), zero or one
breakdownElementRevisionStatus (inherited fromBreakdownElementRevision), zero or one
softwareElementSize, one or many
softwareElementModificationFrequency, one or many
softwareElementLoadingStrategy, zero, one or many

Associations
This class has the following associations:−−

A directed has association with zero, one or many instances ofBreakdownElementRevisionRelationship (inherited fromBreakdownElementRevision). Refer to Para 3.3
A directed has association with zero, one or many instances ofSoftwareElementPartRealization
3.34.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElementRevision).
Refer to Para 3.21−−

BreakdownElementInZoneItem (inherited fromBreakdownElementRevision). Refer to Para 3.41
ChangeControlledItem (inherited from BreakdownElementRevision).
Refer to Para 3.4

−
−
−
−
−
−

DetectionMeansAlarmItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
DigitalFileReferencingItem (inherited fromBreakdownElementRevision). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.14
InServiceOptimizationAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElementRevision). Refer to Para 3.16

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 157

S3000L-B6865-03000-00−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem (inherited fromBreakdownElementRevision). Refer to Para 3.26
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TaskAnalysisItem (inherited from BreakdownElementRevision). Refer toPara 3.39−

TaskRequirementAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.37

3.35

S3000L UoF Special Event

3.35.1

Description
The Special Event UoF provides the capability to define typical happenings which can be
induced to an item under analysis and which can impact the operational capability of the
Product during its in-service phase.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 158

S3000L-B6865-03000-00

3.35.2Graphical description

ICN-B6865-S3000L0281-001-01
Fig 39 S3000L UoF Special Event
3.35.33.35.3.1

Class definition
SpecialEventAnalysis

SpecialEventAnalysis is AnalysisActivity (refer to Para 3.21) that
represents the objective for, and outcome of, a special event analysis carried out for the
AnalysisCandidateItem (refer to Para 3.21).
3.35.3.1.1

Attribute(s)This class has the following attributes:−

3.35.3.1.2

analysisActivityType (inherited from AnalysisActivity)

Associations
This class has the following associations:−

An aggregate association with one or many instances ofSpecialEventAnalysisRevision

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 159

S3000L-B6865-03000-00

3.35.3.1.3

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from AnalysisActivity). Refer
to Para 3.2−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from AnalysisActivity). Refer
to Para 3.33

3.35.3.2

SpecialEventAnalysisRevision

SpecialEventAnalysisRevision is an AnalysisActivityRevision(refer to Para 3.21) representing an iteration applied to a SpecialEventAnalysis.
3.35.3.2.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−

3.35.3.2.2

Associations
This class has the following associations:−3.35.3.2.3

analysisActivityRevisionIdentifier (inherited from
AnalysisActivityRevision)
analysisActivityDecision (inherited from
AnalysisActivityRevision)
analysisActivityDecisionRationale (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityStatusDescription (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityRevisionRationale (inherited from
AnalysisActivityRevision), zero, one or many
analysisActivityRevisionDate (inherited from
AnalysisActivityRevision), zero or one
analysisActivityRevisionStatus (inherited from
AnalysisActivityRevision), zero or one

An aggregate association with one or many instances ofSpecialEventDefinition

Implementations
This class implements the following <<extend>> interfaces:−

ChangeControlledItem (inherited from AnalysisActivityRevision).
Refer to Para 3.4−−−

DigitalFileReferencingItem (inherited from
AnalysisActivityRevision). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 160

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.35.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SpecialEventDefinition

SpecialEventDefinition is a <<class>>that represents a typical happening
which can be induced to the item under analysis during its normal operation, and can lead todamages.
3.35.3.3.1

Attribute(s)This class has the following attributes:−−−−

3.35.3.3.2

specialEventDefinitionName, one or many
specialEventDefinitionCauseCategory
specialEventDefinitionDecription, zero, one or many
specialEventDefinitionOccurrenceValue, zero, one or many

Associations
This class has the following associations:−

A directed has association with zero, one or many instances ofSpecialEventProductUsagePhaseOccurrence
3.35.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−3.35.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SpecialEventProductUsagePhaseOccurrence

SpecialEventProductUsagePhaseOccurrence is a <<relationship>>that defines an association between an instance of SpecialEventDefinition and an
instance of ProductUsagePhase (refer to Para 3.30) during which the special event canoccur.
3.35.3.4.1

Attribute(s)This class has the following attributes:−

3.35.3.4.2

Associations
This class has the following associations:−3.35.3.4.3

specialEventOccurenceRatio, zero, one or many

A directed definedBy association with one instance of ProductUsagePhase.
Refer to Para 3.30

Implementations
This class implements the following <<extend>> interfaces:−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 161

S3000L-B6865-03000-00−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.36

S3000L UoF Task

3.36.1

Description
The Task UoF supports the detailed definition of tasks required to support a Product.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 162

S3000L-B6865-03000-00

3.36.2Graphical description

ICN-B6865-S3000L0227-004-01
Fig 40 S3000L UoF Task
3.36.33.36.3.1

Class definition
CircuitBreakerItem

CircuitBreakerItem is a <<select>> interface that identifies items which canrepresent the referenced circuit breaker.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 163

S3000L-B6865-03000-00

3.36.3.1.1

Class members
This <<select>> interface includes the following class members:−−

3.36.3.2

CircuitBreaker. Refer to Para 3.5
HardwareElement. Refer to Para 3.17

CircuitBreakerSetting

CircuitBreakerSetting is a <<class>> that specifies an individual circuit breakerthat must be in a specific state.
3.36.3.2.1

Attribute(s)This class has the following attributes:−−

3.36.3.2.2

Associations
This class has the following associations:−3.36.3.2.3

circuitBreakerSettingIdentifier
circuitBreakerStateA directed definedBy association with one instance of CircuitBreakerItem

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

CircuitBreakerSettings

CircuitBreakerSettings is a <<class>> that identifies a set of circuit breakers
that must be set in specific states.
3.36.3.3.1

Attribute(s)This class has the following attributes:−−

3.36.3.3.2

Associations
This class has the following associations:−3.36.3.3.3

circuitBreakerSettingsIdentifier
circuitBreakerSettingsOrderedAn aggregate association with zero, one or many instances of

CircuitBreakerSetting

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 164

S3000L-B6865-03000-00−
3.36.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

OperationalTask

OperationalTask is a Task that is required to support the use of a product.
Example(s)− Fueling− Towing
3.36.3.4.1

Attribute(s)This class has the following attributes:−

3.36.3.4.2

Associations
This class has the following associations:−3.36.3.4.3

taskIdentifier (inherited from Task), one or many

An aggregate association with zero, one or many instances of TaskRevision (inheritedfrom Task).

Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem (inherited from Task). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem (inherited from Task). Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Task). Refer to Para 3.33

RectifyingTask

RectifyingTask is a Task that ensures or returns the function of the associated item.
Note
An event that can require a Task to be performed includes a failure, damage, a special
event, and a time limit.
Example(s)− Lubrication− Repair− Replace
3.36.3.5.1

Attribute(s)This class has the following attributes:−−

3.36.3.5.2

taskIdentifier (inherited from Task), one or many
packagedTask

Associations
This class has the following associations:−

An aggregate association with zero, one or many instances of TaskRevision (inheritedfrom Task).

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 165

S3000L-B6865-03000-00

3.36.3.5.3

Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem (inherited from Task). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem (inherited from Task). Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Task). Para 3.33

ResultingDataModule

ResultingDataModule is a <<relationship>> that identifies a data moduleissue in which a TaskRevision is further detailed.
Note
A data module can contain either a complete or partial description of a given task revision.
3.36.3.6.1

Associations
This class has the following associations:−3.36.3.6.2

A directed definedBy association with one instance of
S1000DDataModuleIssue. Refer to Para 3.11

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Subtask

Subtask is a <<class>> that represents the specification of a work step that is to be
performed as part of a Task.
3.36.3.7.1

Attribute(s)This class has the following attributes:−−

3.36.3.7.2

3.36.3.7.3

subtaskIdentifier
subtaskRole, zero or one

Associations
This class has the following associations:−

A directed hasPredecessor association with zero or one instance of−SubtaskTimeline
A directed has association with zero, one or many instances ofSubtaskWarningCautionNote

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 166

S3000L-B6865-03000-00

−
−
−
−

ApplicabilityStatementItem. Refer to Para 3.2
DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

SubtaskAcceptanceParameter

SubtaskAcceptanceParameter is a <<class>> that represents acceptancecriteria which must be met before the Subtask is completed.
3.36.3.8.1

Attribute(s)This class has the following attributes:−−−−

subtaskAcceptanceParameterName, one or many
subtaskAcceptanceParameterDescription, zero, one or many
subtaskAcceptanceParameterValue, zero, one or many
subtaskAcceptanceParameterValueComparisonOperator, zero orone

3.36.3.8.2

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.9

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SubtaskByDefinition

SubtaskByDefinition is a Subtask that provides detailed information of the defined
work step.
3.36.3.9.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−
−

3.36.3.9.2

subtaskIdentifier (inherited from Subtask)
subtaskRole (inherited from Subtask), zero or one
subtaskName, one or many
subtaskInformationCode, zero or one
subtaskDescription, zero, one or many
subtaskDuration, zero, one or many
subtaskMaintenanceLocation, zero, one or many
subtaskEndItemObjectiveState, zero, one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 167

S3000L-B6865-03000-00−

An ordered aggregate association with zero, one or many instances of

CircuitBreakerSettings
−
−
−
−
−
−
3.36.3.9.3

An aggregate association with zero, one or many instances ofSubtaskAcceptanceParameter
A directed hasPredecessor association with zero or one instance ofSubtaskTimeline (inherited from Subtask)
A directed has association with zero, one or many instances ofSubtaskWarningCautionNote (inherited from Subtask)
A directed has association with zero, one or many instances of SubtaskInZone
A directed has association with zero, one or many instances ofSubtaskSourceDocument
A directed has association with zero, one or many instances of SubtaskTarget

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem (inherited from Subtask). Refer to Para 3.2
DigitalFileReferencingItem (inherited from Subtask). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−−3.36.3.10

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Subtask). Refer to Para 3.33
TaskResourceItem. Refer to Para 3.38

SubtaskByTaskReference

SubtaskByTaskReference is a Subtask where the details of the subtask aredefined as a separate Task.
3.36.3.10.1 Attribute(s)This class has the following attributes:−−

subtaskIdentifier (inherited from Subtask)
subtaskRole (inherited from Subtask), zero or one

3.36.3.10.2 Associations
This class has the following associations:−−−

A directed hasPredecessor association with zero or one instance ofSubtaskTimeline (inherited from Subtask)
A directed has association with zero, one or many instances ofSubtaskWarningCautionNote (inherited from Subtask)
A directed referencedTask association with one instance of Task

3.36.3.10.3 Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem (inherited from Subtask). Refer to Para 3.2
DigitalFileReferencingItem (inherited from Subtask). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 168

S3000L-B6865-03000-00−

OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.11

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Subtask). Refer to Para 3.33

SubtaskInZone

SubtaskInZone is a <<relationship>> that identifies the zone where theSubtask is to be performed.
3.36.3.11.1 Associations
This class has the following associations:−

A directed definedBy association with one instance of ZoneElement. Refer toPara 3.41

3.36.3.11.2 Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.12

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SubtaskSourceDocument

SubtaskSourceDocument is a <<relationship>> that identifies an external
Document (refer to Para 3.11) where the Subtask is originally defined and more details
are given.
3.36.3.12.1 Attribute(s)This class has the following attributes:−

sourceDocumentPortion, zero, one or many

3.36.3.12.2 Associations
This class has the following associations:−

A directed definedBy association with one instance of DocumentItem. Refer toPara 3.11

3.36.3.12.3 Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 169

S3000L-B6865-03000-00

3.36.3.13

SubtaskTarget

SubtaskTarget is a <<relationship>> that identifies the item on which theSubtask is to be performed.
3.36.3.13.1 Associations
This class has the following associations:−

A directed definedBy association one instance of SubtaskTargetItem

3.36.3.13.2 Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.14

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SubtaskTargetItem

SubtaskTargetItem is a <<select>> interface that identifies items on which a
Subtask can be performed.
3.36.3.14.1 Class members
This <<select>> interface includes the following class members:−−
3.36.3.15

BreakdownElement. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25

SubtaskTimeline

SubtaskTimeline is a <<relationship>> that identifies that there is a timedependency between two Subtasks within the same Task.
3.36.3.15.1 Attribute(s)This class has the following attributes:−−

subtaskTimelineEvent
subtaskTimelineLag, zero, one or many

3.36.3.15.2 Associations
This class has the following associations:−

A directed definedBy association with one instance of Subtask

3.36.3.15.3 Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 170

S3000L-B6865-03000-00

3.36.3.16

SubtaskWarningCautionNote

SubtaskWarningCautionNote is a <<relationship>> that identifies a
WarningCautionNote that is associated with a given Subtask.
3.36.3.16.1 Associations
This class has the following associations:−

A directed definedBy association with one instance of WarningCautionNote

3.36.3.16.2 Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.17

RemarkItem (inherited from BaseObject). Refer to Para 3.31

SupportingTask

SupportingTask is a Task that does not meet a TaskRequirement, but identifies
a set of work steps which will be carried out as part of multiple Tasks.
Note
The objective for a SupportingTask is to enable reuse of a sequence of work steps,
needed by a set of Tasks.
Note
A SupportingTask will only be used in the context ofSubtaskByTaskReference.
Example(s)− Jack vehicle− Open hatch
3.36.3.17.1 Attribute(s)This class has the following attributes:−

taskIdentifier (inherited from Task), one or many

3.36.3.17.2 Associations
This class has the following associations:−

An aggregate association with zero, one or many instances of TaskRevision (inheritedfrom Task).

3.36.3.17.3 Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem (inherited from Task). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem (inherited from Task). Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 171

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.18

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from Task). Refer to Para 3.33

Task

Task is a <<class>> that represents the specification of work to be done or undertaken.
3.36.3.18.1 Attribute(s)This class has the following attributes:−

taskIdentifier, one or many

3.36.3.18.2 Associations
This class has the following associations:−

An aggregate association with zero, one or many instances of TaskRevision.

3.36.3.18.3 Implementations
This class implements the following <<extend>> interfaces:−−−−

DigitalFileReferencingItem. Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.19

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

TaskJustification

TaskJustification is a <<relationship>> that identifies a
TaskRequirement (refer to Para 3.37) that defines the need for the existence of a Task.
3.36.3.19.1 Associations
This class has the following associations:−

A directed definedBy association with one instance of
TaskRequirementRevision. Refer to Para 3.37

3.36.3.19.2 Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.20

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskRevision

TaskRevision is a <<class>> representing an iteration applied to a Task.
3.36.3.20.1 Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 172

S3000L-B6865-03000-00

−
−
−
−
−
−
−
−
−
−
−
−

taskRevisionIdentifier
taskName, one or many
taskRevisionChangeDescription, zero, one or many
taskInformationCode
taskPersonnelSafetyCriticality, zero or one
taskProductIntegrityCriticality, zero or one
taskOperabilityImpact, zero or one
taskDuration, zero, one or manytaskTotalLaborTime, zero, one or many
taskRevisionRationale, zero, one or many
taskRevisionDate, zero or one
taskRevisionStatus, zero or one

3.36.3.20.2 Associations
This class has the following associations:−−−−

An ordered aggregate association with one or many instances of Subtask
A directed has association with zero, one or many instances ofResultingDataModule
A directed has association with zero, one or many instances of
TaskJustification
A directed has association with zero, one or many instances of
TaskRevisionWarningCautionNote

3.36.3.20.3 Implementations
This class implements the following <<extend>> interfaces:−−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
EnvironmentDefinitionItem. Refer to Para 3.12
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.36.3.21

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TaskResourceItem. Refer to Para 3.38

TaskRevisionWarningCautionNote

TaskRevisionWarningCautionNote is a <<relationship>> that identifies a
WarningCautionNote that is associated with a given Task.
3.36.3.21.1 Associations
This class has the following associations:−

A directed definedBy association with one instance of WarningCautionNote

3.36.3.21.2 Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 173

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.36.3.22

RemarkItem (inherited from BaseObject). Refer to Para 3.31

WarningCautionNote

WarningCautionNote is a <<class>> that defines advice concerning safety, legal
and health aspects.
3.36.3.22.1 Attribute(s)This class has the following attributes:−−−

warningCautionNoteIdentifier, one or many
warningCautionNoteDescription, one or many
warningCautionNoteType

3.36.3.22.2 Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.37

S3000L UoF Task Requirement

3.37.1

Description
The Task Requirement UoF supports early documentation of the need for a task to be
performed to support a Product.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 174

S3000L-B6865-03000-00

3.37.2Graphical description

ICN-B6865-S3000L0226-004-01
Fig 41 S3000L UoF Task Requirement
3.37.33.37.3.1

Class definition
AuthorityDrivenTaskRequirement

AuthorityDrivenTaskRequirement is an <<attributeGroup>> thatcollects information on task requirement derived from regulations and/or other authoritative
sources.
3.37.3.1.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

taskRequirementAuthoritySourceType, zero or one
taskRequirementAuthority

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 175

S3000L-B6865-03000-00

3.37.3.2

IdentifiedTaskRequirement

IdentifiedTaskRequirement is a <<relationship>> that associates a
TaskRequirement with a TaskRequirementAnalysisItem.
3.37.3.2.1

Associations
This class has the following associations:−3.37.3.2.2

A directed definedBy association with one instance of TaskRequirement

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.37.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TimeLimitItem. Refer to Para 3.40

TaskRequirement

TaskRequirement is a <<class>> that represents the need for a procedure to be
developed and documented.
Note
Task requirements are identified and documented prior to any detailed task analysis.
Note
A task requirement can have more than one task being developed for different usage
scenarios.
Note
Examples of support analysis activities which result in a set of documented task
requirements are: Preventive maintenance analysis (refer to S4000P) and special event
analysis.
3.37.3.3.1

Attribute(s)This class has the following attributes:−

3.37.3.3.2

3.37.3.3.3

taskRequirementIdentifier, one or many

Associations
This class has the following associations:−

An aggregate association with zero or one instance of−An aggregate association with one or many instances of

AuthorityDrivenTaskRequirement
TaskRequirementRevision

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 176

S3000L-B6865-03000-00−−
3.37.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem. Refer to Para 3.33

TaskRequirementAnalysisItem

TaskRequirementAnalysisItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.37.3.4.1

Class members
Classes that implement the TaskRequirementAnalysisItem <<extend>>
interface are:−−3.37.3.4.2

BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25

Associations
The TaskRequirementAnalysisItem <<extend>> interface has the following
associations:−

A directed has association with zero, one or many instances of

IdentifiedTaskRequirement
3.37.3.5

TaskRequirementJustification

TaskRequirementJustification is a <<relationship>> that identifies asource which defines the need for a task.
3.37.3.5.1

Attribute(s)This class has the following attributes:−

3.37.3.5.2

taskRequirementJustificationDescription, zero, one or many

Associations
This class has the following associations:−

A directed definedBy association with one instance of

TaskRequirementJustificationItem
3.37.3.5.3

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.37.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskRequirementJustificationItem

TaskRequirementJustificationItem is a <<select>> interface that
identifies items which can be selected as being the source that justifies the
TaskRequirement.
3.37.3.6.1

Class members
This <<select>> interface includes the following class members:−−

AnalysisActivityRevision. Refer to Para 3.21
ChangeAuthorization. Refer to Para 3.4

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 177

S3000L-B6865-03000-00

3.37.3.7

TaskRequirementRevision

TaskRequirementRevision is a <<class>> representing an iteration applied to a
TaskRequirement.
3.37.3.7.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−
−
−

3.37.3.7.2

taskRequirementRevisionIdentifier
taskRequirementRevisionChangeDescription, zero, one or many
taskRequirementDescription, zero, one or many
taskRequirementSpecialResourceRequirement, zero, one or many
taskRequirementInformationCode, zero or one
taskRequirementRevisionRationale, zero, one or many
taskRequirementRevisionDate, zero or one
taskRequirementRevisionStatus, zero or one

Associations
This class has the following associations:−

A directed has association with zero, one or many instances of

TaskRequirementJustification
3.37.3.7.3

Implementations
This class implements the following <<extend>> interfaces:−−−

ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.38

S3000L UoF Task Resource

3.38.1

Description
The Task Resource UoF supports a detailed specification of resources needed to perform a
specified amount of work.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 178

S3000L-B6865-03000-00

3.38.2Graphical description

ICN-B6865-S3000L0228-004-01
Fig 42 S3000L UoF Task Resource
3.38.33.38.3.1

Class definition
AdditionalTrainingNeed

AdditionalTrainingNeed is an <<attributeGroup>> that specifies additional
learning required for the associated CompetenceDefinitionItem (refer to Para 3.6) inorder to qualify as the TaskPersonnelResource.
3.38.3.1.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

3.38.3.2

additionalTrainingNeedDescription, one or many
proposedTrainingMethod, zero or one

TaskDocumentResource

TaskDocumentResource is a TaskResource that identifies a Document (refer toPara 3.11) used as a resource.
Example(s)− A form that must be filled out before, during or after the specified amount of work is carriedout.
3.38.3.2.1

Attribute(s)This class has the following attributes:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 179

S3000L-B6865-03000-00−−−
3.38.3.2.2

Associations
This class has the following associations:−−3.38.3.2.3

taskResourceIdentifier (inherited from TaskResource), one or many
taskResourceFixedResourceMarker (inherited from TaskResource)taskResourceDuration (inherited from TaskResource), zero, one or many

A directed has association with zero, one or many instances of
TaskResourceRelationship (inherited from TaskResource)
A directed definedBy association with one instance of DocumentItem. Refer toPara 3.11

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from TaskResource). Refer toPara 3.2−−−

ChangeControlledItem (inherited from TaskResource). Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.38.3.3

RemarkItem (inherited from BaseObject). Para 3.31

TaskInfrastructureResource

TaskInfrastructureResource is a TaskResource that defines foundational
systems and services required as a resource.
3.38.3.3.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.38.3.3.2

taskResourceIdentifier (inherited from TaskResource), one or many
taskResourceFixedResourceMarker (inherited from TaskResource)taskResourceDuration (inherited from TaskResource), zero, one or many
taskInfrastructureResourceQuantity, zero, one or many
taskInfrastructureResourceCategory, zero or one

Associations
This class has the following associations:−−

A directed has association with zero, one or many instances of
TaskResourceRelationship (inherited from TaskResource)
A directed has association with zero or one instance of

TaskResourceDefinitionItem
3.38.3.3.3

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from TaskResource). Refer toPara 3.2−−−

ChangeControlledItem (inherited from TaskResource). Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 180

S3000L-B6865-03000-00−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.38.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskMaterialResource

TaskMaterialResource is a TaskResource that identifies parts which are required
as a resource.
3.38.3.4.1

Attribute(s)This class has the following attributes:
−
−
−
−
−

3.38.3.4.2

taskResourceIdentifier (inherited from TaskResource), one or many
taskResourceFixedResourceMarker (inherited from TaskResource)taskResourceDuration (inherited from TaskResource), zero, one or many
taskMaterialResourceQuantity, one or many
taskMaterialResourceCategory, zero, one or many

Associations
This class has the following associations:−−

A directed has association with zero, one or many instances of
TaskResourceRelationship (inherited from TaskResource)
A directed has association with zero or one instance of

TaskResourceDefinitionItem
3.38.3.4.3

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from TaskResource). Refer toPara 3.2−−−

ChangeControlledItem (inherited from TaskResource). Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.38.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskPersonnelResource

TaskPersonnelResource is a TaskResource that specifies the man power
required as a resource.
3.38.3.5.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.38.3.5.2

taskResourceIdentifier (inherited from TaskResource), one or many
taskResourceFixedResourceMarker (inherited from TaskResource)taskResourceDuration (inherited from TaskResource), zero, one or many
taskPersonnelResourceRole
taskPersonnelResourceQuantity, zero, one or many
taskPersonnelResourceLaborTime, zero, one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 181

S3000L-B6865-03000-00−−

3.38.3.5.3

A directed has association with zero, one or many instances of
TaskResourceRelationship (inherited from TaskResource)
A directed requires association with zero, one or many instances of
TaskPersonnelResourceCompetence.

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from TaskResource). Refer toPara 3.2−−−

ChangeControlledItem (inherited from TaskResource). Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.38.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskPersonnelResourceCompetence

TaskPersonnelResourceCompetence is a <<relationship>> that identifies
the proficiency required for TaskPersonnelResource.
3.38.3.6.1

Associations
This class has the following associations:−−3.38.3.6.2

An aggregate association with zero, one or many instances of

AdditionalTrainingNeed
A directed definedBy association with one instance ofCompetencyDefinitionItem. Refer to Para 3.6

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.38.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskResource

TaskResource is a <<class>> that identifies means that have to be available toperform a specified amount of work.
3.38.3.7.1

Attribute(s)This class has the following attributes:−−−

3.38.3.7.2

taskResourceIdentifier, one or many
taskResourceFixedResourceMarker
taskResourceDuration, zero, one or many

Associations
This class has the following associations:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 182

S3000L-B6865-03000-00−

A directed has association with zero, one or many instances of

TaskResourceRelationship3.38.3.7.3

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.38.3.8

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskResourceDefinitionItem

TaskResourceDefinitionItem is a <<select>> interface that identifies items
which can be used as either infrastructure or material resources.
3.38.3.8.1

Class members
This <<select>> interface includes the following class members:−−−−

3.38.3.9

BreakdownElement. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25
PartAsDesignedPartsListEntry. Refer to Para 3.25
ResourceSpecification. Refer to Para 3.32

TaskResourceItem

TaskResourceItem is an <<extend>> interface that provides its associated data
model to those classes that implement it.
3.38.3.9.1

Class members
Classes that implement the TaskResourceItem <<extend>> interface are:−−3.38.3.9.2

Associations
The TaskResourceItem <<extend>> interface has the following associations:−3.38.3.10

SubtaskByDefinition. Refer to Para 3.36
TaskRevision. Refer to Para 3.36

An aggregate association with zero, one or many instances of TaskResource

TaskResourceRelationship

TaskResourceRelationship is a <<relationship>> where one
TaskResource relates to another TaskResource.
3.38.3.10.1 Attribute(s)This class has the following attributes:−

taskResourceRelationshipType

3.38.3.10.2 Associations
This class has the following associations:−

A directed definedBy association with one instance of TaskResource

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 183

S3000L-B6865-03000-00

3.38.3.10.3 Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.39

S3000L UoF Task Usage

3.39.1

Description
The Task Usage UoF provides the capability to expand the definition for the execution of a task
in the context of a given support solution.

3.39.2Graphical description

ICN-B6865-S3000L0287-001-01
Fig 43 S3000L UoF Task Usage
3.39.33.39.3.1

Class definition
AllocatedTaskLocation

AllocatedTaskLocation is a <<class>> that identifies where a Task (refer toPara 3.36) is to be performed in the context of a given support solution.
3.39.3.1.1

Associations
This class has the following associations:−

A directed definedBy association with one instance of TaskLocationItem

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 184

S3000L-B6865-03000-00

3.39.3.1.2

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.39.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

PlannedTaskItem

PlannedTaskItem is a <<select>> interface that identifies items which can be usedin the context of PlannedTaskUsage.
3.39.3.2.1

Class members
This <<select>> interface includes the following class members:−−

3.39.3.3

OperationalTask. Refer to Para 3.36
RectifyingTask. Refer to Para 3.36

PlannedTaskUsage

PlannedTaskUsage is a TaskUsage that expands the definition of a required Task
(refer to Para 3.36) in the context of a given support solution.
Note
Both rectifying and operational tasks are justified by task requirements identified during
various analysis activities.
3.39.3.3.1

Associations
This class has the following associations:−−−3.39.3.3.2

An aggregate association with zero, one or many instances of TaskFrequency(inherited from TaskUsage)
An aggregate association with zero, one or many instances of

AllocatedTaskLocation
A directed definedBy association with one instance of PlannedTaskItem

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem (inherited from TaskUsage). Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.39.3.4

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TimeLimitItem. Refer to Para 3.40

SupportingTaskUsage

SupportingTaskUsage is a TaskUsage that expands the definition of an embedded
reusable Task (refer to Para 3.36) in the context of a given support solution.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 185

S3000L-B6865-03000-00

Note
A SupportingTask has no special characterizations apart from a
TaskFrequency since it will never be performed on its own.
3.39.3.4.1

Associations
This class has the following associations:−−3.39.3.4.2

An aggregate association with zero, one or many instances of TaskFrequency(inherited from TaskUsage)
A directed definedBy association with one instance of SupportingTask

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem (inherited from TaskUsage). Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.39.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TaskAnalysisItem

TaskAnalysisItem is an <<extend>> interface that provides its associated data
model to those classes that implement it.
3.39.3.5.1

Class members
Classes that implement the TaskAnalysisItem <<extend>> interface are:−−3.39.3.5.2

Associations
The TaskAnalysisItem <<extend>> interface has the following associations:−3.39.3.6

BreakdownElementRevision. Refer to Para 3.3
PartAsDesigned. Refer to Para 3.25

A directed has association with zero, one or many instances of TaskUsage

TaskFrequency

TaskFrequency is an <<attributeGroup>> that specifies the rate of occurrence ofa Task (refer to Para 3.36) in its defined usage.
3.39.3.6.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

3.39.3.6.2

Implementations
This class implements the following <<extend>> interfaces:−

3.39.3.7

taskFrequencyValue, one or many
taskFrequencyCalculationMethod, zero, one or many

ApplicabilityStatementItem. Refer to Para 3.2

TaskLocationItem

TaskLocationItem is a <<select>> interface that identifies items where Tasks(refer to Para 3.36) can be performed.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 186

S3000L-B6865-03000-00

3.39.3.7.1

Class members
This <<select>> interface includes the following class members:−−−−

3.39.3.8

Facility. Refer to Para 3.13
MaintenanceLevel. Refer to Para 3.29
OperatingLocationType. Refer to Para 3.29
Organization. Refer to Para 3.24

TaskUsage

TaskUsage is a <<relationship>> that identifies a Task (refer to Para 3.36)
required for the TaskAnalysisItem.
3.39.3.8.1

Associations
This class has the following associations:−3.39.3.8.2

An aggregate association with zero, one or many instances of TaskFrequency

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

3.40

S3000L UoF Time Limit

3.40.1

Description
The Time Limit UoF provides the capability to define the circumstances under which an action is
to be initiated.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 187

S3000L-B6865-03000-00

3.40.2Graphical description

ICN-B6865-S3000L0288-001-01
Fig 44 S3000L UoF Time Limit
3.40.33.40.3.1

Class definition
DiscreteTimeLimit

DiscreteTimeLimit is a TimeLimit that is distinct, where its next possible
occurrence cannot be scheduled.
Note
A Trigger is something that activates a DiscreteTimeLimit.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 188

S3000L-B6865-03000-00

Note
A Threshold is a point that must not be exceeded once the DiscreteTimeLimit has
been activated. If there is no threshold value, then the TimeLimitItem must be
initiated immediately after the DiscreteTimeLimit activation.
3.40.3.1.1

Attribute(s)This class has the following attributes:−−

3.40.3.1.2

3.40.3.1.3

timeLimitDescription (inherited from TimeLimit), zero, one or many
timeLimitHarmonizationIndicator (inherited from TimeLimit)

Associations
This class has the following associations:−

An aggregate threshold association with zero, one or many instances of−ThresholdDefinition
An aggregate trigger association with zero, one or many instances ofThresholdDefinition

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem (inherited from TimeLimit). Refer to Para 3.2
ChangeControlledItem (inherited from TimeLimit). Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.40.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SamplingItem. Refer to Para 3.40

EventThresholdDefinition

EventThresholdDefinition is a ThresholdDefinition that is driven byoccurrences of related TimeLimitEventItems.
3.40.3.2.1

Attribute(s)This class has the following attributes:−

3.40.3.2.2

Associations
This class has the following associations:−3.40.3.2.3

eventThresholdNumberOfEventOccurrences, zero or one

A directed definedBy association with one instance of TimeLimitEventItem

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from ThresholdDefinition).
Refer to Para 3.2−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 189

S3000L-B6865-03000-00−
3.40.3.3

RemarkItem (inherited from BaseObject). Refer to Para 3.31

MeasurementPointDegradedStateDefinition

MeasurementPointDegradedStateDefinition is an<<attributeGroup>> that specifies a measurable condition which, when met, identifies
that a degraded state is entered.
3.40.3.3.1

Attribute(s)This <<attributeGroup>> has the following attributes:−

measurementPointDegradedStateDefinitionAssertValue, one ormany−

3.40.3.4

measurementPointDegradedStateDefinitionAssertValueCompar
isonOperator

ParameterThresholdDefinition

ParameterThresholdDefinition is a ThresholdDefinition that iscontinuously measured and evaluated, and when reached, activates the associated trigger
threshold.
3.40.3.4.1

Attribute(s)This class has the following attributes:−−

3.40.3.4.2

thresholdValue
thresholdValueQualifier, zero or one

Implementations
This class implements the following <<extend>> interfaces:−

ApplicabilityStatementItem (inherited from ThresholdDefinition).
Refer to Para 3.2−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.40.3.5

RemarkItem (inherited from BaseObject). Refer to Para 3.31

PeriodicTimeLimit

PeriodicTimeLimit is a TimeLimit that is repeated and its next occurrence can bescheduled.
3.40.3.5.1

Attribute(s)This class has the following attributes:−−

3.40.3.5.2

timeLimitDescription (inherited from TimeLimit), zero, one or many
timeLimitHarmonizationIndicator (inherited from TimeLimit)

Associations
This class has the following associations:−

An ordered aggregate association with one or many instances of

RepeatDefinition
3.40.3.5.3

Implementations
This class implements the following <<extend>> interfaces:

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 190

S3000L-B6865-03000-00

−
−
−
−

ApplicabilityStatementItem (inherited from TimeLimit). Refer to Para 3.2
ChangeControlledItem (inherited from TimeLimit). Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.40.3.6

RemarkItem (inherited from BaseObject). Refer to Para 3.31

RepeatDefinition

RepeatDefinition is a <<class>> that represents the set of circumstances which
defines the PeriodicTimeLimit.
Note
A trigger is something that activates a RepeatDefinition.
Note
A threshold is a point that must not be exceeded by the TimeLimitItem once theRepeatDefinition has been activated.
Note
Only one RepeatDefinition must be active at a specific moment in time.
3.40.3.6.1

3.40.3.6.2

Associations
This class has the following associations:−

An aggregate threshold association with one or many instances of−ThresholdDefinition
An aggregate trigger association with zero, one or many instances ofThresholdDefinition

Implementations
This class implements the following <<extend>> interfaces:−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−−3.40.3.7

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SamplingItem

SamplingDefinition

SamplingDefinition is an <<attributeGroup>> that specifies whether the
associated action is to be performed on a subset of the population of the associated target item.
3.40.3.7.1

Attribute(s)This <<attributeGroup>> has the following attributes:−−

3.40.3.8

samplingMethodDescription, zero, one or many
samplingValue, one or many

SamplingItem

SamplingItem is an <<extend>> interface that represents the common behavior for
those classes which can have an associated SamplingDefinition.
Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 191

S3000L-B6865-03000-00

3.40.3.8.1

Class members
Classes that implement the SamplingItem <<extend>> interface are:−−3.40.3.8.2

Associations
The SamplingItem <<extend>> interface has the following associations:−3.40.3.9

DiscreteTimeLimit
RepeatDefinition

An aggregate association with zero or one instance of SamplingDefinition

ThresholdDefinition

ThresholdDefinition is a <<class>> that represents the circumstance that is used
as a trigger or threshold.
3.40.3.9.1

Implementations
This class implements the following <<extend>> interfaces:−−−

ApplicabilityStatementItem. Refer to Para 3.2
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.40.3.10

RemarkItem (inherited from BaseObject). Refer to Para 3.31

TimeLimit

TimeLimit is a <<class>> that represents the specification of circumstances underwhich the associated item is initiated.
Note
Time is used in the sense of "time to do something" and must not be seen as only aperiod of time.
Note

TimeLimit does not have the concept of an identification which means that if there is achange to a TimeLimit for a TimeLimitItem, then all TimeLimits must be
resent as part of a Message.
3.40.3.10.1 Attribute(s)This class has the following attributes:−−

timeLimitDescription, zero, one or many
timeLimitHarmonizationIndicator

3.40.3.10.2 Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−

RemarkItem (inherited from BaseObject). Refer to Para 3.31

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 192

S3000L-B6865-03000-00

3.40.3.11

TimeLimitEventItem

TimeLimitEventItem is a <<select>> interface that identifies which items can beused to define an EventThresholdDefinition.
3.40.3.11.1 Class members
This <<select>> interface includes the following class members:
−
−
−
−
−
−
3.40.3.12

ChangeAuthorization. Refer to Para 3.4
DetectionMeansAlarm. Refer to Para 3.16
FailureModeSymptomsSignature. Refer to Para 3.16
MeasurementPointDefinition. Refer to Para 3.16
SpecialEventDefinition. Refer to Para 3.35
Task. Refer to Para 3.36

TimeLimitItem

TimeLimitItem is an <<extend>> interface that provides its associated data model tothose classes that implement it.
3.40.3.12.1 Class members
Classes that implement the TimeLimitItem <<extend>> interface are:−−IdentifiedTaskRequirement. Refer to Para 3.37
PlannedTaskUsage. Refer to Para 3.39

3.40.3.12.2 Associations
The TimeLimitItem <<extend>> interface has the following associations:−

An aggregate association with zero, one or many instances of TimeLimit

3.41

S3000L UoF Zone Element

3.41.1

Description
The Zone Element UoF defines the characteristics that are unique for a breakdown element that
represents a three-dimensional space related to a Product.

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 193

S3000L-B6865-03000-00

3.41.2Graphical description

ICN-B6865-S3000L0220-004-01
Fig 45 S3000L UoF Zone Element
3.41.33.41.3.1

Class definition
BreakdownElementInZone

BreakdownElementInZone is a <<relationship>> where a
BreakdownElementInZoneItem relates to the ZoneElement where it is located.
3.41.3.1.1

Associations
This class has the following associations:−3.41.3.1.2

A directed definedBy association with one instance of ZoneElement

Implementations
This class implements the following <<extend>> interfaces:−−−−

ApplicabilityStatementItem. Refer to Para 3.2
ChangeControlledItem. Refer to Para 3.4
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D

−3.41.3.2

RemarkItem (inherited from BaseObject). Refer to Para 3.31

BreakdownElementInZoneItem

BreakdownElementInZoneItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.
3.41.3.2.1

Class members
Classes that implement the BreakdownElementInZoneItem <<extend>>
interface are:Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 194

S3000L-B6865-03000-00−−−
3.41.3.2.2

Associations
The BreakdownElementInZoneItem <<extend>> interface has the following
associations:−3.41.3.3

BreakdownElement. Refer to Para 3.3
BreakdownElementRevision. Refer to Para 3.3
BreakdownElementUsageInBreakdown. Refer to Para 3.3

A directed has association with one instance of BreakdownElementInZone

ZoneElement

ZoneElement is a BreakdownElement (refer to Para 3.3) that represents a threedimensional space related to a Product (refer to Para 3.27).
Note
A zone can also represent a work area such as a mechanical workshop onboard a ship.
3.41.3.3.1

Attribute(s)This class has the following attributes:−

breakdownElementIdentifier (inherited from BreakdownElement), one
or many−

breakdownElementName (inherited from BreakdownElement), zero, one or
many−

breakdownElementEssentiality (inherited from BreakdownElement),
zero or one−
3.41.3.3.2

Associations
This class has the following associations:−3.41.3.3.3

zoneElementType, one or many

An aggregate association with one or many instances of ZoneElement

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElement). Refer toPara 3.21−−

BreakdownElementInZoneItem (inherited from BreakdownElement
DecisionTreeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.8−

DetectionMeansAlarmItem (inherited from BreakdownElement). Refer toPara 3.16−

DigitalFileReferencingItem (inherited from BreakdownElement). Refer
Para 3.10−−

DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited from BreakdownElement). Refer toPara 3.14−−−

InServiceOptimizationAnalysisItem (inherited fromBreakdownElement). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElement). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 195

S3000L-B6865-03000-00−

PerformanceParameterItem (inherited from BreakdownElement). Refer toPara 3.26−

ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
SecurityClassificationItem (inherited from BreakdownElement). Refer
to Para 3.33

3.41.3.4

ZoneElementRevision

ZoneElementRevision is a BreakdownElementRevision (refer to Para 3.3)
representing an iteration applied to a ZoneElement.
3.41.3.4.1

Attribute(s)This class has the following attributes:
−
−
−
−
−
−

3.41.3.4.2

Associations
This class has the following associations:−3.41.3.4.3

breakdownElementRevisionIdentifier (inherited fromBreakdownElementRevision)
breakdownElementDescription (inherited fromBreakdownElementRevision), zero, one or many
maintenanceSignificantOrRelevant (inherited fromBreakdownElementRevision)
breakdownElementRevisionRationale (inherited fromBreakdownElementRevision), zero, one or many
breakdownElementRevisionDate (inherited fromBreakdownElementRevision), zero or one
breakdownElementRevisionStatus (inherited fromBreakdownElementRevision), zero or one

A directed has association, to zero, one or many objects of type
BreakdownElementRevisionRelationship (inherited fromBreakdownElementRevision)

Implementations
This class implements the following <<extend>> interfaces:−

AnalysisCandidateItem (inherited from BreakdownElementRevision).
Refer to Para 3.21−−

BreakdownElementInZoneItem (inherited fromBreakdownElementRevision). Refer to Para 3.41
ChangeControlledItem (inherited from BreakdownElementRevision).
Refer to Para 3.4

−
−
−
−

DetectionMeansAlarmItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
DigitalFileReferencingItem (inherited fromBreakdownElementRevision). Refer to Para 3.10
DocumentReferencingItem (inherited from BaseObject). Refer to Para 3.11
FailureModeAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.14

Applicable to: All

DMC-S3000L-A-19-00-0000-00A-040A-A
Chap 19

DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

2021-04-30 Page 196

S3000L-B6865-03000-00−−−

InServiceOptimizationAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.18
MeasurementPointDefinitionItem (inherited fromBreakdownElementRevision). Refer to Para 3.16
OrganizationReferencingItem (inherited from BaseObject). Refer toPara 3.24−−

PerformanceParameterItem (inherited fromBreakdownElementRevision). Refer to Para 3.26
ProjectSpecificExtensionItem (inherited from BaseObject). Refer to
SX002D−−

RemarkItem (inherited from BaseObject). Refer to Para 3.31
TaskAnalysisItem (inherited from BreakdownElementRevision). Refer toPara 3.39−

TaskRequirementAnalysisItem (inherited fromBreakdownElementRevision). Refer to Para 3.37

DMC-S3000L-A-19-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-19-00-0000-00A-040A-A_003-00_EN-US

Chap 192021-04-30 Page 197

S3000L-B6865-03000-00

Chapter 20
Data exchange
Table of contents
1
1.1
1.2
2
2.1
2.1.1
2.1.2
3
4

Page

General ............................................................................................................................ 1
Purpose ........................................................................................................................... 2
Scope ............................................................................................................................... 2
Overview .......................................................................................................................... 2
S3000L data exchange .................................................................................................... 2
Data flow from other disciplines to LSA ........................................................................... 2
Data flow from LSA to other disciplines or stakeholders ................................................. 3
S3000L XML schemas .................................................................................................... 3
Product Life Cycle Support (PLCS) ................................................................................. 4

List of tables
1

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

List of figures
1
2

Data exchange using S3000L XML schemas ................................................................. 2
ASD XML schema to PLCS implementation mapping .................................................... 4

References
Table 1 References
Chap No./Document No.

Title

Chap 19

Data model

SX005G

S-Series ILS specification XML schema implementation guidance

http://www.plcs.org/plcslib/plcslib/

PLCS Platform Specific Model (PSM)

http://www.s3000l.org

S3000L website

ISO 10303-239 PLCS

Product Life Cycle Support (PLCS)

1

GeneralThis chapter defines the standard technology used for the exchange of data that results from
Logistics Support Analysis (LSA) as defined in S3000L. The exchange of data for S3000L is
defined using XML and XML schema.
It is also possible to use the XML schema to receive data from sources, which provide input tothe S3000L process.
S3000L XML schemas are published separately on the S3000L website (www.s3000l.org).

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

1.1

PurposeThe purpose of this chapter is to describe how the S3000L XML schemas support the S3000L
LSA process and its interaction with other business processes.

1.2

Scope
The following areas are within scope for this chapter:−−−overview of S3000L data exchange using S3000L XML schemas
overview of the defined S3000L XML schemas
relationship between S3000L XML schemas and ISO 10303-239 PLCS

2

Overview

2.1

S3000L data exchange
Fig 1 provides an example of the types of data exchange supported by the S3000L XML
schemas:ICN-B6865-S3000L0236-003-00
Fig 1 Data exchange using S3000L XML schemas
2.1.1

Data flow from other disciplines to LSA
From product design and development to LSA, examples on types of data exchange using the
S3000L XML schema, which can feed the S3000L activities, can contain the following
information:

Applicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00−

Product breakdown can include, but is not limited to the following information on:
•
•
•
•
•

−

part data can include, but are not limited to, the following information on:
•
•
•
•
•

−

2.1.2

part identifiers (eg, part numbers)
part names
technical characteristics
parts lists, Bill of Material (BOM)
operational authorized life

Failure Modes and Effects Analysis (FMEA) data can include identified failure modes
defined for parts that can require the identification of corrective maintenance tasks

Data flow from LSA to other disciplines or stakeholders
The identified types of data exchange (refer to Fig 1) contain the following information:−−−−

the entire dataset (from LSA to external partners) contains the complete LSA dataset
LSA candidate list (from LSA to the customer) includes information on selected LSA
candidates and recommended (agreed upon) analysis activities
failure mode groups (from LSA to the customer) include information about how to justify therecommended corrective maintenance tasks
task requirements (from LSA to customers and product development, ie engineering andsupport engineering), includes, but is not limited to, information on:
•
•
•

−

task requirement specification
task requirement authority
task limit requirements

task data (from LSA to the customer, technical publication, training, material support and inservice data feedback) include, but is not limited to, information on:
•
•
•
•

3

the Product that requires support and its Product variants
breakdowns defined for the Product, including its breakdown elements (eg, systems,
functions, hardware, software, zones)
possible breakdown element realizations in terms of hardware or software
allowed Product design configurations
key performance parameters defined for the Product and its included elements

task identification
task justificationsubtasks
task resources

S3000L XML schemas
The S3000L XML schemas are derived from the S3000L data model defined in Chap 19. The
mapping of the S3000L data model to the S3000L XML schemas complies with the XML
schema authoring rules defined by the Data Model and Exchange Working Group (DMEWG).
The option to only exchange updates is one of the defined features for the exchange of LSA
data using the XML schemas for S3000L. Apart from complete (baseline) messages, it ispossible to send update messages, which can accommodate minor, as well as major, changes
to the LSA data. This means that the receiver of LSA data does not need to analyze what
actions to take with respect to updating the target data set (eg, database). For more information,refer to SX005G.
Another additional feature in the XML schemas for S3000L is the support of project-specificattributes, as described in Chap 19. This allows for projects to add data elements required forApplicable to: All

S3000L-A-20-00-0000-00A-040A-A
Chap 20

DMC-S3000L-A-20-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

the project, but which are not part of the S3000L data model and its associated XML schemas.
For more information, refer to SX005G.

4

Product Life Cycle Support (PLCS)
S3000L XML schemas will provide mappings to ISO 10303-239 PLCS (ed3) in order to support
continued use of ISO 10303-239 PLCS. Because of their design, these mappings will form an
integral part of the respective S3000L XML schemas.
In awaiting ISO 10303-239 PLCS (ed3) and its associated data exchange development
environment, all S-Series IPS specifications follow the same XML schema approach as definedfor S3000L. Fig 2 illustrates how to consider an S-Series IPS specification XML schema withrespect to ISO 10303-239 PLCS and OASIS PLCS Platform Specific Model (PSM).

ICN-B6865-S3000L0237-002-00
Fig 2 ASD XML schema to PLCS implementation mapping
The S-Series IPS specifications XML schemas aim to support data exchange at the Business
Object Model (BOM) layer. Future XML schema will also include the mapping details required
for an unambiguous mapping to PLCS of each element and attribute, in order to enable PLCSbased data exchange and/or PLCS-based data consolidation.

S3000L-A-20-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-20-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 202021-04-30 Page 4

S3000L-B6865-03000-00

Chapter 21
Terms, abbreviations and acronyms
Table of contents

Page

Terms, abbreviations and acronyms .............................................................................................. 1
References ..................................................................................................................................... 1
1
General ............................................................................................................................ 1
1.1
Purpose ........................................................................................................................... 1
1.2
Scope ............................................................................................................................... 1
2
Glossary of terms............................................................................................................. 1
3
General considerations for the list of abbreviations and acronyms ............................... 14
3.1
Word combination - acronym......................................................................................... 14
3.2
Tense and number ........................................................................................................ 14
3.3
Abbreviation and acronym list ....................................................................................... 14

List of tables
1
2
3

References ...................................................................................................................... 1
Glossary of terms............................................................................................................. 2
Abbreviations and acronyms ......................................................................................... 14

References
Table 1 References
Chap No./Document No.

Title

None

1

General

1.1

PurposeThis chapter provides a comprehensive dictionary for the terms, abbreviations and acronyms
used throughout S3000L.

1.2

Scope
This chapter comprises a comprehensive dictionary of the terms, abbreviations, and acronyms(including initialisms and portmanteaus) used throughout this specification.

2

Glossary of terms
Table 2 provides the definitions of terms used throughout this specification.

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

Table 2 Glossary of terms
Term

Definition

allowed Productconfiguration

An approved combination of hardware and software parts that canor must be installed in specific locations or positions, and a set of
associated engineering instructions to follow during assembly andoperation. The allowed Product configuration demonstrates that a
Product complies with applicable regulations.

alternate part

A part that can replace another part for any purpose, is context
independent, and is equivalent to the original part in form, fit andfunction.
−

Refer to form, fit and function

availability

When the mission or operation is called for at an unknown time,
availability measures the extent to which an item is in an operable
and ready-for-use state at the start of a mission or operation.

Bill of Material (BOM)

A comprehensive list of the raw materials, assemblies,
subassemblies, parts, and components needed to manufacture a
Product, along with the quantities of each.

breakdown

A view of a Product that identifies the specific partitioning of the
Product into a set of related elements, forming parent-child viewsof Product elements.

Breakdown Element(BE)

A definition of an item used to represent a system, subsystem,function, zone, hardware item, or any other type of Productpartitioning. A breakdown element may be a member of one ormore breakdowns.

Breakdown Element
Identifier (BEI)

Identifies an individual breakdown element defined within afunctional, physical, or any other type of Product breakdown. In thecase of a physical breakdown element, there is also an indicationof the installation location.

breakdown element
realization

The combination of a hardware or software item with a breakdown
element and its associated installation location.
−

Refer to realization

Breakdown Element
Revision (BER)

Defines a specific release of a breakdown element.

Breakdown Revision(BR)

Defines a specific release of a breakdown.

−−

Refer to revision

Refer to revision

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Term

Definition

Built-In Test (BIT)

An integrated testing method implemented in an item. Usually,
three types of BIT are implemented:−

Power-on BIT (P-BIT), which is executed when the item
starts up−

Continuous BIT (C-BIT), which is executed periodicallyduring the operation of the item, without any intervention
from the operating crew−

Initiated BIT (I-BIT), which is executed on demand by theoperator or maintainer

Each of these tests detects specific categories of failures,characterized by:−

A detection rate, which is the percentage of functions or
items whose failure is detected−

A localization rate, also known as an isolation rate, whichis the percentage of detected failures that are associatedwith the failure of a replaceable unit, which is identified
unambiguously−

A false alarm rate, which is the percentage of positive tests
that do not actually represent a failure

The intent of a BIT is to detect failures and localize replaceable
units that have failed. Localization can be either non-ambiguous orambiguous.
−

A non-ambiguous failure means it is possible to attributethe failure to a specific item with an acceptable degree ofcertainty−

An ambiguous failure can be attributed to a group of
replaceable parts without certainty as to which specific partin the group has failed

The goal of troubleshooting analysis is to remove the ambiguity
behind common or critical failures. For critical failures, the BIT
typically issues a warning or alarm message to the operator.
Built-in Test
Equipment (BITE)

Test equipment permanently installed in the Product, for the
express purpose of testing the Product.
−

Refer to General Purpose Test Equipment (GPTE), special
test equipment, test equipment

Candidate Item (CI)

An item identified as requiring analysis through the LSA process.

Candidate Item List
(CIL)

A list of the candidate items that serves as documentation of the
LSA candidate selection process.
−Chemical Abstracts
Service (CAS)identification number

Refer to Candidate Item (CI)A unique identifier of a substance, suitable for lookup in the CAS
database. It is often referred to as the CAS number.

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

Term

Definition

Commercial Off-TheShelf (COTS)

Software or hardware that is ready-made and available for sale,lease, or license to the public. This term is typically used inreference to technology products.

common cause

A failure cause which results in multiple related failures. For
example, the failure of a power supply leads to the failure of all
items to which it supplies power. When analyzing all of thesefailures together, the detected common cause is the failure of thepower supply.

Concept ofOperations(CONOPS)A document describing the characteristics of a proposed Productfrom the perspective of a Product user. It is used to communicate
the desired Product characteristics to all stakeholders, in both aquantitative and qualitative manner.

consumable

A non-repairable item, typically purchased and stocked in bulk, andis disposable (eg, fluids, grease, screws, O-rings).

corrective
maintenanceA maintenance activity carried out to restore a malfunctioning item
to its full functionality.

CustomerRequirements
Document (CRD)

A document containing all of the customer’s supportability
requirements. The CRD is a necessary input for the LSA Guidance
Conference (LSA GC).

damageA loss or reduction of functionality, not including failures due to theintrinsic reliabilities of an item. Normally, damage will require amaintenance task to restore the damaged item to its fullfunctionality. Different types of damage (ie, ways in which an item
can be damaged) are often grouped into families, which are
addressed by a standard repair procedure. For example, astructure can have scratches, dents, and/or cracks, but it ispossible to define a single standard repair procedure for any such
structural damage.

Data and
Assumptions
Definition Document(DADD)

A document containing the ground rules and assumptions for Life
Cycle Cost (LCC) analysis. This includes organizational, program,technical and economic data.

dangerous substanceA substance known to harm people and/or the environment.

Data Element List
(DEL)

A list of selected data elements, generally given by the output of adata element tailoring process. This list contains all the data
elements required for a project, and is not necessarily limited todata elements pre-defined by any particular information standard.

defectAny nonconformity of an item to its specified requirements. A
defect does not necessarily result in a failure of the item.
−

Refer to failure

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

Term

Definition

definition files

Support files related to an item, such as technical descriptions,interface definitions, wiring diagrams or protocols.
Definition files can be useful when it becomes necessary to carryout functional or electrical tests to help isolate the failed item if theperformance of simple troubleshooting fails to do so.

demilitarization

An operation that makes a defense Product unavailable or
unsuitable for its intended military use.

deviation

The authorization to deviate from a particular requirement of an
approved Product/equipment configuration for a specified period.
Deviations allow the acceptance of a Product/equipment that does
not fully meet a particular requirement, but is considered suitablefor use either as-is, after repair, or after modification by anapproved method.

Diminishing
Manufacturing
Sources (DMS)

The loss or impending loss of item manufacturers or suppliers.

Diminishing
Manufacturing
Sources and Material
Shortages (DMSMS)

The loss or impending loss of item manufacturers, suppliers, or
raw materials.

directly replaceable

A hardware and software element categorization that indicates theitem is directly replaceable on the Product.

−−−
disposal

Refer to disposal process

Refer to disposal, disposal phase

A code used to identify a Product in several logistics product data
specifications, for example, refer to GEIA-STD-0007.
−

external cause

Refer to disposal phase, disposal process

A set of tasks to be performed on the Product in order to achieve
the disposal of the Product when it reaches the end of its service
life. It is necessary to consider the disposal process from the very
early phases of every project in which a Product is acquired, eventhough it is performed at the very end of the Product life cycle.
−

End Item Acronym
Code (EIAC)

Refer to not directly replaceable, non-replaceable

The final phase of the Product life cycle, in which the disposal of
the Product is achieved.
−

disposal process

Refer to Diminishing Manufacturing Sources (DMS)

The act of ending the service life of a Product.
−

disposal phase

Refer to Diminishing Manufacturing Sources and Material
Shortages (DMSMS)

Refer to Product

A cause due to an event independent of normal Product usage,
such as a bird strike for an aircraft.
−

Refer to internal cause, special event

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

Term

Definition

facility

A place suited for a particular purpose, such as repair,maintenance, training, or other supportability activities.

failureA failure occurs when an item does not perform to the level
required by its performance specification under normal use andprevents further use of the item.

failure cause

Any circumstance leading to a particular failure that occurred
during Product design, manufacture or use.

failure detection

The method by which an operator becomes aware of a failure.

failure mode

The end result of a predicted or observed physical, mechanical,
thermal or other process whose end result can or has led to a
failure. The failure mode is stated relative to the operating
conditions at the time of the failure.

failure rate

The probability of a failure occurring. It is expressed in failures perunit of operating time.

Failure Modes andEffects Analysis(FMEA)A procedure for analyzing the potential failure modes of a system
to classify them by severity, or to determine the effect of lowerlevel failures on the entire system.

Failure Mode, Effects,
and Criticality
Analysis (FMECA)

An extension of a FMEA that also includes a criticality analysis.
The purpose of a criticality analysis is to chart the probability of
failure modes against the severity of their consequences. It isconstructed by calculating how probable it is for each particularfault in each particular item to have caused each failure mode. The
severity of the consequences of each fault is used to determine theremedial action required to correct the fault and return the item toservice.

fault

A physical condition that causes a device, a component, or anelement to fail to perform in accordance with the item
requirements.

fault isolation
procedure

The process of determining the location of a fault to the extent
necessary to repair the faulty item.

Field Loadable
Software (FLS)

Software that can be installed into one or several pieces ofequipment of a Product, without the need to remove the equipmentfrom its installed location.
−

firmware

Refer to firmware, Shop Loadable Software (SLS)Software that can be loaded into a Line Replaceable Unit or Shop
Replaceable Unit, but requires the host component to be removed
from its installation location on the operational system andsubsequently replaced.
−

Refer to Field Loadable Software (FLS), Shop Loadable
Software (SLS)

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

Term

Definition

form, fit and function

The physical parameters (form), physical interface (fit) andperformance requirements (function) of an item. Usually, thisphrase is used to express the suitability of a similar item that, if itwere to replace the original item in a Product or piece ofequipment, it would not alter the performance characteristics ofthat Product or piece of equipment.

functional analysis

The identification and characterization of the functions performedby the Product, systems, subsystems and sub-subsystems.
It is possible to characterize each system function using theparameters that:−it takes as inputs−

it requires as part of its operation−

it provides as outputs

The outputs provided by the characterization justify the inclusion of
the items in the design. The results of the functionality analysis areused to identify the effect of a failed physical item or items on otherassociated functions. The results also indicate the detection
methods and corrective actions required to prevent failure, andensure the continuity or restoration of the item’s intended
functionality.
functional breakdown

functional symptom

A functional breakdown refers to the partitioning of functions
typically provided by the Product from a user or operator point ofview. For example, an aircraft’s functional breakdown can include
elements for taxiing, take off, flying, or landing.
−

Refer to system breakdown−

Refer to symptom

General Purpose Test
Equipment (GPTE)

Test equipment that is not limited to a specific test application.

Guidance Conference(GC)

A conference where the contractor and the customer agree on thescope and depth of the LSA business processes and procedures.

Guidance Document(GD)

A signed, contractual record of the agreements reached by thecontractor and the customer during the LSA GC.

hardware element

A BE representing a specification realized as a hardware part.

infrastructure

An overarching term for all resources required for an activity but
not specified. For example, “facilities and infrastructure” includes
the subject facilities, and any other improvements required to use
the facilities, such as roads or utilities.

−

Refer to Built-In Test Equipment (BITE), special test
equipment, test equipment

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Term

Definition

Integrated Logistics
Support (ILS)

An integrated and iterative process for developing material and a
support strategy that optimizes functional support, leverages
existing resources, and guides the system engineering process toquantify and lower life cycle cost and decrease the logistics
footprint (ie, the demand for logistics), making the system easier tosupport.
−

Refer to Integrated Product Support (IPS)

NoteIntegrated Logistics Support (ILS) has been replaced byIntegrated Product Support (IPS).
Integrated ProductSupport (IPS)

An integrated and iterative process for developing material and a
support strategy that optimizes functional support, leverages
existing resources, and guides the system engineering process toquantify and lower life cycle cost and decrease the logistics
footprint (ie, the demand for logistics), making the system easier tosupport.
−internal cause

Refer to Integrated Logistics Support (ILS)

A cause due to an event that results from normal Product usage,(eg, excessive vibration).
−

Refer to external cause, special event

Key Performance
Indicator (KPI)

A crucial Product requirement, expressed in a quantitative manner.

labor time

The accumulated time of personnel working on an entire task or anindividual subtask. If the persons involved are of different
competencies, the labor time is reported separately for each areaof competency.

Level of Repair
Analysis (LORA)

An analytical methodology performed on a list of selected LSA
candidates to determine an optimized maintenance solution. It
takes into consideration customers’ support and operational
requirements, Product technical information, economic aspects,
and legal and environmental constraints. The outcome indicates atwhich maintenance level each selected item must be removed,
replaced, repaired, checked, overhauled, inspected or discarded.

life cycle

The total lifespan of a Product, from its initial feasibility phasethrough its service, withdrawal, and disposal phases.

Life Cycle Cost (LCC)

All direct costs plus any indirect-variable costs associated with theprocurement, operations, support and disposal of the Product.
−

Refer to Total Cost of Ownership (TCO), Whole Life Cost
(WLC)Line Replaceable Unit
(LRU)

An item that can be removed and installed at the organizational
maintenance, or field level. Synonymous with “Weapon
Replacement Assembly (WRA)” and “module replaceable unit”.

localization

Failure isolation that indicates the item or group of items that havefailed. This isolation is usually associated with a failure detection.

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

Term

Definition

Logistics Support
Analysis (LSA)

A structured approach to increasing maintenance efficiency andreducing the cost of providing support by planning all aspects of
IPS as far in advance as possible.

LSA candidate item−

Refer to Candidate Item (CI)

LSA database

A database that records the supportability data gathered throughthe LSA process. Historically synonymous with “Logistics Support
Analysis Record (LSAR)” and “Logistics Product Database”.

LSA Guidance
Conference (LSA GC)

A conference where the contractor and the customer agree on thescope and depth of the LSA process and procedures.

maintainability

A measure of the ability of an item to be retained in, or restored toa specified condition, when maintenance is performed usingprescribed procedures and resources at each prescribed level ofmaintenance and repair.

maintenance concept

A strategy for providing maintenance support to ensure that a
Product meets its mission performance requirements.

maintenance planA plan for conducting maintenance in the most efficient and costeffective way, such that the Product performs as intended to meetits mission requirements. The maintenance plan also ensures that
all required maintenance resources are in place to support the
deployment of the Product.
The maintenance plan specifies the time, place and method for the
performance of maintenance tasks on the Product/equipment,
including both preventive and corrective maintenance.

Maintenance Task
Analysis (MTA)

A detailed analysis process that results in the identification of theprocedures, spares and materials, tools, support equipment,
personnel skill levels, facilities, and estimated and elapsed times,that it is necessary to consider for each corrective, repair or
preventive maintenance task.

MaintenanceRelevant Item (MRI)

An item that can be repaired or replaced in case of a failure ordamage. Normally, this item is automatically a potential LSA
candidate, but not necessarily a Maintenance Significant Item
(MSI).
−

Refer to LSA candidate, Maintenance Significant Item
(MSI)

MaintenanceSignificant Item (MSI)

An item identified by any selection process to be the result of aPreventive Maintenance Analysis (PMA) procedure (eg, describedin S4000P). An MSI can become an LSA candidate if the PMA
process identifies Preventive Maintenance Task Requirements
Interval (PMTRI) documented in the LSA database. Refer toS4000P.

Mean Elapsed Time(MET)

The average time required to complete a task, irrespective of thenumber of personnel involved. The duration of the whole task isthe sum of the time required to perform each of the subtasks andthe referenced supporting tasks.

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Term

Definition

Mean Time Between
Failures (MTBF)

MTBF is the predicted elapsed time between inherent failures of asystem during operation. It is calculated as the arithmetic mean
(average) time between failures of a system. The MTBF is typicallypart of a model that assumes the failed system is immediately
repaired (zero elapsed time) as a part of a renewal process. In
contrast, the Mean Time To Failure (MTTF) measures the averagetime between failures with the modeling assumption that the failed
system is not repaired.

non-replaceable

A hardware and software element categorization that indicates anitem is intrinsically related to another item and cannot be replaced
separately.
−

not directly
replaceable

Refer to directly replaceable, not directly replaceable

A hardware and software element categorization that indicates anitem is not directly replaceable on the Product without the removalof the parent assembly.
−

Refer to directly replaceable, non-replaceable

Operational
Requirements
Document (ORD)

Defines the operational requirements in a qualitative way for the
Product, and must be available for the LSA GC.

operational supporttask

Any support activity that resolves a task requirement in the context
of the Product operation, but that does not relate to the areas ofthe direct operation or maintenance of the Product. For example,
Packaging, Handling, Storage and Transportation (PHST) tasks
are operational support tasks.

parts list−

Refer to Bill of Material (BOM)

personnel

People with specific human aptitudes, knowledge, skills, abilities
and experience levels needed to perform Product operation andsupport tasks properly.

physical breakdown

A breakdown of the Product hardware and software based on theengineering design model/drawings.

physical symptom−

Refer to breakdown−

Refer to symptom

preventive
maintenance

Maintenance activities for preventing critical failures or damage inconjunction with safety, economical or ecological considerations.
The term “preventive maintenance” also includes activities
performed after special events, even though the occurrence of
these events, chronological intervals between them, and othertypical thresholds cannot be defined.

Preventive
Maintenance Analysis(PMA)

The method used to determine the Preventive Maintenance Task
Requirements (PMTR) and their intervals/thresholds.

Product

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

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

Termproduct breakdown

Definition−

Refer to breakdown

product variant

A member of a Product family that is configured for a specificpurpose and is offered to customers.

project

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

realization

The completion of a physical breakdown from a design breakdown,
including different physical systems, subsystems or componentsthat can be used for the same installed location.

rectifying task

A rectifying task is any support activity that resolves an issue, suchas failures, damages, special events, or thresholds.

reliability

The duration or probability of failure-free performance of a Productunder stated conditions, or the probability that an item can perform
its intended function for a specified period under stated conditions.

Reliability Centered
Maintenance (RCM)

A disciplined logic or methodology used to identify scheduled
maintenance tasks in order to maintain the inherent reliability ofequipment, with a minimum expenditure of resources.

revision

A particular version of something that is undergoing an iterative
process. The BR and BER capture the design iterations of a
Product, the compilation of which represents a record of the
Product’s development progress. The use of these revisions
supports the Configuration Management (CM) discipline,
particularly with regard to the synchronization of changes
originating from the Product design process, and their effect on the
LSA process.
−

Refer to Breakdown Revision (BR), Breakdown Element
Revision (BER)

scheduledmaintenance

Maintenance activities that prevent the occurrence of critical
failures or damages in conjunction with safety, economical or
ecological aspects. These maintenance tasks have acorresponding interval or threshold (eg, after a certain amount ofelapsed time, cycles completed, rounds expended, or distancetraveled). Scheduled maintenance is a subset of preventive
maintenance.

Shop Loadable
Software (SLS)Software that can be installed on an LRU, but which requires thetarget LRU to be removed from the system where it is installed.
−

Shop Replaceable
Unit

An item that requires a maintenance level higher than theorganizational level for replacement.
−

Software Support
Analysis (SSA)

Refer to Field Loadable Software (FLS), firmware

Refer to Line Replaceable Unit (LRU)

The method used to identify a cost-effective Software Support
Concept (SSC).
−

Refer to Software Support Concept (SSC)

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

Term

Definition

Software Support
Concept (SSC)

A strategy for providing operational and maintenance support tosoftware items. This includes the identification of all equipment,
tools, personnel, documentation, infrastructure, skills, training andmodification required to enable the continued usage of thesoftware within the Product.

spare part

A part not installed on the Product and reserved for installation on
the Product during the performance of future maintenance tasks.

special event

An event that occurs during a Product’s life that is not part of thenormal operation of the Product. A special event is generally due
to either an external cause or the use of the Product outside its
prescribed operating boundaries (such as the result of an over-G
maneuver of an aircraft).
−

Refer to external cause, internal cause

special test
equipment

Test equipment designed for a specific application.

Structural Detail (SD)A localized area of a Structure Significant Item (SSI). Refer toS4000P.

−−

Refer to Built-in Test Equipment (BITE), General Purpose
Test Equipment (GPTE), test equipment

Refer to Structure Significant Item (SSI)

Structural Item (SI)

Any part of the Product structure.

Structure Significant
Item (SSI)

An SI or assembly that is significant due to its requirement to carryhigh aerodynamic, ground, pressure, or control loads, and whose
failure could affect the structural integrity necessary for Productsafety, human safety, legal operation or environmental integrity.
Refer to S4000P.

substitute part

A part that can replace another part in a specific use. The ability to
use a part as a substitute is context-dependent, and is notnecessarily a form, fit and function equivalent.
−

Refer to form, fit and function

supply chain

All organizations directly or indirectly involved in fulfilling acustomer support requirement.

supply chain
management

The process of planning, implementing and controlling theoperations of the supply chain as efficiently as possible.

supply support

Methods, practices and procedures used to determine therequirements of goods and services, as well as their acquisition,
receipt, storage, issuance, and final disposal.

support equipment

Equipment required to support the operation and maintenance of a
Product.

supportability

The measure of the extent to which all resources required tooperate and maintain the Product are properly designed andprovided in sufficient quantity.

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

Term

Definition

supporting task

A supporting task is a part of a complete rectifying or operational
support task. Supporting tasks alone cannot rectify issues such as
failures, damages, special events or thresholds.

symptom

Evidence of an abnormality directly or indirectly related to thepresence of a fault.

system breakdown−

A functional symptom may be observed during a functional
check and/or by observing the failure of an item associatedwith the function.

−

A physical symptom may be observed by visual inspection,measurement of a wear-out parameter, material
degradation or by other means. It is detectable and/or
measurable regardless of the state of operation of thesystem.

A system breakdown refers to the partitioning of a Product into a
set of systems and subsystems from an engineering point of view.
−

Refer to functional breakdown

system of systems

A collection of Products, each capable of independent operation,that operate together to enable more advanced capabilities.

task requirement

The determination that a task is necessary to meet supportability
requirements.

task resource

Any item necessary to complete a task, such as personnel, spareparts, consumables, raw material, support equipment, facilities ordocuments.

technical data

All data describing the handling, maintenance, functionality andarchitecture of a Product.

testability

A design characteristic that allows the status of an item (operable,
inoperable, or degraded) to be determined, and the location of any
faults and/or failures within the item with a high degree of certainty
and in a timely manner.

test equipment

Equipment used to enable or facilitate troubleshooting.
−

Refer to Built-in Test Equipment (BITE), General Purpose
Test Equipment (GPTE), special test equipment

Training Needs
Analysis (TNA)The process used to identify the training requirements for
operational and maintenance activities.

Total Cost of
Ownership (TCO)

All elements that are part of the LCC, plus the indirect, fixed, andlinked costs, such as common support equipment, common
facilities, personnel required for unit command, administration,
supervision, operations planning and control, fuel, and munitions
handling. The TCO represents all costs associated with theownership of a system, except for non-linked fixed costs that are
related to the running of the organization.
−

Refer to Life Cycle Cost (LCC), Whole Life Cost (WLC)

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

Term

Definition−

toxic substance
troubleshooting

The process of localizing failed replaceable units when their failure
is not obvious or localized by other means such as through a builtin test. Troubleshooting is carried out after a failure has been
detected.

Usable On Code
(UOC)

Analogous to a model identifier in several Logistics Product Data
Specifications, for example, refer to GEIA-STD-0007.
−

Whole Life Cost
(WLC)

Refer to product variant

All elements that are a part of the TCO, plus indirect, fixed, andnon-linked costs, such as family housing, medical services,
ceremonial units, basic training, headquarters and staff, academies
and recruiters.
−

3

Refer to dangerous substance

Refer to Life Cycle Cost (LCC), Total Cost of Ownership(TCO)

General considerations for the list of abbreviations andacronyms
Whenever in doubt regarding the intelligibility of an abbreviation or acronym, and whenever
there is ample space in the document, write the term in full.

3.1

Word combination - acronym
Abbreviations and acronyms that represent combinations of words must be used as shown
unless otherwise authorized. Individual parts of abbreviations or acronyms must not be used
independently unless those parts are defined as acronyms themselves. Acronyms may be
combined if necessary, even if there is no acronym listed for the combination.

3.2

Tense and number
Abbreviations and acronyms are used consistently throughout this specification to represent all
instances of the relevant term, whether it is used in the singular or in the plural form.

3.3

Abbreviation and acronym list
Table 3 provides the definitions of abbreviations and acronyms used throughout thisspecification.
Table 3 Abbreviations and acronyms
Abbreviation /acronymDefinition

A

Availability

acid

Acidification

AIA

Aerospace Industries Association of America

ALC

Alternate Logistics Support Analysis Control Number

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

AOR

Annual Operating Requirements

ASD

AeroSpace and Defence 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

BOM

Bill of Material

BPR

Biocidal Products Regulations

BR

Breakdown Revision

CAD

Computer-Aided Design

CAGE

Commercial and Government Entity

CAS

Chemical Abstracts Service

CAT

Substance Category

CBS

Cost Breakdown Structure

CDR

Critical Design Review

CDRL

Contracted Data Requirement List

CFC

Chlorofluorocarbon

Chap

ChapterCI

Candidate Item

CIL

Candidate Item List

CLP

Classification, Labeling, and Packaging

cm

Centimeter

CM

Configuration Management

CMR

Certification Maintenance Requirement

CONOPS

Concept of Operations

COTS

Commercial Off The Shelf

CRD

Customer Requirements Document

CSC

Computer Software Configuration

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

CSCI

Computer Software Configuration ItemDA

Design Authority

DADD

Data and Assumptions Definition Document

DEL

Data Element List

DEX

Data Exchange Specification

DLM

Depot Level Maintenance

DMC

Data Module CodeDMS

Diminishing Manufacturing Sources

DMSMS

Diminishing Manufacturing Sources and Material Shortages

DoD

Department of Defense

DRACAS

Data Reporting and Corrective Action System

EBOM

Engineering Bill of MaterialEC

European Community

EIAC

End Item Acronym Code

ELORA

Economical Level of Repair Analysis

ELV

End-of Life Vehicle

eneEnergy regaining by burning

FFE

Functional Failure Effect

FFEC

Functional Failure Effect Code

Fig

FigureFLS

Field Loadable Software

FMA

Failure Modes Analysis

FMDR

Failure Mode Distribution Ratio

FMEA

Failure Modes and Effects Analysis

FMECA

Failure Modes, Effects and Criticality Analysis

FMG

Failure Mode GroupFMR

Failure Mode Ratio

FPGA

Field Programmable Gate Arrayftfoot/feet

FTA

Fault Tree Analysis

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

GC

Guidance Conference

GD

Guidance Document

GEIA

Government Electronic and Information Technology Association

GFE

Government Furnished Equipment

GPTE

General Purpose Test Equipment

GSE

Ground Support Equipment

GVI

General Visual Inspection

gwp

Greenhouse effect

HCFC

Hydro chlorofluorocarbon

HFES

Human Factors and Ergonomics Society

HIRF

High Intensity Radiated Field

HUMS

Health and Usage Monitoring System

HVAC

Heating, Ventilation, and Air Conditioning

HW

Hardware

IAEA

International Atomic Energy Agency

IATA

International Air Transport Association

ICN

Information Control Number

ILC

Item Location Code

ILS

Integrated Logistics Support

IMO

International Maritime Organization

IPS

Integrated Product Support

ISMO

In-Service Maintenance Optimization

ISO

International Organization for Standardization

ISSO

In-Service Support Optimization

IT

Information Technology

IUA

Item Under Analysiskg

kilogram

KPI

Key Performance Indicator

LAN

Local Area Network

lb

pound

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

LCC

Life Cycle Cost

LCCBS

Life Cycle Cost Breakdown Structure

LCN

Logistics Support Analysis Control Number

LORA

Level of Repair Analysis

LRU

Line Replaceable Unit

LSA

Logistics Support Analysis

LSA GCLSA Guidance Conference

LSA PPLSA Program Plan

LSA RCLSA Review Conference

LSAR

Logistics Support Analysis Record

m

Meter

MDT

Mean Maintenance Down Time

MET

Mean Elapsed TimeML

Maintenance Level

MoD

Ministry of Defence

MoU

Memorandum of Understanding

mrMaterial recycling

MRI

Maintenance Relevant Item

MRO

Maintenance, Repair and Overhaul

MSDS

Material Safety Data Sheet

MTA

Maintenance Task Analysis

MTBF

Mean Time Between Failures

MTBM

Mean Time Between Maintenance

MTBUR

Mean Time Between Unscheduled Removal

MTTF

Mean Time To Failure

MTTR

Mean Time To Repair

mw

Material waste

NATO

North Atlantic Treaty Organization

NEA

Nuclear Energy Agency

NFF

No Fault Found

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

O&S

Operating and Support

OECD

Organization for Economic Co-operation and Development

OEM

Original Equipment Manufacturer

OH

Operating Hour

OM

Obsolescence Management

OMP

Operator Maintenance Plan

ORD

Operational Requirements Document

ozon

Dangerous for ozone layer

Para

Paragraph

PBS

Product Breakdown Structure

PDF

Product Disposal File

PDM

Product Data Management / Product Design Management

PDR

Preliminary Design Review

PE

Planned Event

PHST

Packaging, Handling, Storage and Transportation

PI

Part Identifier

PLCS

Product Life Cycle Support

PLM

Product Lifecycle Management

PMA

Preventive Maintenance Analysis

PMP

Preventive Maintenance Program / Preventive Maintenance Plan

PMTR

Preventative Maintenance Task Requirement

PMTRE

Preventive Maintenance Task Requirement Event

PMTRI

Preventive Maintenance Task Requirement IntervalPOP

Persistent Organic Pollutants

posEnvironmental aspects, positive

PP

Program Plan

PSA

Product Support Analysis

RAMT

Reliability, Availability, Maintainability and Testability

RC

Review Conference

RCM

Reliability Centered MaintenanceApplicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

REACH

Registration, Evaluation, Authorisation and Restriction of Chemicals

RFP

Request for Proposal

RMT

Reliability, Maintainability, Testability

ROHS

Restriction of (the use of certain) Hazardous Substances

ROM

Read-Only Memory

SBOM

Support Bill of MaterialSD

Significant Detail / Structural Detail

SDS

Safety Data SheetSI

Structural Item

SLA

Special Libraries Association

SLS

Shop Loadable Software

SMP

Scheduled Maintenance Program

SMR

Source, Maintenance, and Recoverability

SNSStandard Numbering System

SOW

Statement of WorkSRU

Shop Replaceable Unit

SSA

Software Support Analysis

SSC

Software Support Concept

SSI

Structural Significant ItemSW

Software

TBD

To Be Defined

TCO

Total Cost of Ownership

TF

Task Frequency

TNA

Training Needs Analysis

tox

Toxic, bioaccumulation, and/or difficult to decompose

UN

United Nations

UOC

Usable On Code

UoF

Unit of Functionality

US

United States

WAN

Wide Area Network

Applicable to: All

S3000L-A-21-00-0000-00A-040A-A
Chap 21

DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

Abbreviation /acronymDefinition

WBS

Work Breakdown Structure

WEEE

Waste from Electrical and Electronic Equipment

WLC

Whole-Life Cost

WRA

Weapon Replacement Assembly

XML

Extensible Mark-up Language

S3000L-A-21-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-21-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 212021-04-30 Page 21

S3000L-B6865-03000-00

Chapter 22
Data element list
Table of contents
1
2
3
4
5

Page

General ............................................................................................................................ 1
Classes ............................................................................................................................ 2
Class attribute list .......................................................................................................... 40
Valid values ................................................................................................................... 99
Valid value libraries ..................................................................................................... 118

List of tables
1
2
3
4
5

References ...................................................................................................................... 1
List of classes and interfaces .......................................................................................... 3
List of class attributes .................................................................................................... 41
List of valid values ......................................................................................................... 99
List of valid value libraries ........................................................................................... 118

References
Table 1 References
Chap No./Document No.

Title

Chap 19

Data model

S1000DInternational specification for technical publications using acommon source database

S4000PInternational specification for developing and continuously
improving preventive maintenance

SX001G

Glossary for the S-Series ILS specifications

SX004G

Unified Modeling Language (UML) model reader's guide

SX005G

S-Series IPS specifications XML schema implementation
guidance

ISO 3166-1

Codes for the representation of names of countries andtheir subdivisions – Part 1: Country codes

ISO 639:1988

Language codes

SAE-GEIA-STD-0007

Logistics Product Data (LPD)

1

GeneralThis chapter defines all data elements (classes, interfaces and attributes) and valid values thatare used in the S3000L data model, refer to Chap 19.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 1

S3000L-B6865-03000-00

2

Classes
The full list of S3000L classes and interfaces is provided in Table 2.
Table 2 is organized alphabetically by class and interface name, and contains:
−
−
−
−
−

Class/interface nameClass/interface type (refer to SX004G on more details on class and interfaces used in the
S-Series IPS specifications
Class/interface stereotype (refer to SX004G on more details on stereotypes used in the
S-Series IPS specifications)Class/interface definition
Unit of Functionality (UoF) identifies the section in Chap 19 where the class or interface isdefinedApplicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 2

S3000L-B6865-03000-00

Table 2 List of classes and interfaces
Class nameType

Stereotype

Definition

UoF

AdditionalTrainingNeed

Class

attributeGroup

AdditionalTrainingNeed is an <<attributeGroup>> that

S3000L UoF Task Resource

specifies additional learning required for the associatedCompetenceDefinitionItem in order to qualify as the
TaskPersonnelResource.

AggregatedElement

Class

class

AggregatedElement is a BreakdownElement that is a container for acollection of BreakdownElements which are grouped for an identified

S3000L UoF Aggregated Element

purpose.

AggregatedElementRevision

Class

class

AggregatedElementRevision is a BreakdownElementRevision
representing an iteration applied to an AggregatedElement.

S3000L UoF Aggregated Element

AllocatedTaskLocation

Class

class

AllocatedTaskLocation is a <<class>> that identifies where a Task

S3000L UoF Task Usageis to be performed in the context of a given support solution.

AllowedProductConfiguration

InterfaceextendAllowedProductConfiguration is an <<extend>> interface thatprovides its associated data model to those classes that must define permitted
combinations of hardware and software parts which can or must be installed in
specific locations (positions).

S3000L UoF Product Design
Configuration

Note
One and the same serialized product can adhere to different allowed
product configurations over time.
Note
An allowed product configuration can also include associated engineering
instructions that must be adhered to during assembly and operation and that
demonstrates that a product complies with applicable regulations.
Example−AllowedProductConfiguration
ByConfigurationIdentifier

Class

class

Applicable regulations may be a type certificate.

AllowedProductConfigurationByConfigurationIdentifier
is a <<class>> that defines an AllowedProductConfiguration by

S3000L UoF Product Design
Configurationmeans other than a part number.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 3

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

AllowedProductConfiguration
HardwarePartAsDesigned

Class

class

AllowedProductConfigurationHardwarePartAsDesigned is a
HardwarePartAsDesigned that is managed as an
AllowedProductConfiguration.

S3000L UoF Product Design
Configuration

AllowedProductConfiguration
Item

InterfaceselectAllowedProductConfigurationItem is a <<select>> interface

S3000L UoF Product Design
Configuration

AllowedProductConfiguration
sByConfigurationIdentifier

Class

that identifies items which can be selected as an allowed product configuration.
exchange

AllowedProductConfigurationsByConfigurationIdentifier
is a wrapper element that contains all instances of

S3000L UoF Logistics Support
Analysis Message Content

AllowedProductConfigurationByConfigurationIdentifierthat are in scope for a data exchange.

AlternatePartAsDesignedClassrelationship

AlternatePartAsDesigned is a <<relationship>> that defines analternate PartAsDesigned which can replace the base
PartAsDesigned in all its usages ie, it is context independent, and is form,

S3000L UoF Part Definition

fit, and function equivalent.
Note
A part can have one or more alternate parts. The alternate part isinterchangeable with the base part in any/all uses.

AnalysisActivity

Class

class

AnalysisActivity is a <<class>> that represents the objective for, andoutcome of, an analysis carried out for the AnalysisCandidateItem.

S3000L UoF LSA Candidate

AnalysisActivityRevision

Class

class

AnalysisActivityRevision is a <<class>> representing an iteration
applied to an AnalysisActivity.

S3000L UoF LSA Candidate

AnalysisCandidateItem

InterfaceextendAnalysisCandidateItem is an <<extend>> interface that provides its

S3000L UoF LSA Candidate

associated data model to those classes that can have an associatedAnalysisActivity.

AnalysisCandidateItemSelectionDataClass

Applicable to: All

attributeGroup

AnalysisCandidateItemSelectionData is an<<attributeGroup>> that summarizes decisions made for the
AnalysisCandidateItem from a support analysis activities perspective.

S3000L UoF LSA Candidate

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 4

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

ApplicabilityDefinitionData

Class

exchange

ApplicabilityDefinitionData is a wrapper element that contains all
instances of ApplicabilityStatement that are in scope for a data

S3000L UoF Logistics Support
Analysis Message Content

exchange.

ApplicabilityStatement

Class

class

ApplicabilityStatement is a <<class>> that defines the situation orsituations under which related items are valid.

ApplicabilityStatementItem

InterfaceextendApplicabilityStatementItem is an <<extend>> interface thatprovides its associated data model to those classes which can have restrictedvalidity as defined by an associated ApplicabilityStatement.

S3000L UoF Applicability
Statement
S3000L UoF Applicability
Statement

ApplicableDecisionTreeTempl
ate

Class

relationshipApplicableDecisionTreeTemplate is a <<relationship>> that
identifies a DecisionTreeTemplate which can be used for theDecisionTreeAnalysisItem.

S3000L UoF Decision Tree
Template Definition

AssociatedEnvironmentDefini
tion

Class

relationship

AssociatedEnvironmentDefinition is a <<relationship>>that associates an EnvironmentDefinitionItem with an
EnvironmentDefinition relevant to its existence, operation and/or

S3000L UoF Environment
Definition

support.

AuthorityDrivenTaskRequirem
ent

Class

attributeGroup

AuthorityDrivenTaskRequirement is an <<attributeGroup>>that collects information on the TaskRequirement, where it is derived from

S3000L UoF Task Requirement

regulations and/or other authoritative sources.

AuthorityToOperate

Class

class

AuthorityToOperate is a <<class>> that represents a certification
allowing a specific configuration of a product to be put into operation.

S3000L UoF Product Design
Configuration

Note
Type certificate for an aircraft signifies the airworthiness of its design.
Note
A design change cannot be put into operation without re-certification.

BreakdownClass

Applicable to: Allclass

Breakdown is a <<class>> that identifies a specific partitioning of a
Product to form a parent-child structure of related instances ofBreakdownElement.

S3000L UoF Breakdown Structure

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 5

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

BreakdownElement

Class

class

BreakdownElement is a <<class>> defining a partition of a Productthat is used in one or many instances of Breakdown.

S3000L UoF Breakdown Structure

BreakdownElementInZoneClass

relationshipBreakdownElementInZone is a <<relationship>> where a
BreakdownElementInZoneItem relates to the ZoneElement where it

S3000L UoF Zone Element

is located.

BreakdownElementInZoneItem

InterfaceextendBreakdownElementInZoneItem is an <<extend>> interface that

S3000L UoF Zone Element

provides its associated data model to those classes that implement it.

BreakdownElementRevision

Class

class

BreakdownElementRevision is a <<class>> representing an iteration
applied to a BreakdownElement.

S3000L UoF Breakdown Structure

BreakdownElementRevisionRelationshipClass

relationshipBreakdownElementRevisionRelationship is a<<relationship>> where one BreakdownElementRevision relates
to another BreakdownElement or BreakdownElementRevision.

S3000L UoF Breakdown Structure

BreakdownElementRevisionRelationshipItem

InterfaceselectBreakdownElementRevisionRelationshipItem is a<<select>> interface that provides the capability to be associated with a
BreakdownElementRevision.

S3000L UoF Breakdown Structure

BreakdownElements

Classexchange

BreakdownElements is a wrapper element that contains all instances ofBreakdownElement that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

BreakdownElementStructureClass

relationshipBreakdownElementStructure is a <<relationship>> that

S3000L UoF Breakdown Structure

establishes a hierarchical structure between two usages ofBreakdownElement that belong to the same BreakdownRevision.

BreakdownElementUsageInBrea
kdown

Class

class

BreakdownElementUsageInBreakdown is a <<class>> that
represents a member of a BreakdownRevision.

S3000L UoF Breakdown Structure

Note
A BreakdownElementRevision can belong to multiple
BreakdownRevisions.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 6

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

BreakdownElementUsageRelati
onshipClass

relationshipBreakdownElementUsageRelationship is a <<relationship>>where one usage of a BreakdownElement relates to the usage of another
BreakdownElement.

S3000L UoF Breakdown Structure

Note
Both related instances of BreakdownElementUsageInBreakdown
must reside within the same BreakdownRevision.
Example−BreakdownItem

InterfaceextendVersion C of a radio is restricted to the use of software version B in
breakdown revision 2.

BreakdownItem is an <<extend>> interface that provides its associated

S3000L UoF Breakdown Structure

data model to those classes that implement it.

BreakdownRevision

Class

class

BreakdownRevision is a <<class>> representing an iteration applied toa Breakdown.

S3000L UoF Breakdown Structure

Note

BreakdownRevision is used to document design iterations and notbreakdown variants.

BreakdownRevisionRelationsh
ip

Class

relationshipBreakdownRevisionRelationship is a <<relationship>> where
one BreakdownRevision relates to another BreakdownRevision.

S3000L UoF Breakdown Structure

ChangeAuthorization

Class

class

ChangeAuthorization is a <<class>> that is the record of the

S3000L UoF Change Information

permission to modify product design, its procedures and/or associated productsupport data.

ChangeAuthorizations

Classexchange

ChangeAuthorizations is a wrapper element that contains all instancesof ChangeAuthorization that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ChangeControlledItem

InterfaceextendChangeControlledItem is an <<extend>> interface that provides its

S3000L UoF Change Information

associated data model to those classes that can be affected by aChangeAuthorization.

ChangeNotification

Class

Applicable to: Allrelationship

ChangeNotification is a <<relationship>> that identifies an itemchanged due to the associated ChangeAuthorization.

S3000L UoF Change Information

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 7

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

ChangeRequest

Class

class

ChangeRequest is a <<class>> that represents a formal proposal for a

S3000L UoF Design Change
Requestmodification to a configuration item upon a given baseline.
Note
Typical configuration items are eg, Product, PartAsDesigned, andBreakdownElement.

ChangeRequestRationaleClassrelationship

ChangeRequestRationale is a <<relationship>> that associates a
ChangeRequest with a ChangeRequestRationaleItem.

S3000L UoF Design Change
RequestChangeRequestRationaleItem

InterfaceselectChangeRequestRationaleItem is a <<select>> interface that
identifies items which can support a ChangeRequest.

S3000L UoF Design Change
RequestChangeRequests

Classexchange

ChangeRequests is a wrapper element that contains all instances of
ChangeRequest that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ChangeRequestTargetClass

relationship

ChangeRequestTarget is a <<relationship>> that associates a
ChangeRequest with a ChangeRequestTargetItem.

S3000L UoF Design Change
RequestChangeRequestTargetItem

InterfaceselectChangeRequestTargetItem is a <<select>> interface that identifies
items which can be the subject for a ChangeRequest.

S3000L UoF Design Change
RequestCircuitBreaker

Class

class

CircuitBreaker is a <<class>> that represents an individual circuit
breaker identified in the context of a defined Product.

S3000L UoF Circuit BreakerCircuitBreakerItem

InterfaceselectCircuitBreakerItem is a <<select>> interface that identifies items

S3000L UoF Task

which can represent the referenced circuit breaker.

CircuitBreakerLocationClass

relationship

CircuitBreakerLocation is a <<relationship>> that identifies theitem on which the CircuitBreaker is placed.

S3000L UoF Circuit BreakerCircuitBreakerLocationItem

InterfaceselectCircuitBreakerLocationItem is a <<select>> interface that

S3000L UoF Circuit Breaker

identifies items which can be selected in order to determine the location for a
CircuitBreaker.

CircuitBreakers

Class

Applicable to: All

exchange

CircuitBreakers is a wrapper element that contains all instances of
CircuitBreaker that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 8

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

CircuitBreakerSetting

Class

class

CircuitBreakerSetting is a <<class>> that specifies an individual

S3000L UoF Task

circuit breaker that must be in a specific state.

CircuitBreakerSettings

Class

class

CircuitBreakerSettings is a <<class>> that identifies a set of

S3000L UoF Task

circuit breakers that must be set in specific states.

ClassInstanceAssertItem

InterfaceselectClassInstanceAssertItem is a <<select>> interface that identifies
classes from which an instance can be used as the

S3000L UoF Applicability
Statement

EvaluationByAssertionOfClassInstance assert item.
CompetenceDefinitionItem

InterfaceselectCompetenceDefinitionItem is a <<select>> interface that identifies
items which define measurable or observable possession of knowledge andskills.

CompetencyDefinition

Class

class

CompetencyDefinition is a <<class>> that represents the

S3000L UoF Competence
Definition
S3000L UoF Competence
Definition

specification of measurable or observable knowledge, skills, and/or abilities
necessary for successful performance by a person in a given context.
Note
Competency definition is broadly defined to include assertions of academic,
professional, occupational, vocational and life goals, outcomes, andstandards, however labeled.

CompetencyDefinitions

Classexchange

CompetencyDefinitions is a wrapper element that contains all instancesof CompetencyDefinition that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ConditionDefinitionItem

InterfaceselectConditionDefinitionItem is a <<select>> interface that identifies

S3000L UoF Applicability
Statement

classes from which an instance can be used as the
EvaluationByAssertionOfCondition assert condition.

ConditionInstance

Class

class

ConditionInstance is a <<class>> that defines an individual concept
or object having the characteristics of a generic ConditionType.

S3000L UoF Applicability
Statement

Example−Applicable to: All

Uniquely identified service bulletin

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 9

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

ConditionType

Class

class

ConditionType is a <<class>> that defines a concept or an object that

S3000L UoF Applicability
Statement

needs to be included in applicability statements where the concept or object is
not already explicitly represented in the data model.
Example−Environmental conditions

ConditionTypeAssertMember

Class

class

ConditionTypeAssertMember is a <<class>> that defines a member
for a given ConditionType which can be mapped to a Boolean expression
and be evaluated to be either TRUE or FALSE.

S3000L UoF Applicability
Statement

ConditionTypes

Class

exchange

ConditionTypes is a wrapper element that contains all instances ofConditionType that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ContainedSubstanceClass

relationshipContainedSubstance is a <<relationship>> that associates a
HardwarePartAsDesigned with a contained
SubstanceDefinition.

S3000L UoF Part Definition

Contract

Class

class

Contract is a <<class>> that represents a binding agreement between

S3000L UoF Product and Project

two or more parties.

ContractedProductVariantAtO
peratingLocationClass

relationship

ContractedProductVariantAtOperatingLocation is a<<relationship>> that identifies an OperatingLocation where acontracted ProductVariant is defined to be operated.

S3000L UoF Product Usage
Context

ContractedProductVariantAtO
peratingLocationType

Class

relationship

ContractedProductVariantAtOperatingLocationType is a<<relationship>> that identifies an OperatingLocationType
where a contracted ProductVariant is defined to be operated.

S3000L UoF Product Usage
Context

ContractItemDetailsClass

relationship

ContractItemDetails is a <<relationship>> that identifies an item
which is the subject of the Contract.

S3000L UoF Product and ProjectContractPartyClass

relationship

ContractParty is a <<relationship>> that identifies a Contract

S3000L UoF Product and Projectstakeholder.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 10

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

ContractRelationshipClassrelationship

ContractRelationship is a <<relationship>> where one
Contract relates to another Contract.

S3000L UoF Product and ProjectContracts

Class

exchange

Contracts is a wrapper element that contains all instances of Contract

S3000L UoF Logistics Support
Analysis Message Content

that are in scope for a data exchange.

CorrectionFactorClass

attributeGroup

CorrectionFactor is an <<attributeGroup>> that defines amathematical adjustment of a defined value to account for a specified deviation
in a given context.

CountriesClass

exchange

Countries is a wrapper element that contains all instances of Country that

S3000L UoF Performance
Parameter

are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

Country

Class

class

Country is a self-governing political entity, occupying a particular territory.

S3000L UoF Location

DamageAnalysis

Class

class

DamageAnalysis is an AnalysisActivity that represents the

S3000L UoF Damage Definition

objective for, and outcome of, a damage analysis carried out for the
AnalysisCandidateItem.

DamageAnalysisRevision

Class

class

DamageAnalysisRevision is an AnalysisActivityRevision
representing an iteration applied to a DamageAnalysis.

S3000L UoF Damage Definition

DamageCauseClass

relationship

DamageCause is a <<relationship>> where a DamageDefinition
relates to a SpecialEventDefinition that in some way is associatedwith the DamageDefinition.

S3000L UoF Damage Definition

DamageDefinition

Class

class

DamageDefinition is a <<class>> that represents a loss or reduction of

S3000L UoF Damage Definition

functionality due to external causes or use outside specified limits.

DamageImpact

Classrelationship

DamageImpact is a <<relationship>> that defines a consequence
resulting from the identified DamageDefinition.

S3000L UoF Damage Definition

DecisionTreeAnalysisItem

InterfaceextendDecisionTreeAnalysisItem is an <<extend>> interface that

S3000L UoF Decision Tree
Template Definition

provides its associated data model to those classes that implement it.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 11

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

DecisionTreeTemplate

Class

class

DecisionTreeTemplate is a <<class>> that enables the

S3000L UoF Decision Tree
Template Definition

representation of a decision process including a set of defined steps and binary
decisions.

DecisionTreeTemplateActionD
efinition

Class

DecisionTreeTemplateEndActi
onDefinition

Class

class

DecisionTreeTemplateActionDefinition is a <<class>> thatspecifies actions and/or measures that must be taken as part of the decision
process.

class

DecisionTreeTemplateEndActionDefinition is a
DecisionTreeTemplateActionDefinition that defines an end

S3000L UoF Decision Tree
Template Definition
S3000L UoF Decision Tree
Template Definition

action for the decision process.

DecisionTreeTemplateFollowO
nItem

Interface

DecisionTreeTemplateFurther
AnalysisActionDefinitionClass

selectDecisionTreeTemplateFollowOnItem is a <<select>> interface
that identifies items which can be selected to define the next step in thedecision process.

class

DecisionTreeTemplateFurtherAnalysisActionDefinition isa DecisionTreeTemplateActionDefinition that will be followed by

S3000L UoF Decision Tree
Template Definition
S3000L UoF Decision Tree
Template Definition

another question or action.

DecisionTreeTemplateQuestio
nDefinition

Class

class

DecisionTreeTemplateQuestionDefinition is a <<class>>
that specifies a question that results in a YES or NO answer.

S3000L UoF Decision Tree
Template Definition

DecisionTreeTemplateRevisio
n

Class

class

DecisionTreeTemplateRevision is a <<class>> representing an
iteration applied to a DecisionTreeTemplate.

S3000L UoF Decision Tree
Template Definition

DecisionTreeTemplatesClassexchange

DecisionTreeTemplates is a wrapper element that contains all instancesof DecisionTreeTemplate that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

DecisionTreeTemplateStartIt
em

InterfaceselectDecisionTreeTemplateStartItem is a <<select>> interface that

S3000L UoF Decision Tree
Template Definition

DetectionMeansAlarmClass

identifies items which can be selected as the starting point for the decision
process.
class

DetectionMeansAlarm is a <<class>> that supports the definition anddescription of an alarm being implemented by a
DetectionMeansAlarmItem.

Applicable to: All

S3000L UoF Failure Mode
Symptom

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 12

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

DetectionMeansAlarmItem

InterfaceextendDetectionMeansAlarmItem is an <<extend>> interface that provides

S3000L UoF Failure Mode
Symptom

its associated data model to those classes that can have an associatedDetectionMeansAlarm.

DigitalFile

Class

class

DigitalFile is a <<class>> that provides the identification of data stored

S3000L UoF Digital Fileon an electronic device that can be interpreted by a computer.

DigitalFileReferenceClass

relationship

DigitalFileReference is a <<relationship>> that allows a
DigitalFile to reference a DigitalFileReferencedItem.

S3000L UoF Digital File

DigitalFileReferencedItem

InterfaceselectDigitalFileReferencedItem is a <<select>> interface that

S3000L UoF Digital Fileidentifies an item which in some way is associated with the content in the
DigitalFile.

DigitalFileReferencingItem

InterfaceextendDigitalFileReferencingItem is an <<extend>> interface that

S3000L UoF Digital Fileprovides its associated data model to those classes that implement it.

DigitalFilesClass

exchange

DigitalFiles is a wrapper element that contains all instances ofDigitalFile that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

DiscreteTimeLimit

Class

class

DiscreteTimeLimit is a TimeLimit that is distinct, where its next

S3000L UoF Time Limit

possible occurrence cannot be scheduled.
Note
A Trigger is something that activates a DiscreteTimeLimit.
Note
A Threshold is a point that must not be exceeded once theDiscreteTimeLimit has been activated. If there is no threshold value,then the TimeLimitItem must be initiated immediately after the
DiscreteTimeLimit activation.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 13

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

Document

Class

class

Document is a <<class>> that represents a compiled set of information

S3000L UoF Documentthat serves a purpose.
Example−−−Drawing
ReportManualDocumentData

Class

exchange

DocumentData is a wrapper element that contains all instances ofDocument that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

DocumentIssue

Class

class

DocumentIssue is a <<class>> that represents a specific release of a
Document.

S3000L UoF Document

DocumentItem

InterfaceselectDocumentItem is a <<select>> interface that identifies items which canbe selected as Document.

S3000L UoF Document

DocumentReferencingItem

InterfaceextendDocumentReferencingItem is an <<extend>> interface that provides

S3000L UoF Document

its associated data model to those classes that implement it.

EffectiveOnProductConfigura
tion

Class

relationshipEffectiveOnProductConfiguration is a <<relationship>>that identifies that an EffectiveOnProductConfigurationItem,
included in the Breakdown for the overall Product, is effective in theassociated AllowedProductConfiguration.

S3000L UoF Product Design
Configuration

EffectiveOnProductConfigurationItemInterfaceextendEffectiveOnProductConfigurationItem is an <<extend>>

S3000L UoF Product Design
Configuration

EnvironmentDefinitionClassinterface that provides its associated data model to those classes that can be
included in one or many instances of AllowedProductConfiguration.
class

EnvironmentDefinition is a <<class>> that specifies thecircumstances, objects, events and/or conditions by which something can besurrounded and that influence the performance of an associated item.

Applicable to: All

S3000L UoF Environment
Definition

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 14

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

EnvironmentDefinitionCharacteristic

Class

class

EnvironmentDefinitionCharacteristic is a <<class>> that

S3000L UoF Environment
Definition

EnvironmentDefinitionItem

Interface

represents a measurable or observable characteristic for a circumstance,
object, event or condition that is significant to theEnvironmentDefinition.
extendEnvironmentDefinitionItem is an <<extend>> interface that

S3000L UoF Environment
Definition

provides its associated data model to those classes that implement it.

EnvironmentDefinitionRelati
onshipClass

relationship

EnvironmentDefinitionRelationship is a <<relationship>>where one EnvironmentDefinition relates to anotherEnvironmentDefinition.

S3000L UoF Environment
Definition

EnvironmentDefinitionRevisi
on

Class

class

EnvironmentDefinitionRevision is a <<class>> representing an
iteration applied to an EnvironmentDefinition.

S3000L UoF Environment
Definition

EnvironmentDefinitions

Classexchange

EnvironmentDefinitions is a wrapper element that contains all
instances of EnvironmentDefinition that are in scope for a data

S3000L UoF Logistics Support
Analysis Message Content

exchange.

EvaluationByAssertionOfClas
sInstance

Class

class

EvaluationByAssertionOfClassInstance is an
EvaluationCriteria that identifies a class instance to be used as an

S3000L UoF Applicability
Statement

assert item and be mapped to a Boolean expression which can be evaluated tobe either TRUE or FALSE.

EvaluationByAssertionOfCond
ition

Class

class

EvaluationByAssertionOfCondition is an
EvaluationCriteria that identifies a combination of a defined condition

S3000L UoF Applicability
Statement

and a defined value to be used as an assert item and be mapped to a Boolean
expression which can be evaluated to be either TRUE or FALSE.

EvaluationByAssertionOfSeri
alizedItems

Class

class

EvaluationByAssertionOfSerializedItems is an
EvaluationCriteria that identifies a class instance together with an

S3000L UoF Applicability
Statement

associated serial number range to be used as an assert item and be mapped toa Boolean expression which can be evaluated to be either TRUE or FALSE.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 15

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

EvaluationByNestedApplicabi
lityStatement

Class

class

EvaluationByNestedApplicabilityStatement is an
EvaluationCriteria that enables an ApplicabilityStatement tobe reused as part of this EvaluationCriteria.

S3000L UoF Applicability
Statement

Note
This class enables the definition of nested applicability statements.

EvaluationCriteria

Class

class

EvaluationCriteria is a <<class>> that defines conditions that can bemapped to a Boolean expression which can be evaluated to be either TRUE or
FALSE.

S3000L UoF Applicability
Statement

EventThresholdDefinition

Class

class

EventThresholdDefinition is a ThresholdDefinition that isdriven by occurrences of related TimeLimitEventItems.

S3000L UoF Time Limit

Facilities

Class

exchange

Facilities is a wrapper element that contains all instances of Facility
that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

Facility is a <<class> that represents a physically limited infrastructure

S3000L UoF Facility

Facility

Class

class

which exists, or is intended to be built or installed, and is established to serve a
particular purpose.

FacilityRelationshipClassrelationship

FacilityRelationship is a <<relationship>> where one
Facility relates to another Facility.

S3000L UoF Facility

FailureMode

Class

class

FailureMode is a <<class>> that defines a functional consequence of an
unacceptable state of the FailureModeAnalysisItem.

S3000L UoF Failure Mode

Example−FailureModeAnalysis

Class

class

No output from electrical circuit.

FailureModeAnalysis is a <<class>> that represents failure modes,

S3000L UoF Failure Mode

effects and criticality identified for the associatedFailureModeAnalysisItem.

FailureModeAnalysisItem

InterfaceextendFailureModeAnalysisItem is an <<extend>> interface that provides

S3000L UoF Failure Mode

its associated data model to those classes that can have an associatedFailureModeAnalysis.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 16

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

FailureModeAnalysisRevision

Class

class

FailureModeAnalysisRevision is a <<class>> representing an
iteration applied to a FailureModeAnalysis.

S3000L UoF Failure Mode

FailureModeCause

Class

class

FailureModeCause is a <<class>> that specifies the physical orchemical process(es) that is the reason for the FailureMode.

S3000L UoF Failure Mode

FailureModeCauseItem

InterfaceselectFailureModeCauseItem is a <<select>> interface that identifies items
which can be selected as being associated with a FailureModeCause.

S3000L UoF Failure Mode

FailureModeCauseItemRelatio
nship

Class

relationship

FailureModeCauseItemRelationship is a <<relationship>>where a FailureModeCause relates to the FailureModeCauseItemthat in some way is associated with the FailureModeCause.

S3000L UoF Failure Mode

FailureModeEffect

Class

class

FailureModeEffect is a <<class>> that defines the consequences ofan identified FailureMode on the operation, function, or status for the

S3000L UoF Failure Mode

referred item.

FailureModeEffectItem

InterfaceselectFailureModeEffectItem is a <<select>> interface that identifies
items which can be selected as being affected by a FailureMode.

S3000L UoF Failure Mode

FailureModeEffectItemRelati
onshipClass

relationship

FailureModeEffectItemRelationship is a <<relationship>>where a FailureModeEffect relates to the
FailureModeEffectItem that is affected by the FailureMode.

S3000L UoF Failure Mode

FailureModeIsolationCharact
eristics

Class

attributeGroup

FailureModeIsolationCharacteristics is an<<attributeGroup>> that collects data which describes the ability to

S3000L UoF Failure Mode
Isolation

determine that it is the associated failure mode that has occurred.

FailureModeIsolationItem

InterfaceextendFailureModeIsolationItem is an <<extend>> interface that

S3000L UoF Failure Mode
Isolation

provides its associated data model to those classes that implement it.

FailureModeSymptomClass

relationship

FailureModeSymptom is a <<relationship>> that identifies ameasurable or visible parameter whose appearance can be related, directly or
indirectly, to the occurrence of the associated failure mode.

Applicable to: All

S3000L UoF Failure Mode
Symptom

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 17

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

FailureModeSymptomItem

InterfaceselectFailureModeSymptomItem is a <<select>> interface that identifies

S3000L UoF Failure Mode
Symptomitems which can provide a measurable or visible parameter whose appearance
can be related, directly or indirectly, to the occurrence of the associated failure
mode.

FailureModeSymptomsSignatur
e

Class

class

FailureModeSymptomsSignature is a <<class>> that identifies aset of failure mode symptoms and effects which can be associated with a failure
mode.

S3000L UoF Failure Mode
Symptom

Note
Failure mode symptoms can be human observable as well as alarms andmeasurements.

FailureModeSymptomsSignatur
eItem

Interface

FinalInServiceOptimizationAnalysisStep

Class

extendFailureModeSymptomsSignatureItem is an <<extend>> interface
that provides its associated data model to those classes that can have anassociated FailureModeSymptomsSignature.

class

FinalInServiceOptimizationAnalysisStep is an
InServiceOptimizationAnalysisStep that specifies final actions

S3000L UoF Failure Mode
Symptom

S3000L UoF In Service
Optimization Analysis

and measures taken together with the decision process conclusion andrecommendations.

FollowOnInServiceOptimizati
onAnalysis

Class

relationshipFollowOnInServiceOptimizationAnalysis is a<<relationship>> where the outcome from the
InServiceOptimizationAnalysis resulted in an additional
InServiceOptimizationAnalysis.

S3000L UoF In Service
Optimization Analysis

FurtherAnalysisInServiceOpt
imizationAnalysisStep

Class

class

FurtherAnalysisInServiceOptimizationAnalysisStep is an
InServiceOptimizationAnalysisStep that specifies actions andS3000L UoF In Service
Optimization Analysis

measures taken before continuing to the next step defined in the associatedDecisionTreeTemplate.

GeographicalArea

Class

class

GeographicalArea is a <<class>> that represents a particular extent of

S3000L UoF Location

space.

GeographicalAreasClass

Applicable to: All

exchange

GeographicalAreas is a wrapper element that contains all instances ofGeographicalArea that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 18

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

GlobalPosition

Class

class

GlobalPosition is a <<class>> that identifies a point in space by a set

S3000L UoF Locationof coordinates.

GlobalPositions

Classexchange

GlobalPositions is a wrapper element that contains all instances of
GlobalPosition that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

HardwareElement

Class

class

HardwareElement is a BreakdownElement that is realized as a
HardwarePartAsDesigned.

S3000L UoF Hardware Element

HardwareElementPartRealizat
ion

Class

relationship

HardwareElementPartRealization is a <<relationship>>where a HardwareElementRevision relates to an instance ofHardwarePartAsDesigned which fulfills the HardwareElement

S3000L UoF Hardware Element

specification.

HardwareElementRevision

Class

class

HardwareElementRevision is a BreakdownElementRevision
representing an iteration applied to a HardwareElement.

S3000L UoF Hardware Element

HardwarePartAsDesigned

Class

class

HardwarePartAsDesigned is a PartAsDesigned that is to be realized

S3000L UoF Part Definitionas physical items, including non-countable material.
Note
Examples of non-countable materials are: oil, sealant, paint.

HardwarePartAsDesignedDesig
nData

Class

attributeGroup

HardwarePartAsDesignedDesignData is an<<attributeGroup>> that collects HardwarePartAsDesigned

S3000L UoF Part Definition

characteristics identified during design activities.

HardwarePartAsDesignedSuppo
rtDataClass

attributeGroup

HardwarePartAsDesignedSupportData is an<<attributeGroup>> that collects HardwarePartAsDesigned

S3000L UoF Part Definition

characteristics identified during supportability analysis activities.

IdentifiedTaskRequirement

Class

Applicable to: Allrelationship

IdentifiedTaskRequirement is a <<relationship>> thatassociates a TaskRequirement with a
TaskRequirementAnalysisItem.

S3000L UoF Task Requirement

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 19

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

InfrastructureComplianceClassrelationshipInfrastructureCompliance is a <<relationship>> that
documents how the InfrastructureCompliantItem fulfills
requirements stated in the associated ResourceSpecification.

S3000L UoF Facility

InfrastructureCompliantItem

InterfaceextendInfrastructureCompliantItem is an <<extend>> interface that

S3000L UoF Facility

provides its associated data model to those classes that implement it.

InServiceOptimizationAnalys
is

Class

InServiceOptimizationAnalys
isItemInterface

InServiceOptimizationAnalys
isRevision

Class

class

InServiceOptimizationAnalysis is a <<class>> that represents
the result from an in-service optimization analysis carried out for the
InServiceOptimizationAnalysisItem.

extendInServiceOptimizationAnalysisItem is an <<extend>>
interface that provides its associated data model to those classes that can havean associated InServiceOptimizationAnalysis.

class

InServiceOptimizationAnalysisRevision is a <<class>>

S3000L UoF In Service
Optimization Analysis

S3000L UoF In Service
Optimization Analysis

S3000L UoF In Service
Optimization Analysis

representing an iteration applied to an

InServiceOptimizationAnalysis.
InServiceOptimizationAnalys
isStepClass

LocationInterface

class

InServiceOptimizationAnalysisStep is a <<class>> that

S3000L UoF In Service
Optimization Analysis

represents the results from an individual step in the associated decision
process.
extendLocation is an <<extend>> interface that provides its associated data

S3000L UoF Location

model to those classes that implement it.

LocationItem

InterfaceselectLocationItem is a <<select>> interface that identifies items which can

S3000L UoF Location

be selected to provide the definition of a geographic location.

LocationRelationshipClassrelationship

LocationRelationship is a <<relationship>> where one
LocationItem relates to another LocationItem.

S3000L UoF Location

LogicalAND

Class

class

LogicalAND is an EvaluationCriteria that defines a Boolean
operation where the results of all its associated EvaluationCriteria
must be TRUE for the result to be TRUE, otherwise the result is FALSE.

S3000L UoF Applicability
Statement

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 20

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

LogicalNOT

Class

class

LogicalNOT is an EvaluationCriteria that defines a Boolean
operation where the result from its associated EvaluationCriteria mustbe FALSE for the result to be TRUE, otherwise the result is FALSE.

S3000L UoF Applicability
Statement

LogicalOR

Class

class

LogicalOR is an EvaluationCriteria that defines a Boolean operation
where the result from at least one of its associated EvaluationCriteria
must be TRUE for the result to be TRUE, otherwise the result is FALSE.

S3000L UoF Applicability
Statement

LogicalXOR

Class

class

LogicalXOR is an EvaluationCriteria that defines a Boolean

S3000L UoF Applicability
Statement

operation where the result from one and only one of its associatedEvaluationCriteria must be TRUE for the result to be TRUE, otherwise
the result is FALSE.

LogisticsSupportAnalysisMes
sageContent

Classexchange

LogisticsSupportAnalysisMessageContent is a
MessageContent that contains data resulting from LSA activities.

S3000L UoF Logistics Support
Analysis Message Content

LogisticsSupportAnalysisPri
maryData

Classexchange

LogisticsSupportAnalysisPrimaryData is a subset of the
LogisticsSupportAnalysisMessageContent <<exchange>>

S3000L UoF Logistics Support
Analysis Message Content

dataset and include the primary data used in and resulting from the LSA
activities.

LogisticsSupportAnalysisSup
portingData

Class

exchange

LogisticsSupportAnalysisSupportingData is a subset of the
LogisticsSupportAnalysisMessageContent <<exchange>>

S3000L UoF Logistics Support
Analysis Message Content

dataset and include data that support the LSA activities.

LSACorrectiveMaintenanceAna
lysis

Class

LSACorrectiveMaintenanceAna
lysisRevision

Class

class

LSACorrectiveMaintenanceAnalysis is an AnalysisActivity
that represents the outcome of corrective maintenance analysis carried out for
the AnalysisCandidateItem.

Applicable to: All

class

LSACorrectiveMaintenanceAnalysisRevision is an
AnalysisActivityRevision representing an iteration applied to
LSACorrectiveMaintenanceAnalysis.

S3000L UoF LSA Failure Mode
Group

S3000L UoF LSA Failure Mode
Group

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 21

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

LSACorrectiveMaintenanceAna
lysisSourceClassrelationship

LSACorrectiveMaintenanceAnalysisSource is a<<relationship>> where an
LSACorrectiveMaintenanceAnalysisRevision relates to the

S3000L UoF LSA Failure ModeGroup

failure mode related source information which is used to identify a required
corrective maintenance task.

LSACorrectiveMaintenanceAna
lysisSourceItem

Interfaceselect

LSACorrectiveMaintenanceAnalysisSourceItem is a<<select>> interface that identifies the failure mode source information used

S3000L UoF LSA Failure ModeGroup

to define the required corrective maintenance task.

LSAFailureModeGroup

Class

class

LSAFailureModeGroup is a <<class>> that represents a set of failuremodes that leads to the same set of actions for its detection, isolation andrectifying intervention.

S3000L UoF LSA Failure ModeGroup

LSAFailureModeGroupIncluded
FailureModeClass

relationship

LSAFailureModeGroupIncludedFailureMode is a<<relationship>> that identifies a FailureMode which is a member ofthe LSAFailureModeGroup.

S3000L UoF LSA Failure ModeGroup

LSAFailureModeGroupItem

Interfaceselect

LSAFailureModeGroupItem is a <<select>> interface that identifies
failure modes which are included in the LSAFailureModeGroup.

S3000L UoF LSA Failure ModeGroup

LSAFailureModeGroupTaskRequirementClass

relationship

LSAFailureModeGroupTaskRequirement is a<<relationship>> where an LSAFailureModeGroup relates to the
TaskRequirement needed in the process to either detect and isolate afailure, or to restore the AnalysisCandidateItem.

S3000L UoF LSA Failure ModeGroup

MaintenanceCapabilityAtOper
atingLocationType

Class

relationship

MaintenanceCapabilityAtOperatingLocationType is a<<relationship>> that identifies maintenance capabilities which areavailable at the defined OperatingLocationType.

S3000L UoF Product Usage
Context

MaintenanceFacility

Class

class

MaintenanceFacility is a Facility that is mainly established for

S3000L UoF Facility

providing product support.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 22

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

MaintenanceLevel

Class

class

MaintenanceLevel is a <<class>> that represents the definition of a set

S3000L UoF Product Usage
Context

of maintenance capabilities which will be made available to support a defined
Product.
Note

MaintenanceLevel might be established either by a single
organization or be distributed between a set of organizations.
MaintenanceLevels

Classexchange

MaintenanceLevels is a wrapper element that contains all instances of
MaintenanceLevel that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

MeasurementPointDefinition

Class

class

MeasurementPointDefinition is a <<class>> that specifies a

S3000L UoF Failure Mode
Symptomcharacteristic which can be observed for a

MeasurementPointDefinitionItem.
MeasurementPointDefinitionI
tem

Interface

MeasurementPointDegradedSta
teDefinitionClassextendMeasurementPointDefinitionItem is an <<extend>> interface
that provides its associated data model to those classes that can have anassociated MeasurementPointDefinition.

attributeGroup

MeasurementPointDegradedStateDefinition is an<<attributeGroup>> that specifies a measurable condition which, when

S3000L UoF Failure Mode
Symptom

S3000L UoF Time Limit

met, identifies that a degraded state has been entered.

MeasurementPointFaultStateD
efinitionClassattributeGroup

MeasurementPointFaultStateDefinition is an<<attributeGroup>> that specifies a measurable condition which, when

S3000L UoF Failure Mode
Symptommet, can identify that a failure has occurred.

Message

Class

class

Message is a <<class>> that represents the collection of information

S3000L UoF Message

brought together by a message sender for the purpose of communicating it toanother party.

MessageContent

Class

Applicable to: All

exchange

MessageContent is a <<exchange>> definition that represents thecollection of information that is the subject of the Message.

S3000L UoF Message

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 23

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

MessageContext

ClassrelationshipMessageContext is a <<relationship>> between a Message and

S3000L UoF Message

the context for which it is being provided.
Example−−−Product
Project
Contract

MessageContextItem

InterfaceselectMessageContextItem is a <<select>> interface that identifies items
which can be selected as the context for a Message.

S3000L UoF Message

MessagePartyClass

relationshipMessageParty is a <<relationship>> between a Message and astakeholder for the Message.

S3000L UoF Message

MessagePartyItem

InterfaceselectMessagePartyItem is a <<select>> interface that identifies items which
can be selected as the party for a Message.

S3000L UoF Message

MessageRelationshipClassrelationshipMessageRelationship is a <<relationship>> where one Message
relates to another Message.

S3000L UoF Message

Example−−One Message is a reply to another Message
One Message is an update to another Message

NestedAllowedProductConfigu
rationClassrelationship

NestedAllowedProductConfiguration is a <<relationship>>that defines that one AllowedProductConfiguration includes asubordinate AllowedProductConfiguration.

S3000L UoF Product Design
Configuration

NestedProductVariantClass

relationship

NestedProductVariant is a <<relationship>> that defines thatone ProductVariant includes a subordinate ProductVariant.

S3000L UoF Product Design
Configuration

NonConformanceDataClass

attributeGroup

NonConformanceData is an <<attributeGroup>> that collects
information on how the EffectiveOnProductConfigurationItem

S3000L UoF Product Design
Configuration

does not comply with the requirements of its usage.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 24

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

OperatingBase

Class

class

OperatingBase is a Facility that is mainly established for providing

S3000L UoF Facility

support for operations.

OperatingLocationType
OperatingLocationTypes

Class
Class

class
exchange

OperatingLocationType is a <<class>> that represents the definitionof the nature of the environment in which a product will be operated.

S3000L UoF Product Usage
Context

OperatingLocationTypes is a wrapper element that contains all
instances of OperatingLocationType that are in scope for a data

S3000L UoF Logistics Support
Analysis Message Content

exchange.

OperationalTask

Class

class

OperationalTask is a Task that is required to support the use of a

S3000L UoF Task

product.
Example−−Organization

Class

class

Fueling
TowingOrganization is a <<class>> that represents an administrative structurewith a particular purpose belonging to a legal entity.

S3000L UoF Organization
Assignment

Example−−−−OrganizationReferencingItem

InterfaceextendInternational agency
Department
Government department
Company

OrganizationReferencingItem is an <<extend>> interface thatprovides its associated data model to those classes that implement it.

S3000L UoF Organization
Assignment

Organizations

Classexchange

Organizations is a wrapper element that contains all instances ofOrganization that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ParameterThresholdDefinitio
n

Class

class

ParameterThresholdDefinition is a ThresholdDefinition

S3000L UoF Time Limit

Applicable to: Allthat is continuously measured and evaluated, and when reached, activates theassociated trigger or threshold.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 25

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

PartAsDesigned

Class

class

PartAsDesigned is a <<class>> that represents the definitional

S3000L UoF Part Definition

information for an artifact fulfilling a set of requirements, which can be produced
or realized.

PartAsDesignedControlledIte
mData

Class

attributeGroup

PartAsDesignedControlledItemData is an<<attributeGroup>> that collects PartAsDesigned characteristics

S3000L UoF Part Definition

identified during different controlled item analysis activities.

PartAsDesignedDesignData

Class

attributeGroup

PartAsDesignedDesignData is an <<attributeGroup>> thatcollects PartAsDesigned characteristics identified during design activities.

S3000L UoF Part Definition

PartAsDesignedPartsList

Class

class

PartAsDesignedPartsList is a <<class>> that represents thedefinitional information for the collection of
PartAsDesignedPartsListEntry included in the assembly of theparent PartAsDesigned.

S3000L UoF Part Definition

Note

PartAsDesignedPartsList is typically referred to as a Bill of Material(BOM).

PartAsDesignedPartsListEntr
y

Class

class

PartAsDesignedPartsListEntry is a <<class>> that represents
the inclusion of a PartAsDesigned in a
PartAsDesignedPartsListRevision.

S3000L UoF Part Definition

PartAsDesignedPartsListRela
tionshipClass

relationship

PartAsDesignedPartsListRelationship is a<<relationship>> where one PartAsDesignedPartsList relates
to another PartAsDesignedPartsList.

S3000L UoF Part Definition

PartAsDesignedPartsListRevi
sion

Class

class

PartAsDesignedPartsListRevision is a <<class>> representing
an iteration applied to a PartAsDesignedPartsList.

S3000L UoF Part Definition

PartAsDesignedSupportDataClass

attributeGroup

PartAsDesignedSupportData is an <<attributeGroup>> thatcollects PartAsDesigned characteristics identified during supportability

S3000L UoF Part Definition

analysis activities.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 26

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

Parts

Class

exchange

Parts is a wrapper element that contains all instances of PartAsDesigned

S3000L UoF Logistics Support
Analysis Message Content

that are in scope for a data exchange.

PerformanceParameter

Class

class

PerformanceParameter is a <<class>> that represents a metric that ifchanged, or not fulfilled, can have a major impact on the performance,schedule, cost and/or risk for the PerformanceParameterItem.

PerformanceParameterItem

InterfaceextendPerformanceParameterItem is an <<extend>> interface that

S3000L UoF Performance
Parameter

S3000L UoF Performance
Parameter

provides its associated data model to those classes that can have anassociated PerformanceParameter.

PerformanceParameterRevisio
n

Class

class

PerformanceParameterRevision is a <<class>> that represents an
iteration applied to a PerformanceParameter.

S3000L UoF Performance
Parameter

PerformanceParameterValueGr
oup

Class

attributeGroup

PerformanceParameterValueGroup is an <<attributeGroup>>that organizes PerformanceParameter values for a defined purpose.

S3000L UoF Performance
Parameter

PeriodicTimeLimit

Class

class

PeriodicTimeLimit is a TimeLimit that is repeated and its next

S3000L UoF Time Limit

occurrence can be scheduled.

PlannedTaskItem

InterfaceselectPlannedTaskItem is a <<select>> interface that identifies items which
can be used in the context of PlannedTaskUsage.

S3000L UoF Task Usage

PlannedTaskUsageClass

relationship

PlannedTaskUsage is a TaskUsage that expands the definition of arequired Task in the context of a given support solution.

S3000L UoF Task Usage

Note
Both rectifying and operational tasks are justified by task requirements
identified during various analysis activities.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 27

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

Product

Class

class

Product is a <<class>> that represents a family of items which share the

S3000L UoF Product and Projectsame underlying design purpose.
Example
−
−
−
−
−
−

Products
ProductUsagePhase

Class
Class

exchange
class

Airbus A340
iPhone 12
Pegasus engine
Ford Fusion
Stryker
Aegis Class Destroyer

Products is a wrapper element that contains all instances of Product thatare in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ProductUsagePhase is a <<class>> that represents a distinct period oftime during which a ProductUsagePhaseItem is in an operational state

S3000L UoF Product Usage
Phase

which has specific characteristics that need special considerations.
Example−−ProductUsagePhaseItem

InterfaceextendPreflight, post flight, cruise, and taxiing for an aircraft.
Emersion, surface and dock for a submarine.

ProductUsagePhaseItem is an <<extend>> interface that provides its
associated data model to those classes that implement it.

S3000L UoF Product Usage
Phase

ProductUsagePhaseRelationsh
ip

Class

relationship

ProductUsagePhaseRelationship is a <<relationship>> where
one ProductUsagePhase relates to another ProductUsagePhase.

S3000L UoF Product Usage
Phase

ProductVariant

Class

class

ProductVariant is a <<class>> that defines a member of a Product

S3000L UoF Product and Projectfamily which is configured for a specific purpose and is made available to themarket.
Note
A product variant is often known as a model.
Example−−Applicable to: All

Boeing 787-800 vs 787-900
Ford Fusion S vs. SE vs. SEL

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 28

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

Project

Class

class

Project is a <<class>> that represents the overall set of Integrated
Product Support (IPS) activities defined for a Product.

S3000L UoF Product and Project

Note

Project is often referred to as an IPS program.
ProjectContract

Class

relationship

ProjectContract is a <<relationship>> that establishes anassociation between a Project and a Contract.

S3000L UoF Product and Project

Projects

Class

exchange

Projects is a wrapper element that contains all instances of Project that

S3000L UoF Logistics Support
Analysis Message Content

are in scope for a data exchange.

QuestionInServiceOptimizati
onAnalysisStep

Class

class

QuestionInServiceOptimizationAnalysisStep is an
InServiceOptimizationAnalysisStep that specifies the answer to aquestion defined in the associated DecisionTreeTemplate.

S3000L UoF In Service
Optimization Analysis

RectifyingTask

Class

class

RectifyingTask is a Task that ensures or returns the function of the

S3000L UoF Task

associated item.
Note
An event that can require a Task to be performed includes a failure,damage, a special event, and a time limit.
Example−−−Lubrication
RepairReplace

ReferencedDigitalFile

Class

relationship

ReferencedDigitalFile is a <<relationship> that allows an item to referto a DigitalFile.

S3000L UoF Digital File

ReferencedDocumentClassrelationship

ReferencedDocument is a <<relationship>> where one
DocumentReferencingItem relates to a DocumentItem.

S3000L UoF Document

ReferencedOrganizationClass

relationship

ReferencedOrganization is a <<relationship>> where one
OrganizationReferencingItem relates to an Organization.

S3000L UoF Organization
Assignment

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 29

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

RemarkClass

attributeGroup

Remark is an <<attributeGroup>> that provides additional information

S3000L UoF Remark

about the associated item.
Note
A remark may be a personal opinion (“I prefer more onions in my soup”) or it
may be a technical fact (“The manufacturer recommends heating the soup
to 45 degrees Celsius”).

RemarkItem

InterfaceextendRemarkItem is an <<extend>> interface that provides its associated data

S3000L UoF Remark

model to those classes that implement it.

RepeatDefinition

Class

class

RepeatDefinition is a <<class>> that represents the set ofcircumstances which define the PeriodicTimeLimit.

S3000L UoF Time Limit

Note
Only one RepeatDefinition must be active at a specific moment in
time.
Note
A trigger is something that activates a RepeatDefinition.
Note
A threshold is a point that must not be exceeded by the TimeLimitItem
once the RepeatDefinition has been activated.

ResourceRealizationClass

relationshipResourceRealization is a <<relationship>> where a
ResourceSpecification relates to an instance of PartAsDesigned

S3000L UoF Resource
Specificationthat fulfills the resource specification.

ResourceSpecification

Class

class

ResourceSpecification is a <<class>> that defines a resource by its
characteristics.

S3000L UoF Resource
Specification

Note

ResourceSpecification allows for more generic resource definitions
ie, a task/subtask does not need to be changed due to eg, customer specificresource preferences.

ResourceSpecificationRevisi
on

Class

Applicable to: All

class

ResourceSpecificationRevision is a <<class>> representing an
iteration applied to a ResourceSpecification.

S3000L UoF Resource
Specification

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 30

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

ResourceSpecifications

Classexchange

ResourceSpecifications is a wrapper element that contains all
instances of ResourceSpecification that are in scope for a data

S3000L UoF Logistics Support
Analysis Message Content

exchange.

ResultingDataModuleClass

relationshipResultingDataModule is a <<relationship>> that identifies a data
module issue in which a TaskRevision is further detailed.

S3000L UoF Task

Note
A data module can contain either a complete or partial description of a given
Task.

S1000DDataModule

Class

class

S1000DDataModule is a Document that is written in accordance with an

S3000L UoF Document

S1000D schema.

S1000DDataModuleIssue

Class

class

S1000DDataModuleIssue is a DocumentIssue that identifies a

S3000L UoF Document

specific issue of a data module produced in accordance with S1000D.

S1000DPublicationModule

Class

class

S1000DPublicationModule is a Document that identifies a publication

S3000L UoF Document

published in accordance with S1000D.

S1000DPublicationModuleIssu
e

Class

SamplingDefinition

Class

class

S1000DPublicationModuleIssue is a DocumentIssue that

S3000L UoF Document

identifies a specific issue of a publication module published in accordance with
S1000D.
attributeGroup

SamplingDefinition is an <<attributeGroup>> that specifies

S3000L UoF Time Limit

whether the associated action is to be performed on a subset of the populationof the associated target item.

SamplingItem

InterfaceextendSamplingItem is an <<extend>> interface that represents the common

S3000L UoF Time Limit

behavior for those classes which can have an associatedSamplingDefinition.

SecurityClass
SecurityClasses

Class
Class

Applicable to: Allclass
exchange

SecurityClass is a <<class>> that identifies a level of confidentiality
which can be used to protect something against unauthorized access.

S3000L UoF Security
Classification

SecurityClasses is a wrapper element that contains all instances of
SecurityClass that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 31

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

SecurityClassificationClass

relationship

SecurityClassification is a <<relationship>> that associates agiven SecurityClass with the item that must be protected against

S3000L UoF Security
Classification

unauthorized access or distribution.

SecurityClassificationItem

InterfaceextendSecurityClassificationItem is an <<extend>> interface that

S3000L UoF Security
Classification

provides its associated data model to those classes that implement it.

SerializedAssertItem

InterfaceselectSerializedAssertItem is a <<select>> interface that identifies

S3000L UoF Applicability
Statement

classes from which an instance can be used as the

EvaluationByAssertionOfSerializedItems assert item.
Skill

Class

class

Skill is a <<class>> that represents human cognitive, psychomotor, andaffective abilities.

S3000L UoF Competence
Definition

SkillLevel

Class

class

SkillLevel is a <<class>> that represents a defined proficiency of a
Trade.

S3000L UoF Competence
Definition

SkillsClass

exchange

Skills is a wrapper element that contains all instances of Skill that are in

S3000L UoF Logistics Support
Analysis Message Content

scope for a data exchange.

SoftwareElement

Class

class

SoftwareElement is a BreakdownElement that is realized as a
SoftwarePartAsDesigned.

S3000L UoF Software Element

SoftwareElementPartRealizat
ion

Class

relationship

SoftwareElementPartRealization is a <<relationship>>where a SoftwareElementRevision relates to an instance ofSoftwarePartAsDesigned which fulfills the SoftwareElement

S3000L UoF Software Element

specification.

SoftwareElementRevision

Class

class

SoftwareElementRevision is a BreakdownElementRevision
representing an iteration applied to a SoftwareElement.

S3000L UoF Software Element

SoftwarePartAsDesigned

Class

class

SoftwarePartAsDesigned is a PartAsDesigned that is produced as

S3000L UoF Part Definition

an executable software or as a data file.
Note
Non-executable software includes eg, maps.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 32

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

SoftwarePartAsDesignedDesig
nData

Class

attributeGroup

SoftwarePartAsDesignedDesignData is an<<attributeGroup>> that collects SoftwarePartAsDesigned

S3000L UoF Part Definition

characteristics identified during design activities.

SpecialEventAnalysis

Class

class

SpecialEventAnalysis is an AnalysisActivity that represents the

S3000L UoF Special Event

objective for, and outcome of, a special event analysis carried out for the
AnalysisCandidateItem.

SpecialEventAnalysisRevisio
n

Class

class

SpecialEventAnalysisRevision is an
AnalysisActivityRevision representing an iteration applied to aSpecialEventAnalysis.

S3000L UoF Special Event

SpecialEventDefinition

Class

class

SpecialEventDefinition is a <<class>>that represents a typical

S3000L UoF Special Event

happening which can be induced to the item under analysis during its normal
operation, and can lead to damages.

SpecialEventProductUsagePha
seOccurrenceClass

relationshipSpecialEventProductUsagePhaseOccurrence is a<<relationship>> that defines an association between an instance ofSpecialEventDefinition and an instance of ProductUsagePhase

S3000L UoF Special Eventduring which the special event can occur.

StreetAddress

Class

class

StreetAddress is a <<class> that represents a locatable position along a

S3000L UoF Location

road.

SubstanceDefinition

Class

class

SubstanceDefinition is a <<class>> that identifies high concern

S3000L UoF Part Definition

physical matter.
Example−−SubstanceDefinitions

Class

Applicable to: All

exchange

CAS (Chemical Abstract Substance) Registry
REACH (Registration, Evaluation, Authorisation and restriction of Chemicals)

SubstanceDefinitions is a wrapper element that contains all instancesof SubstanceDefinition that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 33

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

SubstitutePartAsDesignedClassrelationship

SubstitutePartAsDesigned is a <<relationship>> that defines a
substitute PartAsDesignedPartsListEntry which can replace thebase PartAsDesignedPartsListEntry in the context of the parent
PartAsDesignedPartsList.

S3000L UoF Part Definition

Subtask

Class

class

Subtask is a <<class>> that represents the specification of a work stepthat is to be performed as part of a Task.

S3000L UoF Task

SubtaskAcceptanceParameter

Class

class

SubtaskAcceptanceParameter is a <<class>> that represents
acceptance criteria which must be met before the Subtask is completed.

S3000L UoF Task

SubtaskByDefinition

Class

class

SubtaskByDefinition is a Subtask that provides detailed information

S3000L UoF Taskof the defined work step.

SubtaskByTaskReference

Class

class

SubtaskByTaskReference is a Subtask where the details of thesubtask are defined as a separate Task.

S3000L UoF Task

SubtaskInZoneClass

relationship

SubtaskInZone is a <<relationship>> that identifies the zone where
the Subtask is to be performed.

S3000L UoF Task

SubtaskSourceDocumentClassrelationship

SubtaskSourceDocument is a <<relationship>> that identifies anexternal Document where the Subtask is originally defined and more details

S3000L UoF Task

are given.

SubtaskTargetClass

relationship

SubtaskTarget is a <<relationship>> that identifies the item on
which the Subtask is to be performed.

S3000L UoF Task

SubtaskTargetItem

InterfaceselectSubtaskTargetItem is a <<select>> interface that identifies items on
which a Subtask can be performed.

S3000L UoF Task

SubtaskTimelineClassrelationship

SubtaskTimeline is a <<relationship>> that identifies that there is atime dependency between two Subtasks within the same Task.

S3000L UoF Task

SubtaskWarningCautionNote

Class

relationship

SubtaskWarningCautionNote is a <<relationship>> that
identifies a WarningCautionNote that is associated with a given
Subtask.

S3000L UoF Task

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 34

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

SupportingTask

Class

class

SupportingTask is a Task that does not meet a TaskRequirement,

S3000L UoF Task

but identifies a set of work steps which will be carried out as part of multiple
Tasks.
Note
A SupportingTask will only be used in the context ofSubtaskByTaskReference.
Note
The objective for a SupportingTask is to enable reuse of a sequence ofwork steps, needed by a set of Tasks.
Example−−SupportingTaskUsageClass

relationshipOpen hatch
Jack vehicle

SupportingTaskUsage is a TaskUsage that expands the definition of anembedded reusable Task in the context of a given support solution.

S3000L UoF Task Usage

Note
A SupportingTask has no special characterizations apart from a
TaskFrequency since it will never be performed on its own.

Task

Class

class

Task is a <<class>> that represents the specification of work to be done or

S3000L UoF Task

undertaken.

TaskAnalysisItem

InterfaceextendTaskAnalysisItem is an <<extend>> interface that provides its

S3000L UoF Task Usage

associated data model to those classes that implement it.

TaskDocumentResource

Class

class

TaskDocumentResource is a TaskResource that identifies a
Document used as a resource.

S3000L UoF Task Resource

Example−TaskFrequency

Class

Applicable to: All

attributeGroupA form that must be filled out before, during or after the specified amount ofwork is carried out

TaskFrequency is an <<attributeGroup>> that specifies the rate ofoccurrence of a Task in its defined usage.

S3000L UoF Task Usage

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 35

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

TaskInfrastructureResource

Class

class

TaskInfrastructureResource is a TaskResource that defines

S3000L UoF Task Resource

foundational systems and services required as a resource.

TaskJustificationClass

relationship

TaskJustification is a <<relationship>> that identifies a
TaskRequirement that defines the need for the existence of a task.

S3000L UoF Task

TaskLocationItem

InterfaceselectTaskLocationItem is a <<select>> interface that identifies items
where Tasks can be performed.

S3000L UoF Task Usage

TaskMaterialResource

Class

class

TaskMaterialResource is a TaskResource that identifies parts which

S3000L UoF Task Resource

are required as a resource.

TaskPersonnelResource

Class

class

TaskPersonnelResource is a TaskResource that specifies the man

S3000L UoF Task Resource

power required as a resource.

TaskPersonnelResourceCompet
ence

Class

relationship

TaskPersonnelResourceCompetence is a <<relationship>>that identifies the proficiency required for TaskPersonnelResource.

S3000L UoF Task Resource

TaskRequirement

Class

class

TaskRequirement is a <<class>> that represents the need for a

S3000L UoF Task Requirement

procedure to be developed and documented.
Note
A task requirement can have more than one task being developed for
different usage scenarios.
Note
Task requirements are identified and documented prior to any detailed task
analysis.
Note
Examples of support analysis activities which result in a set of documented
task requirements are: Preventive Maintenance Analysis (PMA) (refer toS4000P) and special event analysis.

TaskRequirementAnalysisItem

InterfaceextendTaskRequirementAnalysisItem is an <<extend>> interface that

S3000L UoF Task Requirement

provides its associated data model to those classes that implement it.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 36

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

TaskRequirementJustificatio
n

Class

relationship

TaskRequirementJustification is a <<relationship>> that
identifies a source which defines the need for a Task.

S3000L UoF Task Requirement

TaskRequirementJustificationItem

InterfaceselectTaskRequirementJustificationItem is a <<select>> interface

S3000L UoF Task Requirement

TaskRequirementRevision

Class

class

TaskRequirementRevision is a <<class>> representing an iteration
applied to a TaskRequirement.

S3000L UoF Task Requirement

TaskRequirements

Classexchange

TaskRequirements is a wrapper element that contains all instances of
TaskRequirement that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

TaskResource

Class

class

TaskResource is a <<class>> that identifies means that have to be

S3000L UoF Task Resourcethat identifies items which can be selected as being the source that justifies the
TaskRequirement.

available to perform a specified amount of work.

TaskResourceDefinitionItem

InterfaceselectTaskResourceDefinitionItem is a <<select>> interface that

S3000L UoF Task Resource

identifies items which can be used as either infrastructure or material resources.

TaskResourceItem

InterfaceextendTaskResourceItem is an <<extend>> interface that provides its

S3000L UoF Task Resource

associated data model to those classes that implement it.

TaskResourceRelationshipClassrelationship

TaskResourceRelationship is a <<relationship>> where one
TaskResource relates to another TaskResource.

S3000L UoF Task Resource

TaskRevision

Class

class

TaskRevision is a <<class>> representing an iteration applied to a
Task.

S3000L UoF Task

TaskRevisionWarningCautionN
ote

Class

relationship

TaskRevisionWarningCautionNote is a <<relationship>> that
identifies a WarningCautionNote that is associated with a given Task.

S3000L UoF Task

Tasks

Class

exchange

Tasks is a wrapper element that contains all instances of Task that are in

S3000L UoF Logistics Support
Analysis Message Content

scope for a data exchange.

TaskUsage

Class

Applicable to: Allrelationship

TaskUsage is a <<relationship>> that identifies a Task required for
the TaskAnalysisItem.

S3000L UoF Task Usage

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 37

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

TechnologyBehaviorRatingClass

attributeGroup

TechnologyBehaviorRating is an <<attributeGroup>> thatcollects attributes which categorizes the AnalysisCandidateItem based

S3000L UoF Damage Definition

on knowledge on technology sensitivity and behavior perspective.

ThresholdDefinition

Class

class

ThresholdDefinition is a <<class>> that represents the

S3000L UoF Time Limit

circumstance that is used as a trigger or threshold.

TimeLimit

Class

class

TimeLimit is a <<class>> that represents the specification of

S3000L UoF Time Limit

circumstances under which the associated item is initiated.
Note

TimeLimit does not have the concept of an identification which meansthat if there is a change to a TimeLimit for a TimeLimitItem, then all
instances of TimeLimit must be re-sent as part of a Message.
NoteTime is used in the sense of "time to do something" and must not be seen
as only a period of time.

TimeLimitEventItem

InterfaceselectTimeLimitEventItem is a <<select>> interface that identifies which
items can be used to define an EventThresholdDefinition.

S3000L UoF Time Limit

TimeLimitItem

InterfaceextendTimeLimitItem is an <<extend>> interface that provides its associated

S3000L UoF Time Limit

data model to those classes that implement it.

Trade

Class

class

Trade is a <<class>> that represents a craft or profession which requires
specific skills.

TradesClass

exchange

Trades is a wrapper element that contains all instances of Trade that are inscope for a data exchange.

UsableOnItem

InterfaceextendUsableOnItem is an <<extend>> interface that provides its associateddata model to those classes that can have a limited effectivity with respect to its
usage in one or many instances of ProductVariant.

Applicable to: All

S3000L UoF Competence
Definition
S3000L UoF Logistics Support
Analysis Message Content
S3000L UoF Product Design
Configuration

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 38

S3000L-B6865-03000-00

Class nameType

Stereotype

Definition

UoF

UsableOnProductVariantClass

relationshipUsableOnProductVariant is a <<relationship>> that defines thata UsableOnItem, included in the Breakdown for the overall Product, iseffective in the associated ProductVariant.

S3000L UoF Product Design
Configuration

Note

UsableOnProductVariant is the equivalent of the Usable On Code in
SAE STD-GEIA-0007.

WarningCautionNote

Class

class

WarningCautionNote is a <<class>> that defines advice concerning

S3000L UoF Task

safety, legal and health aspects.

WarningCautionNotes

Class

exchange

WarningCautionNotes is a wrapper element that contains all instances ofWarningCautionNote that are in scope for a data exchange.

S3000L UoF Logistics Support
Analysis Message Content

ZoneElement

Class

class

ZoneElement is a BreakdownElement that represents a threedimensional space related to a Product.

S3000L UoF Zone Element

Note
A zone can also represent a work area such as a mechanical workshop
onboard a ship.

ZoneElementRevision

Class

Applicable to: All

class

ZoneElementRevision is a BreakdownElementRevision
representing an iteration applied to a ZoneElement.

S3000L UoF Zone Element

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 39

S3000L-B6865-03000-00

3

Class attribute list
The full list of S3000L attributes is provided in Table 3.
Table 3 is organized alphabetically by class attribute name and contains:
−
−
−
−
−

Attribute name
Attribute data type (refer to SX004G for more details on data types used in S3000L)
Attribute definition which contains a textual definition
Class name identifies the class in the S3000L data model where the attribute is used (refer toChap 19)
Unit of Functionality (UoF) identifies the section in Chap 19 where the class is defined

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 40

S3000L-B6865-03000-00

Table 3 List of class attributes
Attribute NameType

Definition

Class Name

UoF

additionalAddress
Information

DescriptorType

additionalAddressInformation is a description that provides

StreetAddress

S3000L UoF Location

AdditionalTraini
ngNeed

S3000L UoF Task Resource

additional information to further locate an address.
Example−−−additionalTrainin
gNeedDescription

DescriptorType

Building 7 in campus
First floor, apartment 7
Suite 204

additionalTrainingNeedDescription is a description thatgives more information on additional learning required.
Example−−−−−Behaviors
Experience
Knowledge
SkillsValuesaggregatedElement
Type

ClassificationType

aggregatedElementType is a classification that identifies further
specialization for an AggregatedElement.

AggregatedElement

S3000L UoF AggregatedElement

allowedProductCon
figurationIdentif
ier

IdentifierType

allowedProductConfigurationIdentifier is an identifier

AllowedProductCo
nfigurationByCon
figurationIdenti
fier

S3000L UoF Product Design
Configuration

altitudeumlString

GlobalPosition

S3000L UoF Locationthat establishes a unique designator for an

AllowedProductConfigurationByConfigurationIdentif
ier and to differentiate it from other instances ofAllowedProductConfigurationByConfigurationIdentif
ier.
altitude is a string of characters that represents the height above or
below a fixed reference point.
Example−Applicable to: All

34m above sea level

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 41

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

analysisActivityD
ecisionClassificationType

analysisActivityDecision is a classification that identifies if theAnalysisActivity is to be performed on the
AnalysisCandidateItem.

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityD
ecisionRationale

DescriptorType

analysisActivityDecisionRationale is a description that

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityR
evisionDate

DateType

analysisActivityRevisionDate is a date that specifies whenan AnalysisActivityRevision was defined.

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityR
evisionIdentifier

IdentifierType

analysisActivityRevisionIdentifier is an identifier that

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityR
evisionRationale

DescriptorType

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityR
evisionStatus

StateTypeanalysisActivityRevisionStatus is a state that identifies thematurity of an AnalysisActivityRevision.

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityS
tatusDescription

DescriptorType

analysisActivityStatusDescription is a description that

AnalysisActivity
Revision

S3000L UoF LSA Candidate

analysisActivityT
ype

ClassificationType

analysisActivityType is a classification that identifies further
specialization of AnalysisActivity.

AnalysisActivity

S3000L UoF LSA Candidate

analysisCandidate
ItemSelectionIndi
cator

ClassificationType

analysisCandidateItemSelectionIndicator is a

AnalysisCandidat
eItemSelectionDa
ta

S3000L UoF LSA Candidate

gives more information on the reason for the selection / non-selection of
the AnalysisActivity.

establishes a unique designator for an
AnalysisActivityRevision and to differentiate it from otherinstances of AnalysisActivityRevision.

analysisActivityRevisionRationale is a description thatgives more information on the justification for revising the defined
AnalysisActivity.

gives further information on the progression of theAnalysisActivity.

Applicable to: Allclassification that specifies the extent to which analysis activities will be
carried out on the associated AnalysisCandidateItem.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 42

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

analysisCandidate
ItemSelectionRati
onale

DescriptorType

analysisCandidateItemSelectionRationale is a

AnalysisCandidat
eItemSelectionDa
ta

S3000L UoF LSA Candidate

analysisCandidate
MaintenanceConcept

DescriptorType

AnalysisCandidat
eItemSelectionDa
ta

S3000L UoF LSA Candidate

analysisCandidate
MaintenanceSoluti
on

DescriptorType

AnalysisCandidat
eItemSelectionDa
ta

S3000L UoF LSA Candidate

applicabilityStat
ementDateRange

DateRange

ApplicabilitySta
tement

S3000L UoF Applicability
Statement

provides a human readable expression of the defined rule.

ApplicabilitySta
tement

S3000L UoF Applicability
Statement

applicabilityStatementIdentifier is an identifier that
establishes a unique designator for an ApplicabilityStatement

ApplicabilitySta
tement

S3000L UoF Applicability
Statement

UsableOnProductVariant

S3000L UoF Product Design
Configuration

EffectiveOnProdu
ctConfiguration

S3000L UoF Product Design
Configuration

description that gives more information on the reason for the candidate
selection.

analysisCandidateMaintenanceConcept is a statement ofmaintenance considerations, constraints and strategy for the operational
support that governs the maintenance levels and type of maintenanceactivities to be carried out on the AnalysisCandidateItem.

analysisCandidateMaintenanceSolution is a statement ofmaintenance activities and maintenance levels that have been decided for
the AnalysisCandidateItem.

applicabilityStatementDateRange is a date range thatdefines the date interval for when the applicability evaluation can result ina TRUE result.
Note
If outside that date range, the ApplicabilityStatement
always results in a FALSE statement.

applicabilityStat
ementDescription

DescriptorTypeapplicabilityStat
ementIdentifier

IdentifierTypeapplicabilityStatementDescription is a description thatand to differentiate it from other instances ofApplicabilityStatement.

applicableSerialN
umberRange

SerialNumberRange

Applicable to: AllapplicableSerialNumberRange is a serial number range that
identifies a limited effectivity with respect to a given interval of serialized
items.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 43

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

EvaluationByAsse
rtionOfSerialize
dItems

S3000L UoF Applicability
Statement

assembly

umlStringassembly is a string of characters that represents the unit orassembly attribute of the data module code.

S1000DDataModule

S3000L UoF Document

authorityToOperat
eIdentifier

IdentifierType

authorityToOperateIdentifier is an identifier that establishes
a unique designator for an AuthorityToOperate and to differentiate
it from other instances of AuthorityToOperate.

AuthorityToOperate

S3000L UoF Product Design
Configuration

breakdownElementC
hildSequenceNumberumlStringbreakdownElementChildSequenceNumber is a string of

BreakdownElement
Structure

S3000L UoF Breakdown
Structure

breakdownElementD
escription

DescriptorType

breakdownElementDescription is a description that gives more
information on the BreakdownElement.

BreakdownElement
Revision

S3000L UoF Breakdown
Structure

breakdownElementE
ssentiality

ClassificationType

breakdownElementEssentiality is a classification that identifies
the operational importance of the BreakdownElement at theProduct level.

BreakdownElement

S3000L UoF Breakdown
Structure

characters that controls the order for the included child element.
Note
The sequence number can be used to control how child elements arepresented in eg, a list.

Note
Based on the criticality as defined during the FMECA.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 44

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

breakdownElementI
dentifierIdentifierType

breakdownElementIdentifier is an identifier that establishes aunique designator for a BreakdownElement and to differentiate it fromother instances of BreakdownElement.

BreakdownElement

S3000L UoF Breakdown
StructureNote
Can be used to establish a hierarchical structure of the technicalsystem.
Example−−The combination of Logistics Support Analysis Control Number (LCN)and Alternate Logistics Support Analysis Control Number (ALC) within
SAE GEIA-STD-0007
The Standard Numbering System (SNS) defined by S1000D

breakdownElementN
ame

NameType

breakdownElementName is a name by which the
BreakdownElement is known and can be easily referenced.

BreakdownElement

S3000L UoF Breakdown
Structure

breakdownElementR
evisionDate

DateType

breakdownElementRevisionDate is a date that specifies whenthe BreakdownElement was revised.

BreakdownElement
Revision

S3000L UoF Breakdown
Structure

breakdownElementR
evisionIdentifier

IdentifierType

breakdownElementRevisionIdentifier is an identifier that
establishes a unique designator for a BreakdownElementRevision

BreakdownElement
Revision

S3000L UoF Breakdown
Structure

BreakdownElement
Revision

S3000L UoF Breakdown
Structure

BreakdownElement
RevisionRelation
ship

S3000L UoF Breakdown
Structureand to differentiate it from other instances ofBreakdownElementRevision.

breakdownElementR
evisionRationale

DescriptorType

breakdownElementR
evisionRelationsh
ipTypeClassificationType

breakdownElementRevisionRationale is a description thatgives more information on the justification for revising the
BreakdownElement.

Applicable to: All

breakdownElementRevisionRelationshipType is aclassification that identifies the meaning of the established relationship.
Note
The related breakdown elements do not need to be used in the same
breakdown ie, it can be used to establish the relationship between abreakdown element in a functional breakdown and a breakdown
element in a physical breakdown.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 45

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

breakdownElementR
evisionStatus

StateTypebreakdownElementRevisionStatus is a state that identifies thematurity of a BreakdownElementRevision.

BreakdownElement
Revision

S3000L UoF Breakdown
Structure

breakdownElementU
sageIdentifier

IdentifierType

breakdownElementUsageIdentifier is an identifier thatBreakdownElement
UsageInBreakdown

S3000L UoF Breakdown
Structure

BreakdownElement
UsageInBreakdown

S3000L UoF Breakdown
Structurethat identifies the meaning of the established relationship.

BreakdownElement
UsageRelationshi
p

S3000L UoF Breakdown
Structureestablishes a unique designator for a

BreakdownElementUsageInBreakdown and to differentiate itfrom other instances of BreakdownElementUsageInBreakdown.
breakdownElementU
sageQuantity

PropertyType

breakdownElementUsageQuantity is a property that specifies
the amount of the BreakdownElement used in its parent
BreakdownElement.
Note
If no value is given, it must be interpreted as value "1" with a unit of"each". For as required amounts, the text property is used with "As
Required" or other text as appropriate.

breakdownElementU
sageRelationshipT
ype

ClassificationType

breakdownRevision
Date

DateType

breakdownRevisionDate is a date that specifies when the
Breakdown was revised.

BreakdownRevision

S3000L UoF Breakdown
Structure

breakdownRevision
Identifier

IdentifierType

breakdownRevisionIdentifier is an identifier that establishes aunique designator for a BreakdownRevision and to differentiate itfrom other instances of BreakdownRevision.

BreakdownRevision

S3000L UoF Breakdown
Structure

breakdownRevision
Rationale

DescriptorType

breakdownRevisionRationale is a description that gives more
information on the justification for revising the Breakdown.

BreakdownRevision

S3000L UoF Breakdown
Structure

breakdownRevision
RelationshipType

ClassificationType

breakdownRevisionRelationshipType is a classification that
identifies the meaning of the established relationship.

BreakdownRevisio
nRelationship

S3000L UoF Breakdown
Structure

breakdownRevision
StatusStateTypebreakdownRevisionStatus is a state that identifies the maturity of
a BreakdownRevision.

BreakdownRevision

S3000L UoF Breakdown
Structure

Applicable to: All

breakdownElementUsageRelationshipType is a classification

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 46

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

breakdownType

ClassificationType

breakdownType is a classification that identifies the perspective fromwhich the Breakdown is defined.

Breakdown

S3000L UoF Breakdown
StructurechangeAuthorizati
onIdentifier

IdentifierTypechangeAuthorizationIdentifier is an identifier that
establishes a unique designator for a ChangeAuthorization and todifferentiate it from other instances of ChangeAuthorization.

ChangeAuthorizat
ion

S3000L UoF Change Information

changeNotificationDescription

DescriptorTypechangeNotificationDescription is a description providing a

ChangeNotificati
on

S3000L UoF Change Information

changeNotificatio
nTypeClassificationType

ChangeNotificati
on

S3000L UoF Change Information

changeRequestDesc
riptionDescriptorType

ChangeRequest

S3000L UoF Design Change
RequestchangeRequestIden
tifierIdentifierTypechangeRequestIdentifier is an identifier that establishes aunique designator for a ChangeRequest and to differentiate it fromother instances of ChangeRequest.

ChangeRequest

S3000L UoF Design Change
RequestchangeRequestInte
ndedEffectDescriptorTypechangeRequestIntendedEffect is a description, providing

ChangeRequest

S3000L UoF Design Change
RequestchangeRequestStatus

StateTypechangeRequestStatus is a state, that documents the progress of
the ChangeRequest within its lifecycle.

ChangeRequest

S3000L UoF Design Change
RequestcircuitBreakerIdentifier

IdentifierType

circuitBreakerIdentifier is an identifier that establishes aunique designator for a CircuitBreaker and to differentiate it fromother instances of CircuitBreaker.

CircuitBreaker

S3000L UoF Circuit BreakercircuitBreakerLoc
ationDescription

DescriptorType

circuitBreakerLocationDescription is a description thatprovides further details on where the CircuitBreaker is located on
the referenced CircuitBreakerLocationItem.

CircuitBreakerLo
cation

S3000L UoF Circuit Breakersummary of affects made to the related item due to a
ChangeAuthorization.

changeNotificationType is a classification that identifies achange effect as belonging to a group of change effects sharing aparticular characteristic or set of characteristics.

changeRequestDescription is a description, providing detailed
explanation of the desired change.

detailed explanation of the expected effect of the change.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 47

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

circuitBreakerNam
eNameType

circuitBreakerName is a name by which the CircuitBreakerCircuitBreaker

S3000L UoF Circuit BreakercircuitBreakerSet
tingIdentifier

IdentifierType

CircuitBreakerSe
tting

S3000L UoF Task

circuitBreakerSettingsIdentifier

IdentifierType

CircuitBreakerSe
ttings

S3000L UoF Task

circuitBreakerSettingsOrdered

umlBoolean

CircuitBreakerSe
ttings

S3000L UoF Task

is known and can be easily referenced.

circuitBreakerSettingIdentifier is an identifier that
establishes a unique designator for a defined
CircuitBreakerSetting, and to differentiate it from otherinstances of CircuitBreakerSetting.

circuitBreakerSettingsIdentifier is an identifier that
establishes a unique designator for a defined set of circuit breakersettings and to differentiate it from other instances of circuit breakersettings.

circuitBreakerSettingsOrdered is a boolean that defines if
the individual circuit breaker setting must be performed in the specified
order.
Note
A TRUE value specifies that the circuit breaker settings must be
accomplished in the defined order.
A FALSE value specifies that the circuit breaker settings can beaccomplished in any order.

circuitBreakerStateStateTypecircuitBreakerState is a state that identifies the position that agiven CircuitBreaker must be in after the accomplishment of adefined CircuitBreakerSetting.

CircuitBreakerSe
tting

S3000L UoF Task

circuitBreakerTypeClassificationType

circuitBreakerType is a classification that defines the technicalprinciple for the CircuitBreaker.

CircuitBreaker

S3000L UoF Circuit Breaker

cityName

NameType

cityName is a name by which an incorporated municipal unit is known

StreetAddress

S3000L UoF Location

CompetencyDefinition

S3000L UoF Competence
Definitionand can be easily referenced.

competencyDefinit
ionDescription

DescriptorType

Applicable to: AllcompetencyDefinitionDescription is a description thatprovides information on the knowledge, skills and attitudes that a person
is expected to have by having acquired a certain competency.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 48

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

competencyDefinit
ionIdentifier

IdentifierTypecompetencyDefinitionIdentifier is an identifier that
establishes a unique designator for a CompetencyDefinition andto differentiate it from other instances of CompetencyDefinition.

CompetencyDefinition

S3000L UoF Competence
DefinitioncompetencyDefinit
ionNameNameTypecompetencyDefinitionName is a name by which theCompetencyDefinition is known and can be easily referenced.

CompetencyDefinition

S3000L UoF Competence
DefinitioncompetencyDefinit
ionTypeClassificationTypecompetencyDefinitionType is a classification that identifies
further specialization of CompetencyDefinition.

CompetencyDefinition

S3000L UoF Competence
Definition

conditionInstanceDescription

DescriptorTypeconditionInstanceDescription is a description that gives more
information on the meaning of the ConditionInstance.

ConditionInstance

S3000L UoF Applicability
Statement

conditionInstance
Identifier

IdentifierTypeconditionInstanceIdentifier is an identifier that establishes aunique designator for a ConditionInstance and to differentiate itfrom other instances of ConditionInstance.

ConditionInstance

S3000L UoF Applicability
Statement

conditionInstanceName

NameType

conditionInstanceName is a name by which theConditionInstance is known and can be easily referenced.

ConditionInstance

S3000L UoF Applicability
Statement

conditionTypeAsse
rtMemberAssertValue

PropertyTypeconditionTypeAssertMemberAssertValue is a numerical

ConditionTypeAss
ertMember

S3000L UoF Applicability
Statement

conditionTypeAsse
rtMemberAssertVal
ueComparisonOpera
tor

ClassificationType

ConditionTypeAss
ertMember

S3000L UoF Applicability
Statement

ConditionTypeAss
ertMember

S3000L UoF Applicability
Statement

property that specifies values which can be used to further characterize
the ConditionTypeAssertMember.

conditionTypeAssertMemberAssertValueComparisonOpe
rator is a classification that identifies a mathematical operation to be
applied when testing a value against a definedconditionTypeAssertMemberAssertValue.
Example−−conditionTypeAsse
rtMemberDescripti
on

DescriptorType

Applicable to: All

Greater thanLess thanconditionTypeAssertMemberDescription is a descriptionthat gives more information on the meaning of theConditionTypeAssertMember.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 49

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

conditionTypeAsse
rtMemberName

NameType

conditionTypeAssertMemberName is a name that identifies a
ConditionTypeAssertMember.

ConditionTypeAss
ertMember

S3000L UoF Applicability
Statement

conditionTypeDesc
riptionDescriptorTypeconditionTypeDescription is a description that gives more
information on the meaning of the ConditionType.

ConditionType

S3000L UoF Applicability
Statement

conditionTypeName

NameType

conditionTypeName is a name by which the ConditionType is

ConditionType

S3000L UoF Applicability
Statement

ContainedSubstan
ce

S3000L UoF Part Definition

known and can be easily referenced.
Example−−−−Ashore or afloat
Maintenance environment
Operational environment
Service bulletin

containedSubstanceJustification

DescriptorType

contractIdentifier

IdentifierType

contractIdentifier is an identifer that establishes a uniquedesignator for a Contract and to differentiate it from other instances ofContract.

Contract

S3000L UoF Product and ProjectcontractItemDetai
lsBlockOfSerializ
edItems

SerialNumberRange

contractItemDetailsBlockOfSerializedItems is a serial

ContractItemDeta
ils

S3000L UoF Product and ProjectcontractItemDetai
lsContractQuantityPropertyType

ContractItemDeta
ils

S3000L UoF Product and ProjectcontractName

NameType

Contract

S3000L UoF Product and ProjectcontainedSubstanceJustification is a description that gives
more information on the properties of the included substance required forthe function of the HardwarePartAsDesigned.

number range that identifies an interval of serialized items as known by
the customer.

contractItemDetailsContractQuantity is a property that
identifies the number of contract items that are included in theContract.

contractName is a name by which the Contract is known and canbe easily referenced.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 50

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

contractPartyRole

ClassificationTypecontractPartyRole is a classification that defines the purpose of
the association between a ContractParty and the Contract.

ContractParty

S3000L UoF Product and ProjectContractRelation
ship

S3000L UoF Product and ProjectCorrectionFactor

S3000L UoF Performance
Parameter

CorrectionFactor

S3000L UoF Performance
Parameter

Country

S3000L UoF Location

DamageDefinition

S3000L UoF Damage Definition

Example−−−−−contractRelations
hipTypeClassificationType

Contractor
Customer
Escrow holder
Subcontractor
Supplier

contractRelationshipType is a classification that identifies themeaning of the established relationship.
Example−−−−correctionFactorJ
ustification

DescriptorType

AssociatedExtends
Replaces
Subcontract

correctionFactorJustification is a description that gives
more information on the reason for the CorrectionFactor and forthe correction value to be applied.

correctionFactorV
alue

umlRealcountryCode

ClassificationTypecorrectionFactorValue is a <<umlReal>> that specifies theamount by which the associated value is to be adjusted in the definedcontext.

countryCode is a string of characters used to uniquely identify aCountry and to differentiate it from other instances of Country.
Note
It is advised to use ISO 3166-1 alpha-2.

damageDefinitionD
escription

DescriptorType

Applicable to: AlldamageDefinitionDescription is a description that gives more
information on the DamageDefinition.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 51

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

damageDefinitionF
amily

ClassificationTypedamageDefinitionFamily is a classification that identifies a group

DamageDefinition

S3000L UoF Damage Definitionof damages which share the damage characteristics and often lead to thesame, or similar, corrective action.
Example
−
−
−

Crack
Dent
ScratchdamageDefinitionN
ame

NameType

damageDefinitionName is a name by which theDamageDefinition is known and can be easily referenced.

DamageDefinition

S3000L UoF Damage Definition

damageImpactRatio

PropertyTypedamageImpactRatio identifies the fraction of individual occurrencesof DamageDefinition that will result in the associatedFailureMode in relation to the entire population of occurences of theDamageDefinition identified for the AnalysisCandidateItem.

DamageImpact

S3000L UoF Damage Definition

dataModuleIssueIn
WorkNumber

umlStringdataModuleIssueInWorkNumber is a string of characters used for

S1000DDataModule
Issue

S3000L UoF Document

S1000DDataModule
Issue

S3000L UoF Document

monitoring and control of intermediate drafts of
S1000DDataModuleIssue.
Note
A dataModuleIssueInWorkNumber must be created inaccordance with the rules defined in S1000D.

dataModuleIssueLa
nguageClassificationType

dataModuleIssueLanguage is a classification that identifies thelanguage used to produce the content of the
S1000DDataModuleIssue.
Note
A dataModuleIssueLanguage must be created in accordancewith the rules defined in S1000D.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 52

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

dataModuleIssueLa
nguageCountry

ClassificationType

dataModuleIssueLanguageCountry is a classification that

S1000DDataModule
Issue

S3000L UoF Document

S1000DDataModule
Issue

S3000L UoF Document

DecisionTreeTemp
lateActionDefinition

S3000L UoF Decision Tree
Template Definition

DecisionTreeTemp
lateActionDefinition

S3000L UoF Decision Tree
Template Definition

DecisionTreeTemp
lateActionDefinition

S3000L UoF Decision Tree
Template Definition

identifies the country where the language, identified bydataModuleIssueLanguage, is spoken
Note
A dataModuleIssueLanguageCountry must be created inaccordance with the rules defined in S1000D.

dataModuleIssueNu
mberumlStringdataModuleIssueNumber is a string of characters used to identify
the release number of the S1000DDataModuleIssue
Note
A dataModuleIssueNumber must be created in accordance withthe rules defined in S1000D.

decisionTreeTempl
ateActionDefiniti
onDescription

DescriptorTypedecisionTreeTempl
ateActionDefiniti
onIdentifier

IdentifierTypedecisionTreeTemplateActionDefinitionDescription isa description that provides further information on the action to be taken.

decisionTreeTemplateActionDefinitionIdentifier is
an identifier that establishes a unique designator for a

DecisionTreeTemplateActionDefinition and to differentiate
it from other instances ofDecisionTreeTemplateActionDefinition.
decisionTreeTempl
ateActionDefiniti
onNameNameType

Applicable to: AlldecisionTreeTemplateActionDefinitionName is a namethat defines the core action and/or measure to be taken.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 53

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

decisionTreeTempl
ateAnalysisDomain

NameType

decisionTreeTemplateAnalysisDomain is a name that further
specifies the domain for which the DecisionTreeTemplate is

DecisionTreeTemplateRevision

S3000L UoF Decision Tree
Template Definition

DecisionTreeTemplateRevision

S3000L UoF Decision Tree
Template Definition

defined.
Example−−−−−Gear boxes
In Service Support Optimization
In Service Training Optimization
Logistics Support Analysis
ObsolescencedecisionTreeTempl
ateDescription

DescriptorTypedecisionTreeTempl
ateIdentifier

IdentifierTypedecisionTreeTemplateIdentifier is an identifier that
establishes a unique designator for a DecisionTreeTemplate andto differentiate it from other instances of DecisionTreeTemplate.

DecisionTreeTemplate

S3000L UoF Decision Tree
Template Definition

decisionTreeTempl
ateNameNameType

decisionTreeTemplateName is a name by which theDecisionTreeTemplate is known and can be easily referenced.

DecisionTreeTemplate

S3000L UoF Decision Tree
Template Definition

decisionTreeTempl
ateQuestionDefinitionDescription

DescriptorTypedecisionTreeTemplateQuestionDefinitionDescription

DecisionTreeTemplateQuestionDefi
nition

S3000L UoF Decision Tree
Template Definition

decisionTreeTempl
ateQuestionDefinitionIdentifier

IdentifierType

DecisionTreeTemplateQuestionDefi
nition

S3000L UoF Decision Tree
Template Definition

DecisionTreeTemplateQuestionDefi
nition

S3000L UoF Decision Tree
Template Definition

decisionTreeTemplateDescription is a description thatprovides more information on the purpose and scope of the defined
analysis.

is a description that provides further information and clarification about thequestion to be answered.

decisionTreeTemplateQuestionDefinitionIdentifier
is an identifier that establishes a unique designator for a

DecisionTreeTemplateQuestionDefinition and todifferentiate it from other instances ofDecisionTreeTemplateQuestionDefinition.
decisionTreeTempl
ateQuestionDefinitionName

NameType

Applicable to: AlldecisionTreeTemplateQuestionDefinitionName is a namethat defines the core question to be answered.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 54

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

decisionTreeTempl
ateRevisionDate

DateType

decisionTreeTemplateRevisionDate is a date that specifies
when a DecisionTreeTemplateRevision was defined.

DecisionTreeTemplateRevision

S3000L UoF Decision Tree
Template Definition

decisionTreeTempl
ateRevisionIdenti
fier

IdentifierTypedecisionTreeTemplateRevisionIdentifier is an identifier

DecisionTreeTemplateRevision

S3000L UoF Decision Tree
Template Definition

decisionTreeTempl
ateRevisionRation
ale

DescriptorType

DecisionTreeTemplateRevision

S3000L UoF Decision Tree
Template Definition

decisionTreeTempl
ateRevisionStatus

StateTypedecisionTreeTemplateRevisionStatus is a state that
identifies the maturity of a DecisionTreeTemplateRevision.

DecisionTreeTemplateRevision

S3000L UoF Decision Tree
Template Definition

detectionMeansAla
rmDescription

DescriptorType

detectionMeansAlarmDescription is a description that gives
more information on the DetectionMeansAlarm.

DetectionMeansAl
arm

S3000L UoF Failure Mode
Symptom

detectionMeansAla
rmFalseAlarmRate

PropertyType

detectionMeansAlarmFalseAlarmRate identifies the portion of

DetectionMeansAl
arm

S3000L UoF Failure Mode
Symptom

detectionMeansAla
rmIdentifier

IdentifierType

detectionMeansAlarmIdentifier is an identifier that
establishes a unique designator for a DetectionMeansAlarm and todifferentiate it from other instances of DetectionMeansAlarm.

DetectionMeansAl
arm

S3000L UoF Failure Mode
Symptom

detectionMeansAla
rmPresentation

DescriptorType

detectionMeansAlarmPresentation is a description that gives

DetectionMeansAl
arm

S3000L UoF Failure Mode
Symptom

detectionMeansAla
rmTypeClassificationType

DetectionMeansAl
arm

S3000L UoF Failure Mode
Symptomthat establishes a unique designator for a

DecisionTreeTemplateRevision and to differentiate it fromother instances of DecisionTreeTemplateRevision.
decisionTreeTemplateRevisionRationale is a descriptionthat gives more information on the justification for revising the defined
DecisionTreeTemplate.

all alarms that indicate a malfunction that cannot be verified by personnel
performing follow-on tests.

more information on how the alarm is presented.

Applicable to: All

detectionMeansAlarmType is a classification that defines the typeof test that generates the symptom.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 55

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

digitalFileContentClassClassificationType

digitalFileContentClass is a classification that determine themeaning of the information within the DigitalFile.

DigitalFile

S3000L UoF Digital File

Example
−
−
−
−
−
−

Audio
Courseware
Drawing
Movie
Problem report
Publication

digitalFileConten
tDescription

DescriptorType

digitalFileContentDescription is a phrase that gives moredetails about the information contained in the DigitalFile.

DigitalFile

S3000L UoF Digital FiledigitalFileLocator

IdentifierType

digitalFileLocator is an identifier that establishes a uniquedesignator for a DigitalFile used to locate and identify aDigitalFile and to differentiate it from other instances ofDigitalFile.

DigitalFile

S3000L UoF Digital FiledigitalFileRefere
nceJustification

DescriptorType

digitalFileReferenceJustification is a description that

DigitalFileRefer
ence

S3000L UoF Digital File

DigitalFile

S3000L UoF Digital File

DigitalFile

S3000L UoF Digital Fileprovides more on information on the reason why the
DigitalFileReferencedItem is referenced.
Example−digitalFileRepres
entation

umlString

Crack discovered on BreakdownElement 'ABC-123'

digitalFileRepresentation is a string of characters
representing the content of the DigitalFile.
ExampleA uuencoded ASCII umlString representing a binary source file.

digitalFileType

ClassificationType

digitalFileType is a classification that specifies the format of thedata within the DigitalFile.
Note
Typically, the file name extension in Microsoft Windows.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 56

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

disassemblyCode

umlStringdisassemblyCode is a string of characters that represents the

S1000DDataModule

S3000L UoF Document

S1000DDataModule

S3000L UoF Document

disassembly code attribute of the data module code.
Note
A disassemblyCode must be created in accordance with the rules
defined in S1000D.

disassemblyCodeVa
riantumlStringdisassemblyCodeVariant is a string of characters that represents
the disassembly code variant attribute of the data module code.
Note
A disassemblyCodeVariant must be created in accordancewith the rules defined in S1000D.

documentIdentifier

IdentifierType

documentIdentifier is an identifier that establishes a uniquedesignator for a Document and to differentiate it from other instances ofDocument.

Document

S3000L UoF Document

documentIssueDate

DateType

documentIssueDate is a date that defines when a specific issue of a

DocumentIssue

S3000L UoF Document

document was released.

documentIssueIdentifierIdentifierType

documentIssueIdentifier is an identifier that establishes aunique designator for a DocumentIssue and to differentiate it fromother instances of DocumentIssue.

DocumentIssue

S3000L UoF Document

documentTitle

NameType

documentTitle is a name by which the Document is known and canDocument

S3000L UoF Document

be easily referenced.

documentType

ClassificationType

documentType is a classification that identifies the category of theDocument.

Document

S3000L UoF Document

environmentDefinitionCharacteristi
cDescription

DescriptorTypeenvironmentDefinitionCharacteristicDescription is a

EnvironmentDefinitionCharacteris
tic

S3000L UoF Environment
Definition

Applicable to: All

description that gives more information on theEnvironmentDefinitionCharacteristic.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 57

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

environmentDefinitionCharacteristi
cName

NameType

environmentDefinitionCharacteristicName is a name bywhich the EnvironmentDefinitionCharacteristic is known

EnvironmentDefinitionCharacteris
tic

S3000L UoF Environment
Definition

environmentDefinitionCharacteristi
cValuePropertyType

EnvironmentDefinitionCharacteris
tic

S3000L UoF Environment
Definition

environmentDefinitionCharacteristi
cValueComparisonO
peratorClassificationType

EnvironmentDefinitionCharacteris
tic

S3000L UoF Environment
Definition

environmentDefinitionDescription

DescriptorTypeenvironmentDefinitionDescription is a description thatgives more information on the EnvironmentDefinition.

EnvironmentDefinitionRevision

S3000L UoF Environment
Definition

environmentDefinitionIdentifier

IdentifierTypeenvironmentDefinitionIdentifier is an identifier that
establishes a unique designator for an EnvironmentDefinition

EnvironmentDefin
ition

S3000L UoF Environment
Definitionand can be easily referenced.

environmentDefinitionCharacteristicValue is a property
that represents a measurable or observable characteristic for acircumstance, object, event, or condition that is typical to theEnvironmentDefinition.

environmentDefinitionCharacteristicValueCompariso
nOperator is a classification that identifies the comparison operator
which is to be used in order to qualify whether an actual environment is amember of the defined EnvironmentDefinition.

and to differentiate it from other instances ofEnvironmentDefinition.

environmentDefinitionName

NameType

environmentDefinitionName is a name by which theEnvironmentDefinition is known and can be easily referenced.

EnvironmentDefinitionRevision

S3000L UoF Environment
Definition

environmentDefinitionRelationshipT
ype

ClassificationTypeenvironmentDefinitionRelationshipType is a classificationthat identifies the meaning of the established relationship.

EnvironmentDefinitionRelationshi
p

S3000L UoF Environment
Definition

environmentDefinitionRevisionDate

DateType

environmentDefinitionRevisionDate is a date that specifies
when the EnvironmentDefinition was revised.

EnvironmentDefinitionRevision

S3000L UoF Environment
Definition

environmentDefinitionRevisionIdent
ifier

IdentifierTypeenvironmentDefinitionRevisionIdentifier is an identifier

EnvironmentDefinitionRevision

S3000L UoF Environment
Definition

Applicable to: Allthat establishes a unique designator for an

EnvironmentDefinitionRevision and to differentiate it fromother instances of EnvironmentDefinitionRevision.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 58

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

environmentDefinitionRevisionRatio
nale

DescriptorTypeenvironmentDefinitionRevisionRationale is a description

EnvironmentDefinitionRevision

S3000L UoF Environment
Definition

environmentDefinitionRevisionStatus

StateTypeenvironmentDefinitionRevisionStatus is a state that
identifies the maturity of an EnvironmentDefinitionRevision.

EnvironmentDefinitionRevision

S3000L UoF Environment
Definition

evaluationByAssertionRole

ClassificationTypeevaluationByAssertionRole is a classification that defines the

EvaluationByAsse
rtionOfClassInst
ance

S3000L UoF Applicability
Statement

EventThresholdDefinition

S3000L UoF Time Limit

S1000DDataModule

S3000L UoF Document

S1000DPublicatio
nModule

S3000L UoF Document

S1000DDataModule

S3000L UoF Document

S1000DPublicatio
nModule

S3000L UoF Documentthat provides a justification for revising theEnvironmentDefinition.

context in which the

EvaluationByAssertionOfClassInstance is beingreferenced.

eventThresholdNum
berOfEventOccurrences

umlInteger

extensionCode

umlString

eventThresholdNumberOfEventOccurrences is an integerthat defines how many times an event must be repeated for the
EventThresholdDefinition to be activated.

extensionCode is a string of characters used to identify theorganization receiving the customized data module.
Note
An extensionCode must be created in accordance with the rules
defined in S1000D.

extensionProducer

umlStringextensionProducer is a string of characters used to identify theorganization providing the customized data module.
Note
An extensionProducer must be created in accordance with therules defined in S1000D.

facilityDescripti
on

DescriptorType

facilityDescription is a description that gives more information
on capabilities provided by the Facility.

Facility

S3000L UoF Facility

facilityIdentifier

IdentifierType

facilityIdentifier is an identifier that establishes a uniquedesignator for a Facility and to differentiate it from other instances ofFacility.

Facility

S3000L UoF Facility

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 59

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

facilityName

NameType

facilityName is a name by which the Facility is known and can

Facility

S3000L UoF Facility

FacilityRelation
ship

S3000L UoF Facility

meaning of the established relationship.

failureModeAnalysisDescription is a description that gives
more information on the FailureModeAnalysis.

FailureModeAnaly
sisRevision

S3000L UoF Failure Modebe easily referenced.

facilityRelations
hipTypeClassificationType

failureModeAnalys
isDescription

DescriptorType

facilityRelationshipType is a classification that identifies the

Example−The failureModeAnalysisDescription can give further
information on background and scope.

failureModeAnalys
isRevisionDate

DateType

failureModeAnalysisRevisionDate is a date that specifies
when the FailureModeAnalysis was revised.

FailureModeAnaly
sisRevision

S3000L UoF Failure ModefailureModeAnalys
isRevisionIdentif
ier

IdentifierType

failureModeAnalysisRevisionIdentifier is an identifier

FailureModeAnaly
sisRevision

S3000L UoF Failure ModefailureModeAnalys
isRevisionRationaleDescriptorType

FailureModeAnaly
sisRevision

S3000L UoF Failure ModefailureModeAnalys
isRevisionStatus

StateTypefailureModeAnalysisRevisionStatus is a state that identifies
the maturity of a FailureModeAnalysisRevision.

FailureModeAnaly
sisRevision

S3000L UoF Failure ModefailureModeAnalys
isTypeClassificationType

failureModeAnalysisType is a classification that identifies further
specialization for FailureModeAnalysis.

FailureModeAnaly
sis

S3000L UoF Failure ModefailureModeCauseD
escription

DescriptorType

failureModeCauseDescription is a description that gives more
information on the FailureModeCause.

FailureModeCause

S3000L UoF Failure Modethat establishes a unique designator for a

FailureModeAnalysisRevision and to differentiate it from otherinstances of FailureModeAnalysisRevision.
failureModeAnalysisRevisionRationale is a descriptionthat gives more information on the justification for revising the
FailureModeAnalysis.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 60

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

failureModeCauseI
dentifierIdentifierType

failureModeCauseIdentifier is an identifier that establishes aunique designator for a FailureModeCause and to differentiate it fromother instances of FailureModeCause.

FailureModeCause

S3000L UoF Failure ModefailureModeCauseI
temRelationshipTy
peClassificationType

failureModeCauseItemRelationshipType is a classification

FailureModeCause
ItemRelationship

S3000L UoF Failure ModefailureModeCauseR
atio

PropertyType

failureModeCauseRatio identifies the fraction of an individual
FailureModeCause in relation to the entire population of
FailureModeCauses identified for the FailureMode.

FailureModeCause

S3000L UoF Failure ModefailureModeCritic
alityClassificationType

failureModeCriticality is a classification that identifies the mostserious impact that the FailureMode will have on the referred item.

FailureModeEffect

S3000L UoF Failure ModefailureModeDescri
ption

DescriptorType

failureModeDescription is a description that gives more
information on the FailureMode.

FailureMode

S3000L UoF Failure ModefailureModeDetect
ionAbilityDescrip
tion

DescriptorType

failureModeDetectionAbilityDescription is a description

FailureModeSympt
omsSignature

S3000L UoF Failure Mode
Symptom

failureModeDetect
ionAbilityRatio

PropertyType

FailureModeSympt
omsSignature

S3000L UoF Failure Mode
Symptom

failureModeEffectDescription

DescriptorType

failureModeEffectDescription is a description that gives more
information on the FailureModeEffect.

FailureModeEffect

S3000L UoF Failure ModefailureModeEffect
Level

ClassificationType

failureModeEffectLevel is classification that identifies the higher
indenture level that will be affected by the FailureMode.

FailureModeEffect

S3000L UoF Failure ModefailureModeEffect
Name

NameType

failureModeEffectName is a name by which the
FailureModeEffect is known and can be easily referenced.

FailureModeEffect

S3000L UoF Failure Modethat identifies the meaning of the established relationship.

that gives more information on the ability to detect the associated failure
mode.

failureModeDetectionAbilityRatio is a property that
identifies the fraction of failure mode occurrences that will be detected
through the symptoms signature in relation to the entire population of
occurrences for the associatedFailureModeSymptomsSignatureItem.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 61

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

failureModeEffectSummaryDescriptionDescriptorType

failureModeEffectSummaryDescription is a description that

FailureModeSympt
omsSignature

S3000L UoF Failure Mode
Symptom

failureModeIdenti
fier

IdentifierType

failureModeIdentifier is an identifier that establishes a uniquedesignator for a FailureMode and to differentiate it from otherinstances of FailureMode.

FailureMode

S3000L UoF Failure ModefailureModeIsolat
ionAbilityDescrip
tion

DescriptorType

failureModeIsolationAbilityDescription is a description

FailureModeIsola
tionCharacterist
ics

S3000L UoF Failure Mode
Isolation

failureModeIsolat
ionAbilityRating

ClassificationType

FailureModeIsola
tionCharacterist
ics

S3000L UoF Failure Mode
Isolation

failureModeIsolat
ionRatePropertyType

failures that can be associated to a failure of an identified item orcomponent without ambiguity.

FailureModeIsola
tionCharacterist
ics

S3000L UoF Failure Mode
Isolation

failureModeName

NameType

failureModeName is a name by which the FailureMode is known

FailureMode

S3000L UoF Failure Mode

FailureMode

S3000L UoF Failure Mode

FailureModeSympt
om

S3000L UoF Failure Mode
Symptom

provides a summary of human observable failure mode effects thatindicates that the associated failure mode has occurred.

that gives more information on the ability to isolate the associated failure
mode.

failureModeIsolationAbilityRating is a classification thatdefines the ability to isolate the associated failure mode(s).

failureModeIsolationRate defines the fraction of detected

and can be easily referenced.

failureModeRatio

PropertyType

failureModeRatio identifies the fraction of an individual
FailureMode in relation to the entire population of FailureModes
identified for the FailureModeAnalysisItem.
Note
If the failureModeRatio equals '0' then the failure mode is only
driven by damage.

failureModeSympto
mRatioPropertyType

Applicable to: All

failureModeSymptomRatio is a property that specifies the fractionof failure mode occurrences that will be detected through the associatedsymptom in relation to the entire population of occurrences for the
associated FaiureModeSymptomsSignatureItem.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 62

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

failureModeSympto
msDescription

DescriptorType

failureModeSymptomsDescription is a description that

FailureModeSympt
omsSignature

S3000L UoF Failure Mode
Symptom

failureModeSympto
msSignatureIdenti
fier

IdentifierType

FailureModeSympt
omsSignature

S3000L UoF Failure Mode
SymptomfollowOnInService
OptimizationAnaly
sisRationale

DescriptorType

FollowOnInServic
eOptimizationAna
lysis

S3000L UoF In Service
Optimization Analysis

geographicalAreaD
escription

DescriptorType

geographicalAreaDescription is a description that provides
more information about the GeographicalArea.

GeographicalArea

S3000L UoF Location

geographicalAreaN
ame

NameType

geographicalAreaName is a name by which theGeographicalArea is known and can be easily referenced.

GeographicalArea

S3000L UoF Location

provides a human readable summary of the set of symptoms that together
indicates that the associated failure mode have occurred.

failureModeSymptomsSignatureIdentifier is an identifierthat establishes a unique designator for a

FailureModeSymptomsSignature and to differentiate it fromother instances of FailureModeSymptomsSignature.
followOnInServiceOptimizationAnalysisRationale is a
description that gives more information on the reason for the additionallyinitiated InServiceOptimizationAnalysis.

Example
−
−
−
−
−
−

Central alps
Dade county
EuropeGobi desert
Tokyo
USA

geographicalAreaT
ype

ClassificationType

geographicalAreaType is a classification that identifies the natureof the GeographicalArea.

GeographicalArea

S3000L UoF Location

geographicalCoord
inateSystem

ClassificationType

geographicalCoordinateSystem is a classification that identifies
the geographical coordinate system used to determine latitude andlongitude.

GlobalPosition

S3000L UoF Location

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 63

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

hardwareElementRepairability

ClassificationType

hardwareElementRepairability is a classification that indicates
whether the HardwareElement part realization is expected to be

HardwareElementR
evision

S3000L UoF Hardware Element

HardwareElementR
evision

S3000L UoF Hardware Element

HardwareElementR
evision

S3000L UoF Hardware Element

HardwareElementR
evision

S3000L UoF Hardware Element

reparable from a technical standpoint, independent of customer
maintenance concepts.

hardwareElementRepairabilityStrategyClassificationType

hardwareElementRepairabilityStrategy is a classificationthat identifies the reparability strategy chosen for a specific customer andmaintenance concept.
Note
Repairability strategy can include information on which maintenancelevel the repair is to be performed.

hardwareElementRe
placeability

ClassificationType

hardwareElementReplaceability is a classification that
identifies whether the HardwareElement part realization is expected
to be replaceable from a technical standpoint, independent from customer
maintenance concepts.

hardwareElementRe
placeabilityStrat
egyClassificationType

hardwareElementReplaceabilityStrategy is a classificationthat identifies the replaceability strategy chosen for a specific customer
and maintenance concept.
Note
Replaceability strategy can include information about the maintenancelevel at which the replacement task is to be performed.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 64

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

hardwareElementSt
ructuralIndicator

ClassificationType

hardwareElementStructuralIndicator is a classification thatdefines how important the HardwareElement is to structural integrity.

HardwareElementR
evision

S3000L UoF Hardware Element

HardwareElement

S3000L UoF Hardware Element

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

Note
A Structural Item (SI) is part of the systems bodywork.
Note
A Structure Significant Item (SSI) is an item which has been identified
by a selection process coming from a Preventive MaintenanceAnalysis (PMA) procedure eg, S4000P. For this item, a PMA will be
performed.
Note
A Structural Detail (SD), also named Significant Detail in S4000P, is alimited area or a local spot of an SSI. In contrast to an SSI, the SD
isn´t identified by its own part identifier (eg, its own part number).

hardwareElementTy
peClassificationType

hardwareElementType is a classification that identifies further
specialization for a HardwareElement.
Example
−
−
−
−
−
−

hardwarePartConsu
mptionRate

PropertyType

hardwarePartElectromagneticIncompa
tible

umlBoolean

Access point
Door
Electrical panel
Equipment
Panel
Slot

hardwarePartConsumptionRate is a property that specifies thenumber of times that the part is replaced in 100 repairs of the next higher
assembly.

Applicable to: All

hardwarePartElectromagneticIncompatible is aclassification that identifies the ability of an electrical
HardwarePartAsDesigned to function satisfactorily in its
electromagnetic environment without inadmissibly influencing thisenvironment to which other HardwarePartAsDesigned belong.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 65

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

hardwarePartElectromagneticSensiti
ve

umlBoolean

hardwarePartElectromagneticSensitive is a classificationthat specifies whether the HardwarePartAsDesigned can be

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

hardwarePartElectrostaticSensitive

umlBoolean

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

subject to catastrophic failure, major characteristic change or performancedegradation, due to influences of electromagnetic fields.

hardwarePartElectrostaticSensitive is a classification thatspecifies whether the HardwarePartAsDesigned can be subject tocatastrophic failure, major characteristic change or performancedegradation, due to influences of electrostatic fields and/or electricalcharges.

hardwarePartEnvir
onmentalAspectInU
seClass

DatedClassification

hardwarePartEnvir
onmentalAspectPlannedDisposalClass

DatedClassification

hardwarePartFitme
ntRequirement

ClassificationType

hardwarePartEnvironmentalAspectInUseClass is aclassification that identifies environment aspects that must to beconsidered during use of and maintenance on the
HardwarePartAsDesigned.

hardwarePartEnvironmentalAspectPlannedDisposalCla
ss is a classification that identifies environment aspects that must to beconsidered during planned disposal of the
HardwarePartAsDesigned.

hardwarePartFitmentRequirement is a classification that
identifies if a HardwarePartAsDesigned cannot be fitted in its ‘as
supplied’ state but must undergo some operation before or during
installation.

hardwarePartHazar
dousClass

ClassificationType

hardwarePartHazardousClass is a classification that identifies towhat extent a HardwarePartAsDesigned is capable of posing asignificant risk to health, safety or property during transportation, handling,or storage.

hardwarePartLogis
ticsCategory

ClassificationType

hardwarePartLogisticsCategory is a classification that defines
the role of the HardwarePartAsDesigned in the context of productsupport.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 66

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

hardwarePartMagne
ticSensitive

umlBoolean

hardwarePartMagneticSensitive is a classification thatspecifies whether the HardwarePartAsDesigned can be subject toHardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

catastrophic failure, major characteristic change or performancedegradation, due to influences of magnetic fields.

hardwarePartMaint
enanceSchedulingS
tart

ClassificationType

hardwarePartOpera
tionalAuthorizedL
ife

AuthorizedLife

hardwarePartMaintenanceSchedulingStart is aclassification that specifies when maintenance scheduling must be
initiated for a realized part.

hardwarePartOperationalAuthorizedLife is an extended
property that identifies the maximum usage limit for which an item can be
operated, and upon reaching this limit, any further usage of the item must
be re-authorized.
Example−−−−hardwarePartRadia
tionSensitive

umlBoolean

CalendarCyclesHours
Landings

hardwarePartRadiationSensitive is a classification thatspecifies whether the HardwarePartAsDesigned can be subject tocatastrophic failure, major characteristic change or performancedegradation, due to influences of radioactive radiation.

hardwarePartRepai
rability

ClassificationType

hardwarePartRepairability is a classification that identifies theextent to which the HardwarePartAsDesigned is repairable from atechnical perspective, independent of customer maintenance concepts.

hardwarePartRepai
rabilityStrategy

ClassificationType

hardwarePartRepairabilityStrategy is a classification thatspecifies if a repairable HardwarePartAsDesigned is to repaired
and optionally also at what maintenance level or maintenance facility.
Note

hardwarePartRepairabilityStrategy is often defined in thecontext of a specific customer and maintenance concept (Refer to UoF
Applicability Statement).

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 67

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

hardwarePartScrap
Rate

NumericalPropertyType

hardwarePartScrapRate is a property that defines the fraction of

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

repairable units which, when removed from service, will be found to be
beyond economic repair and therefore have to be scrapped.

hardwarePartSize

ThreeDimensional

hardwarePartSize is an extended property that specifies the spatial
magnitudes for a HardwarePartAsDesigned.

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

HardwarePartAsDe
signedSupportData

S3000L UoF Part DefinitionNote

hardwarePartSize must exclude packaging and other external
factors.

hardwarePartSuppo
rtFamilyClassClassificationType

hardwarePartSupportFamilyClass is a classification thatgeneralizes the HardwarePartAsDesigned from a support analysis
perspective.
Note

hardwarePartSupportFamilyClass can be used to organize
hardware parts that share similar support characteristics and/or
mainitenance solution.
Example−hardwarePartTraceabilityClassClassificationType

GearboxhardwarePartTraceabilityClass is a classification thatspecifies the way the HardwarePartAsDesigned is to be tracked
and traced when entered into service.

hardwarePartWaste
ProductsInUseDisp
osalDescription

DescriptorType

Applicable to: All

hardwarePartWasteProductsInUseDisposalDescription
is a description that gives more information on how waste products for anindividual HardwarePartAsDesigned need to be managed when
the part is disposed of according to the procedure during use or after
being used.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 68

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

hardwarePartWaste
ProductsPlannedDi
sposalDescription

DescriptorType

hardwarePartWasteProductsPlannedDisposalDescripti
on is a description that gives more information on how waste products

HardwarePartAsDe
signedSupportData

S3000L UoF Part Definition

hardwarePartWeight

PropertyType

HardwarePartAsDe
signedDesignData

S3000L UoF Part Definition

S1000DDataModule

S3000L UoF Document

S1000DDataModule

S3000L UoF Document

InfrastructureCo
mpliance

S3000L UoF Facility

InfrastructureCo
mpliance

S3000L UoF Facility

InfrastructureCo
mpliance

S3000L UoF Facility

need to be managed when the entire population of a
HardwarePartAsDesigned is disposed of according to theprocedure for planned disposal.

hardwarePartWeight is a property that specifies the mass for a
HardwarePartAsDesigned.
NotehardwarePartWeight must exclude packaging and otherexternal factors.

informationCode

umlString

informationCode is a string of characters that represents theinformation code attribute of the data module code.
Note
An informationCode must be created in accordance with therules defined in S1000D.

informationCodeVa
riantumlString

informationCodeVariant is a string of characters that represents
the information code variant attribute of the data module code.
Note
An informationCodeVariant must be created in accordancewith the rules defined in S1000D.

infrastructureCom
plianceDate

DateType

infrastructureCom
plianceDescriptionDescriptorType

infrastructureCom
plianceLevel

ClassificationType

infrastructureComplianceDate is a date that defines wheninfrastructure compliance was declared.

infrastructureComplianceDescription is a description thatgives more information on compliance fulfillment.

Applicable to: All

infrastructureComplianceLevel is a classification thatspecifies the degree of compliance.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 69

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

inServiceOptimiza
tionAnalysisName

NameType

inServiceOptimizationAnalysisName is a name by which the
InServiceOptimizationAnalysis is known and can be easily

InServiceOptimiz
ationAnalysis

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisRev
ision

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisRev
ision

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisRev
ision

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisRev
ision

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisRev
ision

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisStep

S3000L UoF In Service
Optimization Analysis

InServiceOptimiz
ationAnalysisStep

S3000L UoF In Service
Optimization Analysis

referenced.

inServiceOptimiza
tionAnalysisRatio
nale

DescriptorType

inServiceOptimiza
tionAnalysisRevis
ionDateDateType

inServiceOptimiza
tionAnalysisRevis
ionIdentifier

IdentifierType

inServiceOptimizationAnalysisRationale is a descriptionthat gives more information on the reason for the defined
InServiceOptimizationAnalysis.

inServiceOptimizationAnalysisRevisionDate is a datethat specifies when an InServiceOptimizationAnalysis wasrevised.

inServiceOptimizationAnalysisRevisionIdentifier is
an identifier that establishes a unique designator for an

InServiceOptimizationAnalysisRevision and todifferentiate it from other instances of

InServiceOptimizationAnalysisRevision.
inServiceOptimiza
tionAnalysisRevis
ionRationale

DescriptorType

inServiceOptimiza
tionAnalysisRevis
ionStatus

StateTypeinServiceOptimiza
tionAnalysisStepD
escription

DescriptorType

inServiceOptimiza
tionAnalysisStepI
dentifierIdentifierType

inServiceOptimizationAnalysisRevisionRationale is a
description that gives more information on the justification for revising thedefined InServiceOptimizationAnalysis.

inServiceOptimizationAnalysisRevisionStatus is astate that identifies the maturity of an

InServiceOptimizationAnalysisRevision.
inServiceOptimizationAnalysisStepDescription is a
description that gives information on actions taken, information gathered,decisions and conclusions made during the
InServiceOptimizationAnalysisStep.

Applicable to: All

inServiceOptimizationAnalysisStepIdentifier is an
identifier that establishes a unique designator for an
InServiceOptimizationAnalysisStep and to differentiate itfrom other instances of InServiceOptimizationAnalysisStep.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 70

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

inServiceOptimiza
tionAnalysisStepQ
uestionAnswer

umlBoolean

inServiceOptimizationAnalysisStepQuestionAnswer isa boolean that specifies a TRUE or FALSE conclusion to the associated

QuestionInServic
eOptimizationAna
lysisStep

S3000L UoF In Service
Optimization Analysis

inServiceOptimiza
tionAnalysisSumma
ryDescription

DescriptorTypea description that gives summarized information on decisions andconclusions made during the InServiceOptimizationAnalysis.

InServiceOptimiz
ationAnalysisRev
ision

S3000L UoF In Service
Optimization Analysis

itemLocationCode

umlString

itemLocationCode is a string of characters that represents the item

S1000DDataModule

S3000L UoF Document

GlobalPosition

S3000L UoF Location

S1000DDataModule

S3000L UoF Document

S1000DDataModule

S3000L UoF Document

question.

inServiceOptimizationAnalysisSummaryDescription is

location code attribute of the data module code.
Note
An itemLocationCode must be created in accordance with therules defined in S1000D.

latitudeumlString

latitude is a string of characters that represents a geographic
coordinate specifying the north-south position of a point.
Example−−−learnCodeumlString

39.5693900
39°34.1634' N
39°34'09" NlearnCode is a string of characters that represents the learn code
attribute of the data module code.
Note
A learnCode must be created in accordance with the rules definedin S1000D.

learnEventCode

umlStringlearnEventCode is a string of characters that represents the learn
event code attribute of the data module code.
Note
A learnEventCode must be created in accordance with the rules
defined in S1000D.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 71

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

locationRelations
hipTypeClassificationTypelocationRelationshipType is a classification that identifies the

LocationRelation
ship

S3000L UoF Location

GlobalPosition

S3000L UoF Location

meaning of the established relationship.
Example−−longitude

umlString

located inlocated next tolongitude is a string of characters that represents a geographic
coordinate specifying the east–west position of a point.
Example−−−2.6502400°
2°39.0144' E
2°39'00" E

lsaFailureModeGro
upDescription

DescriptorTypelsaFailureModeGroupDescription is a description that gives
more information on the LSAFailureModeGroup.

LSAFailureModeGr
oup

S3000L UoF LSA Failure ModeGroup

lsaFailureModeGro
upDistributionRat
io

PropertyTypelsaFailureModeGroupDistributionRatio is a property that
identifies the occurrence fraction of the LSAFailureModeGroup in
relation to the entire population of LSAFailureModeGroups identified
for the AnalysisActivityItem.

LSAFailureModeGr
oup

S3000L UoF LSA Failure ModeGroup

lsaFailureModeGro
upIdentifier

IdentifierTypelsaFailureModeGroupIdentifier is an identifier that
establishes a unique designator for a LSAFailureModeGroup and todifferentiate it from other instances of LSAFailureModeGroup.

LSAFailureModeGr
oup

S3000L UoF LSA Failure ModeGroup

lsaFailureModeGro
upNameNameType

lsaFailureModeGroupName is a name by which the
LSAFailureModeGroup is known and can be easily referenced.

LSAFailureModeGr
oup

S3000L UoF LSA Failure ModeGroup

lsaFailureModeGro
upTaskRequirement
PurposeClassificationTypelsaFailureModeGroupTaskRequirementPurpose is aclassification that identifies the role of the referred TaskRequirementin the context of the LSAFailureModeGroup.

LSAFailureModeGr
oupTaskRequireme
nt

S3000L UoF LSA Failure ModeGroup

maintenanceFacili
tyTypeClassificationTypemaintenanceFacilityType is a classification that identifies further
specialization for a MaintenanceFacility.

MaintenanceFacil
ity

S3000L UoF Facility

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 72

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

maintenanceLevelC
apabilityDescript
ion

DescriptorTypemaintenanceLevelCapabilityDescription is a description

MaintenanceLevel

S3000L UoF Product Usage
Context

that gives more information on the ability to perform maintenance basedon availability of support resources and environmental conditions.
Note
The defined abilities are the basis for determining the functions to beaccomplished at the defined maintenance level.
Note
Support resources include eg, personnel and skills, special facilities
and support equipment, etc.

maintenanceLevelI
dentifierIdentifierTypemaintenanceLevelIdentifier is an identifier that establishes aunique designator for a MaintenanceLevel and to differentiate it fromother instances of MaintenanceLevel.

MaintenanceLevel

S3000L UoF Product Usage
Context

maintenanceLevelN
ame

NameType

maintenanceLevelName is a name by which theMaintenanceLevel is known and can be easily referenced.

MaintenanceLevel

S3000L UoF Product Usage
Context

maintenanceSignif
icantOrRelevant

ClassificationTypemaintenanceSignificantOrRelevant is a classfication that
identifies whether a BreakdownElement requires maintenance

BreakdownElement
Revision

S3000L UoF Breakdown
Structure

activities or not.
Note
A maintenance relevant item is an item which can be repaired or
replaced as a result of failure or damage.
Note
A maintenance significant item is an item which has been identified bya selection process coming from a Preventive Maintenance Analysis(PMA) eg, S4000P. For this type of item, a preventive maintenancetask will be documented.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 73

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

materialItemCateg
oryCodeumlStringmaterialItemCategoryCode is a string of characters that

S1000DDataModule

S3000L UoF Document

MeasurementPoint
Definition

S3000L UoF Failure Mode
Symptom

MeasurementPoint
Definition

S3000L UoF Failure Mode
Symptom

MeasurementPoint
Definition

S3000L UoF Failure Mode
Symptom

MeasurementPoint
Definition

S3000L UoF Failure Mode
Symptom

represents the material item category code attribute of the data module
code.
Note
A materialItemCategoryCode must be created in accordancewith the rules defined in S1000D.

measurementPointD
efinitionDescript
ion

DescriptorType

measurementPointD
efinitionIdentifi
er

IdentifierType

measurementPointD
efinitionName

NameType

measurementPointDefinitionDescription is a descriptionthat gives more information on the

MeasurementPointDefinition.
measurementPointDefinitionIdentifier is an identifier that
establishes a unique designator for a

MeasurementPointDefinition and to differentiate it from otherinstances of MeasurementPointDefinition.
measurementPointDefinitionName is a name by which the
MeasurementPointDefinition is known and can be easilyreferenced.

measurementPointD
efinitionType

ClassificationTypemeasurementPointDefinitionType is a classification that
identifies further specialization of MeasurementPointDefinition.
Example−Gauge

measurementPointD
egradedStateDefinitionAssertValue

PropertyType

measurementPointDegradedStateDefinitionAssertValu
e is a property that defines the value to be evaluated as part of the
MeasurementPointDegradedStateDefinition.

MeasurementPoint
DegradedStateDef
inition

S3000L UoF Time Limit

measurementPointD
egradedStateDefinitionAssertValueC
omparisonOperator

ClassificationTypemeasurementPointDegradedStateDefinitionAssertValu
eComparisonOperator is a classification that identifies the

MeasurementPoint
DegradedStateDef
inition

S3000L UoF Time Limit

Applicable to: Allcomparison operator against which a recorded value is to be evaluatedagainst themeasurementPointDegradedStateDefinitionAssertValu
e.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 74

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

measurementPointF
aultStateDefiniti
onAssertValue

PropertyType

measurementPointFaultStateDefinitionAssertValue isMeasurementPoint
FaultStateDefinition

S3000L UoF Failure Mode
SymptommeasurementPointF
aultStateDefiniti
onAssertValueComp
arisonOperator

ClassificationType

MeasurementPoint
FaultStateDefinition

S3000L UoF Failure Mode
SymptommessageContentSta
tus

StateType

Message

S3000L UoF Message

messageContentTypeClassificationType

Message

S3000L UoF Message

messageCreationDa
teTimeDateTimeTypemessageCreationDateTime is a date and time that defines when
the Message was generated.

Message

S3000L UoF Message

messageIdentifier

IdentifierTypemessageIdentifier is an identifier that establishes a uniquedesignator for a Message and allows it to be differentiated from otherinstances of Message.

Message

S3000L UoF Message

messageLanguage

ClassificationTypemessageLanguage is a classification that identifies the language of the

Message

S3000L UoF Message

MessageParty

S3000L UoF Message

MessageRelations
hip

S3000L UoF Message

a property that defines the value to be evaluated as part of the
MeasurementPointFaultStateDefinition.

measurementPointFaultStateDefinitionAssertValueCo
mparisonOperator is a classification that identifies the comparison
operator against which a recorded value is to be evaluated against themeasurementPointFaultStateDefinitionAssertValue.
messageContentStatus is a state that identifies the quality
assurance status of the message content.

messageContentType is a classification that characterizes theinformation included in the message content.

information in the message content.

messagePartyType

ClassificationTypemessagePartyType is a classification that identifies the role of theassociated MessagePartyItem.
Example−−messageRelationsh
ipTypeClassificationType

Applicable to: All

Receiver
SendermessageRelationshipType is a classification that characterizes
the relationship that is established between two Messages.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 75

S3000L-B6865-03000-00

Attribute NameType

Definition

modelIdentificati
onCodeumlStringmodelIdentificationCode is a string of characters that

nonConformanceDes
cription

DescriptorType

Class Name

UoF

represents the model identification code attribute of the data module
code.

S1000DDataModule

S3000L UoF Document

Note
A modelIdentificationCode must be created in accordancewith the rules defined in S1000D.

S1000DPublicatio
nModule

S3000L UoF Document

nonConformanceDescription is a description that gives more

NonConformanceDa
ta

S3000L UoF Product Design
Configuration

NonConformanceDa
ta

S3000L UoF Product Design
Configuration

NonConformanceDa
ta

S3000L UoF Product Design
Configuration

OperatingLocationType

S3000L UoF Product Usage
Context

information on how the

EffectiveOnProductConfigurationItem does not comply
with its requirements.

nonConformanceRes
triction

DescriptorType

nonConformanceRestriction is a description that gives more
information on how the use of the related

EffectiveOnProductConfigurationItem restricts the
specified capabilities of the AllowedProductConfiguration inwhich it is contained.

nonConformanceTypeClassificationType

nonConformanceType is a classification that identifies in which way
the EffectiveOnProductConfigurationItem does not comply
with its requirements.

numberOfOperating
Locations

PropertyType

numberOfOperatingLocations is a property that specifies thenumber of locations of the OperatingLocationType that need to beconsidered when dimensioning for the support solution.

operatingBaseType

ClassificationType

operatingBaseType is a classification that identifies further
specialization for a OperatingBase.

OperatingBase

S3000L UoF Facility

operatingLocation
TypeDescription

DescriptorType

operatingLocationTypeDescription is a description thatgives more information on the OperatingLocationType, including

OperatingLocationType

S3000L UoF Product Usage
Context

the environmental conditions to be expected.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 76

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

operatingLocation
TypeIdentifier

IdentifierType

operatingLocationTypeIdentifier is an identifier that
establishes a unique designator for an OperatingLocationType

OperatingLocationType

S3000L UoF Product Usage
Context

and to differentiate it from other instances ofOperatingLocationType.

operatingLocation
TypeName

NameType

operatingLocationTypeName is a name by which the
OperatingLocationType is known and can be easily referenced.

OperatingLocationType

S3000L UoF Product Usage
Context

operatingRequirem
entAtOperatingLoc
ation

PropertyType

operatingRequirementAtOperatingLocation is a property

ContractedProductVariantAtOperat
ingLocation

S3000L UoF Product Usage
Context

ContractedProductVariantAtOperat
ingLocationType

S3000L UoF Product Usage
Context

RectifyingTask

S3000L UoF Task

PartAsDesignedPa
rtsListRelations
hip

S3000L UoF Part Definition

that specifies the (annual) operating requirement per operating locationand contracted ProductVariant.
Note
Annual operating requirements are typically based on operating hours,
but other measurement bases are also possible.

operatingRequirem
entAtOperatingLoc
ationType

PropertyType

operatingRequirementAtOperatingLocationType is aproperty that specifies the (annual) operating requirement per
OperatingLocationType and contracted ProductVariant.
Note
Annual operating requirements are typically based on operating hours,
but other measurement bases are also possible.

packagedTask

umlBoolean

packagedTask is a boolean that specifies if the Task is created inorder to group a set of defined Tasks for a specific purpose.
Note
Grouping of Tasks that can be performed to support maintenanceplanning and scheduling activities.
Example−partAsDesignedPar
tsListRelationshi
pType

ClassificationType

Applicable to: All

1000 flight hours overhaul

partAsDesignedPartsListRelationshipType is aclassification that identifies the meaning of the established relationship.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 77

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

partDemilitarizat
ionClass

DatedClassification

partDemilitarizationClass is a classification defining special
measures to be taken when a PartAsDesigned is being disposed of.

PartAsDesignedCo
ntrolledItemData

S3000L UoF Part Definition

PartAsDesigned

S3000L UoF Part Definition

PartAsDesignedSu
pportData

S3000L UoF Part Definition

PartAsDesigned

S3000L UoF Part Definition

Note
Special measures can include rendering an item useless for military
purposes or destroy any indications of military purposes or
performance characteristics.

partIdentifier

IdentifierType

partIdentifier is an identifier that establishes a unique designator
for a PartAsDesigned and to differentiate it from other instances of
PartAsDesigned.
NotePart identification includes drawing, model, type, or source
controlling numbers.
Example−partMaturityClass

DatedClassification'12345-501'

partMaturityClass is a classification that defines the maturity of
the PartAsDesigned in order to determine the certainty by which its
characteristics can be valued.

partName

NameType

partName is a name by which the PartAsDesigned is known andcan be easily referenced.

partObsolescenceR
iskAssessment

DescriptorType

partObsolescenceRiskAssessment is a description of the risk
associated with loss of the PartAsDesigned in the supply chain.

PartAsDesignedSu
pportData

S3000L UoF Part Definition

partsListEntryIde
ntifier

IdentifierTypepartsListEntryIdentifier is an identifier that establishes aunique designator for a PartAsDesignedPartsListEntry and to

PartAsDesignedPa
rtsListEntry

S3000L UoF Part Definition

PartAsDesignedPa
rtsListEntry

S3000L UoF Part Definitiondifferentiate it from other instances of

PartAsDesignedPartsListEntry.
partsListEntryQua
ntity

PropertyType

Applicable to: All

partsListEntryQuantity is a property that specifies the amountof the PartAsDesigned used in its parent
PartAsDesignedPartsListRevision.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 78

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

partsListRevision
Date

DateType

partsListRevisionDate is a date that specifies when the
PartAsDesignedPartsList was revised.

PartAsDesignedPa
rtsListRevision

S3000L UoF Part Definition

partsListRevision
Identifier

IdentifierTypepartsListRevisionIdentifier is an identifier that establishes aunique designator for a PartAsDesignedPartsListRevision

PartAsDesignedPa
rtsListRevision

S3000L UoF Part Definition

PartAsDesignedPa
rtsListRevision

S3000L UoF Part Definition

and to differentiate it from other instances of

PartAsDesignedPartsListRevision for the same
partsListType.
partsListRevision
Rationale

DescriptorTypepartsListRevision
StatusStateTypepartsListRevisionStatus is a state that identifies the maturity ofa PartAsDesignedPartsListRevision.

PartAsDesignedPa
rtsListRevision

S3000L UoF Part Definition

partsListType

ClassificationTypepartsListType is a classification that identifies the context andintended use of the PartAsDesignedPartsList.

PartAsDesignedPa
rtsList

S3000L UoF Part Definition

partSpecialHandli
ngRequirement

DescriptorType

partSpecialHandlingRequirement is a description that gives

PartAsDesignedDe
signData

S3000L UoF Part Definition

performanceParame
terCalculationMet
hod

DescriptorType

PerformanceParam
eterValueGroup

S3000L UoF Performance
Parameter

performanceParame
terRevisionDate

DateType

performanceParameterRevisionDate is a date that specifies
when a PerformanceParameterRevision was defined.

PerformanceParameterRevision

S3000L UoF Performance
Parameter

performanceParame
terRevisionIdenti
fier

IdentifierType

performanceParameterRevisionIdentifier is an identifier

PerformanceParameterRevision

S3000L UoF Performance
ParameterpartsListRevisionRationale is a description that gives more
information on the justification for revising the
PartAsDesignedPartsList.

more information on requirements for special handling of the
PartAsDesigned.

performanceParameterCalculationMethod is a descriptionthat gives more information on the method by which theperformanceParameterValue has been derived.

Applicable to: Allthat establishes a unique designator for a

PerformanceParameterRevision and to differentiate it fromother instances of PerformanceParameterRevision.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 79

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

performanceParame
terRevisionRation
ale

DescriptorType

performanceParameterRevisionRationale is a description

PerformanceParameterRevision

S3000L UoF Performance
Parameter

performanceParame
terRevisionStatus

StateTypeperformanceParameterRevisionStatus is a state that
identifies the maturity of a PerformanceParameterRevision.

PerformanceParameterRevision

S3000L UoF Performance
Parameter

performanceParame
terTypeClassificationType

performanceParameterType is a classification that identifies thetype of PerformanceParameter being exchanged.

PerformanceParam
eter

S3000L UoF Performance
Parameter

performanceParame
terValue

PropertyType

performanceParameterValue is a property that represents avalue which is determined for the PerformanceParameter.

PerformanceParam
eterValueGroup

S3000L UoF Performance
Parameter

performanceParame
terValueFraction

PropertyType

performanceParameterValueFraction is a property that

PerformanceParam
eterValueGroup

S3000L UoF Performance
Parameter

PerformanceParam
eter

S3000L UoF Performance
Parameterthat gives more information on the justification for revising the defined
PerformanceParameter and its values.

represents the fraction of all occurrences related to a specified
PerformanceParameter that must be within the limit of the defined
performanceParameterValue.
Example−A customer requirement is that 98% of all replacement tasks must be
performed below a specified value of two hours (= maximum
replacement time)

performanceParame
terValueLimitQual
ifier

ClassificationType

physicalReplaceab
ilityClassificationType

physicalReplaceability is a classification which identifies
whether a part is interchangeable in a specific assembly.

PartAsDesignedPa
rtsListEntry

S3000L UoF Part Definition

physicalReplaceab
ilityStrategy

ClassificationType

physicalReplaceabilityStrategy is a classification that

PartAsDesignedPa
rtsListEntry

S3000L UoF Part Definition

performanceParameterValueLimitQualifier is aclassification that specifies a directed limit to be applied when testing avalue against the defined PerformanceParameter.

identifies the replaceability strategy chosen for a specific customer andmaintenance concept.
Note
Replaceability strategy can include information about the maintenancelevel, at which the replacement task is to be performed.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 80

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

postalCode

umlString

postalCode is a string of characters that represents a short code used

StreetAddress

S3000L UoF Locationby the postal service to identify a geographical area.

productIdentifier

IdentifierType

productIdentifier is an identifier that establishes a uniquedesignator for a Product and to differentiate it from other instances of
Product.

Product

S3000L UoF Product and ProjectproductName

NameType

productName is a name by which the Product is known and can be

Product

S3000L UoF Product and Project

easily referenced.

productUsagePhase
Description

DescriptorType

productUsagePhaseDescription is a description that gives more
information on the ProductUsagePhase.

ProductUsagePhas
e

S3000L UoF Product Usage
Phase

productUsagePhase
Duration

PropertyType

productUsagePhaseDuration is a property that specifies theaverage time that the ProductUsagePhaseItem will remain in the

ProductUsagePhas
e

S3000L UoF Product Usage
Phase

specified state.

productUsagePhase
Name

NameType

productUsagePhaseName is a name by which theProductUsagePhase is known and can be easily referenced.

ProductUsagePhas
e

S3000L UoF Product Usage
Phase

productUsagePhase
RelationshipType

ClassificationType

productUsagePhaseRelationshipType is a classification that

ProductUsagePhas
eRelationship

S3000L UoF Product Usage
Phase

productVariantIde
ntifier

IdentifierType

productVariantIdentifier is an identifier that establishes aunique designator for a ProductVariant and to differentiate it fromother instances of ProductVariant.

ProductVariant

S3000L UoF Product and ProjectproductVariantName

NameType

productVariantName is a name by which the ProductVariant

ProductVariant

S3000L UoF Product and ProjectprojectIdentifier

IdentifierType

projectIdentifier is an identifier that establishes a uniquedesignator for a Project and to differentiate it from other instances ofProject.

Project

S3000L UoF Product and ProjectprojectName

NameType

projectName is a name by which the Project is known and can be

Project

S3000L UoF Product and Project

identifies the meaning of the established relationship.

is known and can be easily referenced.

easily referenced.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 81

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

proposedTrainingM
ethod

ClassificationType

proposedTrainingMethod is a classification that suggests the way

AdditionalTraini
ngNeed

S3000L UoF Task Resource

publicationModule
IssueInWorkNumber

umlString

S1000DPublicatio
nModuleIssue

S3000L UoF Document

S1000DPublicatio
nModuleIssue

S3000L UoF Document

S1000DPublicatio
nModuleIssue

S3000L UoF Document

S1000DPublicatio
nModuleIssue

S3000L UoF Documentin which the additional learning can be acquired.

publicationModuleIssueInWorkNumber is a string ofcharacters used for monitoring and control of intermediate drafts of
S1000DPublicationModuleIssue.
Note
A publicationModuleIssueInWorkNumber must be createdin accordance with the rules defined in S1000D.

publicationModule
IssueLanguage

ClassificationType

publicationModuleIssueLanguage is a classification that
identifies the language used to produce the content of the
S1000DPublicationModuleIssue.
Note
A publicationModuleIssueLanguage must be created inaccordance with the rules defined in S1000D.

publicationModule
IssueLanguageCoun
try

ClassificationType

publicationModuleIssueLanguageCountry is a classificationthat identifies the country where the language, identified bypublicationModuleIssueLanguage, is spoken.
Note
A publicationModuleIssueLanguageCountry must be
created in accordance with the rules defined in S1000D.

publicationModule
IssueNumber

umlString

publicationModuleIssueNumber is a string of characters used
to identify the release number of the

S1000DPublicationModuleIssue.
Note
A publicationModuleIssueNumber must be created inaccordance with the rules defined in S1000D.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 82

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

publicationModule
IssuerumlString

publicationModuleIssuer is a string of characters that

S1000DPublicatio
nModule

S3000L UoF Document

S1000DPublicatio
nModule

S3000L UoF Document

S1000DPublicatio
nModule

S3000L UoF Document

ContainedSubstan
ce

S3000L UoF Part Definition

ContractedProductVariantAtOperat
ingLocation

S3000L UoF Product Usage
Context

ContractedProductVariantAtOperat
ingLocationType

S3000L UoF Product Usage
Context

represents the issuing authority attribute of the publication module code.
Note
A publicationModuleIssuer must be created in accordancewith the rules defined in S1000D.

publicationModule
NumberumlString

publicationModuleNumber is a string of characters that
represents the number of the publication module attribute of the
publication module code.
Note
A publicationModuleNumber must be created in accordancewith the rules defined in S1000D.

publicationModule
VolumeumlString

publicationModuleVolume is a string of characters that
represents the volume of the publication attribute of the publication
module code.
Note
A publicationModuleVolume must be created in accordancewith the rules defined in S1000D.

quantityOfContain
edSubstance

PropertyType

quantityOfProduct
VariantAtOperatin
gLocation

PropertyType

quantityOfProduct
VariantAtOperatin
gLocationType

PropertyType

quantityOfContainedSubstance is a property that identifies theamount of the substance included in the
HardwarePartAsDesigned.

quantityOfProductVariantAtOperatingLocation is aproperty that specifies the number of serialized items, of a specific
ProductVariant, that is to be operated at a specific operating
location.

Applicable to: All

quantityOfProductVariantAtOperatingLocationType isa property that specifies the number of serialized items, of a specific
ProductVariant, that is to be operated at a specificOperatingLocationType.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 83

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

referencedDigital
FileJustification

DescriptorTypereferencedDigitalFileJustification is a phrase thatprovides more information on the reason why the DigitalFile isReferencedDigita
lFile

S3000L UoF Digital File

ReferencedDocume
nt

S3000L UoF Document

ReferencedDocume
nt

S3000L UoF Document

BreakdownElement
UsageInBreakdown

S3000L UoF Breakdown
Structure

PartAsDesignedPa
rtsListEntry

S3000L UoF Part Definition

the function of the established relationship.

ReferencedOrgani
zation

S3000L UoF Organization
Assignment

remarkText is a description that provides the text of the additional

Remark

S3000L UoF Remark

referenced.
Example−referencedDocumentPortion

DescriptorType

A video showing the task execution.

referencedDocumentPortion is a description that provides areference to the portion of a Document which is of interest in a specificusage.

referencedDocumen
tRole

ClassificationTypereferencedDocumentRole is a classification that identifies thefunction of the established relationship.
Example
−
−
−
−
−
−

referenceDesignat
or

IdentifierType

Design document reference
Directive
Document reference
Drawing reference
SourceVerificationreferenceDesignator is an identifier that establishes a uniquedesignator for a location within the overall Product, and to differentiate
it from other locations.
Note
Reference designators serve as a cross reference between partscontained in wiring diagrams, hydraulic systems etc. and eg, theIllustrated Parts Data (IPD).

referencedOrganiz
ationRoleClassificationType

remarkText

DescriptorTypereferencedOrganizationRole is a classification that identifies

information.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 84

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

remarkType

ClassificationType

remarkType is a classification that defines the purpose of the Remark.

Remark

S3000L UoF Remark

ResourceSpecificationRevision

S3000L UoF Resource
Specification

Example−−Internal noteTechnical fact

resourceSpecifica
tionDescription

DescriptorType

resourceSpecificationIdentifier

IdentifierType

resourceSpecificationIdentifier is an identifier that
establishes a unique designator for a ResourceSpecification andto differentiate it from other instances of ResourceSpecification.

ResourceSpecification

S3000L UoF Resource
Specification

resourceSpecifica
tionName

NameType

resourceSpecificationName is a name by which the
ResourceSpecification is known and can be easily referenced.

ResourceSpecificationRevision

S3000L UoF Resource
Specification

resourceSpecifica
tionRevisionDate

DateType

resourceSpecificationRevisionDate is a date that specifies
when the ResourceSpecification was revised.

ResourceSpecificationRevision

S3000L UoF Resource
Specification

resourceSpecifica
tionRevisionIdent
ifier

IdentifierType

resourceSpecificationRevisionIdentifier is an identifier

ResourceSpecificationRevision

S3000L UoF Resource
Specification

resourceSpecifica
tionRevisionRatio
nale

DescriptorType

ResourceSpecificationRevision

S3000L UoF Resource
Specification

resourceSpecifica
tionRevisionStatus

StateType

resourceSpecificationRevisionStatus is a state that
identifies the maturity of a ResourceSpecificationRevision.

ResourceSpecificationRevision

S3000L UoF Resource
Specification

resourceSpecifica
tionType

ClassificationType

resourceSpecificationType is a classification that identifies
further specialization for a ResourceSpecification.

ResourceSpecification

S3000L UoF Resource
Specification

resourceSpecificationDescription is a description thatgives more information on the characteristics that a part realization must
fulfill in order to qualify as a possible resource.

that establishes a unique designator for a

ResourceSpecificationRevision and to differentiate it fromother instances of ResourceSpecificationRevision.
resourceSpecificationRevisionRationale is a descriptionthat gives more information on the justification for revising the
ResourceSpecification.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 85

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

samplingMethodDes
cription

DescriptorType

samplingMethodDescription is a description that gives more

SamplingDefiniti
on

S3000L UoF Time Limit

samplingValue

PropertyType

SamplingDefiniti
on

S3000L UoF Time Limit

information on the way in which the sample must be selected.

samplingValue is a property that specifies the number or fraction of
the total population to be selected.

securityClassificationAuthority

Organization

securityClassificationAuthority identifies theOrganization that is the authoritative source for the defined
SecurityClassification.

SecurityClassifi
cation

S3000L UoF Security
Classification

securityClassificationDate

DateType

securityClassificationDate is a date when the security
classification is declared.

SecurityClassifi
cation

S3000L UoF Security
Classification

securityClassValu
e

NameType

securityClassValue is a name that defines the level of

SecurityClass

S3000L UoF Security
Classification

confidentiality.
Example
−
−
−
−
−
−

Company confidential
Confidential
Restricted
SecretTop secret
Unclassified

skillCodeIdentifierTypeskillCode is an identifier that establishes a unique designator for a
Skill and to differentiate it from other instances of Skill.

Skill

S3000L UoF Competence
Definition

skillLevelDescrip
tion

DescriptorTypeskillLevelDescription is a description that gives more

SkillLevel

S3000L UoF Competence
Definition

skillLevelName

NameType

SkillLevel

S3000L UoF Competence
Definition

information on a proficiency.

Applicable to: All

skillLevelName is a name that uniquely establishes a proficiency.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 86

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

softwareElementLo
adingStrategy

ClassificationType

softwareElementLoadingStrategy is a classification that

SoftwareElementR
evision

S3000L UoF Software Element

SoftwareElementR
evision

S3000L UoF Software Element

SoftwareElementR
evision

S3000L UoF Software Element

identifies the loading strategy chosen for a specific customer andmaintenance concept.
Note
Software loading strategy can be used to include information about
the maintenance level at which the software loading task is to be
performed.

softwareElementMo
dificationFrequencyPropertyType

softwareElementModificationFrequency is a property thatdefines the expected frequency with which theSoftwarePartAsDesigned which realizes thisSoftwareElementRevision will be modified.
Example−−softwareElementSi
ze

PropertyType

3 months
5 years

softwareElementSize is a property that defines the size of the
SoftwarePartAsDesigned which realizes thisSoftwareElementRevision.
Example−−−10.000 lines of code - estimated
23.5 Mbytes - executable
800 Kbytes - contracted

softwareElementTy
peClassificationType

softwareElementType is a classification that identifies further
specialization for a SoftwareElement.

SoftwareElement

S3000L UoF Software Element

softwarePartSize

PropertyType

softwarePartSize is a property that specifies the volume which theSoftwarePartAsDe
signedDesignData

S3000L UoF Part Definition

SoftwarePartAsDe
signedDesignData

S3000L UoF Part Definition

software will occupy on a digital storage media.

softwarePartType

ClassificationType

Applicable to: All

softwarePartType is a classification that identifies how the
SoftwarePartAsDesigned is designed to be installed on therelated HardwarePartAsDesigned.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 87

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

sourceDocumentPor
tion

DescriptorTypesourceDocumentPortion is a description that gives more
information on relevant portions of the related Document.

SubtaskSourceDoc
ument

S3000L UoF Task

specialEventDefinitionCauseCategoryClassificationType

specialEventDefinitionCauseCategory is a classification

SpecialEventDefi
nition

S3000L UoF Special Event

specialEventDefinitionDecription

DescriptorType

specialEventDefinitionDecription is a description thatgives more information on the SpecialEventDefinition.

SpecialEventDefi
nition

S3000L UoF Special Event

specialEventDefinitionName

NameType

specialEventDefinitionName is a name by which theSpecialEventDefinition is known and can be easily referenced.

SpecialEventDefi
nition

S3000L UoF Special Event

specialEventDefinitionOccurrenceVa
lue

PropertyType

specialEventDefinitionOccurrenceValue is a property thatSpecialEventDefi
nition

S3000L UoF Special Event

specialEventOccur
enceRatio

PropertyType

specialEventOccurenceRatio identifies the fraction of anindividual SpecialEventDefinition in relation to the entire
population of special events identified for the Product that will occur inrelation to the associated ProductUsagePhase.

SpecialEventProd
uctUsagePhaseOcc
urrence

S3000L UoF Special EventstreetName

NameTypestreetName is the name by which a road is officially known and can beStreetAddress

S3000L UoF Location

StreetAddress

S3000L UoF Locationthat identifies a generalization that organize special events into an
overarching special event taxonomy.

quantifies how often a defined special event is likely to occur.

easily referenced.
Example−−streetNumber

umlString

E-2561 Road
Main Street

streetNumber is a string of characters that represents the position
along a street.
Example−−Applicable to: All

4
Km 35.5

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 88

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

substanceCharacte
risticsRecordingD
ate

DateType

substanceCharacteristicsRecordingDate is a date thatdefines when a SubstanceDefinition was last updated.

SubstanceDefinition

S3000L UoF Part Definition

substanceDescript
ion

DescriptorType

substanceDescription is a description that gives more information

SubstanceDefinition

S3000L UoF Part Definition

substanceIdentifi
er

IdentifierType

substanceIdentifier is an identifier that establishes a uniquedesignator for a SubstanceDefinition and to differentiate it fromother instances of SubstanceDefinition.

SubstanceDefinition

S3000L UoF Part Definition

substanceName

NameType

substanceName is a name by which the SubstanceDefinition

SubstanceDefinition

S3000L UoF Part Definition

SubstanceDefinition

S3000L UoF Part Definition

SubstanceDefinition

S3000L UoF Part Definition

SubstanceDefinition

S3000L UoF Part Definition

possible limitations in substance usage.

subSubSystem is a string of characters that represents the sub-

S1000DDataModule

S3000L UoF Document

S1000DDataModule

S3000L UoF Documenton the substance.

is known and can be easily referenced.

substanceRiskDesc
riptionDescriptorType

substanceRiskFact
orClassificationType

substanceUsageCat
egory

ClassificationType

subSubSystem

umlString

substanceRiskDescription is a description that specifies risks
associated with the substance.

substanceRiskFactor is a classification which identifies possible
risks associated with substance usage.

substanceUsageCategory is a classification which identifies

subsystem attribute of the data module code.
Note
A subSubSystem must be created in accordance with the rules
defined in S1000D.

subSystem

umlString

subSystem is a string of characters that represents the subsystem
attribute of the data module code.
Note
A subSystem must be created in accordance with the rules definedin S1000D.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 89

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

subtaskAcceptanceParameterDescript
ion

DescriptorTypesubtaskAcceptanceParameterDescription is a description

SubtaskAcceptanc
eParameter

S3000L UoF Task

subtaskAcceptanceParameterName

NameType

SubtaskAcceptanc
eParameter

S3000L UoF Task

SubtaskAcceptanc
eParameter

S3000L UoF Task

SubtaskAcceptanc
eParameter

S3000L UoF Task

that gives more information on the criteria that determines whether a
Subtask is completed or not.

subtaskAcceptanceParameterName is a name by which theSubtaskAcceptanceParameter is known and can be easilyreferenced.

subtaskAcceptanceParameterValue

PropertyType

subtaskAcceptanceParameterValue is a property that specifies
the value (criteria) that must be fulfilled before the Subtask can beended.

subtaskAcceptanceParameterValueComparisonOperator

ClassificationType

subtaskAcceptanceParameterValueComparisonOperator

subtaskDescriptionDescriptorTypesubtaskDescription is a description of the procedure performed
during the Subtask.

SubtaskByDefinition

S3000L UoF Task

subtaskDuration

PropertyType

subtaskDuration is a property that specifies the average timerequired for the performance of a Subtask, regardless of the number ofSubtaskByDefinition

S3000L UoF Task

SubtaskByDefinition

S3000L UoF Task

is a classification that identifies the comparison operator against which a
recorded value is to be evaluated against thesubtaskAcceptanceParameterValue.

personnel working simultaneously.
NotesubtaskDuration does not include time spent awaiting spares,
support equipment, facilities or personnel (logistics delay time).

subtaskEndItemObj
ectiveState

StateType

Applicable to: AllsubtaskEndItemObjectiveState is a state that identifies thecondition of the Product that will exist after the accomplishment of the
Subtask.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 90

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

subtaskIdentifier

IdentifierTypesubtaskIdentifier is an identifier that establishes a uniquedesignator for a Subtask and to differentiate it from other instances ofSubtask.

Subtask

S3000L UoF Task

SubtaskByDefinition

S3000L UoF Task

SubtaskByDefinition

S3000L UoF Task

SubtaskByDefinition

S3000L UoF Task

Subtask

S3000L UoF Task

Note
A Subtask is identified within the context of a specific Task.

subtaskInformatio
nCodeClassificationType

subtaskInformationCode is a classification that identifies the main
purpose for the Subtask.
Note
A subtaskInformationCode must be created in accordancewith the rules defined in S1000D.

subtaskMaintenanc
eLocation

ClassificationType

subtaskMaintenanceLocation is a classification that specifies
where the Subtask will be performed in relation to the Product.
Note
Proposed values equal the S1000D Item Location Codes.

subtaskName

NameTypesubtaskName is a name by which the Subtask is known and can beeasily referenced.

subtaskRole

ClassificationType

subtaskRole is a classification that identifies how the Subtask isrelated to the main function of the Task.
NotesubtaskRole enables mapping between S3000L and the main
portions of the S1000D procedure schema.

subtaskTimelineEv
ent

ClassificationType

subtaskTimelineEvent is a classification that identifies how thestarting point for a Subtask depends upon its preceding Subtask.

SubtaskTimeline

S3000L UoF Task

subtaskTimelineLag

PropertyType

subtaskTimelineLag is a property that specifies the time that must
elapse before the Subtask under consideration can start in relation to
its associated subtaskTimelineEvent.

SubtaskTimeline

S3000L UoF Task

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 91

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

systemumlStringsystem is a string of characters that represents the system attribute of

S1000DDataModule

S3000L UoF Document

S1000DDataModule

S3000L UoF Document

TaskRevision

S3000L UoF Task

TaskFrequency

S3000L UoF Task Usage

TaskFrequency

S3000L UoF Task Usage

the data module code.
Note
A system must be created in accordance with the rules defined in
S1000D.

systemDifferenceC
ode

umlStringsystemDifferenceCode is a string of characters that represents thesystem difference code attribute of the data module code.
Note
A systemDifferenceCode must be created in accordance withthe rules defined in S1000D.

taskDuration

PropertyType

taskDuration is a property that specifies the average time required
for the performance of a Task, regardless of the number of personnel
working simultaneously.
NotetaskDuration does not include time spent awaiting spares,
support equipment, facilities or personnel (logistics delay time).
NotetaskDuration could be calculated from the subtask durations.
taskFrequencyCalc
ulationMethod

DescriptorTypetaskFrequencyValu
ePropertyType

taskIdentifier

IdentifierType

taskIdentifier is an identifier that establishes a unique designator
for a Task and to differentiate it from other instances of Task.

Task

S3000L UoF Task

taskInformationCodeClassificationType

taskInformationCode is a classification that identifies the main
purpose for the Task.

TaskRevision

S3000L UoF Task

taskFrequencyCalculationMethod is a description that gives
further information on how the TaskFrequencyValue has been derived.

taskFrequencyValue is a property that represents the rate ofoccurrence value.

Note
Valid classifications are defined in the S1000D.

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 92

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

taskInfrastructureResourceCategory

ClassificationType

taskInfrastructureResourceCategory is a classification that

TaskInfrastructu
reResource

S3000L UoF Task Resource

identifies further specialization for a

TaskInfrastructureResource.
taskInfrastructureResourceQuantity

PropertyType

taskInfrastructureResourceQuantity is a property thatspecifies the number of the TaskInfrastructureResource.

TaskInfrastructu
reResource

S3000L UoF Task Resource

taskMaterialResou
rceCategory

ClassificationTypetaskMaterialResourceCategory is a classification that defines
the role of the TaskMaterialResource in the context of thespecified Task.

TaskMaterialReso
urce

S3000L UoF Task Resource

taskMaterialResourceQuantity

PropertyType

taskMaterialResourceQuantity is a property that specifies thenumber of a TaskMaterialResource.

TaskMaterialReso
urce

S3000L UoF Task Resource

taskName

NameType

taskName is a name by which the Task is known and can be easily

TaskRevision

S3000L UoF Task

TaskRevision

S3000L UoF Task

TaskPersonnelRes
ource

S3000L UoF Task Resource

TaskPersonnelRes
ource

S3000L UoF Task Resource

referenced.

taskOperabilityIm
pact

ClassificationType

taskPersonnelReso
urceLaborTime

PropertyTypetaskOperabilityImpact is a classification that indicates theoperational status and mission readiness of the end item during the
Task.

taskPersonnelResourceLaborTime is a property that specifies
the time expended by the required TaskPersonnelResource.
Note
Labor time can be given as single values but also as ranges or as text
eg, "AsRequired".

taskPersonnelReso
urceQuantity

PropertyType

taskPersonnelResourceQuantity is a property that specifies
the number of the required TaskPersonnelResource
Note
Quantities can be given as single values but also as ranges or as text
eg, "AsRequired".

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 93

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

taskPersonnelReso
urceRole

ClassificationType

taskPersonnelResourceRole is a classification that defines the
purpose of the required TaskPersonnelResource.

TaskPersonnelRes
ource

S3000L UoF Task Resource

TaskRevision

S3000L UoF Task

TaskRevision

S3000L UoF Task

Example−−−−−taskPersonnelSafe
tyCriticality

ClassificationType

taskProductIntegr
ityCriticality

ClassificationType

Man A
Man B
Performer
Quality assurance
Supervisor

taskPersonnelSafetyCriticality is a classification that
identifies the most serious health aspects that the performance of the
Task can pose on personnel performing the Task.

taskProductIntegrityCriticality is a classification that
identifies whether the Task is critical ie, if failure to accomplish it would
result in adverse effects on product or system reliability, efficiency,
effectiveness, safety, or cost.
Note
A task will also be designated as critical whenever system design
characteristics approach human limitations, and thereby, significantly
increase the likelihood of degraded, delayed, or otherwise impaired
mission performance.

taskRequirementAu
thority

Organization

taskRequirementAuthority identifies the Organization thatis the authoritative source for the identified TaskRequirement.

AuthorityDrivenT
askRequirement

S3000L UoF Task Requirement

taskRequirementAu
thoritySourceType

ClassificationType

taskRequirementAuthoritySourceType is a classification thatindicates the significance of the source from which TaskRequirement

AuthorityDrivenT
askRequirement

S3000L UoF Task Requirement

TaskRequirementR
evision

S3000L UoF Task Requirement

is derived.

taskRequirementDe
scription

DescriptorType

Applicable to: All

taskRequirementDescription is a description that summarizes
the procedure that needs to be performed based on the outcome of a
support analysis activity.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 94

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

taskRequirementId
entifier

IdentifierType

taskRequirementIdentifier is an identifier that establishes aunique designator for a TaskRequirement and to differentiate it fromother instances of TaskRequirement.

TaskRequirement

S3000L UoF Task Requirement

taskRequirementIn
formationCode

ClassificationType

taskRequirementInformationCode is a classification that
identifies the main purpose for the TaskRequirement.

TaskRequirementR
evision

S3000L UoF Task Requirement

TaskRequirementJ
ustification

S3000L UoF Task Requirement

TaskRequirementR
evision

S3000L UoF Task Requirement

Note
Valid classifications are defined in the S1000D.

taskRequirementJu
stificationDescri
ption

DescriptorType

taskRequirementRe
visionChangeDescr
iptionDescriptorType

taskRequirementRe
visionDate

DateTypetaskRequirementRevisionDate is a date that specifies when a
TaskRequirementRevision was defined.

TaskRequirementR
evision

S3000L UoF Task Requirement

taskRequirementRe
visionIdentifier

IdentifierType

taskRequirementRevisionIdentifier is an identifier that
establishes a unique designator for a TaskRequirementRevision

TaskRequirementR
evision

S3000L UoF Task Requirement

TaskRequirementR
evision

S3000L UoF Task Requirement

taskRequirementJustificationDescription is a
description that summarizes the need for a Task to meet the results froma support analysis activity.

taskRequirementRevisionChangeDescription is a
description that gives more information on content that has been altered
between two revisions of a TaskRequirement.

and to differentiate it from other instances of
TaskRequirementRevision.

taskRequirementRe
visionRationale

DescriptorType

taskRequirementRe
visionStatus

StateTypetaskRequirementRevisionStatus is a state that identifies thematurity of a TaskRequirementRevision.

TaskRequirementR
evision

S3000L UoF Task Requirement

taskRequirementSp
ecialResourceRequirement

DescriptorType

taskRequirementSpecialResourceRequirement is a

TaskRequirementR
evision

S3000L UoF Task Requirement

taskRequirementRevisionRationale is a description thatgives more information on the justification for revising the
TaskRequirement.

Applicable to: All

description that gives more information on unusual resources which areneeded for the performance of the required Task.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 95

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

taskResourceDurat
ion

PropertyType

taskResourceDuration is a property that specifies the averagetime that a TaskResource is needed to perform a specified amount of

TaskResource

S3000L UoF Task Resource

TaskResource

S3000L UoF Task Resource

work.

taskResourceFixed
ResourceMarker

umlBoolean

taskResourceIdent
ifier

IdentifierType

taskResourceIdentifier is an identifier that establishes a uniquedesignator for a TaskResource and to differentiate it from otherinstances of TaskResource.

TaskResource

S3000L UoF Task Resource

taskResourceRelat
ionshipType

ClassificationType

taskResourceRelationshipType is a classification that identifies

TaskResourceRela
tionship

S3000L UoF Task Resource

the meaning of the established relationship.

taskRevisionChangeDescription

DescriptorType

taskRevisionChangeDescription is a description that gives

TaskRevision

S3000L UoF Task

taskRevisionDate

DateType

TaskRevision

S3000L UoF Task

taskResourceFixedResourceMarker is a boolean that identifies
that no resource other than the one specified is allowed to be used as the
TaskResourceItem.

more information on content that has been altered between two revisionsof a Task.

taskRevisionDate is a date that specifies when the Task wasrevised.

taskRevisionIdent
ifier

IdentifierType

taskRevisionIdentifier is an identifier that establishes a uniquedesignator for a TaskRevision and to differentiate it from otherinstances of TaskRevision.

TaskRevision

S3000L UoF Task

taskRevisionRatio
nale

DescriptorType

taskRevisionRationale is a description that gives more
information on the justification for revising the Task.

TaskRevision

S3000L UoF Task

taskRevisionStatus

StateTypetaskRevisionStatus is a state that identifies the progress on thedevelopment of a TaskRevision.

TaskRevision

S3000L UoF Task

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 96

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

taskTotalLaborTime

PropertyType

taskTotalLaborTime is a property that specifies the total time to be
expended during a Task.

TaskRevision

S3000L UoF Task

TechnologyBehavi
orRating

S3000L UoF Damage Definition

TechnologyBehavi
orRating

S3000L UoF Damage Definition

ParameterThresho
ldDefinition

S3000L UoF Time Limit

ParameterThresho
ldDefinition

S3000L UoF Time Limit

TimeLimit

S3000L UoF Time Limit

Note

taskTotalLaborTime includes the labor time for all required task
personnel resources.

technologyBehavio
rKnowledgeRating

DatedClassification

technologySensiti
vityRating

DatedClassification

technologyBehaviorKnowledgeRating is a classification that
identifies to which extent knowledge exist on the behavior of thetechnology used, during normal use or caused by special event.

technologySensitivityRating is a classification that identifies
the likelihood that the AnalysisCandidateItem will be subject fordamage during its life cycle.

thresholdValue

PropertyType

thresholdValue is a property that represents the value that ismeasured and evaluated as part of theParameterThresholdDefinition.
thresholdValueQua
lifierClassificationType

timeLimitDescript
ion

DescriptorType

timeLimitHarmonizationIndicator

umlBoolean

timeLimitHarmonizationIndicator is a boolean that identifies
if the TimeLimit is the result from a Task packaging procedure.

TimeLimit

S3000L UoF Time Limit

tradeName

NameType

tradeName is a name that uniquely establishes a craft or profession.

Trade

S3000L UoF Competence
Definition

warningCautionNot
eDescription

DescriptorTypewarningCautionNoteDescription is a description that gives

WarningCautionNo
te

S3000L UoF Task

thresholdValueQualifier is a classification that specifies a
constraint to be used when evaluating an actual value against thethresholdValue.

timeLimitDescription is a description that provides a humanreadable expression of the defined time limit expression.

Applicable to: All

more information on safety, legal and health considerations.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 97

S3000L-B6865-03000-00

Attribute NameType

Definition

Class Name

UoF

warningCautionNot
eIdentifier

IdentifierTypewarningCautionNoteIdentifier is an identifier that establishes

WarningCautionNo
te

S3000L UoF Task

warningCautionNot
eType

ClassificationType

WarningCautionNo
te

S3000L UoF Task

zoneElementType

ClassificationType

ZoneElement

S3000L UoF Zone Elementa unique designator for a warning, caution or note, and to differentiate itfrom other instances of warning , caution or note.

warningCautionNoteType is a classification that identifies severity
and scope for the safety, legal and health considerations.

Applicable to: All

zoneElementType is a classification that identifies further
specialization for a ZoneElement.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 98

S3000L-B6865-03000-00

4

Valid values
The full list of S3000L attribute valid values is provided in Table 4.
Note
The specification does not yet define valid values for all classification types.
Note
Specified valid values are recommended values and projects can therefore tailor the valid
values as needed (refer to SX005G).
Table 4 List of valid values

Attribute name

Valid value

Valid value nameaggregatedElementType

FA

SX001G:familyBreakdownElement

FU

SX001G:functionBreakdownElementGR

SX001G:groupBreakdownElement

SY

SX001G:systemBreakdownElement

allowedProductConfigurationId
entifierID

SX001G:allowedProductConfigurationIdentifier

analysisActivityDecisionO

SX001G:toBeDecidedAnalysisActivity

R

SX001G:rejectedAnalysisActivity

S

SX001G:selectedAnalysisActivity

ID

SX001G:analysisActivityRevisionIdentifier

analysisActivityRevisionIdent
ifier
analysisActivityRevisionStatusanalysisActivityType

Refer to revisionStatusCode valid value library,
Para 5.

CMP

SX001G:lsaComparativeAnalysis

COR

SX001G:lsaCorrectiveMaintenanceAnalysis

DMG

SX001G:lsaDamageAnalysis

HF

SX001G:lsaHumanFactorAnalysis

LORA

SX001G:lsaLevelOfRepairAnalysis

MNT

SX001G:lsaMaintainabilityAnalysis

MTA

SX001G:lsaMaintenanceTaskAnalysis

OP

SX001G:lsaOperationalAnalysis

OTH

SX001G:lsaOtherAnalysis

REL

SX001G:lsaReliabilityAnalysis

SEV

SX001G:lsaSpecialEventAnalysis

SIM

SX001G:lsaSimulationOperationalScenariosAnalysis

SWD

SX001G:lsaSoftwareDataLoadingAnalysis

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 99

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value nameSWS

SX001G:lsaSoftwareSupportAnalysis

TNA

SX001G:lsaTrainingNeedsAnalysis

TST

SX001G:lsaTestabilityAnalysis

F

SX001G:fullCandidateItem

N

SX001G:nonCandidateItem

O

SX001G:toBeDecidedCandidateItem

P

SX001G:partialCandidateItem

applicabilityStatementIdentif
ier

ID

SX001G:applicabilityStatementIdentifier

authorityToOperateIdentifierID

SX001G:authorityToOperateIdentifier

breakdownElementEssentiality

1

SX001G:criticalBreakdownElement

2

SX001G:partialCriticalBreakdownElement

3

SX001G:nonCriticalBreakdownElement

ASD

SX001G:asdSystemHardwareIdentificationCodeCSN

SX001G:figureItemIdentifierID

SX001G:breakdownElementIdentifier

LCN

SX001G:fullLogisticsSupportAnalysisControlNumber

SNS

SX001G:standardNumberingSystemIdentifier

breakdownElementRevisionIdent
ifier

ID

SX001G:breakdownElementRevisionIdentifier

breakdownElementRevisionRelat
ionshipType

ALT

SX001G:alternateToBreakdownElement

AP

SX001G:breakdownElementAccessPointFP

SX001G:functionalToPhysicalBreakdownElementRelationship

analysisCandidateItemSelectio
nIndicator

breakdownElementIdentifier

breakdownElementRevisionStatus

Refer to revisionStatusCode valid value library,
Para 5.

breakdownElementUsageIdentifi
er

ID

SX001G:breakdownElementUsageIdentifier

breakdownElementUsageRelation
shipTypeAND

SX001G:mutualBreakdownElementInclusion

XOR

SX001G:mutualBreakdownElementExclusion

breakdownRevisionIdentifierID

SX001G:breakdownRevisionIdentifier

breakdownRevisionRelationship
Type

BO

SX001G:basedOnBreakdownRevision

M

SX001G:matchesBreakdownRevision

breakdownRevisionStatus

Applicable to: All

Refer to revisionStatusCode valid value library,
Para 5.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 100

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namebreakdownType

ASD

SX001G:asdSystemHardwareBreakdown

FAM

SX001G:familyBreakdown

FU

SX001G:functionalBreakdownPH

SX001G:physicalBreakdown

PR

SX001G:provisioningBreakdown

SY

SX001G:systemBreakdown

ZONE

SX001G:zonalBreakdown

AMN

SX001G:changeAmendmentNumber

CAN

SX001G:changeAuthorizationNumberID

SX001G:changeAuthorizationIdentifierA

SX001G:applicabilityChangeNotificationE

SX001G:editorialChangeNotification

M

SX001G:markupChangeNotification

T

SX001G:technicalChangeNotification

changeRequestIdentifierID

SX001G:changeRequestIdentifierchangeRequestStatusA

SX001G:approvedChangeRequestIW

SX001G:inWorkChangeRequestR

SX001G:rejectedChangeRequestS

SX001G:submittedChangeRequest

circuitBreakerIdentifierID

SX001G:circuitBreakerIdentifier

circuitBreakerSettingIdentifi
er

ID

SX001G:circuitBreakerSettingIdentifier

circuitBreakerSettingsIdentif
ier

ID

SX001G:circuitBreakerSettingsIdentifier

circuitBreakerStateC

SX001G:closeCircuitBreakerStateO

SX001G:openCircuitBreakerStateVC

SX001G:verifyCloseCircuitBreakerStateVO

SX001G:verifyOpenCircuitBreakerState

CLIP

SX001G:dummyCircuitBreaker

ELMEC

SX001G:electroMechanicCircuitBreaker

ELTRO

SX001G:electronicCircuitBreakerID

SX001G:competencyDefinitionIdentifierchangeAuthorizationIdentifierchangeNotificationType

circuitBreakerTypecompetencyDefinitionIdentifierApplicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 101

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namecompetencyDefinitionType

CRED

SX001G:credentialCompetencyDefinition

EXPE

SX001G:experienceCompetencyDefinitionJOBT

SX001G:jobTitleCompetencyDefinitionID

SX001G:conditionInstanceIdentifierSB

SX001G:serviceBulletinIdentifierconditionInstanceIdentifierconditionTypeAssertMemberAsse
rtValueComparisonOperator

Refer to comparisonOperatorCode valid value library,
Para 5.

contractIdentifierID

SX001G:contractIdentifiercontractPartyRole

CTR

SX001G:contractor

CUS

SX001G:customer

SUB

SX001G:subContractor

USER

SX001G:user

EXTC

SX001G:extendsContract

RELC

SX001G:relatedContractREPC

SX001G:replacesContract

SUBC

SX001G:subContractOf

contractRelationshipType

countryCode
damageDefinitionFamily

Refer to countryCodeValues valid value library,
Para 5.

CRK

SX001G:crackDamageDefinition

DNT

SX001G:dentDamageDefinition

SCR

SX001G:scratchDamageDefinition

dataModuleIssueLanguage

Refer to languageCodeValues valid value library,
Para 5.

dataModuleIssueLanguageCountryRefer to countryCodeValues valid value library,
Para 5.

decisionTreeTemplateActionDef
initionIdentifierID

SX001G:decisionTreeTemplateActionDefinitionIdentif
ier

decisionTreeTemplateIdentifier

ID

SX001G:decisionTreeTemplateIdentifier

decisionTreeTemplateQuestionD
efinitionIdentifierID

SX001G:decisionTreeTemplateQuestionDefinitionIde
ntifierdecisionTreeTemplateRevisionI
dentifierID

SX001G:decisionTreeTemplateRevisionIdentifier

decisionTreeTemplateRevisionS
tatus
detectionMeansAlarmIdentifier

Refer to revisionStatusCode valid value library,
Para 5.

ID

Applicable to: All

SX001G:detectionMeanAlarmIdentifier

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 102

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namedetectionMeansAlarmType

BIT

SX001G:builtInTest

CBIT

SX001G:continuousBuiltInTest

GSE

SX001G:groundSupportEquipmentTestIBIT

SX001G:initiatedBuiltInTest

PBIT

SX001G:powerOnBuiltInTest

3D

SX001G:3dModelFileContent

AUD

SX001G:audioFileContent

DRW

SX001G:drawingFileContent

MOV

SX001G:movieFileContent

PHO

SX001G:photographFileContent

PUB

SX001G:publicationFileContent

REP

SX001G:reportFileContent

SCH

SX001G:schematicsFileContent

WIR

SX001G:wiringFileContent

digitalFileLocatorID

SX001G:digitalFileLocator

digitalFileType

ASF

SX001G:advanceSystemsFormatFileType

AVI

SX001G:audioVideoInterleavedFileType

BIN

SX001G:binaryFileType

CGM

SX001G:computerGraphicsMetafileFileType

DAT

SX001G:dataFormatFileType

DOC

SX001G:microsoftWordFormatFileType

DOCX

SX001G:microsoftWordFormatFileType

EDF

SX001G:europeanDataFormatSignalFileType

HTM

SX001G:hyperTextMarkupLanguageFileTypeJPEG

SX001G:jointPhotographicExpertsGroupFileType

MOV

SX001G:quickTimeMovieFileType

MP3

SX001G:mp3AudioFileType

MPEG

SX001G:motionPictureExpertsGroupMovieFileType

ODS

SX001G:openDocumentSpreadsheetFileTypeODTSX001G:openDocumentTextFileType

PDF

SX001G:portableDocumentFormatFileType

PNG

SX001G:portableNetworkGraphicsFileType

digitalFileContentClass

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 103

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value nameRAW

SX001G:rawSampleAudioFileType

TIFF

SX001G:taggedImageFileFormatFileType

TXT

SX001G:textFileType

UNK

SX001G:unknownFileType

WAV

SX001G:waveformAudioFileType

XLS

SX001G:microsoftExcelFormatFileType

XLSX

SX001G:microsoftExcelFormatFileType

XSD

SX001G:xmlSchemaDefinitionFileTypedocumentIdentifierID

SX001G:documentIdentifier

documentIssueIdentifierID

SX001G:documentIssueIdentifier

documentType

DRW

SX001G:drawingDocument

PCAT

SX001G:partsCatalogueDocument

SPEC

SX001G:specificationDocument

STD

SX001G:standardsDocument

TMAN

SX001G:technicalManualTR

SX001G:technicalReportenvironmentDefinitionCharacte
risticValueComparisonOperator

Refer to comparisonOperatorCode valid value library,
Para 5.

environmentDefinitionIdentifi
er

ID

SX001G:environmentDefinitionIdentifierenvironmentDefinitionRelation
shipTypeSPEC

SX001G:specializationOfEnvironmentDefinition

SSNL

SX001G:seasonalEnvironmentDefinitionVariationID

SX001G:environmentDefinitionRevisionIdentifierenvironmentDefinitionRevision
IdentifierenvironmentDefinitionRevision
StatusevaluationByAssertionRole

Refer to revisionStatusCode valid value library,
Para 5.

CUS

SX001G:customerOP

SX001G:operator

facilityIdentifierID

SX001G:facilityIdentifier

facilityRelationshipType

INCL

SX001G:includesFacility

failureModeAnalysisRevisionId
entifierID

SX001G:failureModeAnalysisRevisionIdentifier

failureModeAnalysisRevisionSt
atus

Applicable to: All

Refer to revisionStatusCode valid value library,
Para 5.

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 104

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namefailureModeAnalysisType

E

SX001G:equipmentFailureModeAnalysis

F

SX001G:systemFunctionFailureModeAnalysis

failureModeCauseIdentifierID

SX001G:failureModeCauseIdentifier

failureModeCauseItemRelations
hipTypeA

SX001G:failureCauseAffectedItem

C

SX001G:failureCauseConsequenceOf

I

SX001G:catastrophicFailureModeConsequenceII

SX001G:criticalFailureModeConsequenceIII

SX001G:marginalFailureModeConsequenceIV

SX001G:negligibleFailureModeConsequenceE

SX001G:systemEndItemFailureModeEffectH

SX001G:higherFailureModeEffectL

SX001G:localFailureModeEffectN

SX001G:nextHigherFailureModeEffectfailureModeIdentifierID

SX001G:failureModeIdentifier

failureModeIsolationAbilityRating

H

SX001G:highLikelihoodFailureModeIsolationRating

L

SX001G:lowLikelihoodFailureModeIsolationRating

M

SX001G:mediumLikelihoodFailureModeIsolationRating

MH

SX001G:moderatelyHighLikelihoodFailureModeIsolati
onRating

ML

SX001G:moderatelyLowLikelihoodFailureModeIsolati
onRating

failureModeSymptomsSignatureI
dentifierID

SX001G:failureModeSymptomsSignatureIdentifier

geographicalAreaType

ADM

SX001G:administrativeRegion

CITY

SX001G:city

CON

SX001G:continent

CTYG

SX001G:countryGroupDES

SX001G:desert

MUL

SX001G:multiGeographicalArea

OCE

SX001G:ocean

REG

SX001G:geographicalRegion

SEA

SX001G:sea

failureModeCriticality

failureModeEffectLevel

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 105

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namegeographicalCoordinateSystem

DD

SX001G:decimalDegreeGeographicalCoordinateSyst
em

DMS

SX001G:degreeMinutesSecondsGeographicalCoordi
nateSystemN

SX001G:nonRepairableHardwareElementP

SX001G:partialRepairableHardwareElement

R

SX001G:repairableHardwareElement

B

SX001G:reconditionHardwareElement

D

SX001G:limitedRepairAtLowerLevelOverhaulAtDepot
LevelHardwareElementF

SX001G:repairAtIntermediateLevelHardwareElement

L

SX001G:repairAtIndustryLevelHardwareElementO

SX001G:repairAtOrganizationalLevelHardwareElement

Z

SX001G:nonRepairableHardwareElementN

SX001G:nonReplaceableHardwareElement

R

SX001G:replaceableHardwareElement

LINE

SX001G:lineReplaceableHardwareElement

SHOP

SX001G:shopReplaceableHardwareElementSD

SX001G:structuralDetailSI

SX001G:structuralItem

SSI

SX001G:structuralSignificantItem

EQP

SX001G:equipmentHardwareElement

OPN

SX001G:openingHardwareElement

PNL

SX001G:panelHardwareElement

A

SX001G:acidificationPart

B

SX001G:energyRegainedByBurningPart

G

SX001G:greenhouseEffectPart

H

SX001G:harmfulToEnvironmentPart

O

SX001G:dangerousForOzoneLayerPart

R

SX001G:materialRecyclingPart

W

SX001G:materialWastePart

A

SX001G:acidificationPart

B

SX001G:energyRegainedByBurningPart

hardwareElementRepairability

hardwareElementRepairabilityS
trategy

hardwareElementReplaceability

hardwareElementReplaceability
Strategy
hardwareElementStructuralIndi
cator

hardwareElementType

hardwarePartEnvironmentalAspe
ctInUseClass

hardwarePartEnvironmentalAspe
ctPlannedDisposalClass

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 106

S3000L-B6865-03000-00

Attribute namehardwarePartFitmentRequirementValid value

Valid value name

G

SX001G:greenhouseEffectPart

H

SX001G:harmfulToEnvironmentPart

O

SX001G:dangerousForOzoneLayerPart

R

SX001G:materialRecyclingPart

W

SX001G:materialWastePart

MAJ

SX001G:majorFitmentRequiredPart

MIN

SX001G:minorFitmentRequiredPart

NO

SX001G:noFitmentRequiredPart

hardwarePartHazardousClass
hardwarePartLogisticsCategory

hardwarePartMaintenanceSchedu
lingStart

hardwarePartRepairability

hardwarePartRepairabilityStra

Refer to hardwarePartHazardousClassCode valid
value library, Para 5.

C

SX001G:consumablePart

E

SX001G:expendableSparePart

EP

SX001G:expendablePersonalProtectionPart

HT

SX001G:standardHandTool

IT

SX001G:informationTechnologyPart

M

SX001G:rawMaterial

PA

SX001G:packagingPart

PE

SX001G:personalProtectionPart

PR

SX001G:productProtectionPart

R

SX001G:repairableSparePart

S

SX001G:sparePart

SE

SX001G:supportEquipment

A

SX001G:maintenanceSchedulingStartAtInstallationIn
AssemblyPart

D

SX001G:maintenanceSchedulingStartsAtDeliveryPart

E

SX001G:maintenanceSchedulingStartsAtInstallationI
nEndItemPart

P

SX001G:maintenanceSchedulingStartsAtProductionP
art

N

SX001G:nonRepairablePart

P

SX001G:partialRepairablePart

R

SX001G:repairablePart

B

SX001G:reconditionPart

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 107

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value name

tegy

D

SX001G:limitedRepairAtLowerLevelOverhaulAtDepot
LevelPartF

SX001G:repairAtIntermediateLevelPart

L

SX001G:repairAtIndustryLevelPart

O

SX001G:repairAtOrganizationalLevelPart

Z

SX001G:nonRepairablePart

GBX

SX001G:gearBoxPartSupportFamilyClassHTR

SX001G:heaterPartSupportFamilyClassPMP

SX001G:pumpPartSupportFamilyClassVLVSX001G:valvePartSupportFamilyClassB

SX001G:batchTraceabilityPart

N

SX001G:noTraceabilityRequiredPart

S

SX001G:serializedTraceabilityPart

F

SX001G:fullInfrastructureComplianceN

SX001G:nonInfrastructureComplianceP

SX001G:partialInfrastructureComplianceID

SX001G:inServiceOptimizationAnalysisRevisionIdenti
fier

hardwarePartSupportFamilyClasshardwarePartTraceabilityClass

infrastructureComplianceLevel

inServiceOptimizationAnalysis
RevisionIdentifier
inServiceOptimizationAnalysis
RevisionStatus

Refer to revisionStatusCode valid value library,
Para 5.

inServiceOptimizationAnalysis
StepIdentifierID

SX001G:inServiceOptimizationAnalysisStepIdentifier

locationRelationshipType

IN

SX001G:locationLocatedInNXT

SX001G:locationLocatedNextTo

lsaFailureModeGroupIdentifierID

SX001G:lsaFailureModeGroupIdentifier

lsaFailureModeGroupTaskRequir
ementPurposeC

SX001G:failureModeCorrectiveTaskRequirementI

SX001G:failureModeIsolationTaskRequirement

T

SX001G:failureModeTestTaskRequirement

BAT

SX001G:batteryWorkshop

CAL

SX001G:calibrationWorkshop

HAN

SX001G:hangar

HYD

SX001G:hydraulicWorkshop

REP

SX001G:repairWorkshop

SHOP

SX001G:generalPurposeWorkshop

maintenanceFacilityType

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 108

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namemaintenanceLevelIdentifierID

SX001G:maintenanceLevelIdentifier

maintenanceSignificantOrRelev
ant

N

SX001G:nonMaintenanceSignificantOrRelevantBreakdownElement

R

SX001G:maintenanceRelevantBreakdownElement

S

SX001G:maintenanceSignificantBreakdownElement

measurementPointDefinitionIde
ntifierID

SX001G:measurementPointDefiinitionIdentifiermeasurementPointDefinitionType

G

SX001G:gaugeMeasurementPoint

measurementPointDegradedState
DefinitionAssertValueComparis
onOperator

Refer to comparisonOperatorCode valid value library,
Para 5.

measurementPointFaultStateDef
initionAssertValueComparisonO
perator

Refer to comparisonOperatorCode valid value library,
Para 5.

messageContentStatus

messageContentTypemessageIdentifierD

SX001G:draftMessageContent

F

SX001G:finalMessageContent

P

SX001G:preliminaryMessageContent

B

SX001G:baselineMessage

U

SX001G:netChangeMessage

ID

SX001G:messageIdentifier

messageLanguage
messagePartyTypemessageRelationshipType

nonConformanceType

operatingBaseType

Refer to languageCodeValues valid value library,
Para 5.

F

SX001G:messageForwarderR

SX001G:messageReceiverS

SX001G:messageSenderA

SX001G:acknowledgementOfMessage

O

SX001G:observationOnMessage

R

SX001G:replyToMessage

U

SX001G:updateToMessage

C

SX001G:concession

W

SX001G:waiverD

SX001G:deploymentOperatingBase

F

SX001G:forwardOperatingBase

M

SX001G:mainOperatingBase

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 109

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value nameoperatingLocationTypeIdentifi
er

ID

SX001G:operatingLocationTypeIdentifier

partAsDesignedPartsListRelati
onshipTypeC

SX001G:correspondsToPartsList

D

SX001G:derivedFromPartsList

E

SX001G:extendsPartsList

A

SX001G:demilitarizationNotRequiredPart

B

SX001G:tradeSecurityControlAtDisposalPart

C

SX001G:keyPointsDemilitarizationPart

D

SX001G:mutilationDemilitarizationPart

E

SX001G:nationalFurnishedDemilitarizationPart

F

SX001G:managerFurnishedDemilitarizationPart

G

SX001G:demilitarizationPriorToTransferPart

R

SX001G:specificInstructionsDemilitarizationPart

Y

SX001G:specificInstructionsDemilitarizationCryptoMa
terialID

SX001G:partIdentifierOEM

SX001G:originalEquipmentManufacturerPartNumber

REF

SX001G:partReferenceNumber

STD

SX001G:standardsReferenceDesignator

SUP

SX001G:supplierPartNumber

COTS

SX001G:commonOffTheShelfPart

CUST

SX001G:customerFurnishedPart

MAM

SX001G:majorModificationOfExistingPart

MOM

SX001G:moderateModificationOfExistingPart

NEW

SX001G:newDevelopedPart

OBS

SX001G:obsoletePart

ID

SX001G:partsListEntryIdentifier

LN

SX001G:partsListLineNumberID

SX001G:partsListRevisionIdentifier

partDemilitarizationClass

partIdentifier

partMaturityClass

partsListEntryIdentifierpartsListRevisionIdentifierpartsListRevisionStatuspartsListType

Refer to revisionStatusCode valid value library,
Para 5.

EBOM

SX001G:engineeringPartsList

MBOM

SX001G:manufacturingPartsList

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 110

S3000L-B6865-03000-00

Attribute nameperformanceParameterRevisionI
dentifier

Valid value

Valid value name

PBOM

SX001G:provisioningPartsList

SBOM

SX001G:supportPartsList

ID

SX001G:performanceParameterRevisionIdentifier

performanceParameterRevisionS
tatus
performanceParameterType

performanceParameterValueLimi
tQualifier
physicalReplaceability

physicalReplaceabilityStrateg
yproductIdentifier

Refer to revisionStatusCode valid value library,
Para 5.

DMC

SX001G:directMaintenanceCostPerformanceParame
ter

FOH

SX001G:failuresPerOperatingHourPerformancePara
meter

FR

SX001G:failureRatePerformanceParameter

LCC

SX001G:lifeCycleCostPerformanceParameter

MDT

SX001G:meanDownTimePerformanceParameter

MFOP

SX001G:maintenanceFreeOperatingPeriodPerforma
nceParameter

MMHOH

SX001G:maintenanceManHoursPerOperatingHourPerformanceParameter

MTBF

SX001G:meanTimeBetweenFailurePerformancePara
meter

MTBUR

SX001G:meanTimeBetweenUnscheduledRemovalPe
rformanceParameter

MTTR

SX001G:meanTimeToRepairPerformanceParameter

PSL

SX001G:productServiceLifePerformanceParameter

RT

SX001G:replacementTimePerformanceParameter

SMI

SX001G:scheduledMaintenanceIntervalPerformance
Parameter

SPT

SX001G:shopProcessingTimePerformanceParameterMAX

SX001G:maximumValueLimitQualifier

MIN

SX001G:minimumValueLimitQualifier

NOT

SX001G:nonReplaceablePart

REPL

SX001G:replaceablePart

LINE

SX001G:lineReplaceablePart

SHOP

SX001G:shopReplaceablePart

EIAC

SX001G:endItemAcronymCodeID

SX001G:productIdentifier

MOI

SX001G:modelIdentificationCode

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 111

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value nameproductUsagePhaseRelationshipTypeA

SX001G:happensAfterProductUsagePhase

B

SX001G:happensBeforeProductUsagePhaseD

SX001G:happensDuringProductUsagePhaseP

SX001G:partOfProductUsagePhaseID

SX001G:productVariantIdentifier

MOI

SX001G:modelIdentificationCode

UOC

SX001G:usableOnCodeID

SX001G:projectIdentifier

MOI

SX001G:modelIdentificationCodeCR

SX001G:classroomTrainingMethod

CW

SX001G:coursewareTrainingMethod

OJT

SX001G:onTheJobTrainingMethod

productVariantIdentifier

projectIdentifier

proposedTrainingMethod

publicationModuleIssueLanguageRefer to languageCodeValues valid value library,
Para 5.

publicationModuleIssueLanguag
eCountry

Refer to countryCodeValues valid value library,
Para 5.

referencedDocumentRole

DES

SX001G:designDocumentReference

DIR

SX001G:directiveDocumentReference

DRW

SX001G:drawingDocumentReference

REF

SX001G:generalDocumentReference

REQ

SX001G:requirementsDocumentReferenceRES

SX001G:resultDocumentReference

SRC

SX001G:sourceDocumentReference

VAL

SX001G:validationDocumentReference

VER

SX001G:verificationDocumentReference

referenceDesignator

RFD

SX001G:referenceDesignator

referencedOrganizationRole

APPR

SX001G:approverOrganization

AUTH

SX001G:authorizingOrganizationDSGN

SX001G:responsibleDesignOrganization

PUBL

SX001G:publishedByOrganization

REVW

SX001G:reviewOrganization

INT

SX001G:internalRemark

PUB

SX001G:publicRemark

remarkType

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 112

S3000L-B6865-03000-00

Attribute nameresourceSpecificationIdentifi
erresourceSpecificationRevision
Identifier

Valid value

Valid value name

RSP

SX001G:responseToRemark

ID

SX001G:resourceSpecificationIdentifier

STD

SX001G:standardsReferenceDesignatorID

SX001G:resourceSpecificationRevisionIdentifier

resourceSpecificationRevision
StatusresourceSpecificationType

Refer to revisionStatusCode valid value library,
Para 5.

C

SX001G:consumablePart

CNWK

SX001G:communicationNetworkInfrastructureResour
ce

COMP

SX001G:computerInfrastructureResource

DOCK

SX001G:dockInfrastructureResource

DRYD

SX001G:dryDockInfrastructureResource

E

SX001G:expendableSparePart

EP

SX001G:expendablePersonalProtectionPart

GAR

SX001G:garageInfrastructureResource

HNG

SX001G:hangarInfrastructureResourceHT

SX001G:standardHandTool

INF

SX001G:infrastructureResource

IT

SX001G:informationTechnologyPart

M

SX001G:rawMaterial

PA

SX001G:packagingPart

PE

SX001G:personalProtectionPart

POW

SX001G:powerInfrastructureResource

PR

SX001G:productProtectionPart

R

SX001G:repairableSparePart

S

SX001G:sparePart

SE

SX001G:supportEquipment

SSE

SX001G:safetyRelatedSupportEquipment

TNWK

SX001G:transportNetworkInfrastructureResource

skillCodeID

SX001G:skillCode

softwareElementLoadingStrategy

IND

SX001G:industryLoadableSoftwareElement

LINE

SX001G:lineLoadableSoftwareElement

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 113

S3000L-B6865-03000-00

Attribute namesoftwareElementType

softwarePartType

specialEventDefinitionCauseCa
tegorysubstanceIdentifier

substanceRiskFactor

substanceUsageCategory

Valid value

Valid value nameSHOP

SX001G:shopLoadableSoftwareElement

D

SX001G:distributedSoftwareElement

E

SX001G:embeddedSoftwareElement

L

SX001G:loadableSoftwareElement

D

SX001G:distributedSoftwarePart

E

SX001G:embeddedSoftwarePart

L

SX001G:loadableSoftwarePart

ANI

SX001G:animalSpecialEvent

CBT

SX001G:combatSpecialEvent

DYS

SX001G:internalDysfunctionSpecialEvent

EXT

SX001G:externalCauseSpecialEventHEA

SX001G:extensiveHeatSpecialEvent

HUM

SX001G:humanImpactSpecialEvent

INT

SX001G:internalSpecialEvent

MAN

SX001G:materialManeuverSpecialEvent

MET

SX001G:meteorologicalSpecialEvent

NAT

SX001G:naturalPhenomenonSpecialEvent

VIB

SX001G:extensiveVibrationSpecialEventCAS

SX001G:chemicalAbstractsServiceRegistryNumberID

SX001G:substanceIdentifier

1

SX001G:minimalHealthOrPhysicalHazardSubstance2

SX001G:lowHealthOrPhysicalHazardSubstance3

SX001G:moderateHealthOrPhysicalHazardSubstance

4

SX001G:highHealthOrPhysicalHazardSubstanceF

SX001G:forbiddenSubstanceL

SX001G:authorizedWithLimitationSubstanceN

SX001G:authorizedWithoutLimitationSubstancesubtaskAcceptanceParameterVal
ueComparisonOperator
subtaskEndItemObjectiveState

Refer to comparisonOperatorCode valid value library,
Para 5.

AS

SX001G:airSupplyEstablishedEndItemStateCS

SX001G:controlStatusEstablishedEndItemStateDF

SX001G:defueledEndItemState

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 114

S3000L-B6865-03000-00

Attribute namesubtaskIdentifier

Valid value

Valid value name

EL

SX001G:electricalPowerEstablishedEndItemStateELA

SX001G:electricalPowerFromAPUEstablishedEndIte
mStateELE

SX001G:electricalPowerFromEngineEstablishedEndI
temState

ELI

SX001G:internalElectricalPowerEstablishedEndItem
State

ELX

SX001G:externalElectricalPowerEstablishedEndItem
State

FU

SX001G:fueledEndItemStateHP

SX001G:hydraulicPowerEstablishedEndItemStateJC

SX001G:jackedEndItemStateSY

SX001G:safetyDeviceEstablishedEndItemStateTC

SX001G:taskCheckedEndItemStateUJ

SX001G:unjackedEndItemStateWS

SX001G:waterSupplyEstablishedEndItemStateID

SX001G:subtaskIdentifier

subtaskInformationCode
subtaskMaintenanceLocationsubtaskRole

subtaskTimelineEvent

taskIdentifier

Refer to taskInformationCodeValues valid value
library, Para 5.

A

SX001G:maintenanceOnItemWhenInstalledOnProdu
ct

B

SX001G:maintenanceOnItemOnMajorAssemblyC

SX001G:maintenanceOnBenchD

SX001G:maintenanceAnywhere

CL

SX001G:closeupSubtask

CON

SX001G:coreNoRequiredConditionsSubtask

COR

SX001G:coreSubtask

ST

SX001G:startupSubtask

END

SX001G:subtaskEndEventSTART

SX001G:subtaskStartEventID

SX001G:taskIdentifier

taskInformationCode
taskInfrastructureResourceCat
egory

Refer to taskInformationCodeValues valid value
library, Para 5.

CNWK

SX001G:communicationNetworkInfrastructureResour
ce

COMP

SX001G:computerInfrastructureResource

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 115

S3000L-B6865-03000-00

Attribute nametaskMaterialResourceCategory

taskOperabilityImpact

taskPersonnelResourceRole

taskPersonnelSafetyCriticalit

Valid value

Valid value name

DOCK

SX001G:dockInfrastructureResource

DRYD

SX001G:dryDockInfrastructureResource

GAR

SX001G:garageInfrastructureResource

HNG

SX001G:hangarInfrastructureResource

POW

SX001G:powerInfrastructureResource

TNWK

SX001G:transportNetworkInfrastructureResourceC

SX001G:consumablePart

E

SX001G:expendableSparePart

EP

SX001G:expendablePersonalProtectionPart

HT

SX001G:standardHandTool

IT

SX001G:informationTechnologyPart

M

SX001G:rawMaterial

PA

SX001G:packagingPart

PE

SX001G:personalProtectionPart

PR

SX001G:productProtectionPart

R

SX001G:repairableSparePart

S

SX001G:sparePart

SE

SX001G:supportEquipment

SSE

SX001G:safetyRelatedSupportEquipment

A

SX001G:systemInoperableDuringTaskExecution

B

SX001G:systemOperableDuringTaskExecution

C

SX001G:systemFullMissionCapableDuringTaskExec
ution

D

SX001G:systemPartialMissionCapableDuringTaskEx
ecutionE

SX001G:productNotMissionCapableDuringTaskExec
ution

G

SX001G:turnaroundTask

A

SX001G:assistentTaskPersonnelResourceP

SX001G:performerTaskPersonnelResource

Q

SX001G:qualityAssuranceTaskPersonnelResource

S

SX001G:supervisorTaskPersonnelResource

1

SX001G:catastrophicPersonnelSafetyCriticality

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 116

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value namey2

SX001G:criticalPersonnelSafetyCriticality

3

SX001G:marginalPersonnelSafetyCriticality

4

SX001G:negligiblePersonnelSafetyCriticality

N

SX001G:nonCriticalProductIntegrityTask

Y

SX001G:criticalProductIntegrityTask

CMR

SX001G:certificationMaintenanceRequirement

EZAP

SX001G:enhancedZonalAnalysisProgram

LEMR

SX001G:lawEnforcedMaintenanceRequirement

PMEC

SX001G:preventiveMaintenanceEffectCategoryID

SX001G:taskRequirementIdentifier

taskProductIntegrityCriticalitytaskRequirementAuthoritySourc
eTypetaskRequirementIdentifier
taskRequirementInformationCodetaskRequirementRevisionIdenti
fier

Refer to taskInformationCodeValues valid value
library, Para 5.

ID

taskRequirementRevisionStatus

SX001G:taskRequirementRevisionIdentifier

Refer to revisionStatusCode valid value library,
Para 5.

taskResourceIdentifierID

SX001G:taskResourceIdentifier

taskResourceRelationshipTypeAND

SX001G:mutualInclusionTaskResourceRelationship

COOP

SX001G:cooperationTaskResourceRelationship

SEQ

SX001G:sequenceTaskResourceRelationship

USE

SX001G:usesTaskResourceRelationship

XOR

SX001G:mutualExclusionTaskResourceRelationshipID

SX001G:taskRevisionIdentifier

taskRevisionIdentifier
taskRevisionStatus
technologyBehaviourKnowledgeR
ating

technologySensitivityRating

thresholdValueQualifier

Refer to revisionStatusCode valid value library,
Para 5.

1

SX001G:wellKnownTechnologyBehavior

2

SX001G:knownTechnologyBehavior

3

SX001G:unknownTechnologyBehavior

1

SX001G:extremelyLowLikelihoodOfDamage

2

SX001G:lowLikelihoodOfDamage

3

SX001G:mediumLikelihoodOfDamage

4

SX001G:highLikelihoodOfDamage

5

SX001G:extremelyHighLikelihoodOfDamage

A

SX001G:executeAfterThresholdValueDefinition

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 117

S3000L-B6865-03000-00

Attribute name

Valid value

Valid value nameB

SX001G:executeBeforeThresholdValueDefinition

warningCautionNoteIdentifierID

SX001G:warningCautionNoteIdentifier

warningCautionNoteTypeC

SX001G:cautionAdvise

N

SX001G:noteAdvise

W

SX001G:warningAdvise

W

SX001G:productWorkArea

Z

SX001G:productZone

zoneElementType

5

Valid value libraries
The list of valid value libraries used by S3000L is provided in Table 5. These libraries include
codes from international specifications. Details on the valid values included in the respective
valid value library are given in the valid value XML files that accompany this specification.
Note
Specified valid values are recommended values and projects can therefore tailor the valid
values as needed (refer to SX005G).
Table 5 List of valid value libraries

Library name

Valid value

Valid value namecomparisonOperatorCodeValues

EQ

SX001G:equalToComparisonOperator

NE

SX001G:notEqualToComparisonOperator

LT

SX001G:lessThanComparisonOperator

LE

SX001G:lessThanOrEqualToComparisonOperator

GT

SX001G:greaterThanComparisonOperator

GE

SX001G:greaterThanOrEqualToComparisonOperator

IN

SX001G:withinRangeComparisonOperator

OUT

SX001G:outsideRangeComparisonOperator

countryCodeValues-

Note
The country codes valid value XML schema for
S3000L issue 2.0 lists 193 county codes from ISO
3166-1.

hardwarePartHazardousClassCodeValues-

Note
The hazardous class code valid value XML
schema does not include any predefined valid
values.

languageCodeValues-

Note
The language codes valid value XML schema for
S3000L issue 2.0 lists 136 language codes fromISO 639:1988.

revisionStatusCodeValues

A

SX001G:approvedStatus

Applicable to: All

S3000L-A-22-00-0000-00A-040A-A
Chap 22

DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

2021-04-30 Page 118

S3000L-B6865-03000-00

Library nametaskInformationCodeValues

Valid value

Valid value nameD

SX001G:draftStatusIW

SX001G:inWorkStatusC

SX001G:cancelledStatusR

SX001G:reviewedStatus-

Note
The task information codes valid value XML
schema for S3000L issue 2.0 lists 41 information
codes from S1000D,

S3000L-A-22-00-0000-00A-040A-A

Applicable to: All

End of data module
DMC-S3000L-A-22-00-0000-00A-040A-A_003-00_EN-US.docx

Chap 222021-04-30 Page 119