s1000d to s3000l interchange specification

S1000D to S3000L interchange specification

Issue 1.0 2011-03-31

S1003X-B6865-01003-00

Applicable to: All S1003X-A-00-00-0000-00A-021A-A

DMC-S1003X-A-00-00-0000-00A-021A-A_001_00_EN-US.doc 2011-03-31 Page 1

Copyright and user agreement

1 Copyright Copyright (C) 2009, 2011 AeroSpace and Defence Industries Association of Europe - ASD.

All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system, except as may be expressly permitted by the Copyright Act or in writing by the Publisher.

S1003X™ is a trade mark owned by ASD.

All correspondence and queries should be directed to:

ASD Monsanto Building 270 Avenue de Tervuren B-1150 Brussels Belgium

2 Agreement for use of the specification S1003X™ suite of information

2.1 Definitions S1003X™ suite of information means, but is not limited to:

− the S1000D and S3000L interchange specification - S1003X − examples (eg XML instances, pdf files, style sheets) and schemas − any other software or information under the heading “S1003X™ suite of information”,

available for download from www.asd-stan.org

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

2.2 Notice to user By using all or any portion of S1003X™ suite of information you accept the terms and conditions of this User Agreement.

This User Agreement is enforceable against you and any legal entity that has obtained S1003X™ 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 S1003X™ suite of information.

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

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

http://www.asd-stan.org/�

S1003X-B6865-01003-00



2.6 No warranty S1003X™ suite of information is being delivered to you "as is". The Copyright Holder does not warrant the performance or result you may obtain by using S1003X™ 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 lost savings or for any claim by a third party, even if the Copyright Holder has been advised of the possibility 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 and affiliates and all of their employees, agents, directors, officers, proprietors, partners, representatives, shareholders, servants, attorneys, predecessors, successors, assigns, and those who have worked on the preparation, publication or distribution of the S1003X™ 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 S1003X™ suite of information or any breach by you of this User Agreement.

2.9 Governing law and arbitration This User Agreement will be governed by and construed in accordance with the laws of the Kingdom 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 the matter 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 the filing of a Request for ADR or within such other period as the parties 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 the said Rules of Arbitration. All related proceedings should be at the place of the ICC in Paris, France.

The language to be used in the arbitral proceedings shall be English.

End of data module

S1003X-B6865-01003-00



Table of contents The listed documents are included in Issue 1.0, dated 2011-03-31, of this publication.

Chapter Data module title Data module code Applic

Background Chap 1 S1000D-A-09-00-0000-00A-040A-A All

Introduction Chap 2 S1000D-A-09-01-0000-00A-040A-A All

Principles for product breakdown structures

Chap 3 S1000D-A-09-02-0000-00A-040A-A All

S1000D Procedure and schedule Schemas vs S3000L

Chap 4 S1000D-A-09-02-0100-00A-040A-A All

S1000D Data requirements Chap 5 S1000D-A-09-02-0200-00A-040A-A All

S3000L data required to populate S1000D data modules

Chap 6 S1000D-A-09-02-0300-00A-040A-A All

S1000D feedback to S3000L Chap 7 S1000D-A-09-03-0000-00A-040A-A All

Use of DEX for S1000D and S3000L data exchange

Chap 8 S1000D-A-09-03-0100-00A-040A-A All

Samples with S1000D and S3000L instantiations

Chap 9 S1000D-A-09-03-0200-00A-040A-A All

End of data module

S1003X-B6865-01003-00


Chap 1


Chapter 1

Background

Table of contents Page Background .................................................................................................................................... 1 References ..................................................................................................................................... 1 1 Background ...................................................................................................................... 1 1.1 Purpose ........................................................................................................................... 1 1.2 MTDTT ............................................................................................................................. 1 1.3 Deliverables ..................................................................................................................... 2

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

References

Table 1 References

Chap No./Document No. Title

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

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

S1000D International specification for technical publications using a common source database

S3000L International procedure specification for Logistics Support Analysis - LSA

1 Background 1.1 Purpose

The purpose of this interface specification (S10003X) is to specify data required from the Product Development and Logistic Support Analysis (LSA) activities, in order to produce the maintenance procedure, maintenance planning, applicability cross-reference table and conditions cross-reference table data modules in S1000D.

The content of the interface specification is defined based on the S1000D Schema and S3000L data model respectively.

1.2 MTDTT This issue of the interface specification has been developed by the S1000D Maintenance Task Data Task Team (MTDTT). The scope of work for the MTDTT is to:

− Develop a specification of data required for the exchange of product structures between ASD specifications. Product structure, including its associated applicabilities is normally tied to the product design, often done within a Product Data Management (PDM) system. In

S1003X-B6865-01003-00


Chap 1


other words, the product structure from design must fit into the S1000D/S3000L support/maintenance structure and its applicability model.

− Develop specification of LSA data required to produce S1000D Maintenance Procedures and Maintenance Planning data modules. This specification will define the information needed to be exchanged between an S3000L LSA database and the S1000D Common Source Data Base (CSDB).

− Specify changes required for the CSDB data storage and configuration control, in order to track and manage Product and Task data being imported, using the PLCS-based Aerospace and Defense Data Exchange Specifications.

1.3 Deliverables

− DEX1A&D - Aerospace and Defense business DEX for exchange of product breakdown for support (DEX1AD). DEX1AD is compliant with the OASIS standard DEX 1 (D001) Product Breakdown for Support. This aerospace and defense business specific DEX contains all product related data required for the production of maintenance procedures in S3000L and S1000D, including applicabilities as defined within S3000L and S1000D.

− DEX3A&D - Aerospace and defense business DEX for exchange of a task specification (DEX3AD). DEX3AD is compliant with the OASIS standard DEX 3 (D003) Task Set. This aerospace and defense business specific DEX contains the S3000L task related data, required for the production of maintenance procedure and maintenance planning data modules in S1000D.

− S1000D change proposals required for enabling integration with S3000L. − This S1000D and S3000L interface specification.

End of data module

S1003X-B6865-01003-00


Chap 2


Chapter 2

Introduction

Table of contents Page Introduction .................................................................................................................................... 1 References ..................................................................................................................................... 1 1 Introduction ...................................................................................................................... 1


References

Table 1 References




1 Introduction This issue of S1003X supports the data exchange between S3000L at Issue 1.0 and S1000D at Issue 4.0.1.

S1003X is divided into:

− S1000D data requirements:

• S1000D identification and status section, ie the part which is common to all S1000D data module schemas

• S1000D procedural information, ie the procedural Schema, defining the details for maintenance procedures

• S1000D maintenance planning information, ie the maintenance planning Schema, and its subsections:

− Time limits, which capture information about periodicities and life details for equipment or systems

− Task definitions, which capture the information about individual tasks to be carried out on a system

− Inspection definitions, which capture groups of maintenance tasks or inspection types

− Maintenance allocation, which captures maintenance functions along with maintenance levels and time associated for each task

• S1000D Applicability cross-reference table • S1000D Condition cross-reference table

S1003X-B6865-01003-00


Chap 2


− A summary of the constructs in the S3000L data model that can be used to populate the S1000D Schemas.

End of data module

S1003X-B6865-01003-00


Chap 3


Chapter 3

Principles for product breakdown structures

Table of contents Page Principles for product breakdown structures .................................................................................. 1 References ..................................................................................................................................... 1 1 Principles for product breakdown structures ................................................................... 1


References

Table 1 References



GEIA-STD-0007 Logistics Product Data

1 Principles for product breakdown structures There are many different principles for how to define product breakdown structures. The MTDTT work focused on the ability to support the following two approaches:

− First, the traditional LSA approach. The principle behind this approach is that, for the breakdown structure, all elements are identified in accordance with one breakdown philosophy, ie the identification of the respective breakdown element defines its position in the breakdown structure. Examples of this kind of breakdown are LCN-structures in GEIA-STD-0007, and SNS structures in S1000D. Common to these approaches are that the breakdown element identifiers are critical for navigation.

− Second, the product data model approach. The principle behind this approach is that breakdown elements define “logical” elements such as systems, functions, hardware positions, and the possible realizations of those elements are defined as parts. Breakdown structures are defined by explicit associations between the parent and its child elements, which means that the identification of the respective breakdown element doesn't need to reflect its position in the breakdown. These structures are often seen in PDM systems.

The identification of the advantages and disadvantages with each approach is out of scope of this specification. However, the MTDTT work identified problems for S1003X to define one straightforward mapping, since S3000L supports both approaches, whilst S1000D is based on the first approach. Therefore S1003X addresses both approaches.

End of data module

S1003X-B6865-01003-00


Chap 4


Chapter 4

S1000D Procedure and schedule Schemas vs S3000L

Table of contents Page S1000D Procedure and schedule Schemas vs S3000L ................................................................ 1 References ..................................................................................................................................... 1 1 S1000D Procedure and schedule Schemas vs S3000L ................................................. 1 1.1 S1000D vs S3000L views on a procedural task .............................................................. 2 1.2 S1000D vs S3000L views on packaged tasks ................................................................ 4 1.3 Populating S1000D data modules based on the S3000L data model............................. 6 1.3.1 Populating S1000D procedural data modules ................................................................. 6 1.3.2 Populating S1000D taskDefinition ................................................................................... 7 1.3.3 Populating S1000D inspectionDefinition ......................................................................... 8 1.3.4 Populating S1000D maintAllocation ................................................................................ 9 1.3.5 Populating S1000D timeLimitInfo .................................................................................. 10


List of figures 1 Example of a breakdown of a repair procedure (rectifying task) in S3000L ................... 32 S1000D procedural data module relationship to S3000L task structure ......................... 43 S3000L concept of packaged task, procedural task and limit (thresholds) ..................... 54 S1000D structure of inspectionDefinition, taskDefinition and referenced procedures .... 65 Mapping of S3000L procedural tasks onto S1000D procedural data modules ............... 76 S1000D taskDefinition relationship to S3000L tasks ....................................................... 87 S1000D inspectionDefinition relationship to S3000L tasks ............................................. 98 S1000D maintAllocation relationship to S3000L ........................................................... 109 S1000D timeLimitInfo relationship to S3000L ............................................................... 11

References

Table 1 References




1 S1000D Procedure and schedule Schemas vs S3000L It is important for the reader to understand the different views of a task taken from an LSA perspective compared to the one taken from a technical publications perspective.

S1003X-B6865-01003-00


Chap 4


The difference in views of a task, relates both to the view of a single procedural task, as well as how to package (group) tasks, eg for a scheduled inspection.

The major reason for this is that S3000L has a supplier/vendor perspective, while S1000D has a maintainer's perspective. S1000D organizes the data in a way that simplifies the optimization of tasks that need to be scheduled for a product in operation.

1.1 S1000D vs S3000L views on a procedural task The difference in views of a procedural task and its content is reflected in the mapping between the S1000D elements and the S3000L data model. This mapping is described in detail for each S1000D schema.

The result of the LSA Maintenance Task Analysis (MTA) is a set of tasks that are triggered by identified events, eg a scheduled threshold, a failure, or a special event. These tasks are also referred to as rectifying tasks in S3000L. Each rectifying task is self contained, which means that it contains every step required in order to regain the operational status of an end item, ie the maintenance task starts with the perspective that the end item is not targeted for any other maintenance action. However, each rectifying task is structured so that subtasks, or groups of subtasks, are defined separately as supporting tasks. A supporting task can be reused by many rectifying tasks.

Fig 1 is taken from S3000L and shows the breakdown of a repair procedure (rectifying task) into a set of subtasks.

S1003X-B6865-01003-00


Chap 4


Repair procedure(for equipment 401)

Remove Cover #01 (opening 4 quick fasteners)Subtask 02

Reference on: Remove Cover #02Subtask 03

Open 24 screws for removal of Cover #02 Working Step 01

Remove cover plateWorking Step 02

Remove sealingWorking Step 03

Reference on: Remove equipment 401Subtask 04

Reference on: Disassemble equipment 401Subtask 05

Remove electrical connector E01-013Working Step 01

Open safety screws S01 and S02Working Step 02

Open attaching screws A01 to A07 Working Step 03

Remove equipment 401 from housing Working Step 04

……………Working Step 01

……………………..

Remove defective component 05Subtask 06

Install new component 05Subtask 07

Reference on: Assemble equipment 401Subtask 08

Reference on: Install equipment 401Subtask 09

Reference on: Test function of equipment 401Subtask 10

Reference on: Install Cover #02Subtask 11

Install Cover #01Subtask 12

Reference on: Fault location procedureSubtask 01

ICN-B6865-S1003X0001-001-01

Fig 1 Example of a breakdown of a repair procedure (rectifying task) in S3000L

This approach is different from the approach taken by S1000D. Subtasks required for preparation and close up are not defined as explicit procedural steps in S1000D, but are defined as a set of required conditions.

The S1000D view of a task is defined from an operators/maintainers perspective, where synchronization and optimization between maintenance tasks are important when a set of pre conditions are met.

Fig 2 shows the relationship between a procedural task in S3000L and the content of an S1000D procedural data module. The S1000D preliminary requirements (the element <preliminaryRqmts>) section summarizes the S3000L start up subtasks, the S1000D main procedure (the element <mainProcedure>) covers the S3000L core subtasks, and finally the S1000D close up requirements (the element <closeRqmts>) summarizes the S3000L close up subtasks.1

1 Start up, core and close up categorization of subtasks in S3000L has been

introduced in order to enable integration between ASD specifications, and especially the integration between S3000L and S1000D.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0002-001-01

Fig 2 S1000D procedural data module relationship to S3000L task structure

A main difference between these approaches is that S1000D defines the objective states, in no particular order, before and after the main procedure steps whereas S3000L defines these objective states within an explicit order of subtasks.

1.2 S1000D vs S3000L views on packaged tasks A packaged task in S3000L is regarded as just another task, which references other tasks in the same way as a rectifying task in S3000L can reference a set of supporting tasks as its subtasks. The packaging of tasks in S3000L is described from the perspective of scheduled maintenance, eg a major periodic inspection.

Fig 3 shows how a packaged task is defined within S3000L.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0003-001-01

Fig 3 S3000L concept of packaged task, procedural task and limit (thresholds)

S1000D task structure can start with the inspection (the element <inspectionDefinition>), which relates to one or many tasks (the element <taskDefinition>), which in turn relates to one or many procedural data modules. This is shown in Fig 4.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0004-001-01

Fig 4 S1000D structure of inspectionDefinition, taskDefinition and referenced procedures

There is no straightforward way of mapping a packaged task in S3000L to the structure of the elements <inspectionDefinition> and <taskDefinition> and referenced procedures, as defined within the S1000D maintenance planning information schema. However, a proposed mapping is presented at Para 1.3

1.3 Populating S1000D data modules based on the S3000L data model

.

S3000L has introduced the attribute "S1000D_task_type" for task, which makes it possible to populate the procedural and maintenance planning data modules in S1000D.

1.3.1 Populating S1000D procedural data modules The starting point for the mapping of S3000L is the breakdown of the product in focus. Each element in the product breakdown must correspond to a hardware/System identification2

Each breakdown element, in the S3000L product breakdown, can then be associated with one or many tasks. S3000L tasks being categorized as procedural tasks, using the attribute "S1000D_task_type", can then be mapped onto a set of S1000D procedural data modules as shown in

in S1000D.

Fig 5.

2 Hardware/System identification in S1000D consists of a model identification code,

a system difference code, a Standard Numbering System (SNS) and the disassembly code/disassembly code variant.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0005-001-01

Fig 5 Mapping of S3000L procedural tasks onto S1000D procedural data modules

The objective for any project using both specifications must have the same granularity of a procedural task. This means that each procedural task defined in S3000L, would have a one-to-one relationship with a corresponding procedural data module in S1000D.

1.3.2 Populating S1000D taskDefinition There is no structural concept in S3000L that directly corresponds to an S1000D taskDefinition. However, S1000D taskDefinition’s can be populated on a per S3000L task basis, ie there is one instance of taskDefinition per S3000L task, where the taskDefinition contains the task limit and references to the procedural task to be performed when the limit is met as shown in Fig 6.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0006-001-01

Fig 6 S1000D taskDefinition relationship to S3000L tasks

1.3.3 Populating S1000D inspectionDefinition The clustering and packaging of maintenance tasks into S1000D inspectionDefinition can be accomplished in accordance with S3000L packaged tasks, ie each packaged task defined in S3000L (eg 500 flight hours scheduled maintenance package) can correspond to an instance of inspectionDefinition.

A mapping includes the identification of a packaged task in S3000L, along with its time limit (threshold) and references to its procedural subtasks as shown in Fig 7.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0007-001-01

Fig 7 S1000D inspectionDefinition relationship to S3000L tasks

1.3.4 Populating S1000D maintAllocation S1000D Issue 4.0 introduced a new branch called maintenance allocation (the element <maintAllocation>) within the schema for maintenance planning information. This branch is used for the Maintenance Allocation Chart (MAC) and captures maintenance functions along with maintenance levels and time associated for each task.

The maintenance allocation branch can be populated from the selection of a breakdown element node in a physical product breakdown as shown in Fig 8.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0008-001-01

Fig 8 S1000D maintAllocation relationship to S3000L

Note The dotted lines in between functions and data modules in the figure above show that there is no explicit reference to a procedural data module from the maintenance allocation function.

1.3.5 Populating S1000D timeLimitInfo The S1000D timeLimitInfo can be supported by S3000L, through the identification of all the hardware parts that have a defined operational authorized life, which can be installed on the product in focus.

These parts are indicated by the hardware element realization, which associates breakdown elements within a product and its possible realizations, ie parts, as shown in Fig 9.

S1003X-B6865-01003-00


Chap 4


ICN-B6865-S1003X0009-001-01

Fig 9 S1000D timeLimitInfo relationship to S3000L

End of data module

S1003X-B6865-01003-00


Chap 5


Chapter 5

S1000D Data requirements

Table of contents Page 1 General ............................................................................................................................ 2 1.1 Introduction ...................................................................................................................... 2 1.2 How to use this chapter ................................................................................................... 2 2 S1000D Identification and status section ........................................................................ 2 2.1 Introduction ...................................................................................................................... 2 2.2 Identification and status section requirements ................................................................ 3 2.3 Notes for Table 2 ........................................................................................................... 40 3 S1000D Maintenance procedure ................................................................................... 40 3.1 Introduction .................................................................................................................... 40 3.2 Preliminary requirements ............................................................................................... 41 3.3 Notes for Table 3 ........................................................................................................... 75 3.4 Main procedure .............................................................................................................. 75 4 S1000D Maintenance Planning Information .................................................................. 84 4.1 Introduction .................................................................................................................... 84 4.2 S1000D schedule Schema requirements ...................................................................... 84 4.2.1 Task definition ................................................................................................................ 84 4.3 Inspection definition ..................................................................................................... 114 4.4 Time limit information .................................................................................................. 120 4.5 Maintenance allocation ................................................................................................ 128 5 S1000D Applicability schemas .................................................................................... 145 5.1 Introduction .................................................................................................................. 145 5.2 Applicability cross-reference table ............................................................................... 145 5.3 Condition cross-reference table................................................................................... 150 6 Common information repository .................................................................................. 174

List of tables 1 References ...................................................................................................................... 22 identAndStatusSection - Elements and attributes ........................................................... 43 PreliminaryRqmts (Preliminary requirements) - Elements and attributes ..................... 424 mainProcedure - Elements and attributes ..................................................................... 765 taskDefinition - Elements and attributes ........................................................................ 856 inspectionDefinitions - Elements and attributes .......................................................... 1157 timeLimitInfo - Elements and attributes ....................................................................... 1218 maintAllocations - Elements and attributes ................................................................. 1299 applicCrossRefTable - Elements and attributes .......................................................... 14610 condCrossRefTable - Elements and attributes ............................................................ 151

S1003X-B6865-01003-00


Chap 5


References

Table 1 References




S2000M International specification for material management


1 General 1.1 Introduction

This chapter describes how elements in the S1000D Schemas for data modules containing maintenance procedures, maintenance planning, the applicability cross-reference table and the conditions cross-reference table can be populated with data sourced from S3000L Logistics Support Analysis (LSA).

1.2 How to use this chapter Reading guide for the tables defined in this chapter.

The S1000D Schema elements and attributes which are mapped against S3000L are identified in the left column. The identification of the respective element/attribute is given in its context, ie its parent elements are defined as well.

Example 1:

− The cell that indicates the element <thresholdValue>, as used in the context of the element <taskDefinition><limit><threshold>, contains: <taskDefinition> <limit> <threshold> <thresholdValue>

Example 2:

− The cell that indicates the attribute @toleranceLow of the element <tolerance>, as used in the context of the element <taskDefinition><limit><threshold>, contains: <taskDefinition> <limit> <threshold> <tolerance@toleranceLow>

2 S1000D Identification and status section 2.1 Introduction

The identification and status section (the element <identAndStatusSection>) gives all the identification elements required to address and control the data module. It also provides

S1003X-B6865-01003-00


Chap 5


the status elements for information on the security, quality and technical status together with the applicability of the overall data module content.

Note The element <identAndStatusSection> is common to all S1000D Schemas.

2.2 Identification and status section requirements Table 2 describes the elements and attributes in the element <identAndStatusSection> that are considered candidates for being created (or derived from data being created) during the S3000L LSA process, and therefore also being candidates for being transferred via either DEX1AD or DEX3AD.

S1003X-B6865-01003-00


Chap 5


Table 2 identAndStatusSection - Elements and attributes

S1000D Issue 4.0 Element/Attribute name

S1000D Issue 4.0 Element/Attribute definition

S3000L Element name/AD DEX reference

Mapping - How to get from S3000L to S1000D (Business rules)

<dmAddress> <dmIdent> <dmCode@modelIdentCode>

The model identification code (MI).

Product_variant_identifier AD DEX reference: − DEX1AD section

Product and project - Template table #6 or Template table #8

'Product_variant_identifier' classified as 'Model_identification_code' Notes

1. Defined in 1388-2b using the combination of End Item Acronym Code and Usable On Code (EIAC). Also known as Model id. 2. Defined in S2000M using the MOI data element.

Business rule decision point - Values for model identifiers: At the beginning of a project/program, decide and agree (between systems engineering, logistics support analysis, and tech pubs) the vaules for the attribute <dmCode@modelIdentCode>.

<dmAddress> <dmIdent> <dmCode@systemDiffCode>

System difference code (SDC) indicates variants at the system, subsystem and sub-subsystem level.

Breakdown_element_identifier, Breakdown_element_relationship_type AD DEX reference for Breakdown_element_identifier: − DEX1AD section

Breakdown aggregated element - Template table #170 or Template table #171

AD DEX reference for

If explicit it can be part of the 'Breakdown_element_identifier' for an aggregate breakdown element at any level of indenture in the product. A 'Breakdown_element_identifier' that is defined using the principles defined in S1000D must be classified as 'ASD_system_hardware_identification_code'. The SDC is then part of the identifier. System difference can also be derived from possible usage of 'Breakdown_element_relationship' between aggregate breakdown elements at any level of indenture, where the 'Breakdown_element_relationship_type' is set to 'Alternative_breakdown_element' (DEX reference: DEX1AD section Breakdown aggregated element - Template table #174). Notes

1. Defined in 1388-2b using System Logistic Usable On Code

S1003X-B6865-01003-00


Chap 5






Breakdown_element_relationship_type: − DEX1AD section

Breakdown aggregated element - Template table #174

(SLUOC). 2. The S1000D principles for identifying an LSA-candidate contain: − Model identification code − Systems difference code − System code − Subsystem code − Subsubsystem code − Assembly code − Disassembly code − Disassembly code variant

The sum of these is referred to as the 'ASD_system_hardware_identification_code'.

<dmAddress> <dmIdent> <dmCode@systemCode> <dmCode@subSystemCode> <dmCode@subSubSystemCode> <dmCode@assyCode>

Data modules must reflect the breakdown of the Product. The initial breakdown is described by the Standard Numbering System (SNS).

Breakdown_element_identifier or Part_identifier AD DEX reference for Breakdown_element_identifier: − DEX1AD section

Hardware element realization - Template table #130 or Template table #131 or

Each Breakdown_element and Part being identified as being LSA candidates in S3000L can have an associated 'Breakdown_element_identifier' or 'Part_identifier' being classified as 'ASD_system_hardware_identification_code'. The attributes <dmCode@systemCode>, < dmCode@subSystemCode>, < dmCode@subSubSystemCode> and < dmCode@assyCode> are then part of the identifier. This requires that the 'ASD_system_hardware_identification_code' being associated with the respective LSA_candidate (Breakdown_element/Part), is established at design or during the

S1003X-B6865-01003-00


Chap 5






− DEX1AD section Software element realization - Template table #150 or Template table #111 or

− DEX1AD section Breakdown aggregated element - Template table #170 or Template table #171 or

− DEX1AD section Breakdown zone element - Template table #183 or Template table #184

AD DEX reference for Part_identifier: − DEX1AD section

Hardware part - Template table #50 or Template table #53 or

− DEX1AD section Software part - Template table #80 or Template table #82

LSA process. It is also possible to relate each Breakdown_element and Part to Breakdown_elements in a separate S1000D Breakdown using Breakdown_element_relationship. This Breakdown_element_relationship must then be classified as 'Design_to_S1000D_SNS_relationship'. The unique identifier for each Breakdown_element in the S1000D Breakdown will then be the 'ASD_system_hardware_identification_code'. A separate S1000D breakdown can be defined based on feedback data from S1000D to S3000L. The common denominator for each breakdown element and part must be the 'Breakdown_element_identifier' and 'Part_identifier' as established by design. Note

Defined in 1388-2b using the Logistics Control Number (LCN).

S1003X-B6865-01003-00


Chap 5






<dmAddress> <dmIdent> <dmCode@disassyCode>

Identifies the breakdown condition of an assembly to which maintenance information applies or the order in which assemblies are disassembled.

Part_identifier or Breakdown_element_identifier AD DEX reference for Breakdown_element_identifier: − DEX1AD section

Hardware element realization - Template table #130 or Template table #131 or



Can be included in the 'ASD_system_hardware_identification_code' (ie a type of 'Part_identifier' or 'Breakdown_element_identifier') for Part and Breakdown_element, respectively. Whether the 'ASD_system_hardware_identification_code' is is defined for the Part or Breakdown_element is dependent upon the philosophy for the breakdown. Refer to mapping under the element <dmIdent><dmCode@SystemCode> above. Note

Defined in 1388-2b using the Logistics Control Number (LCN).

S1003X-B6865-01003-00


Chap 5









− DEX1AD section Software part - Template table #80 or Template table #82

<dmAddress> <dmIdent> <dmCode@

disassyCodeVariant>

Designates alternative items of equipment or components differing slightly in design, but not enough to warrant a change of the SDC.

Part_identifier or Breakdown_element_identifier AD DEX reference for Breakdown_element_identifier: − DEX1AD section

Hardware element realization - Template table #130 or Template

Refer to mapping under the element <dmIdent><dmCode@disassyCode> above. Note

Defined in 1388-2b using the Alternative LCN (ALC).

S1003X-B6865-01003-00


Chap 5






table #131 or






− DEX1AD section Software part -

S1003X-B6865-01003-00


Chap 5






Template table #80 or Template table #82

<dmAddress> <dmIdent> <dmCode@infoCode>

Identifies the type of information within a data module.

Information_code AD DEX reference: − DEX3AD section Task

definition - Template table #6

'Information_code' associated with Task.

'Information_code' is used to categorize the task/subtask in S3000L by allocating S1000D Information Codes (IC). When allocating the 'project specific "Not given" ICs', their allocation must be harmonized between S3000L and S1000D. If multiple tasks with the same ‘Information_code’ are associated with a specific instance of Breakdown_element or Part, then these tasks can be candidates for being identified using different Information Code Variants (ICV). A task which contains multiple subtasks with the same 'Information_code' can be a candidate for being split into multiple data modules, identified using different ICVs. Example Performance of an automated test (IC 342), using different test equipments can require different maintenance procedures. Business rule decision point - Multiple tasks and subtasks: Decide wether to break tasks and subtasks down and identify them using the ICV.

<dmAddress> <dmIdent> <dmCode@

infoCodeVariant>

Identifies any variation in the activity defined by the IC.

N/A

Notes 1. There is no explicit variant code in S3000L. 2. Defined in 1388-2b using Task Function within the Task Code

S1003X-B6865-01003-00


Chap 5






<dmAddress> <dmIdent> <dmCode@itemLocationCode>

Identifies where the maintenance task will be carried out.

Maintenance_location_code AD DEX reference: − DEX3AD section

Subtask by definition - Template table #44

Maintenance_location_code is defined in S3000L using reference data that corresponds to the <dmCode@itemLocationCode> code values A, B, C, D:

− Maintenance_location_code = ‘On_product_task’ equals <dmCode@itemLocationCode = ‘A’>

− Maintenance_location_code = ‘Off_product_on_major_assembly_task’ equals <dmCode@itemLocationCode = ‘B’>

− Maintenance_location_code = ‘Off_product_on_bench_task’ equals <dmCode@itemLocationCode = ‘C’>

− Maintenance_location_code = ‘On_and_off_product_task’ equals <dmCode@itemLocationCode = ‘D’>.

Note Maintenance_location_code is assigned to the respective subtask in S3000L, and not to the overall task.

<dmAddress> <dmAddressItems> <dmTitle> <techName>

Must reflect the nomenclature of the hardware or function.

Breakdown_element_name or Part_name AD DEX reference for Breakdown_element_name: − DEX1AD section

If there is a 'Breakdown_element_name' or 'Part_name' which is classified as ‘Breakdown_element_techname’ or 'Part_techname' respectively, then use that name to populate the element <techName>. Note

If Breakdown_elements and Parts have multiple names, but no explicit ‘_techname’, then a project business rule needs to be established that determines which

S1003X-B6865-01003-00


Chap 5






Hardware element realization - Template table #132 or

− DEX1AD section Software element realization - Template table #152 or

− DEX1AD section Breakdown aggregated element - Template table #172 or

− DEX1AD section Breakdown zone element - Template table #185

AD DEX reference for Part_name: − DEX1AD section

Hardware part - Template table #52 or

− DEX1AD section Software part - Template table #83

'Breakdown_element_name' or 'Part_name' to use for populating the element <techName>.

Business rule decision point - Multiple names for breakdown elements and parts: If Breakdown_elements and Parts have multiple names, but no explicit ‘techname’, decide which name to use to populate the element <dmTitle><techName>.

S1003X-B6865-01003-00


Chap 5






<dmAddress> <dmAddressItems> <dmTitle> <infoName>

Normally the information name is the short description of the information code. However, projects can decide to modify (or extend) the information name to one that is more suitable,

Task_name AD DEX reference: − DEX3AD section Task

definition - Template table #1 or Template table #4

The Task_name is used to populate the element <infoName>. However, tasks can have multiple names. Business rule decision point - Multiple names for tasks: If tasks have multiple names, but no explicit ‘infoName’, decide which name to use to populate the element <dmTitle><infoName>.

<dmStatus> <security@

securityClassification>

The security classification of the complete data module.

Security_class Security_class AD DEX reference for Breakdown_element and Part: − DEX1AD section

Security classification - Template table #320

Security_class AD DEX reference for Task, Subtask_by_definition and Task_requirement: − DEX3AD section

Security classification - Template table #320

<security@securityClassification> can be derived from the security classification of Breakdown_element, Part, Task_requirement, Task or Subtask in S3000L. Note

Security classification for a breakdown element or part must be propagated to the respective task being associated with the breakdown element/part.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <security@

commercialClassification>

Project rule. N/A

<dmStatus> <security@caveat>

Project rule. N/A

<dmStatus> <techStandard>

Contains the authorized technical standard and associated data to be entered, describing the information basis used to write the data module.

N/A This element is seldom used

<dmStatus> <techStandard> <authorityInfoAndTp> <authorityInfo>

The authority that owns the source data from which the data module is written. Describing the information basis used to write the data module.

N/A

S1003X-B6865-01003-00


Chap 5






<dmStatus> <techStandard> <authorityInfoAndTp> <techPubBase>

Technical publication baseline to which the data module is written.

Task_identifier@Identifier, Task_identifier@Identifier_set_by_organization, Task_revision_identifier, Task_revision_status

AD DEX reference for Task_identifier@Identifier, Task_identifier@Identifier_set_by_organization and Task_revision_identifier: − DEX3AD section Task


AD DEX reference for Task_revision_status: − DEX3AD section Task

definition - Template table #10)

In order to establish an S1000D feedback to S3000L, this field must contain the Task_identifier, Task_revision_identifier and optionally Task_revision_status, from which the data module is being developed. Tasks can, however, have multiple identifiers. Business rule decision point - Multiple identifiers for tasks: If tasks have multiple identifiers, decide which identifier to use to populate the element <authorityInfoAndTp><techPubBase>. Note

A data module can be developed for more than one S3000L task, which means that this element will contain more than one set of task identification information.

<dmStatus> <systemBreakdownCode>

For those projects that are producing data

Breakdown_element_identifier

Breakdown_element_identifier for the Breakdown element being used within a physical breakdown, ie the associated Breakdown

S1003X-B6865-01003-00


Chap 5






modules that are in line with other logistic databases, the system breakdown code can be used to capture the physical breakdown code.

AD DEX reference: − DEX1AD section

Hardware element realization - Template table #130 or #134 or

− DEX1AD section Software element realization - Template table #150 or #154

attribute 'Breakdown_type' indicates a "Physical" value (DEX reference: DEX1AD section Breakdown structure - Template table #36). Associations between the "functional" and "physical" breakdown elements in S3000L can be established as either: − A Breakdown_element_relationship between two

Breakdown_elements, where the 'Breakdown_element_relationship_type' value is set to ‘Functional_physical_breakdown_element_relationship’ (DEX reference: DEX1AD section Hardware element realization - Template table #134, or section Software element realization - Template table #154)

− Usage of the same Breakdown_element within multiple types of Breakdowns, ie the Breakdown element has multiple instances of 'Breakdow_element_usage_in_breakdown', which relates the Breakdown element to different types of Breakdowns of the same Product (eg one "functional" breakdown and one "physical" breakdown) (DEX reference: DEX1AD section Hardware element realization - Template table #130, or section Software element realization - Template table #150)

Business rule decision point - Multiple identifiers for breakdown elements: If Breakdown elements have multiple identifiers, decide which identifer to use to populate the element <dmStatus><systemBreakdownCode>. Notes

1. Defined in 1388-2b using Logistics Control Number (LCN) - Physical.

S1003X-B6865-01003-00


Chap 5






2. Defined in S2000M using the Text Element Identifier (TEI) ILS.

<dmStatus> <functionalItemCode>

Used to capture the functional breakdown code.

N/A This element is redundant with the element <functionalItemRef> below. The use of is this element is therefore deprecated.

<dmStatus> <functionalItemRef>

Uniquely identify an item performing a function in a system at a given position.

Breakdown_element



− DEX1AD section Software element realization - Template table #150

Breakdown element being used within a functional or family breakdown, ie the associated Breakdown attribute 'Breakdown_type' indicates a 'Functional' value (DEX reference: DEX1AD section Breakdown structure - Template table #36). Note

Functional item ref can be either exact or by family.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <functionalItemRef@functionalItemNumber>

The functional item number value.

Breakdown_element_identifier AD DEX reference: − DEX1AD section

Hardware element realization - Template table #130 or #134 or

− DEX1AD section Software element realization - Template table #150 or #154

Breakdown_element_identifier for the Breakdown element being used within a functional breakdown, ie the associated Breakdown attribute 'Breakdown_type' indicates a 'Functional' value (DEX reference: DEX1AD section Breakdown structure - Template table #36). Business rule decision point - Multiple identifiers for breakdown elements: If Breakdown elements have multiple identifiers, decide which identifer to use to populate the attribute <functionalItemRef@functionalItemNumber>. Notes

Also refer to the mapping for element <dmStatus> <systemBreakdownCode> above.

1. Defined in 1388-2b using Logistics Control Number (LCN) - Functional.

2. Defined in S2000M using the attribute ILS. 3. This element has double meanings. Both specific function and

generic functions are addressed. 4. Use of generic functions need to be Harmonized with S4000M.

<dmStatus> <functionalItemRef@functionalItemType>

Indicates whether it is an exact functional item number (a given item) or a family functional item number (generic code for one component which has more than one position. Eg: seats, lights).

N/A If functionalItemNumber is populated then set the value of the attribute <functionalItemRef@functionalItemType> to 'Exact'.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <functionalItemRef@manufacturerCodeValue>

Supplier NCAGE code (for example in case of a component provided by external company).

Part_identifier@Identifier_set_by_organization AD DEX reference: − DEX1AD section

Hardware part - Template table #50 or #53 or

− DEX1AD section Software part - Template table #80 or #82

The Part that can realize the functional breakdown element is identified via either: − Hardware_part_realization (DEX reference: DEX1AD

section Hardware element realization - Template table #143) − Software_part_realization (DEX reference: DEX1AD

section Software element realization - Template table #164). Assign the id for the Organization that 'owns' the Part_identifier, where Organization_identifier@Identifier_class equals 'NCAGE_code'. Note

Identifier_set_by_organization is part of the S3000L data type Id.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <functionalItemRef> <name>

Coding of the functional item number nomenclature.

Breakdown_element_name AD DEX reference: − DEX1AD section


− DEX1AD section Software element realization - Template table #152

The Breakdown_element_name can be used to populate the element <name>. However, the breakdown element can have multiple names. Business rule decision point - Multiple names for breakdown elements: If Breakdown elements have multiple names, decide which name to use to populate the element <functionalItemRef><name>.

<dmStatus> <sourceDmIdent>

To ensure the traceability of the master data module, related to its instances, it is possible to record the identification of the source data module from which an instance has been derived.

N/A When this is used, it is generated by Tech Docs and the master DMC is exchanged with S3000L and not the DME customer deliverable DMCs.

<dmStatus> <applicCrossRefTableRef>

Contains a pointer to the Applicability Cross-reference Table (ACT) data module that applies to the data module.

N/A

S1003X-B6865-01003-00


Chap 5






<dmStatus> <applic>

The overall applicability for an entire data module.

Applicability_statement AD DEX reference: − DEX3AD section

Textual (not-computable) applicability statement - Template table #370 or

− DEX3AD section Dated applicability statement applicability statement - Template table #380 or

− DEX3AD section Applicability statement by assertion of serial number - Template table #390 or

− DEX3AD section Applicability statement by assertion of condition parameters (except serial number) - Template table #400

An Applicability_statement associated with a Task in S3000L can equal the element <applic> for the entire data module. Refer to Note 5 at Para 2.3Business rule decision point – Use of applicability:

.

Decide how to use applicability for the project/program both initially and through life with revisions. Examples: − Define permitted product attributes (Refer to Para 5.2

− Define permitted conditions (Refer to

on applicability cross-reference table).

Para 5.3

− Define task generality and usage of applicability at, for example, task/subtask/task resource levels.

on condition cross-reference table).

S1003X-B6865-01003-00


Chap 5






<dmStatus> <applic> <displayText> <simplePara>

Provides human readable applicability information.

Applicability_statement_description AD DEX reference: − DEX3AD section

Textual (not-computable) applicability statement - Template table #372 or

− DEX3AD section Dated applicability statement applicability statement - Template table #382 or

− DEX3AD section Applicability statement by assertion of serial number - Template table #392 or


Applicability_statement_description for the associated Applicability_statement.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <applic> <evaluate@andOr>

Provides applicability information in a computable format which can be used to support dynamic display of the annotated content.

Logical_operator subclasses ‘AND’ and ‘OR’, respectively AD DEX reference: − DEX3AD section

Applicability statement using logical operators - Template table #420

Use of 'Applicability_evaluation_by_logical_operator' and the 'Logical_operator' subclasses 'AND' or 'OR', respectively:

If 'Logical_operator' subclass 'AND' is used, then set the attribute <evaluate@andOr> to 'and'.

If 'Logical_operator' subclass 'OR' is used, then set the attribute <evaluate@andOr> to 'or'.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <applic> <assert>

Provides applicability information in a computable format which can be used to support dynamic display of the annotated content, by specifying the product attribute or condition to test and the values to test against.

Applicability_evaluation_by_assertion AD DEX reference: − DEX3AD section

Applicability statement by assertion of serial number - Template table #390 or


Use of either 'Applicability_evaluation_by_assertion_of_class_instance' or 'Applicability_evaluation_by_assertion_of_condition'.

<dmStatus> <applic> <assert@applicPropertyIdent>

Either the product identifier from the ACT data module) or condition identifier from the CCT data module) to test.

Condition_type_name, Condition_identifier, Maintenance_level_type, Maintenance_location, Operating_location_type,

Type of condition or value to be asserted: Condition_type_name:

− The value given in Condition_type_name, if the applicability statement refers to an instance of Condition_statement which in turn refers to an instance of Condition_type as its Condition_definition.

− The value of the attribute <assert@applicPropertyIdent> is exchanged in two different ways using DEX3AD. This is due to that the condition type value can be defined as either a property value or as a class value. If the condition type value is represented as a property

S1003X-B6865-01003-00


Chap 5






Operating_location, Breakdown_element, Part, User, Customer, Contract, Product_variant, Product_variant_realization and Product_usage_phase

AD DEX reference for Condition_type: − DEX3AD section

Applicability statement assertion - Template table #406 if the condition type value is represented as a property in the DEX

− DEX3AD section Applicability statement assertion - Template table #400 if the condition type value is represented as a class value in the DEX

then use the value defined in Template table #406 input parameter ‘property_class_name’ to populate the attribute <assert@applicPropertyIdent>. If the condition type value is represented as a class value then use the value defined in Template table #400 input parameter ‘para_class’ to populate the attribute <assert@applicPropertyIdent>.

Condition_identifier:

− The value given in Condition_identifier, if the applicability statement refers to an instance of Condition_statement which in turn refers to an instance of Condition_by_identifier as its Condition_definition.

Note The value of the attribute <assert@applicPropertyIdent> is exchanged using Template table #408 input parameter ‘id’.

Maintenance_level_type:

− populate the attribute <assert@applicPropertyIdent> with string value ‘maintenanceLevel’, if the applicability statement refers to an instance of Maintenance_level_type

Maintenance_location:

− populate the attribute <assert@applicPropertyIdent> with string value ‘maintenanceLocation’, if the applicability statement refers to an instance of Maintenance_location

Operating_location_type:

S1003X-B6865-01003-00


Chap 5






AD DEX reference for Condition_by_identifier: − DEX3AD section

Applicability statement assertion - Template table #408

AD DEX reference for Maintenance_level_type: − DEX3AD section

Applicability statement assertion and its reference to DEX3AD section Task assignment - Template table #154

AD DEX reference for Maintenance_location: − DEX3AD section


AD DEX reference for Operating_location_type: − DEX3AD section

Applicability statement assertion and its

− populate the attribute <assert@applicPropertyIdent> with string value ‘operatingLocationType’, if the applicability statement refers to an instance of Operating_location_type

Operating_location:

− populate the attribute <assert@applicPropertyIdent> with string value ‘operatingLocation’, if the applicability statement refers to an instance of Operating_location

Breakdown_element:

− populate the attribute <assert@applicPropertyIdent> with string value ‘breakdownElement’, if the applicability statement refers to an instance of Breakdown_element

Part:

− populate the attribute <assert@applicPropertyIdent> with string value ‘part’, if the applicability statement refers to an instance of Part

− populate the attribute <assert@applicPropertyIdent> with string value 'partSerialNumberRange', if the value refers to an instance of Part which in turn refers to an instance of Block_of_serialized_items (DEX reference: DEX3AD section Applicability statement by assertion of serial number - Template table #390)

User:

− populate the attribute <assert@applicPropertyIdent> with string value ‘user’, if the applicability statement refers to an instance of User

S1003X-B6865-01003-00


Chap 5






reference to DEX3AD section Task assignment - Template table #158

AD DEX reference for Operating_location: − DEX3AD section


AD DEX reference for Breakdown_element: − DEX3AD section

Applicability statement assertion and its references to either DEX1AD section Breakdown element realization (Template tables #130 and #150), or DEX1AD section Aggregated breakdown element (Template table #170)

AD DEX reference for Part: − DEX3AD section

Applicability statement

Customer:

− populate the attribute <assert@applicPropertyIdent> with string value ‘customer’, if the applicability statement refers to an instance of Customer

Contract:

− populate the attribute <assert@applicPropertyIdent> with string value ‘contract’, if the applicability statement refers to an instance of Contract

Product_variant:

− populate the attribute <assert@applicPropertyIdent> with string value 'productVariant', if the value refers to an instance of Product_variant

− populate the attribute <assert@applicPropertyIdent> with string value 'endItemSerialNumberRange', if the value refers to an instance of Product_variant which in turn refers to an instance of Block_of_serialized_items (DEX reference: DEX3AD section Applicability statement by assertion of serial number - Template table #390)

Product_variant_realization:

− populate the attribute <assert@applicPropertyIdent> with string value 'productConfiguration', if the value refers to an instance of Product_variant_realization

Product_usage_phase:

− populate the attribute <assert@applicPropertyIdent> with string value ‘productUsagePhase’ if the value refers to an instance of

S1003X-B6865-01003-00


Chap 5






assertion and its references to DEX1AD section Part - Template tables #50 and #80

− DEX3AD section Applicability statement by assertion of serial number - Template table #390

AD DEX reference for User: − DEX3AD section

Applicability statement assertion and its references to DEX1AD section Product and Project - Template table #22

AD DEX reference for Customer: − DEX3AD section


AD DEX reference for Contract: − DEX3AD section

Product_usage_phase Note

Refer to Para 5 - Applicability.

S1003X-B6865-01003-00


Chap 5







AD DEX reference for Product_variant: − DEX3AD section



AD DEX reference for Product_variant_realization: − DEX3AD section

Applicability statement assertion and its references to DEX1AD section Product variant applicability - Template table #203

S1003X-B6865-01003-00


Chap 5






AD DEX reference for Product_usage_phase: − DEX3AD section


<dmStatus> <applic> <assert@applicPropertyType>

Indicates whether the applicability property identifier value references a product attribute or a condition.

Condition_type, Condition_by_identifier, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract, Product_variant, Product_variant_realization and Product_usage_phase

The value to populate the attribute <assert@applicPropertyType> is derived from the type of class that is being used in the Applicability_evaluation_by_assertion:

− The attribute <assert@applicPropertyType> shall be set to 'condition' if the Applicability_evaluation_by_assertion referes to an instance of:

• Condition_type • Condition_by_identifier • Maintenance_level_type • Maintenance_location • Operating_location_type • Operating_location • Breakdown_element • Part • Customer • User • Contract

S1003X-B6865-01003-00


Chap 5






Refer to AD DEX references defined for the <dmStatus><applic><assert@applicPropertyIdent> attribute above.

• Product_usage_phase − The attribute <assert@applicPropertyType> shall be set to

'prodattr' if the Applicability_evaluation_by_assertion referes to an instance of:

• Product_variant • Product_variant_realization

Note Refer to Para 5 - Applicability.

<dmStatus> <applic> <assert@applicPropertyValues>

The values and/or ranges to test against.

Condition_type_class_value, Condition_type_property_value, Maintenance_level_type_name, Maintenance_location_name, Operating_location_type_name, Operating_location_name, Breakdown_element_identifier, Part_identifier, Organization_name

The value to assert (ie value that can populate the attribute <assert@applicPropertyValues>) must equal one of the following: − Condition_type_class_value if:

• The Condition_definition refers to a Condition_type whose condition type value is represented as a class value (DEX reference - DEX3AD section Applicability statement assertion - Template table #400)

• if the Condition_definition refers to a Condition_by_identifier whose value is represented as a class value (DEX reference - DEX3AD section Applicability statement assertion - Template table #408)

− Condition_type_property_value if the Condition_definition refers to a Condition_type whose condition type value is represented as a property (DEX reference - DEX3AD section Applicability statement assertion - Template table #406)

S1003X-B6865-01003-00


Chap 5






Contract_identifier, Product_variant_identifier, Product_variant_realization_identifier, Serial_number_lower_bound, Serial_number_upper_bound and Product_usage_phase

AD DEX reference for Condition_type_class_value: − DEX3AD section

Applicability statement assertion - Template table #405 if the Condition_definition refers to a Condition_type whose condition type value is represented as a class value (ie Condition_type_class_v

− Maintenance_level_type_name, if the attribute <assert@applicPropertyIdent> is defined as 'maintenanceLevel’

− Maintenance_location_name, if the attribute <assert@applicPropertyIdent> is given the value 'maintenanceLocation’

− Operating_location_type_name, if the attribute <assert@applicPropertyIdent> is given the value 'operatingLocationType’

− Operating_location_name, if the attribute <assert@applicPropertyIdent> is given the value 'operatingLocation’

− Breakdown_element_identifier, if the attribute <assert@applicPropertyIdent> is given the value 'breakdownElement’

Business rule decision point - Multiple identifiers for breakdown elements: If Breakdown elements have multiple identifiers, decide which identifer to use to populate the attribute <assert@applicPropertyValues>.

− Part_identifier, if the attribute <assert@applicPropertyIdent> is given the value 'part’

Business rule decision point - Multiple identifiers for parts: If parts have multiple identifiers, decide which identifer to use to populate the attribute <assert@applicPropertyValues>.

− Organization_name if the attribute

S1003X-B6865-01003-00


Chap 5






alue) − DEX3AD section

Applicability statement assertion - Template table #409 if the Condition_definition refers to a Condition_by_identifier whose value is represented as a class value (ie Condition_type_class_value)

AD DEX reference for Condition_type_property_value: − DEX3AD section

Applicability statement assertion - Template table #407 if the Condition_definition referes to a Condition_type whose value is represented as a property (ie Condition_type_property_value)

AD DEX reference for Maintenance_level_type_name:

<assert@applicPropertyIdent> is given the value 'user' or ‘customer’

− Contract_identifier if the attribute <assert@applicPropertyIdent> is given the value 'contract'

Business rule decision point - Multiple identifiers for contracts: If contracts have multiple identifiers, decide which identifer to use to populate the attribute <assert@applicPropertyValues>.

− Product_variant_identifier, if the attribute <assert@applicPropertyIdent> is given the value 'productVariant'

Business rule decision point - Multiple identifiers for product variants: If product variants have multiple identifiers, decide which identifer to use to populate the attribute <assert@applicPropertyValues>.

− Product_variant_realization_identifier, if the attribute <assert@applicPropertyIdent> is given the value 'productConfiguration'

− Serial_number_lower_bound and Serial_number_upper_bound , if <assert@applicPropertyValue is given the value 'endItemSerialNumberRange'

− Product_usage_phase if the attribute <assert@applicPropertyIdent> is given the value ‘productUsagePhase’

Notes 1. In an integration of S1000D and S3000L positive statements should

S1003X-B6865-01003-00


Chap 5






− DEX3AD section Applicability statement assertion and its reference to DEX3AD section Task assignment - Template table #154

AD DEX reference for Maintenance_location_name: − DEX3AD section


AD DEX reference for Operating_location_type_name: − DEX3AD section


AD DEX reference for Operating_location_name: − DEX3AD section

always be used, ie the assert value should always be 'true'. 2. Refer to Para 5 - Applicability.

S1003X-B6865-01003-00


Chap 5







AD DEX reference for Breakdown_element_identifier: − DEX3AD section

Applicability statement assertion and its references to either DEX1AD section Breakdown element realization (Template tables #130/ #131 and #150/#151), or DEX1AD section Aggregated breakdown element (Template table #170/#171)


Applicability statement assertion and its references to DEX1AD section Part - Template tables #50/#53 and

S1003X-B6865-01003-00


Chap 5






#80/#82 AD DEX reference for Organization_name: − DEX3AD section

Applicability statement assertion and its references to DEX1AD section Product and Project - Template table #22, for User

− DEX3AD section Applicability statement assertion and its references to DEX1AD section Product and Project - Template table #19, for Customer

AD DEX reference for Contract_identifier: − DEX3AD section

Applicability statement assertion and its references to DEX1AD section Product and Project - Template table #15/#16

AD DEX reference for Product_variant_identifier: − DEX3AD section

S1003X-B6865-01003-00


Chap 5






Applicability statement assertion and its references to DEX1AD section Product and Project - Template table #6/#8

AD DEX reference for Product_variant_realization_identifier: − DEX3AD section

Applicability statement assertion and its references to DEX1AD section Product variant applicability- Template table #201

AD DEX reference for Serial_number_lower_bound / Serial_numbe_upper_bound: − DEX3AD section

Applicability statement by assertion of serial number - Template table #390



S1003X-B6865-01003-00


Chap 5






assertion - Template table #410

<dmStatus> <referencedApplicGroup>

Provides a container for defining applicability annotations that apply to various parts of the data module. Such applicability annotations can be used to restrict the applicability for a substructure of the data module, compared to the applicability specified for the whole data module.

For detailed mapping of the elements of <applic> and its subelements refer to the <dmStatus><applic> mappings above. Refer to Note 5 at Para 2.3This element can collect Applicability_statements used within an S3000L Task and which are identified using the Applicability_statement_identifier. These Applicability_satatements can then be referenced from within the data module using the attribute <XXX@applicRefId>.

.

The only thing that will differ between the <dmStatus><applic> mappings above and the <dmStatus><referencedApplicGroup> mapping is the use of the attribute <applic@id>

<dmStatus> <referencedApplicGroup> <applic@id>

The identifier of the element.

Applicability_statement_identifier AD DEX reference: − DEX3AD section

Applicability statement - Template tables #371, #381, #391 and #402

Applicability_statement_identifier Refer to the mapping details under the element <dmStatus><referencedApplicGroup> above.

S1003X-B6865-01003-00


Chap 5






<dmStatus> <reasonForUpdate>

A short explanation of the reason for updating of the data module.

Task_revision_change_description AD DEX reference: − DEX3AD section Task


Task_revision_change_description

<dmStatus> <productSafety>

Contains an indication when a module is transmitting information that affects the safety of the product's users.

N/A

<dmStatus> <skillLevel@skillLevelCode>

The skill level to which the data module has been written.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


2.3 Notes for Table 2 These notes are provided to give clarification to many of the entries in Table 2.

Note 1 The product breakdown is defined during design and is exchanged using DEX1AD. This breakdown structure is used by both S1000D and S3000L as the anchor points for which tasks and data modules are defined.

It is recognized that the S3000L process may identify additional candidate breakdown elements that are not indicated in the breakdown as defined during design. However, these additional candidates would always map back to the design breakdown structure in some way. Zonal breakdown elements are examples of breakdown elements that might be created during an LSA.

Note 2 For S1000D, the SNS will be applied to the breakdown elements. S1000D will allocate ICs to data modules based on the S3000L Information_codes that are assigned to the tasks and subtasks.

When the complete DMCs are built, they are exchanged back to S3000L environment to give the traceability between tasks and data modules.

Note 3 Where S3000L "refers out" to an existing task narrative this must be exchanged with S1000D so that S1000D sees that one data module is required for the task, used in multiple places.

Note 4 When the need for ICV is exchanged a plain text definition for the allocation of the ICV must be exchanged so that the element <infoName> is modified in S1000D appropriately. For example SNS = wheel Infoname = remove ICV = front left or rear left, ICV = A, ICV = B, respectively.

Note 5 The use of element <applic> and the element <referencedApplicGroup> are the same throughout the schemas, and will not be repeated for each occurrence in the schemas.

3 S1000D Maintenance procedure 3.1 Introduction

The Maintenance procedure schema is used to capture and represent procedural information. The granularity of maintenance procedure data modules follows the breakdown given by the SNS, and reflects the tasks identified in the maintenance plan.

The procedure covers all information necessary to carry out the task and describes:

− Any actions to be carried out or conditions that must be satisfied before the main procedure is started (the element <preliminaryRqmts>), including personnel, required technical information, support equipment, supplies and spares that are needed to perform the procedure to its completion.

− The detailed procedural steps to be carried out (the element <mainProcedure>). − Any actions that are required after the main procedure is complete, to return the product to

a serviceable condition or the conditions that must be satisfied to have the product in a serviceable condition (the element <closeRqmts>).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Note Maintenance procedures applies to Tasks being instances of both ‘Rectifying_task’, ‘Supporting_task’ and ‘Logistics_operational_task’, for which the value of S1000D_task_type_code is set to 'Procedure_task' (DEX reference: DEX3AD section Task definition – Template tables #2 and #5).The S1000D_task_type attribute defines how a task in S3000L corresponds with the schemas defined in S1000D:

• 'Procedure_task' = S1000D proced Schema • 'Package_task' = S1000D schedul Schema

Note The element <warningAndCautions> is directly under the element <content>. This is a collection element that can contain all the warnings and cautions that are needed for the data module. These are then referenced from the warning or caution elements within the data module. This element needs to be populated by the author.S1000D in accordance with the procedural Schema

3.2 Preliminary requirements Table 3 describes the elements and attributes in preliminaryRqmts (Preliminary requirements).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 3 PreliminaryRqmts (Preliminary requirements) - Elements and attributes





<preliminaryRqmts> <productionMaintData>

Contains the basic information required for the planning and preparation of the task.

<preliminaryRqmts> <productionMaintData> <thresholdInterval>

Note The element <thresholdInterval> is not to be used for the procedure data module. Refer to Para 4.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <productionMaintData> <zoneRef@zoneNumber>

Zoning information (one or more).


Breakdown zone element - Template table #183 or Template table #184

Can be derived from either: − 'Core' Subtasks, and their respective Subtask_in_zone

association with a Zone_element (DEX reference: DEX3AD section Subtask by definition - Template table #47) or

− An assumption that the same as the Zone_element which can be identified via the Hardware_element_in_zone_relationship for the Hardware_element, on which the Task, and/or 'Core' Subtasks, is being performed (DEX reference: DEX1AD section Breakdown zone element - Template table #192).

The associated Zone_element must be categorized as zone, ie the attribute Zone_element_type is set to 'Zone_element' (DEX reference: DEX1AD section Breakdown zone element - Template table #186). Business rule decision point - Multiple identifiers for zone elements: If zone elements have multiple identifiers, decide which identifer to use to populate the attribute <zoneRef@zoneNumber>. Note

Defined in 1388-2b using Work area code.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <productionMaintData> <zoneRef> <name>


Breakdown zone element - Template table #185

Refer to the element <zoneRef@zoneNumber> above for mapping information. Business rule decision point - Multiple names for zone names: If zone elements have multiple names, decide which name to use to populate the element <zoneRef><name>.

<preliminaryRqmts> <productionMaintData> <accessPointRef@accessPointNumber>

Describe any (one or more) access points like panels, doors, hatches.


Hardware element realization - Template table #130 or Template table #131

<accessPointRef@accessPointNumber> can be derived if either: − The Hardware_element to which the Task is assigned is related

to another Hardware_element, using a Breakdown_element_relationship where the Breakdown_element_relationship_type value is set to ‘Access_point’ (DEX reference: DEX1AD section Hardware element realization - Template table #134)

or − If the Task contains Subtask(s) which gives access, eg via an

access point. These subtasks will be categorized by Information_code = 540 and must be 'Startup' subtasks. DEX reference for identifying ‘Startup’ subtasks:

• DEX3AD section Subtask by reference - Template table #25, if subtask by reference or

• DEX3AD section Subtask by definition - Template table #41 if

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






subtask by definition DEX reference for identifying ‘Information_code’:

• DEX3AD section Task definition - Template table #6 if subtask by reference or

• DEX3AD section Subtask by definition - Template table #43 if subtask by definition

The value for the attribute <accessPointRef@accessPointNumber> can then be set to the identifier for breakdown element which is related via the Task_target_item or Subtask_target_item relationship, respectively

DEX reference for identifying Task_target_item or Subtask_target_item:

• DEX3AD section Task assignment - Template table #140 for task target item, or

• DEX3AD section Subtask by definition - Template table #55 for subtask target item).

Notes 1. This mapping applies to 'Closeup' subtasks as well, with the

exception that closeup subtasks will be categorized by Information_code = 740.

2. Breakdown elements which can play the role of access points can be verified by checking that the ‘Hardware_element_type’ equals 'Door_element', 'Control_panel' or

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






'Hatch_element' (DEX reference: DEX1AD section Hardware element realization - Template table #133).

Business rule decision point - Multiple identifiers for zone elements: If zone elements have multiple identifiers, decide which identifer to use to populate the attribute <accessPointRef@accessPointNumber>.

<preliminaryRqmts> <productionMaintData> <accessPointRef@accessPointTypeValue>

Access point type. Hardware_element_type AD DEX reference: − DEX1AD section

Hardware element realization - Template table #133

For mapping information refer to the attribute <preliminaryRqmts><productionMaintData> <accessPointRef@accessPointNumber> above.

<preliminaryRqmts> <productionMaintData> <accessPointRef> <name>

The name of the access point.


Hardware element realization - Template table #132)

For mapping information refer to the attribute <preliminaryRqmts><productionMaintData> <accessPointRef@accessPointnumber> above. Business rule decision point - Multiple names for zone names: If zone elements have multiple names, decide which name to use to populate the element <accessPointRef><name>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <productionMaintData> <workArea>

Area where work is accomplished.



Can be derived from: − 'Core' Subtasks, and their respective Subtask_in_zone

association with Zone_element (DEX reference: DEX3AD section Subtask by definition - Template table #47) or

− Be assumed to be the same as the Zone_element which can be identified via the Hardware_element_in_zone_relationship for the Hardware_element, on which the Task, and/or 'Core' Subtasks, is being performed (DEX reference: DEX1AD section Breakdown zone element - Template table #192).

The associated Zone_element must be categorized as a work area (ie the attribute Zone_element_type is set to 'Work_area') (DEX reference: DEX1AD section Breakdown zone element - Template table #186). Business rule decision point - Categorization of a zone as a work area: Decide on the categorization of the zone element as a work area to populate the element <workArea>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <productionMaintData> <taskDuration@unitOfMeasure>

The unit of measure for all taskDurations (startup, procedure and closeup).

Subtask_duration/Task_duration AD DEX reference: − DEX3AD section Task

definition - Template table #12 if task duration, or

− DEX3AD section Subtask by definition - Template table #46 if subtask duration

The lowest common time unit for the Property_representations that is used to represent the Subtask_durations/Task_durations within the Task under consideration.

<preliminaryRqmts> <productionMaintData> <taskDuration@startupDuration>

Duration for performing preliminary requirements.

Subtask_duration/Task_duration

AD DEX reference: − DEX3AD section Task



Summarize (roll-up) the durations for all subtasks classified as 'Startup_subtask'. Notes

1. Roll-up can also consider Subtask_timeline (DEX reference: DEX3AD section Subtask by reference - Template tables #26 and #27).

2. Roll-up must also consider Task_duration for any Subtask_by_reference.

3. Defined in 1388-2b using Elapsed Time. 4. Refer to Note 1 at Para 3.3.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <productionMaintData> <taskDuration@procedureDuration>

Duration for performing the procedure.





Summarize (roll-up) the durations for all subtasks classified as 'Core_subtask' (incl. 'Core_subtask_without_required_startup'). Notes


2. Roll-up must also consider Task_duration for Subtask_by_reference.

3. Defined in 1388-2b using Elapsed Time Refer to Note 1 at Para 3.3.

<preliminaryRqmts> <productionMaintData> <taskDuration@closeupDuration>

Duration for performing the Requirements after job completion.





Summarize (roll-up) the durations for all subtasks classified as 'Closeup_subtask'. Notes


2. Roll-up must also consider Task_duration for Subtask_by_reference.

3. Defined in 1388-2b using Elapsed Time Refer to Note 1 at Para 3.3.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup>

Required conditions are actions to be done and/or conditions that must be satisfied before you do the procedure which is the subject of the data module.

Subtask


Subtask by reference - Template table #25 if Subtask by reference or

− DEX3AD section Subtask by external reference - Template table #30 if Subtask by external reference or

− DEX3AD section Subtask by definition - Template table #40 if Subtask by definition

Defined by Subtasks where subtask_role is classified as 'Startup_subtask' (DEX reference: DEX3AD section Subtask by reference - Template table #25, DEX3AD section Subtask by external reference - Template table #31, and DEX3AD section Subtask by definition - Template table #41).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <noConds>

Used to indicate that there are no required actions/ conditions for the procedure.

Subtask_role AD DEX reference: − DEX3AD section

Subtask by reference - Template table #25 if subtask by reference or

− DEX3AD section Subtask by external erefence - Template table #31 if Subtask by external reference or

− DEX3AD section Subtask by definition - Template table #41 if Subtask by definition

For tasks in S3000L that has no 'Startup' subtasks, this is indicated by setting the value of Subtask_role for the first subtask to 'Core_subtask_without_required_startup'.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondNoRef <reqCond>

Simple action/ condition with no referenced data module or technical publication (Simple text).

(Task_name &) Subtask_name and Subtask_objective_state


definition - Template table #1 for Task_name and

− DEX3AD section Subtask by definition - Template table #42 for Subtask_name and

− DEX3AD section Subtask by definition Template table #49 for Subtask_objective_state

The element <reqCondNoRef><reqCond> can be populated with a concatenated string value made up from: − Task_name if the ‘Startup_subtask’ is an instance of

Subtask by reference (DEX reference: DEX3AD section Subtask by reference - Template table #25)

− Subtask_name

− Subtask_objective_state

Repeat for possible Subtask_by_reference within the referenced task. Notes

1. There must be one instance of the element <reqCondNoRef><reqCond> per Subtask_by_definition being classified as 'Startup_subtask' (Subtask_role) and that has an associated instance of 'Subtask_objective_state'.

2. Subtask_by_definition where the associated instance of 'Subtask_objective_state' is an instance of 'Subtask_circuit_breaker_state' is defined as separate required conditions within the element <reqCondGroup> <reqCircuitBreakerList> and must not be instantiated within this element.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondNoRef <reqCond@reqCondCategory>

Category of the condition, eg special environmental conditions such as reduced lighting, ventilation, and temperature.

N/A for issue 4.0

<preliminaryRqmts> <reqCondGroup> <reqCondDm>

Simple statement for a condition with a link to a data module that tells you how to satisfy that condition.

N/A There is no notion of data modules when S3000L data is transferred to S1000D.

<preliminaryRqmts> <reqCondGroup> <reqCondPm> <pmRef> <pmRefIdent> <pmCode>

The publication module code.

Publication_module_code AD DEX reference: − DEX3AD section

Subtask by external reference - Template table #34

Publication_module_code for the S1000D_publication_module being associated with Subtask_by_external_reference, where Subtask_role is defined as 'Startup_subtask' (DEX reference: DEX3AD section Subtask by external reference - Template table #31)

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondPm> <pmRef> <pmRefIdent> <issueInfo@issueNumber>

Issue information needed to address a particular destination data module issue.

Publication_module_issue_number AD DEX reference: − DEX3AD section


Publication_module_issue_number for the S1000D_publication_module being associated with Subtask_by_external_reference. Also refer to the mapping defined for element <reqCondGroup><reqCondPm><pmRef> <pmRefIdent><pmCode> above.

<preliminaryRqmts> <reqCondGroup> <reqCondPm> <reqCond>

Contains the required action/condition statement.

Publication_module_title AD DEX reference: − DEX3AD section

Document- Template table #345

Publication_module_title for the S1000D_publication_module being associated with Subtask_by_external_reference. Also refer to the mapping defined for <reqCondGroup><reqCondPm><pmRef> <pmRefIdent><pmCode> above.

<preliminaryRqmts> <reqCondGroup> <reqCondExternalPub> <externalPubRef> <externalPubRefIdent> <externalPubCode>

Contains, as text content, a code that identifies a non S1000D document, such as an ISBN code or similar.

Document_identifier AD DEX reference: − DEX3AD section


Document_identifier for the External_document being associated with Subtask_by_external_reference, where Subtask_role is defined as 'Startup_subtask' (DEX reference: DEX3AD section Subtask by external reference - Template table #31). Note

The required conditions would be described in other technical documentation (which may or may not be in the LSAR).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondExternalPub> <externalPubRef> <externalPubRefIdent> <externalPubTitle>


Document_title AD DEX reference: − DEX3AD section

Document - Template table #348

Document_title for the External_document being associated with Subtask_by_external_reference, where the Subtask_role is defined as 'Startup_subtask'. Also refer to the mapping defined for element <reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent> <externalPubCode> above.

<preliminaryRqmts> <reqCondGroup> <reqCondExternalPub> <externalPubRef> <externalPubRefIdent> <externalPubIssueInfo> <externalPubIssue>

Issue nformation concerning a referred non S1000D document.

Document_issue_identifier AD DEX reference: − DEX3AD section


Document_issue_identifier for the External_document being associated with Subtask_by_external_reference, where the Subtask_role is defined as 'Startup_subtask'. Also refer to the mapping defined for element <reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent> <externalPubCode> above.

<preliminaryRqmts> <reqCondGroup> <reqCondExternalPub> <reqCond>

Contains the required action/condition statement.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <reqCond>

(Required condition of circuit breakers) The required conditions (simple text statement) that a list of circuit breakers must be in. The schema gives the capability to link from an individual data module to further circuit breaker information, held in the CB Tech repository data module.

Subtask_name AD DEX reference: − DEX3AD section


One instance of the element <reqCondCircuitBreaker><reqCond> per Subtask_by_definition where Subtask_role is classfied as 'Startup_subtask' and the Subtask_by_definition has at least one associated instance of Subtask_circuit_breaker_state (DEX reference: DEX3AD section Subtask by definition - Template tables #41 and #50, respectively). The element <reqCond> can be populated with the Subtask_name.

<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <reqCond@reqCondCategory>

The category of the condition, eg special environmental conditions such as reduced lighting, ventilation, and temperature.

N/A

<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup>

Contains the circuit breaker lists information.

N/A Note S3000L defines the circuit breaker state per identified Circuit breaker.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup@circuitBreakerAction>

The action to perform on the whole set of circuit breaker described in the table.

N/A Note S3000L defines the circuit breaker state per identified Circuit breaker.

<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <functionItemRef>

Indicates the particular context for this set of circuit breakers.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerNumber>

The circuit breaker number.

Circuit_breaker_identifier AD DEX reference: − DEX3AD section


Circuit_breaker_identifier for the Circuit_breaker being associated with the Subtask_circuit_breaker_state (DEX reference: DEX3AD section Subtask by definition - Template table #50).

<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerType>

The circuit breaker type. Circuit_breaker_type AD DEX reference: − DEX3AD section


Circuit_breaker_type for the Circuit_breaker being associated with the Subtask_circuit_breaker_state.

Circuit_breaker_type is defined using reference data that corresponds to the S1000D <circuitBreakerRef@circuitBreakerType> allowed values: − ‘Electronic_circuit_breaker_element’ (equals

@circuitBreakerType 'eltro')

− ‘Electro_mechanic_circuit_breaker_element’ (equals @circuitBreakerType 'elmec')

− ‘Dummy_circuit_breaker’ (equals @circuitBreakerType 'clip')

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerAction>

Action to perform on the circuit breaker.

Subtask_objective_state AD DEX reference: − DEX3AD section


Subtask_circuit_breaker_state identifies the specific circuit breakers by its id and its required state (Subtask_objective_state inherited from class Subtask_objective_state). Circuit breaker state is defined using reference data that corresponds to the S1000D <circuitBreakerRef@circuitBreakerAction> allowed values: − ‘Circuit_breaker_open’ (equals

@circuitBreakerAction ‘Open’ and ‘Verify_open’)

− ‘Circuit_breaker_closed’ (equals @circuitBreakerAction ‘Closed’ and ‘Verify_closed’)

<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr> <name>

The name of the circuit breaker.

Circuit_breaker_name AD DEX reference: − DEX3AD section


Circuit_breaker_name for the Circuit_breaker being associated with the Subtask_circuit_breaker_state.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr> <accessPointRef>

Describes/identifies any (one or more) access points like panels, doors, hatches.

N/A Not defined for circuit breakers in S3000L.

<preliminaryRqmts> <reqCondGroup> <reqCondCircuitBreaker> <circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerLocation>

Circuit breaker location in the circuit breaker panel by entering text.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqPersons>

Each person required to do the Procedure can be listed together with the appropriate information as defined by the project: category, skill level, trade/trade code and estimated time spent per person.

Task_personnel_resource

Summary of Task_personnel_resource for all Subtasks where Subtask_role is defined as 'Core_subtask' (including its specialization ‘Core_subtask_without_required_startup’). Note

The absence of a specified quantity in Issue 4 indicates "As required", which is more in line with S3000L.

<preliminaryRqmts> <reqPersons> <personnel>

Contains the information on the required personnel for the task by grouping the personnel by category, skill level and trade/trade code together with the number of personnel of a certain skill (category, skill level, trade).

Task_personnel_resource AD DEX reference: − DEX3AD section Task

personnel resource - Template table #110

Task_personnel_resource where Task_personnel_resource_role doesn't begin with 'Man_' (DEX reference: DEX3AD section Task personnel resource - Template tables #110).

<preliminaryRqmts> <reqPersons> <personnel@numRequired>

The number of personnel for a certain combination of category, skill level and trade.

Task_number_of_personnel_resource AD DEX reference: − DEX3AD section Task


Task_personnel_resource attribute Task_number_of_personnel_resource.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqPersons> <personnel> <personCategory@personCategoryCode>

The typed in category level of the person.

Trade_name AD DEX reference: − DEX3AD section Task


Trade_name for the Trade being associated with Task_personnel_resource.

Trade can be associated with a Task_personnel_resource either directly as the selected Competence, or via Skill as the Competence.

<preliminaryRqmts> <reqPersons> <personnel>

personSkill@skillLevelCode>

The skill level of the person.

Skill_level_name (Not included in the current version of AD DEXs)

The Skill_level_name for the Skill_level being associated with Task_personnel_resource.

<preliminaryRqmts> <reqPersons> <personnel> <trade>

Required trade code of the person.

Skill_code AD DEX reference: − DEX3AD section Task


The Skill_code for the Skill being associated with Task_personnel_resource.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqPersons> <personnel> <estimatedTime>

Estimate of the time that the person will be required on the task. The time must be given in hours with one decimal, eg 2,4 h, or days, eg 1,5 d.

Task_personnel_resource_labour_time AD DEX reference: − DEX3AD section Task


Task_personnel_resource attribute Task_personnel_resource_labour_time. Note

The attribute <estimatedTime@unitOfMeasure> is populated with the Unit given in the Task_personnel_resource_labour_time Property_representation.

<preliminaryRqmts> <reqPersons> <personnel> <estimatedTime@unitOfMeasure>

Unit of measure for estimatedTime.



For mapping information refer to the element <preliminaryRqmts><reqPersons> <personnel><estimatedTime> above.

<preliminaryRqmts> <reqPersons> <person>

The skill information on the required personnel for the task when there are requirements to individually specify the personnel.

Task_personnel_resource AD DEX reference: − DEX3AD section Task


Task_personnel_resource where the value of Task_personnel_resource_role begins with 'Man_'.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqPersons> <person@man>

Alphabetic identifier of the person, starting from A.

Task_personnel_resource_role AD DEX reference: − DEX3AD section Task


Task_personnel_resource attribute Task_personnel_resource_role Extract the last letter from the reference data class used to determine the Task_personnel_resource_role, eg ‘A’ from ‘Man_A’

<preliminaryRqmts> <reqPersons> <person> <personCategory@personCategoryCode

Category level of the person. Project has to list their codes, eg Electrician, Propulsion engineer, Maintainer.



The Trade_name for the Trade being associated with Task_personnel_resource.

Trade can be associated with a Task_personnel_resource either directly as the selected Competence, or via Skill as the Competence.

<preliminaryRqmts> <reqPersons> <person> <personSkill@skillLevelCode>

Represents the skill level that the person must have attained to be able to perform his or her role in the Procedure and is, eg Basic, Intermediate or Advanced.


The Skill_level_name for the Skill_level being associated with Task_personnel_resource.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqPersons> <person> <trade>

Trade or trade code of the person.

Skill_code AD DEX reference: − DEX3AD section Task


The Skill_code for the Skill being associated with Task_personnel_resource.

<preliminaryRqmts> <reqPersons> <person> <estimatedTime>

Estimate of the time that the person will be required on the task.



Task_personnel_resource_labour_time per required personnel resource. Note

The attribute <estimatedTime@unitOfMeasure> is populated with the Unit given in the Task_personnel_resource_labour_time Property_representation.

<preliminaryRqmts> <reqPersons> <person> <estimatedTime@unitOfMeasure>

Unit of measure. Task_personnel_resource_labour_time AD DEX reference: − DEX3AD section Task


For mapping information refer to the element <preliminaryRqmts><reqPersons><person><estimatedTime> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupportEquips>

Support equipment including special tools, required to accomplish the Procedure.

Task_material_resource AD DEX reference: − DEX3AD section Task

material resource by specification - Template table #60, or

− DEX3AD section Task material resource by reference - Template table #80

Summary of Task_material_resource's for all Subtasks where Subtask_role is defined as 'Core_subtask' (including its specialization ‘Core_subtask_without_required_startup’) and Task_material_resource_category is set to ’Required_support_equipment_resource’.

<preliminaryRqmts> <reqSupportEquips> <noSupportEquips>

Used to indicate that there is no support equipment.

The absence of Task_material_resource with Task_material_resource_category set ’Required_support_equipment_resource’.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <name>

The name (nomenclature) of the support equipment.

Resource_specification_name or Part_name AD DEX reference: − DEX3AD section Task

material resource by specification - Template table #68 if resource by specification or

− DEX1AD section Hardware part - Template table #52 if resource by reference

Resource_specification_name if the Task_material_resource is an instance of Task_material_resource_by_specification (DEX reference: DEX3AD section Task material resource by specification - Template tables #67). Part_name if the Task_material_resource is an instance of Task_material_resource_by_reference (DEX reference: DEX3AD section Task material resource by reference - Template tables #86) Business rule decision point - Multiple names for hardware parts: If hardware parts have multiple names, decide which name to use to populate the element <supportEquipDescr><name>.

<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <catalogSeqNumberRef@catalogSeqNumberValue>

Provide the link to the associated parts data module.

N/A Sourced from S2000M. Can not be provided by S3000L.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <natoStockNumber> <fullNatoStockNumber>

The NATO Stock Number (NSN) of the support equipment.

Resource_specification_identifier AD DEX reference: − DEX3AD section Task

material resource by specification - Template table #67

Resource_specification_identifier classified as ’NSN_code’.

<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <identnumber> <manufacturerCode>

The manufacturer's identification information.

Part_identifier@Identifier_set_by_organization AD DEX reference: − DEX3AD section Task

material resource by specification - Template table #70 or

− DEX1AD section Hardware part - Template table #50 or #53.

Identified via either : − Task_material_resource_by_reference (DEX

reference: DEX3AD section Task material resource by reference - Template table #86)

− Task_material_resource_by_specification and Resource_specification (DEX reference: DEX3AD section Task material resource by specification - Template table #67).

Business rule decision point - Multiple identifiers for hardware parts: If hardware parts have multiple identifiers, decide which identifier to use to populate the element <supportEquipDescr><identNo>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <identnumber> <partAndSerialNumber> <partNumber>

Part number. Part_identifier@Identifier AD DEX reference: − DEX3AD section Task

material resource by specification - Template table #70 or

− DEX1AD section Hardware part - Template table #50 or #53.

For mapping information refer to the element <preliminaryRqmts><reqSupportEquips><…> <identnumber><manufacturerCode> above.

<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <toolRef@toolNumber>

Reference a tool for projects which manage a CIR.

N/A (Reference to the CIR data module for the list of tool associated with the procedure).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <reqQuantity>

The quantity of support equipment items.

Task_material_resource_quantity AD DEX reference − DEX3AD section Task



The element <reqQuantity> can be populated in two ways depending on how Task_material_resource_quantity is defined in the data exchange: − If the Task_material_resource is assigned to the overall

Task in S3000L, then must that quantity be used (DEX reference: DEX3AD section Task material resource by specification - Template table #60, or DEX3AD section Task material resource by reference - Template table #80).

− By rolling-up if the Task_material_resource is assigned to individual subtasks (including subtasks by reference) (DEX reference: DEX3AD section Task material resource by specification - Template table #60, or DEX3AD section Task material resource by reference - Template table #80). This approch can also require the usage of Subtask_timeline (DEX reference: DEX3AD section Subtask by reference - Template table #26).

Note The attribute <reqQuantity@unitOfMeasure> must be populated with the Unit given in the Task_material_resource_quantity property representation.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr> <reqQuantity@unitOfMeasure>

Unit of measure for reqQuantity.

Task_material_resource_quantity AD DEX reference: − DEX3AD section Task



Refer to the mapping for the element <preliminaryRqmts><reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr><reqQuantity> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSupplies>

A list of any consumables (such as oils, greases, locking wire), materials (gasket sheet, sheet metal) and expendables (such as O-rings, gaskets, tab washers) required to accomplish the Procedure.

Task_material_resource

Summary of Task_material_resource's for all subtasks where Subtask_role is defined as 'Core_subtask' (including its specialization ‘Core_subtask_without_required_startup’) and Task_material_resource_category is set to 'Required_consumable_resource'. For detailed mapping of the elements defined within the element <reqSupplies>, refer to the elements <preliminaryRqmts><reqSupportEquips> above. Note

The element <reqSupplies> does not contain any occurrences of the element <toolref>.

<preliminaryRqmts> <reqSpares>

A list of any spares required to accomplish the Procedure.

Task_material_resource

Summary of Task_material_resource's for all subtasks where Subtask_role is defined as 'Core_subtask' (including its specialization ‘Core_subtask_without_required_startup’) and Task_material_resource_category is set to'Required_spare_part_resource'. For detailed mapping of the elements defined within the element <reqSpares>, refer to the elements <preliminaryRqmts><reqSupportEquips> above. Note

The element <reqSpares> does not contain any element <toolref>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSafety> <noSafety>

If there are no safety requirements, then the element <noSafety> must be used.

Derived from the absence of Warning_caution_or_note associated with either the overall Task (revision), or any of its 'Startup_subtask' subtasks. (DEX reference: DEX3AD section Task definition - Template table #22, or DEX3AD section Subtask by definition - Template table #22)

<preliminaryRqmts> <reqSafety> <safetyRqmts> <warning> <warningAndCautionPara>

Any warnings applicable to the Procedure and the Requirements after job completion in the data module must be listed here.

Warning_caution_or_note AD DEX reference: − DEX3AD section Task

definition - Template table #22 or

− DEX3AD section Subtask by definition - Template table #22

Warning_caution_or_note (where Warning_caution_or_note_type = 'Advisory_warning') associated with the Task itself or with any of its 'Startup' subtasks (Subtask_role = ‘Startup_subtask’). Note

Safety conditions that must be in place BEFORE the procedure is carried out - not the same as Warnings and Cautions in the body of the procedure.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<preliminaryRqmts> <reqSafety> <safetyRqmts> <caution> <warningAndCautionPara>

Any cautions applicable to the Procedure and the Requirements after job completion in the data module must be listed here.




Warning_caution_or_note (where Warning_caution_or_note_type = 'Advisory_caution') associated with the Task itself or with any of its 'Startup' subtasks (Subtask_role = ‘Startup_subtask’). Note

Safety conditions that must be in place BEFORE the procedure is carried out - not the same as Warnings and Cautions in the body of the procedure.

<preliminaryRqmts> <reqSafety> <safetyRqmts> <note> <notePara>

Any notes applicable to the Procedure and the Requirements after job completion in the data module must be listed here.




Warning_caution_or_note (where Warning_caution_or_note_type = 'Advisory_note') associated with the Task itself or with any of its 'Startup' subtasks (Subtask_role = ‘Startup_subtask’).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


3.3 Notes for Table 3 These notes are provided to give clarification to many of the entries in Table 3.

Note 1 S3000L has the capability to capture supporting documentation that indicates that a task/subtask or group of tasks/subtasks can be carried out in parallel. S1000D does not support this.

Note 2 The same rules apply to the element <closeRqmts><reqCondGroup>.

Note 3 The same rules apply to spares (the element <reqSpares>) and supplies (the element <reqSupplies>).

Note 4 Roll up of resources from S3000L subtasks to the S1000D element <reqCondGroup> needs to be adressed.

3.4 Main procedure Table 4 describes the elements and attributes in the S1000D <mainProcedure> section. The element <mainProcedure> is referred to as main function (the element <mainFunc>) in S1000D Issue 3.0 (and earlier).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 4 mainProcedure - Elements and attributes


S1000D Issue 4.0 Element/ Attribute definition



<mainProcedure@itemCharacteristic>

Characteristics of the item that is the subject of a given procedural step.

N/A

<mainProcedure@independentCheck>

The whole procedure must be supervised with a given qualification

Task_personnel_resource_role AD DEX reference: − DEX3AD section Task


The attribute <mainProcedure@independentCheck> is set to ‘Yes’, if there is a Task_personnel_resource classified as 'Required_work_supervisor' in every 'Core' subtask (Subtask_role = ‘Core_subtask’, including its specialization ‘Core_subtask_without_required_startup’)

<mainProcedure@skillLevelCode>

Lowest skill required for the whole procedure


The Skill_level_name for the Skill_level being associated with Task_personnel_resource where Task_personnel_resource_role is defined as ‘Required_work_performer’ or subclass thereof (DEX reference: DEX3AD section Task personnel resource - Template table #110). Identifies the lowest skill required that can perform the whole task (in practice the highest defined within the task). Rules related to the skill codes needs to be defined for the project. Business rule decision point - Definitions for skill codes: Decide on the definitions of the values for the attribute <mainProcedure@skillCode>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure@ <securityClassification>

Security and restrictive marking.

Security_class AD DEX reference: − DEX1AD section

Security classification - Template table #320 for Breakdown_element and Part, respectively or

− DEX3AD section Security classification - Template table #320 for Task, Subtask_by_definition and Task_requirement, respectively

This could be derived from either the security classification of Breakdown_element, Part, Task_requirement, Task or Subtask in S3000L. Security classification for a breakdown element/ part/software shall be propagated to the respective task being associated with the breakdown element/ part.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure> <proceduralStep>

Contains a step in the procedure.

Subtask AD DEX reference: − DEX3AD section

Subtask by reference - Template table # or

− DEX3AD section Subtask by external reference - Template table #30 or


Create one step per S3000L 'Core' subtask (Subtask_role = ‘Core_subtask’, including its specialization ‘Core_subtask_without_required_startup’, DEX reference: DEX3AD section Subtask by reference - Template table #25, or DEX3AD section Subtask by external reference - Template table #31, or DEX3AD section Subtask by definition - Template table #41).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure> <proceduralStep@independentCheck>

The whole step or individual steps/substeps must be checked by eg a supervisor with a given qualification.

Subtask_objective_state or Task_personell_resource_role


Subtask by definition - Template table #49 for Subtask_objective_state or

− DEX3AD section Task personnel resource - Template table #110 for Task_personell_resource_role

Checks can be defined as a separate Subtasks in S3000L, with Subtask_objective_state set to’Checked_activity’ and/or have a Task_personell_resource with role defined as ’Required_work_quality_assurance_resource’, Note

This includes all nested Subtask_by_reference.

<mainProcedure> <proceduralStep@skillLevelCode>

Skill level required for the whole procedure and/or for individual steps/sub-steps using the attribute skill.


The Skill_level_name for the Skill_level being associated with Task_personnel_resource. Identifies the lowest skill required that can perform the whole subtask (in practice the highest skill defined within the task). Rules related to the skill levels needs to be defined for the project. Note

This includes all nested Subtask_by_reference.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure> <proceduralStep@securityClassification>

Security and restrictive marking.

Security_class AD DEX reference: − DEX1AD section

Security classification - Template table #320 for Breakdown_element and Part, respectively or

− DEX3AD section Security classification - Template table #320 for Task, Subtask_by_definition and Task_requirement, respectively

Security classification relevant for the subtask. This could be derived from either the security classification of Breakdown_element, Part, Task_requirement, Task or Subtask in S3000L. Security classification for a breakdown element/ part/software shall be propagated to the respective task being associated with the breakdown element/ part.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure> <proceduralStep> <title>

Title of the step or a sequence of substeps.

Subtask_name/Task_name


Subtask by definition - Template table #42 for Subtask_name or

− DEX3AD section Task definition - Template table #1 or Template table #4 for Task_name

The Subtask_name if the Subtask is an instance of Subtask_by_definition (DEX reference: DEX3AD section Subtask by definition - Template table #40). The Task_name for the referenced Task if the Subtask is an instance of Subtask_by_reference (DEX reference: DEX3AD section Subtask by reference - Template table #25).

<mainProcedure> <proceduralStep> <warning> <warningAndCautionPara>

Any warnings applicable to the Procedural step.

Warning_caution_or_note AD DEX reference: − DEX3AD section


Warning_caution_or_note associated with the Subtask where Warning_caution_or_note_type = 'Advisory_warning'. Note

A warning that is placed in an element at level 1 applies to all the element at the next level.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure> <proceduralStep <caution> <warningAndCautionPara>

Any cautions applicable to the Procedural step.



Warning_caution_or_note associated with the Subtask where Warning_caution_or_note_type = 'Advisory_caution'. Note

A caution that is placed in an element at level 1 applies to all the element at the next level.

<mainProcedure> <proceduralStep <note> <notePara>

Any notes applicable to the Procedural step.



Warning_caution_or_note associated with the Subtask where Warning_caution_or_note_type = 'Advisory_note'.

<mainProcedure> <proceduralStep> <circuitBreakerDescrGroup>

Steps can also contain a circuit breaker list.

Subtask and Subtask_circuit_breaker_state

AD DEX reference: Refer to the element <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker><circuitBreakerDescrGroup>, and its subelements, above

Subtasks which has an associated instance of Subtask_circuit_breaker_state. Subtask_circuit_breaker_state identifies the specific circuit breakers by its id and its required state. Refer to the mapping details under the element <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker><circuitBreakerDescrGroup> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<mainProcedure> <proceduralStep <para>

Would capture the narrative of the subtask. Any indenturing to substeps is a function of the author.

Subtask_description



Subtask_description

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


4 S1000D Maintenance Planning Information 4.1 Introduction

The schedul Schema contains maintenance planning information. The granularity of data modules created using the schedul Schema, is determined by the application of the SNS.

This Schema has structural elements that provide for four types of maintenance planning information. These are time limits information (the element <timeLimitInfo>), task lists (the element <taskDefiniton>), inspection lists (the element <inspectionDefinition>) and maintenance allocation (the element <maintAllocation>).

4.2 S1000D schedule Schema requirements 4.2.1 Task definition

Table 5 describes the elements and attributes of the S1000D element <taskDefinition>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 5 taskDefinition - Elements and attributes





<taskDefiniton> Task information related to a system.

Task



Applies to Tasks being instances of Rectifying_task, for which the value of S1000D_task_type_code is set to 'Procedure_task' (DEX reference: DEX3AD section Task definition - Template tables #2 and #5). Notes

1. The S1000D_task_type attribute defines how a task in S3000L corresponds with the schemas defined in S1000D:

− 'Procedure_task' = S1000D proced scheme,

− 'Package_task' = S1000D schedul scheme. 2. Refer to Chap 3 - S1000D Procedure and Schedule schemas vs

S3000L for more details on the relationship between S3000L and S1000D.

<taskDefiniton@taskIdent>

Identifier for the list of tasks.

Task_identifier AD DEX reference: − DEX3AD section Task


Task_identifier Business rule decision point - Multiple identifiers for tasks: If tasks have multiple idenitifiers, decide which identifier to use to populate the attribute < taskDefiniton@taskIdent>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition@taskCode>

Type of work to be done (eg GVI, DET, VSK).

Information_code AD DEX reference: − DEX3AD section Task


Tasks attribute Information_code. Business rule decision point – map between task codes and information codes: Decide on the map between valid values for the attribute <taskDefinition@taskCode> and the Information Code.

<taskDefinition@worthinessLimit>

Indicate whether the tasks are mandatory or recommended.

N/A

Should come from S4000M. Can not be provided by S3000L.

<taskDefinition@reducedMaint>

Indicate any reduced maintenance information.

N/A S3000L does not identify the minimum tasks.

<taskDefinition@skillLevelCode>

Skill level required for the task. (Is defined by the project).


Skill_level derived from Skill_code. Business rule decision point - Definitions for skill codes: Decide on the definitions of the values for the attribute <taskDefinition@skillCode>.

<taskDefinition@skillType>

Main technical ability required of the person performing the task eg Airframe, Electrical, Avionic, Engine, etc.



Either Trade_name derived via Skill_code, or Trade_name as the Competence related directly to the Task_personnel_resource (DEX reference: DEX3AD section Task personnel resource - Template tables #110 and #118). Business rule decision point – Main technical ability: Decide on the definitions of the main technical abilities pertaining to the task for the attribute <taskDefinition@skillCode>. Also refer to the mapping for attribute <taskDefinition@skillLevelCode> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition@applicRefId>

Applicability for the whole taskDefinition level.

Applicability_statement

Note Mapping of Applicability is described at Table 2.

<taskDefinition@authorityName>

The authority that determined how these attributes should be populated (eg FAA- Federal Aviation Authority).

N/A

<taskDefinition@authorityDocument>

The document that records that determination.

N/A

<taskDefinition <task>

Any general information about the task.

Task



Note From an S3000L perspective, there is just one task per taskDefinition. This is the same instance of Task as is identified in element <taskDefinition> above.

<taskDefinition> <task> <taskTitle>

Contains a short textual description of the task.



Task_name

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <task> <taskDescr>

Contains a fuller textual description of the task.



Task_name Note

There is no more complete textual description for the task in S3000L than the Task_name.

<taskDefinition> <rqmtSource>

The origination of the requirement.

Authority_driven_task_requirement AD DEX reference: − DEX3AD section Task

requirement- Template table #211

If the Task is associated with an instance of Authority_driven_task_requirement, as the justification for the Task.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <rqmtSource@sourceOfRqmt>

Code that indicates the source of the requirement. Values of this code include MSG3, CMR and AD.

Task_requirement_authority_source_type AD DEX reference: − DEX3AD section Task

requirement- Template table #211

Task_requirement_authority_source_type is defined using reference data that corresponds to the S1000D <rqmtSource@sourceOfRqmt> allowed values:

− ‘Authoritative_source_task_requirement’ (equals <rqmtSource@sourceOfRqmt> value 'AD')

− ‘Scheduled_maintenance_program_task_requirement’ (equals <rqmtSource@sourceOfRqmt> value 'MSG3')

− ‘Certification_maintenance_task_requirement’ (equals <rqmtSource@sourceOfRqmt> value 'CMR')

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition <rqmtSource@sourceIdent>

Document number of the source of requirement or the title of the source if no number is available.

Document_identifier or Document_title


Document - Template table #346 or Template table #347 for document identifier or

− DEX3AD section Document - Template table #348 for document title

Document_identifier or Document_name from a Document being assigned to Authority_driven_task_requirement in the role of 'Directive' (DEX reference: DEX3AD section Document - Template table #346).

<taskDefinition> <rqmtSource@approval>

Level of approval of the source.

N/A

<taskDefinition> <rqmtSource> <issueInfo@issueNumber>

Issue number of the source document.



For mapping information refer to the attribute <taskDefinition><rqmtSource@sourceIdent> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <rqmtSource> <issueDate@year / @month / @day>

The date of the source to distinguish it from previous sources with the same document number.

Document_issue_date AD DEX reference: − DEX3AD section


For mapping information refer to the attribute <taskDefinition><rqmtSource@sourceIdent> above.

<taskDefinition> <rqmtSource> <sourceType@sourceCriticality>

Failure effect category. N/A

<taskDefinition> <preliminaryRqmts>

Resources that are required before the task can be performed.

From an S3000L perspective, there no way to group tasks on this level, ie there is just one task per taskDefinition, which means that the content in the element <taskDefinition> <preliminaryRqmts> equals the <preliminaryRqmts> defined for Procedural information above.

Refer to the mapping for Procedural information above.

<taskDefinition> <refs>

Refers to data modules or other publications that represent the accomplishment instructions for the task.

For mapping information refer to <mainProcedure> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <refs> <dmRef>

Details of the destination data module that is referred from some other S1000D context, such as a data module.

N/A There is no notion of data modules when S3000L data is transferred to S1000D.

<taskDefinition> <refs> <externalPubRef> <externalPubRefIdent> <externalPubCode>


Document_identifier AD DEX reference: − DEX3AD section


If there are one or more 'Core' subtasks within the Task which are instances of Subtask_by_external_reference, which in turn referes to an External_document, then create one instance of the element <externalPubRef> for each External_document being identified (DEX reference: DEX3AD section Subtask by external reference - Template table #30 and Template table #31).

<taskDefinition> <refs> <externalPubRef> <externalPubRefIdent> <externalPubTitle>


Document_title AD DEX reference: − DEX3AD section


Refer to the mapping defined for element <taskDefinition><refs><externalPubRef> <externalPubRefIdent><externalPubCode> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <refs> <externalPubRef> <externalPubRefIdent> <externalPubIssueInfo <externalPubIssue>

Contains issue information concerning a referred non S1000D document.



Refer to the mapping defined for element <taskDefinition><refs><externalPubRef> <externalPubRefIdent><externalPubCode> above.

<taskDefinition> <refs> <pmRef> <pmRefIdent> <pmCode>

Contains the items forming a unique identification of the destination data module.

Publication_module_code AD DEX reference: − DEX3AD section


If there are one or more 'Core' subtasks within the Task which are instances of Subtask_by_external_reference, which in turn referes to an S1000D_publication_module, then create one instance of the element <pmRef> for each S1000D_publication_module being identified (DEX reference: DEX3AD section Subtask by external reference - Template table #30 and Template table #31).

<taskDefinition> <refs> <pmRef> <pmRefIdent> <issueInfo@issueNumber>

Issue information needed to address a particular destination data module issue.

Publication_module_issue_number AD DEX reference: − DEX3AD section


Refer to the mapping defined for element <taskDefinition><refs><pmRef> <pmRefIdent><pmCode> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <equipGroup> <equip>

Provides a grouping of information used to describe equipment that is the subject of, used in or associated to the task.

Part

Retrieved via Task_usage for the Task (DEX reference: DEX3AD section Task assignment - Template table #140). Part information can be derived from the Task_target_item being associated with the Task_usage, if the Task_target_item either is a Part, or a Hardware_element.

If the Task_target_item is an instance of Hardware_element, then the instance(s) of Part can be derived from the respective Hardware_element_realization that is defined for the Hardware_element (DEX reference: DEX1AD section Hardware element realization - Template table #143).

<taskDefinition> <equipGroup> <equip> <name>

Nomenclature for the equipment that belongs to the system for which the list of tasks is relevant.

Part_name AD DEX reference: − DEX1AD section

Hardware part reference - Template table #34

Part_name For mapping information refer to the element <taskDefinition> <equipgroup><equip> above. Business rule decision point - Multiple names for hardware parts: If hardware parts have multiple names, decide which name to use to populate the element <equip><name>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <equipGroup> <equip> <natoStockNumber> <fullNatoStockNumber>

NATO Stock Number for the equipment that belongs to the system for which the list of tasks is relevant.

Resource_specification_identifier AD DEX reference: − DEX3AD section

Material resource by specification - Template table #67

Resource_specification_identifier classified as 'NSN_code'.

The Resource_specification_identifier identifies an Resource_specification which is defined for an NATO stock item. The Resource_specification is associated with the identified Part by a Resource_realization relationship (DEX reference: DEX3AD section Material resource by specification - Template table #67) For Part mapping information refer to the element <taskDefinition> <equipgroup><equip> above. Business rule decision point - Multiple NSNs for hardware parts: If hardware parts have multiple NSNs, decide which NSN to use to populate the element <natoStockNumber><fullNatoStockNumber>.

<taskDefinition> <equipGroup> <equip> <identNumber> <manufacturerCode>

The manufacturer's identification information for the equipment that belongs to the system for which the list of tasks is relevant.


Hardware part - Template table #50 or Template table #53

For mapping information refer to the element <taskDefinition><equipgroup><equip> above. Business rule decision point - Multiple identifiers for hardware parts: If hardware parts have multiple identifiers, decide which identifier to use to populate the element <identNumber><manufacturerCode>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <equipGroup> <equip> <identNumber> <partAndSerialNumber> <partNumber>

Contains the part number. Part_identifier@Identifier AD DEX reference: − DEX1AD section


For mapping information refer to the element <taskDefinition> <equipgroup><equip> above. Business rule decision point - Multiple identifiers for hardware parts: If hardware parts have multiple identifiers, decide which identifier to use to populate the element <partAndSerialNumber><partNumber>.

<taskDefinition> <equipGroup> <equip> <catalogSeqNumberRef@catalogSeqNumberValue>

Link to the associated parts data module for the equipment that belongs to the system for which the list of tasks is relevant.

N/A Should come from S2000M. Can not be provided by S3000L.

<taskDefinition> <name>

Used instead of the element <equip> for structural and other items that do not have part numbers.



Breakdown_element_name

Retrieved via Task_usage for the Task (DEX reference: DEX3AD section Task assignment - Template table #140).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <supervisorLevel@supervisorLevelCode>

Indicate the level of supervision that is appropriate for the task.

Skill_code or Trade_name


personnel resource - Template table #120 if skill code or

− DEX3AD section Task personnel resource - Template table #119 if trade name

Identify level of supervision either by: − Look at the attribute

<mainProcedure@independentCheck> and the attribute <proceduralStep@independentCheck> values for the included (procedural) task, and based on competence (ie trade or skill) identify the "highest" level required.

− Identify if there is any Task_personnel_resource with Task_personnel_resource_role = 'Required_work_supervisor', that is directly associated with the Task being associated with the element <taskDefinition> (DEX reference: DEX3AD section Task personnel resource - Template table #110).

Business rule decision point – Identify the level of supervision: Decide whether to source the required supervisor level from the attribute <mainProcedure@independentCheck> or from the Task_personnel_resource_role with a value of 'Required_work_supervisor'.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition <limit>

Determine when a task must be performed.

Task_limit AD DEX reference: − DEX3AD section

Discrete task limit - Template table #170 or

− DEX3AD section Periodic task limit - Template table #200

Use the Task_limit defined for the rectifying or operational task. Note

A constraint in taskDefinition is that applicability can only be defined at the taskDefinition level, and not on the limit level, whereas S3000L permits applicability at both levels.

<taskDefinition> <limit@limitTypeValue>

Valid limit type values: − "PO" = Perform once

− "OC" = On condition

− "PE" = Perform periodically

Discrete_task_limit Periodic_task_limit Repeat_task_limit AD DEX reference: − DEX3AD section

Discrete task limit - Template table #170 if Discrete_task_limit or

− DEX3AD section Periodic task limit - Template table #200 if Periodic_task_limit

Use one instance of the element <limit@limitTypeValue='PO'> per:

− Instance of Discrete_task_limit, where the threshold for the Discrete_task_limit is an instance of Parameter_threshold (DEX reference: DEX3AD section Discrete task limit - Template tables #170, #181, #183 and #184)

− Instance of Periodic_task_limit that has an instantiation of Initial_task_limit (DEX reference: DEX3AD section Periodic task limit - Template table #203)

One <limit@limitTypeValue='OC'> per:

− Instance of Discrete_task_limit, with no defined threshold, but there is a Task_limit_description (DEX reference: DEX3AD section Discrete task limit - Template tables #170 and #201)

− Instance of Discrete_task_limit, where the threshold for the Discrete_task_limit is an instance of

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






(incl. Repeat_task_limit)

Event_threshold (DEX reference: DEX3AD section Discrete task limit - Template tables #170, #185, #188 and #190)

One <limit@limitTypeValue='PE'> per:

− Instance of Repeat_task_limit being referenced from an instance of Periodic_task_limit. (also refer to the mapping for the element <limit><limitRange> below) (DEX reference: DEX3AD section Periodic task limit - Template table #204)

Note If any of the thresholds defined for Discrete_task_limit, Periodic_task_limit or Repeat_task_limit in S3000L has more than one associated instance of Threshold_definition, then these will be regarded as "whichever comes first", and will result in one instance of the element <limit> per associated instance of Threshold_definition.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit@limitCond>

Indicates the condition type of the limit, ie maritime flight, dirty conditions

Task_limit_description, LSA_failure_mode_description or Special_event_title


Discrete task limit - Template table #187 if LSA_failure_mode_description or

− DEX3AD section Discrete task limit - Template table #188 if Special_event_title

Use Task_limit_description where the Task_limit is an instance of Discrete_task_limit and there is no threshold for the Discrete_task_limit (DEX reference: DEX3AD section Discrete task limit - Template table #171). Use Failure_mode_description or Special_event_title where Task_limit is an instance of Discrete_task_limit, and the threshold for the Discrete_task_limit is an instance of LSA_failure_mode_related_threshold or Special_event_related_threshold, respectively. The text populating the condition attribute can eg be a concatenated string using Event_threshold_number_of_event_occurrences and Special_event_title or LSA_failure_mode_description, respectively (DEX reference: DEX3AD section Discrete task limit - Template table #185 and Template table #188). Note

If the attribute <limit@limitTypeValue> equals "OC", then must the <limit@limitCond> describe the condition.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <sampling>

If the task is based on sampling information.

Sampling_method_ratio AD DEX reference: − DEX3AD section



Sampling_method_ratio (DEX reference: DEX3AD section Discrete task limit - Template table #173) Note

If a Sampling_method_ratio is given, it must be defined as a value representing percentage.

Example: "20" in S1000D means "20%",

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <threshold>

If the task is based on any threshold information

Parameter_threshold AD DEX reference: − DEX3AD section

Discrete task <limit> - Template table #181 or

− DEX3AD section Periodic task limit - Template table #203 or


Parameter_threshold

<taskDefinition> <limit> <threshold@thresholdUnitOfMeasure>

Unit of measure for threshold.

Threshold_value AD DEX reference: − DEX3AD section



The unit given in the Parameter_threshold/Threshold_value/Property_representation.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <threshold@thresholdType>

Contains the value "threshold" or "interval", and it specifies the starting point of the threshold. It can be "from the beginning" of the maintenance program or from "the last time the inspection was performed."

N/A

<taskDefinition> <limit> <threshold> <thresholdValue>

Value Threshold_value AD DEX reference: − DEX3AD section



The value given in the Parameter_threshold/Threshold_value/Property_representation.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <threshold> <tolerance@toleranceLow / toleranceHigh>

Tolerances related to yhr value of the limit threshold.




If the Property_representation for Threshold_value is of type Value_with_tolerances_property, then the optional element <toleranceLow> will be populated with Lower_offset_value given in the Threshold_value, and the element <toleranceHigh> will be populated with Upper_offset_value given in the Threshold_value (DEX reference: DEX3AD section Data type Prp - Template table #607).

<taskDefinition> <limit> <inspectionType@inspectionTypeCategory>

Defines if the task belongs to a particular inspection type.



Navigate from the Task under consideration and backwards through the Subtask_by_reference to any Task that is of type 'Packaged_task'. ie S1000D_task_type='Packaged_task',(DEX references: DEX3AD section Subtask by reference - Template table #25 and DEX3AD section Task definition - Template table #5) and populate the attribute <inspectionType@inspectionTypeCategory> with Task_name. One occurrence of the element <inspectionType@inspectionTypeCategory> per usage of the Task under consideration in a Task of type 'Packaged_task'

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <trigger@releaseEvent>

If the task is based on some trigger event.

Will be populated with 'after' when: − Task_limit is an instance of Discrete_task_limit which

has resulted in an instantiation of the element <limit@limitTypeValue= 'PO'>, and where the Discrete_task_limit instance has at least one instantiation of trigger (DEX reference: DEX3AD section Discrete task limit - Template table #180 and Template table #190).

Note The particular type of <inspectionDefinition> relates to a grouping of maintenance tasks which gives the ability to express that the task refers to an inspection threshold eg monthly inspection.

<taskDefinition> <limit> <trigger> <refs>

Indicate any tasks that must be performed before the inspection.

Example: 10 flight hours after engine installation.

<taskDefinition> <limit> <trigger> <refs> <dmRef>

Details of the destination data module that is referred from some other S1000D context, such as a data module.

N/A

<taskDefinition> <limit> <trigger> <refs> <pmRef>

Details of the destination publication module that is referred from some other S1000D context, such as a data module, another publication module, etc.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <trigger> <refs> <externalPubRef>

Identification of a referenced non S10000D publication or document.

Task

Identify tasks in S3000L that triggers the performance of the S1000D task. Refer to the element <taskDefinition><limit><trigger@releaseEvent> above for more mapping details. Note

The S3000L task can be regarded as an external document.

<taskDefinition> <limit> <trigger> <refs> <externalPubRef> <externalPubRefIdent> <externalPubCode>


Task_identifier AD DEX reference: − DEX3AD section

Discrete task limit - Template table #190

Task_identifier for the Task being associated with Task_related_threshold.

<taskDefinition> <limit> <trigger> <refs> <externalPubRef> <externalPubRefIdent> <externalPubTitle>




Task_name for the Task being associated with Task_related_threshold.

Note

The Task being referenced in DEX3AD section Discrete task limit Template table #190, refers to a Task being defined in accordance with DEX3AD section Task definition Template table #1. However, the refered task does not have to be included in the same data exchange.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <trigger> <refs> <externalPubRef> <externalPubRefIdent> <externalPubIssueInfo> <externalPubIssue>

Contains, as text content, issue designation of a non S1000D document.

N/A

<taskDefinition> <limit> <trigger> <threshold> <thresholdValue>

References or threshold information.

Threshold_value or Event_threshold_number_of_event_occurrences


Discrete task limit - Template table #184 if threshold value or

− DEX3AD section Discrete task limit - Template table #182 if number of event occurrences

Threshold_value or Event_threshold_number_of_event_occurrences for the instance of Threshold_definition being associated as a trigger. It is populated if the condition described under the mapping for element <taskDefinition><limit> <trigger@releaseEvent> is fulfilled. If any of the trigger defined for Discrete_task_limit has more than one associated instance of Threshold_definition, then these will be regarded as "whichever comes first", and will result in one instance of the element <threshold> per associated instance of Threshold_definition.

Example: After two hard landings.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <trigger> <threshold@thresholdUnitOfMeasure>

Unit of measure for the threshold.

Threshold_value, LSA_failure_mode_description, Special_event_title or Task_name


Discrete task limit - Template table #184 if Threshold_vale or

− DEX3AD section Discrete task limit - Template table #185 if LSA_failure_mode or

− DEX3AD section Discrete task limit - Template table #188 if Special_event or

− DEX3AD section Task definition - Template table #190 if Task

Unit of measure defined for the Threshold_value, or the text string defined in the LSA_failure_mode_description, Special_event_title or Task_name. For mapping information refer to the element <taskDefinition><limit><trigger><threshold> <thresholdValue> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <trigger> <threshold> <tolerance@toleranceLow / toleranceHigh>

Tolerances for the threshold value.


Discrete task limit - Template table #184 if Parameter threshold

If the Property_representation for Threshold_value is of type Value_with_tolerances_property, then the optional element <toleranceLow> will be populated with Lower_offset_value given in the Threshold_value, and the element <toleranceHigh> will be populated with Upper_offset_value given in the Threshold_value (DEX reference: DEX3AD section Data type Prp - Template table #607). Note

There is no representation of tolerances for Event_thresholds in S3000L

<taskDefinition> <limit> <limitRange>

Any limit range information.

Repeat_task_limit and Subsequent_repeat_relationship


Periodic task limit - Template tables #200 and #205

If an instance of Periodic_task_limit has more than one associated instance of Repeat_task_limit (DEX reference: DEX3AD section Periodic task limit - Template table #200), then these needs to be organized using the element <limit> and the elements <limitRange>. One instance of the element <limit> per Repeat_task_limit with an associated element <limitRange>, derived from the Subsequent_repeat_relationship threshold values. The order in which the element <limit> is defined must be derived from the S3000L Subsequent_repeat_relationships (DEX reference: DEX3AD section Periodic task limit - Template table #205).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <limitRange> <limitRangeFrom>

The inspection must be performed after this range has been reached.



Repeat_task_limit threshold or the Subsequent_repeat_relationship trigger (DEX reference: DEX3AD section Periodic task limit - Template table #203). The element <limitRangeFrom> for the first instance of Repeat_task_limit (as ordered by Subsequent_repeat_relationship) is set to:

− The threshold value for the first Repeat_task_limit (DEX reference: DEX3AD section Periodic task limit - Template table #203).

The element <limitRangeFrom> for each subsequent Repeat_task_limit is set to:

− The trigger value for the respective subsequent Repeat_task_limit (DEX reference: DEX3AD section Periodic task limit - Template table #203)

<taskDefinition> <limit> <limitRange> <limitRangeFrom> <threshold@thresholdUnitOfMeasure>

Unit of measure for the limit range from threshold value.


Periodic task limit - Template table #184

The unit defined in the Property_representation of the Threshold_value. For more mapping details refer to the element <taskDefinition><limit><limitRange> <limitRangeFrom> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <limitRange> <limitRangeFrom> <threshold> <thresholdValue>

Value for the limit range from threshold.



The value defined in the Property_representation of the Threshold_value. For more mapping details refer to the element <taskDefinition><limit><limitRange> <limitRangeFrom> above.

<taskDefinition> <limit> <limitRange> <limitRangeTo>

The inspection must be performed before this range has been reached.



The element <limitRangeTo> is set to:

− The trigger for the Subsequent_repeat_relationship (DEX reference: DEX3AD section Periodic task limit - Template table #203), where the Repeat_task_limit under consideration is referred to as the preceding Repeat_task_limit.

Note The last instance of Repeat_task_limit, as ordered by the Subsequent_repeat_relationship, will have no given value, and will leave the element <limitRangeTo> empty.

<taskDefinition> <limit> <limitRange> <limitRangeTo> <threshold@thresholdUnitOfMeasure>

Unit of measure for the limit range to threshold value.



The unit defined in the Property_representation of the Threshold_value. For more mapping details refer to the element <taskDefinition><limit><limitRange> <limitRangeTo> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition> <limit> <limitRange> <limitRangeTo> <threshold> <thresholdValue>

Value for limit range to threshold.



The value defined in the Property_representation of the Threshold_value. For more mapping details refer to the element <taskDefinition><limit><limitRange> <limitRangeTo> above.

<taskDefinition> <limit> <remarks> <simplePara>

Contains text giving further information about the inspection.

Remark_text AD DEX reference: − DEX3AD section

Remark - Template table #360

Remarks being associated with the Task_limit in S3000L

<taskDefinition> <remarks> <simplePara>

Contains text giving further information about the inspection.



Remarks being associated with the Task under consideration.

<taskDefinition> <relatedTask>

Provides a relationship between two tasks.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<taskDefinition@applicRefId>

Applicability information associated with the taskDefinition.

Applicability_statement − For AD DEX reference

refer to the element <dmStatus><referencedApplicGroup> in Table 2 above

Applicability_statement associated with Task. Business rule decision point – Use of applicability: Decide how applicability will be used when associated to instances of Task_limit in S3000L. Refer to generic discussion on applicability above (Table 2) above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


4.3 Inspection definition Table 6 describes the elements and attributes in the S1000D element <inspectionDefinition>.

The <inspectionDefinition> branch of the schedule Schema contains information about inspections. Inspections are a way to group tasks that are related to the topic or intent of the inspection, eg weekly inspections, greasing inspections, post flight inspections.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 6 inspectionDefinitions - Elements and attributes





<inspectionDefinition> Information about inspections or groups of tasks.

Task



Task where the S1000D_task_type is set to 'Packaged_task'.

'Packaged_task' corresponds to scheduled maintenance packages in S3000L. S1000D_task_type attribute in S3000L also defines how the task corresponds with the schemas defined in S1000D: − 'Procedure_task' = S1000D proced scheme

− 'Package_task' = S1000D schedul scheme

The Task_target_item for a 'Package_task' must be a Breakdown_element (incl Zone_elements) that corresponds to a System/Subsystem level in S1000D.

<inspectionDefinition> <inspection@id>

Inspection identification Task_identifier AD DEX reference: − DEX3AD section Task


Task_identifier for the Task under consideration. Business rule decision point - Multiple identifiers for tasks: If tasks have multiple identifiers, decide which identifier to use to populate the attribute <inspection@id>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<inspectionDefinition> <inspection> <limit>

Provides a structure that is designed to specify the interval between inspections, or the threshold before which an inspection must be performed.

Task_limit AD DEX reference: − DEX3AD section



For mapping information refer to the element <taskDefinition><limit> in Table above. 5Note

Do not use the mapping for element <limit><inspectionType> as it is described in Table above.

5

Business rule decision point - Use of applicability: Decide how applicability will be used when associated to instances of Task_limit in S3000L.

<inspectionDefinition> <inspection> <remarks> <simplePara>

Any remarks that are considered appropriate.



If there is a Remark being associated with the Task representing the inspection task then use Remark_text (possibly concatenated with Remark_date and Remark_provided_by_organization).

<inspectionDefinition> <taskGroup>

List all the tasks that belong to the inspection or group of tasks.

Subtask_by_reference


Subtask by reference - Template table #25

The set of Subtask_by_reference being used within the Task representing the inspection (DEX reference: DEX3AD section Subtask by definition - Template table #25). All instances of Subtask, within a Task of type 'Package_task' in S3000L, must be Subtask_by_reference.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<inspectionDefinition> <taskGroup> <taskItem>

The individual task. Task AD DEX reference: − DEX3AD section

Subtask by reference - Template table #24

Task (DEX reference: DEX3AD section Subtask by definition - Template table #24) being refered to via Subtask_by_reference (DEX reference: DEX3AD section Subtask by definition - Template table #25). Note

There must be one instance of the element <taskItem> per instance of Subtask_by_reference.

<inspectionDefinition> <taskGroup> <taskItem@taskSeqNumber>

Sequential number to indicate the task position in a sequence.

Subtask_identifier AD DEX reference: − DEX3AD section


For more mapping details refer to the element <inspectionDefinition><taskGroup><taskItem> above

<inspectionDefinition> <taskGroup> <taskItem@taskName>

The task itself. Task_identifier AD DEX reference: − DEX3AD section

Subtask by definition - Template table #1 or section Task definition - Template table #3

Task_identifier for the task being referenced as a subtask for the Packaged task For more mapping details refer to the element <inspectionDefinition><taskGroup><taskItem> above. Business rule decision point - Multiple identifiers for tasks: If tasks have multiple identifiers, decide which identifier to use to populate the attribute < taskItem@taskName>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<inspectionDefinition> <taskGroup> <taskItem@skillLevelCode>

Required skill level for the task.


The Skill_level_name for the Skill_level being associated with Task_personnel_resource (for the Task being referenced via Subtask_by_reference). Identifies the lowest skill required that can perform the whole task (in practice the highest defined within the task). Rules related to the skill codes needs to be defined for the project. Refer to element <mainProcedure@skillLevelCode> under Para 3.4 'Main procedure' above.

<inspectionDefinition> <taskGroup> <taskItem@applicRefId>

Applicability at the task item level.

Applicability_statement For AD DEX reference refer to the element <dmStatus><applic> in Table 2 above

Applicability_statement being associated with Subtask_by_reference. Refer to discussion on applicability in Table element <dmStatus><applic> above.

2

Business rule decision point – Use of applicability: Decide how applicability will be used when associated with the attribute <taskItem@applicRefId>.

<inspectionDefinition> <taskGroup> <taskItem> <task> <taskTitle>

A short textual description of the task.



For more mapping details refer to the element <inspectionDefinition><taskGroup><taskItem> above

Note

The Task being referenced in DEX3AD section Subtask by reference Template table #24, refers to a Task being defined in accordance with DEX3AD section Task definition Template table #1.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<inspectionDefinition> <taskGroup> <taskItem> <task> <taskDescr>

A fuller textual description of the task.



For more mapping details refer to the element <inspectionDefinition><taskGroup><taskItem><task><taskTitle> above

<inspectionDefinition> <taskGroup> <taskItem> <refs> <dmRef>

Refer to data modules or other publications that represent the accomplishment instructions for the task.

N/A

<inspectionDefinition> <taskGroup> <taskItem> <refs> <externalPubRef> or <pmRef>

Refer to data modules or other publications that represent the accomplishment instructions for the task.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


4.4 Time limit information Table 7 describes the elements and attributes in the S1000D element <timeLimitInfo>.

Note There is no reference to any identified task (data module) from element <timeLimitInfo>, as this branch of the Schema refers only to parts and their potential life limit or storage limit.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 7 timeLimitInfo - Elements and attributes





<timeLimitInfo> Time limit, periodicities and life details information relating to a system.

Hardware_part_operational_authorized_life

The data module will contain a list of life limited parts, ie Parts in S3000L that has at least one associated instance of Hardware_part_operational_authorized_life (DEX reference: DEX1AD section Hardware part - Template table #74).

<timeLimitInfo@timeLimitIdent>

The identifier of the <time limit.

N/A

<timeLimitInfo@skillLevelCode>

Skill level required of the person who will perform the task.

N/A

<timeLimitInfo> <equipGroup> <equip>

Equipment that belongs to the system.

Part The Part having a life limit (DEX reference: DEX1AD section Hardware part - Template table #50).

<timeLimitInfo> <equipGroup> <equip> <name>

Nomenclature Part_name AD DEX reference: − DEX1AD section

Hardware part - Template table #52

Note If a the Part has multiple names, a project specific business rule, determined at the beginning of the project, is required that determines which Part_name to use.

For mapping information refer to the element <taskDefinition><equipgroup><equip> in Table above. 5

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<timeLimitInfo> <equipGroup> <equip> <catalogSeqNumberRef@catalogSeqNumberValue>

Catalogue sequence number

N/A

Should come from S2000M. Can not be provided by S3000L.

<timeLimitInfo> <equipGroup> <equip> <natoStockNumber> <fullNatoStockNumber>

The NATO Stock Number Resource_specification_identifier AD DEX reference: − DEX3AD section

Material resource by specification - Template table #67

For mapping information refer to <taskDefinition><equipgroup><equip> in Table above. 5

<timeLimitInfo> <equipGroup> <equip> <identNumber> <manufacturerCode>

The manufacturer's identification information




S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<timeLimitInfo> <equipGroup> <equip> <identNumber> <partAndSerialNumber> <partNumber>

Part_identifier@Identifier AD DEX reference: − DEX1AD section



<timeLimitInfo> <reqQuantity>

Quantity of items of equipment

N/A

<timeLimitInfo> <reqQuantity@unitOfMeasure>

Unit of measure N/A

<timeLimitInfo> <timeLimitCategory>

Can represent categories such as "safety related" or "non-safety related".

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<timeLimitInfo> <timeLimit>

Container element Hardware_part_operational_authorized_life AD DEX reference: − DEX1AD section

Hardware part – template table #74

<timeLimitInfo> <timeLimit> <limitType@limitUnitType>

Defines the type of limit, eg 'between major overhaul'.

'Hard_time' Fixed string value ‘Hard time' (= lt02 in S1000D).

<timeLimitInfo> <timeLimit> <limitType> <threshold>

Value and tolerance.

Hardware_part_operational_authorized_life AD DEX reference: − DEX1AD section


Populated with the Value given in the Property_representation for the Hardware_part_operational_authorized_life. Note

The Hardware_part_operational_authorized_life attribute can have a Lower_offset_value and an Upper_offset_value, if the Property_representation is an instance of the Value_with_tolerances_property.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<timeLimitInfo> <timeLimit> <limitType> <threshold@thresholdUnitOfMeasure>

Unit of measure for threshold value.



The attribute <threshold@thresholdUnitOfMeasure> will be populated with the unit given in the attribute Hardware_part_operational_authorized_life.

<timeLimitInfo> <timeLimit> <limitType> <threshold> <thresholdValue>



The element <thresholdValue> will be populated with value given in the Hardware_part_operational_authorized_life.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<timeLimitInfo <timeLimit> <limitType> <threshold> <tolerance@toleranceLow / toleranceHigh>

Tolerances for the threshold value.



If the Property_representation for Hardware_part_operational_authorized_life is of type Value_with_tolerances_property, then the optinonal element <toleranceLow> will be populated with Lower_offset_value given in the Hardware_part_operational_authorized_life, and the element <toleranceHigh> will be populated with Upper_offset_value given in the Hardware_part_operational_authorized_life (DEX reference: DEX3AD section Data type Prp - Template table #607).

<timeLimitInfo> <timeLimit> <limitType> <remarks>

Remarks at the limit type level.

N/A

<timeLimitInfo> <timeLimit> <remarks> <simplePara>

Remarks at the timeLimit level.

Remark_text AD DEX reference: − DEX3ADsection

Remark – Template table #360

Remark being associated with the Hardware_part_operational_authorized_life property. Remark_text can possibly be concatenated with Remark_date and Remark_provided_by_organization.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<timeLimitInfo@applicRefId>

Applicability_statement For AD DEX reference refer to the element <dmStatus><applic> in Table 2 above

Applicability_statement being associated with the instance of class Hardware_part_operational_authorized_life. Business rule decision point – Use of applicability: Decide how applicability will be used when associated with instances of Hardware_part_operational_authorized_life in S3000L. Refer to discussion on applicability in Table 2 element <dmStatus><applic> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


4.5 Maintenance allocation There are two different approaches to addressing maintenance allocation. These are:

− Display only the root node along with all its associated tasks, and all the tasks associated with its repairable descendent elements

− Display the root node and all its descendent repairable nodes (hardware elements and/or parts) along with their respective associated tasks

The mappings of S3000L, shown in Table 8 reflect the latter of the two approaches.

This mapping is based on the following specific business rule:

− There will be one instance of the element <maintAllocationGroup><componentAssy> per repairable hardware element where the hardware element has no identified part realization in S3000L.

− There will be one instance of the element <maintAllocationGroup><componentAssyGroup> per repairable hardware element where the hardware element has at least one part realization in S3000L.

Note The first instance of the element <componentAssy> within the element <maintAllocationGroup><componentAssyGroup> reflects the hardware element. The following instances of the element <componentAssy> will reflect each repairable Part that can realize the hardware element (including repairable Parts being included in parts list for the Part that can realize the hardware element) in S3000L.

Table 8 describes the between the elements of S3000L and the elements and attributes within the S1000D element <maintAllocation>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 8 maintAllocations - Elements and attributes





<maintAllocation> The maintenance allocation designates the overall authority and the responsibility for the performance of maintenance functions on the identified end item or component.

<maintAllocation> <title>

The title which describes the maintenance allocation.

N/A This title is assigned by the S1000D author. The name of the selected Product_variant and Breakdown_element can be used

<maintAllocation> <maintAllocationGroup>

Used to group functional items together.

Breakdown_element AD DEX reference: − DEX1AD section


There is one instance of the element <maintAllocationGroup> per repairable/replaceable Breakdown_element being part of the selected section of the physical breakdown of the Product (DEX reference: DEX1AD section Breakdown structure - Template table #36).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup@id>

The identifier of the maintenance allocation group.


Hardware element realization - Template table #130 or #134

Breakdown_element_identifier that identifies the respective repairable "Physical" breakdown element. Business rule decision point - Multiple identifiers for breakdown elements: If breakdown elements have multiple identifiers, decide which identifier to use to populate the attribute <maintAllocationGroup@id>.

<maintAllocation> <maintAllocationGroup@skillLevelCode>

The competency level required of the person who will perform the task.

N/A

<maintAllocation> <maintAllocationGroup> <groupNumber>

The functional item group of the end item. The functional group applies to repairable assemblies and subassemb-lies, ie spares (any repairable component required for the maintenance or repair of an end item), but not to repair parts (any consumable, non-repairable component required for the maintenance or repair of an end item).


Breakdown Aggregated Element - Template table #130 or #134

Breakdown_element_identifier for an associated Breakdown element being used in a "Functional" breakdown of the Product (DEX reference: DEX1AD section Breakdown structure - Template table #36). This can be derived from either a Breakdown_element_relationship being classified as 'functional_physical_relationship", (DEX reference: DEX1AD section Hardware element realization - Template table #134) or using the same Breakdown_element_identifier as above (<maintAllocationGroup@id>) if the breakdown element is used within both breakdown structures.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <componentAssy>

Breakdown_element Note Direct usage of the element <componentAssy> within the element <maintAllocationGroup> will only be used for breakdown elements that has no defined Part realization.

<maintAllocation> <maintAllocationGroup> <componentAssy> <name>

The name or nomenclature of the item.



Breakdown_element_name

<maintAllocation> <maintAllocationGroup> <componentAssy> <typeDesignation>

Text string used to give further information about the component assembly.

N/A This is assigned by the S1000D author.

<maintAllocation> <maintAllocationGroup> <maintQualifier>

Maintenance action qualification such as maintenance function, maintenance level estimated work time, any tools and/or test equipment and any remarks.

Task



There is one instance of the element <maintQualifier> per Rectifying_task being associated with the repairable Breakdown_element (DEX reference: DEX3AD section Task assignment - Template table #140).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <maintQualifier> <maintFunction@function>

The maintenance function to be performed on the item listed (eg inspection, test, and service).



The Task_name associated with the Task under consideration (refer to the mapping defined for element <maintAllocation> <maintAllocationGroup><maintQualifier> above). Business rule decision point - Map between information codes and maintenance functions: Decide on the map between information codes and the values for the attribute <maintFunction@function>. Business rule decision point - Multiple names for tasks: If tasks have multiple names, decide which name to use to populate the attribute <maintFunction@function>.

<maintAllocation> <maintAllocationGroup> <maintQualifier> <maintLevelGroup>

The lowest authorized maintenance level and the associated estimated work time to perform the maintenance.

-

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <maintQualifier> <maintLevelGroup> <maintLevel>

Estimated work time. Task_total_labour_time or Task_personnel_resource_labor_time


definition - Template table #14 for task total labour time or

− DEX3AD section Task personnel resource - Template table #117 for task personnel resource labor time

Task_total_labour_time, attribute of the Task under consideration. This could also be calculated by summarizing either: − All Task_personnel_resource_labour_times for all the

Task_personnel_resources being associated directly with the Task (DEX reference: DEX3AD section Task personnel resource - Template table #110).

− All Task_personnel_resource_labour_times for all the Task_personnel_resources being associated with any of the 'Core' Subtask(s) of the Task (DEX reference: DEX3AD section Task personnel resource - Template table #110 and Template table #41).

Note S1000D, Issue 4.0 uses a simple string to capture the man-hours associated with the maintenance level for the maintenance task being documented.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <maintQualifier> <maintLevelGroup> <maintLevel@maintLevelCode>

The maintenance level is specified by selecting an enumerated value for the maintenance level code this element is used to gather the information about the lowest authorized maintenance level and the associated estimated work time to perform the maintenance. The maintenance level is specified by selecting an enumerated value for the maintenance level code.

Maintenance_level_type_name AD DEX reference: − DEX3AD section Task

assignment - Template table #154

The name of the Maintenance_level_type etc being associated with the Maintenance_level_allocation for the Task and Task_usage under consideration. Required business rule. If the task doesn't have an associated maintenance level type it should transform its associated Maintenance_location, Operating_location_type or Operating_location into a maintenance level (DEX reference: DEX3AD section Task assignment - Template table #152, Template table #156, and Template table #158, respectively).

<maintAllocation> <maintAllocationGroup> <maintQualifier> <toolsRefs>

A reference to a required tool or test equipment that is contained in the tools list within the maintenance allocation data.

N/A This is assigned by S1000D author. It can be derived from Task_material_resource_by_reference or Task_material_resource_by_specification, where the resource is identified as Support_equipment. Codes could be assigned to each individual tool but S3000L does not have a data element for this.

<maintAllocation> <maintAllocationGroup> <maintQualifier> <remarksRefs>

A reference to remarks contained in the remarks list within the maintenance allocation data.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <componentAssyGroup>

Used when there is a requirement to subdivide the list into subassemblies.

Breakdown_element/Part


Hardware element realization - Template table #130 and its reference to a Hardware part realization (DEX1AD section Hardware_part - Template table #50

The element <componentAssyGroup> will be used for S3000L elements that have one or many Part realizations which are repairable.

<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <componentAssy> <name>

The name or nomenclature of the item.



Part_name The first instance of the element <componentAssyGroup><componentAssy> shall reflect the hardware element, and shall therefore follow the mapping being defined under the element <maintAllocation><maintAllocationGroup> <componentAssy><name> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <componentAssy> <typeDesignation>

Text string used to give further information about the component assembly.


<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier>

Maintenance actionqualification such as maintenance function, maintenance level estimated work time, any tools and/or test equipment and any remarks.

Task



There is one instance of the element <maintQualifier> per Rectifying_task being associated with the repairable the Part that can realize the hardware element itself (DEX reference: DEX3AD section Task assignment - Template table #140). Note

The first instance of the element <componentAssyGroup><componentAssy> shall reflect the hardware element, and shall therefore follow the mapping being defined under the element <maintAllocation><maintAllocationGroup> <maintQualifier>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier> <maintFunction@function>

The maintenance function to be performed on the item listed (eg inspection, test, and service).

Task_name



The Task_name associated with the Task under consideration (refer to the mapping defined for element <maintAllocation> <maintAllocationGroup> <componentAssyGroup><maintQualifier> above). Business rule decision point - Map between information codes and maintenance functions: Decide on the map between information codes and the value4s for the attribute <maintFunction@function>. Business rule decision point - Multiple names for tasks: If tasks have multiple names, decide which name to use to populate the attribute <maintFunction@function>.

<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier> <maintLevelGroup>

The lowest authorized maintenance level and the associated estimated work time to perform the maintenance.

-

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier> <maintLevelGroup> <maintLevel>

Estimated work time. Task_total_labour_time or Task_personnel_resource_labor_time


definition - Template table #14 for task total labour time or

− DEX3AD section Task personnel resource - Template table #117 for task personnel resource labor time

Task_total_labour_time, attribute of the Task under consideration. This could also be calculated by summarizing either: − All Task_personnel_resource_labour_times for all the

Task_personnel_resources being associated directly with the Task (DEX reference: DEX3AD section Task personnel resource - Template table #110).

− All Task_personnel_resource_labour_times for all the Task_personnel_resources being associated with any of the 'Core' Subtasks of the Task (DEX reference: DEX3AD section Task personnel resource - Template table #110 and Template table #41).

Note S1000D, Issue 4 uses a simple string to capture the man-hours associated with the maintenance level for the maintenance task being documented.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier> <maintLevelGroup> <maintLevel@maintLevelCode>

The maintenance level is specified by selecting an enumerated value for the maintenance level code and is used to gather the information about the lowest authorized maintenance level and the associated estimated work time to perform the maintenance. The maintenance level is specified by selecting an enumerated value for the maintenance level code.



The name of the Maintenance_level_type etc being associated with the Maintenance_level_allocation for the Task and Task_usage under consideration. If the task doesn't have an associated maintenance level type it should transform its associated Maintenance_location, Operating_location_type or Operating_location into a maintenance level (DEX reference: DEX3AD section Task assignment - Template table #152, Template table #156, and Template table #158, respectively).

<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier> <toolsRefs>

A reference to a required tool or test equipment that is contained in the tools list within the maintenance allocation data.

N/A

<maintAllocation> <maintAllocationGroup> <componentAssyGroup> <maintQualifier> <remarksRefs>

A reference to remarks contained in the remarks list within the maintenance allocation data.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation <maintPlanning <toolsList>

Used to list both special and common tools and test equipment required to maintain the equipment as indicated in the maintenance allocation.

S3000L does not maintain a separate tools list. All tools/test equipment are associated with the Task as resources.

<maintAllocation> <maintPlanning> <toolsList> <title

Used to capture the tools and test equipment list title.

N/A This is assigned by S1000D author.

<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup>

Used to capture data about the tool or test equipment.

N/A S3000L does not group tools or test equipment.

<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup@toolsListCode>

Used to provide an id for the purposes of crossreferencing. The element also allows for string data in the event that a particular code suchas "A", "B", or "C" is used to identify the tool in the maintenance allocation data.

N/A This is assigned by S1000D author based on all the tools and test equipment captured by the elements task_material_resource_by_reference or task_material_resource_by_specification. It could be assigned in S3000L, but element does not exist.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup> <maintLevel>

Used to capture the lowest authorized maintenancelevel.

This can be generated from the tools being used for the respective tasks.

<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup> <maintLevel@maintLevelCode>

The enumerated attribute identifying the lowest authorized maintenance level.



The lowest authorized maintenance level can be derived in two ways: − By identifying the lowest Maintenance_level_type being

associated with any Task being associated with the tool (DEX reference: DEX3AD section Task material resource -Template table #140 and Template table #150, respectively),

− By identifying the lowest Maintenance_level_type being associated with a Task within which the tool is being used as a resource (DEX reference: DEX3AD section Task material resource by reference - Template table #80, Template table #86, and Template table #70, respectively).

<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup> <name>

Used to identify the tool or test equipment. A basic name or noun should be used.



The Part_name for the 'Required_support_equipment_resource' identified by the task_material_resource_by_reference (DEX reference: DEX3AD section Task material resource by reference - Template table #80 and Template table #86, respectively). Business rule decision point - Multiple names for parts: If parts have multiple names, decide which name to use to populate the element <toolsListGroup><name>.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup> <natoStockNumber> <fullNatoStockNumber>

Provides an identifier for the equipment thatfollows the coding system determined by NATO, and Ministries or Departments of Defense.

Resource_specification_identifier AD DEX reference: − DEX3AD section Task


Resource_specification_identifier classified as ’NSN_code’for the the 'Required_support_equipment_resource’ identified by the task_material_resource_by_reference (DEX reference: DEX3AD section Task material resource by reference - Template table #86).

<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup> <toolRef>

Used to indicate the tool number.

N/A

<maintAllocation> <maintPlanning> <toolsList> <toolsListGroup> <toolRef@toolNumber>

The tool number. Resource_specification_identifier AD DEX reference: − DEX3AD section Task


Task_material_resource_by_specification attribute Resource_specification_identifier where the Task_material_resource is an instance of Task_material_resource_by_specification. Note

(Reference to the CIR data module for the list of tool associated with the procedure).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <maintPlanning> <toolsList> <remarksList>

Used to list remarks pertinent to the maintenance functions listed in maintenance allocation data. The purpose is to provide a list for referencing from maintenance allocation. When remarks are indicated in the maintenance allocation, the remarks list must be included.

S3000L does not maintain a list of remarks.

<maintAllocation> <remarksList> <title>

Used to capture the remarks list title.


<maintAllocation> <remarksList> <remarksGroup>

Used to capture remarks pertinent to themaintenance of the assemblies and subassemblies. It includes elements for remarks listcode and remarks.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<maintAllocation> <remarksGroup> <remarksCode>

Used to provide an id for the purposes of crossreferencing. The element also allows for string data in the event that a particular code suchas "A", "B", or "C" is used to identify the remark in the maintenance allocation data.

N/A This is assigned by the S1000D author. It could be derived from the remarks associated with a task or the tools/test equipment. The element does not exist in S3000L.

<maintAllocation> <remarksGroup> <remarks>

Used to capture the remarks about the data.

N/A This can be derived from remarks being associated with either the task or the tool.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


5 S1000D Applicability schemas 5.1 Introduction

Applicability, in S1000D, provides the mechanism to identify the context for which a data module or parts of a data module is valid. This context is usually associated with the physical configuration of the Product but can include other aspects such as tool availability and environmental conditions. Applicability capabilities can vary greatly, from a simple annotation placed in the content of a data module to managing the life cycle of applicability which includes product definition, applicability authoring and product instance configuration tracking.

The applicability mechanism is supported by the applicability annotation within data modules and by three specific data module types:

− the Applicability Cross-reference Table (ACT) data module − the Conditions Cross-reference Table (CCT) data module − the Products Cross-reference Table (PCT) data module

The ACT data module is used to declare product attributes that can affect the applicability of data. Product attributes are properties of the Product that will typically not change throughout the service life of a product instance (eg model or serial number).

The CCT data module is used to declare any type of condition that can affect the applicability of data. Conditions can be technical, operational, environmental or any other type of condition that can affect technical data. Technical conditions are typically tied to the configuration of the Product (eg service bulletins or modifications). The state of technical conditions can change throughout the service life of a product instance. (eg location of maintenance, availability of tools, regulatory rules, temperature, wind speed and sandy conditions).

The PCT data module is a repository for defining product instances and the specific values for product attributes and conditions for each product instance. It is a formal method of defining product instances and the configuration of each product instance. This part of the applicability model is out of scope of S3000L, and therefore not considered in the following mapping tables.

5.2 Applicability cross-reference table Table 9 describes the elements and attributes in the S1000D element <applicCrossRefTable> in the ACT Schema.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 9 applicCrossRefTable - Elements and attributes



S3000L Element name/AD DEX referenc


<applicCrossRefTable> <productAttributeList>

A list of attributes of the product. The values for product attributes will typically not change throughout the service life of product instance.

Product_variant, Product_variant_realization and Block_of_serialized_items

The elements in S3000L that can be regarded as being candidates for populating the product attributes list in S3000L are:

− Product_variant

− Product_variant_realization

− Block_of_serialized_items

<applicCrossRefTable> <productAttributeList> <productAttribute>

Is used to declare a single attribute of the Product, such as "serial number" or "model".

A fixed mapping in between the entities and attributes in S3000L and product attributes in S1000D is required. A proposed mapping is defined under attribute <applicCrossRefTable> <productAttributeList><productAttribute@id> below.

<applicCrossRefTable> <productAttributeList> <productAttribute@id>

The identifier of the element <productAttribute>.


AD DEX reference for Product_variant: − DEX3AD section

Applicability statement assertion Template table #400, and its

When mapping between Applicability_statements in S3000L, and the definition of product attributes in S1000D: − Define a product attribute with @id= 'productVariant' in the

ACT, if there is at least one instance of Applicability_evaluation_by_assertion in S3000L that refers to an instance of Product_variant (DEX reference: DEX3AD section Applicability statement assertion Template table #400, and its reference to DEX1AD section Product and Project - Template table #15).

− Define a product attribute with @id= 'productConfiguration' in the ACT, if there is at least one instance of

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






reference to DEX1AD section Product and Project - Template table #15

AD DEX reference for Product_variant_realization: − DEX3AD section

Applicability statement assertion Template table #400, and its references to DEX1AD section Product variant applicability - Template table #203

AD DEX reference for Block_of_serialized_items: − DEX3AD section

Applicability statement by assertion of serial number Template table #390, and its reference to DEX1AD section Product and Project for the Part representing the Product_variant

Applicability_evaluation_by_assertion_of_class in S3000L that refers to an instance of Product_variant_realization (DEX reference: DEX3AD section Applicability statement assertion Template table #400, and its references to DEX1AD section Product variant applicability - Template table #203).

− Define a product attribute with @id= 'endItemSerialNumberRange' in the ACT, if there is at least one instance of Applicability_evaluation_by_assertion_of_class in S3000L that refers to an instance of Product_variant which in turn refers to a Block_of_serialized_items (DEX reference: DEX3AD section Applicability statement by assertion of serial number Template table #390, and its reference to DEX1AD section Product and Project for the Part representing the Product_variant).

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<applicCrossRefTable> <productAttributeList> <productAttribute> <name>

Name of the product attribute.


Refer to the mapping for the attribute <productAttribute@id> above. Proposed names for the respective element <productAttribute><name> are:

− 'Model' for instances of Product_variant

− 'Product configuration' for instances of Product_variant_realization

− 'End item serial number' for instances of Product_variant which refers to Block_of_serialized_items

<applicCrossRefTable> <productAttributeList> <productAttribute> <displayName>

Text which can be used to help automated generation the human readable display text on an applicability annotation.


Refer to the mapping for the attribute <productAttribute@id> above. Proposed display names for the respective element <productAttribute><displayName> are:

− 'Model' for instances of Product_variant

− 'Config' for instances of Product_variant_realization

− 'SN' for instances of Product_variant which refers to Block_of_serialized_items

<applicCrossRefTable> <productAttributeList> <productAttribute> <descr>

Contains further clarification of the meaning of the product attribute.


Refer to the mapping for the attribute <productAttribute@id> above. Proposed descriptions for the respective product attribute <descr> are: − 'A model defines a specific variant of the generic product. Model is also

known as Usable On Code.’ − 'A product configuration defines a specific assembly of the model.’ − 'Serial number defines a range of end items.’

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<applicCrossRefTable> <productAttributeList> <productAttribute> <enumeration @applicPropertyValues>

Allowable values for the product attribute.

Product_variant_identifier, Product_variant_realization_identifier

AD DEX reference for Product_variant_identifier: − DEX1AD section

Product and Project - Template table #6/#8

AD DEX reference for Product_variant_realization_identifier: − DEX1AD section

Product variant applicability- Template table #201

When populating the element <enumeration>:

− For the attribute value <productAttribute@id= 'productVariant'>, populate the element <enumeration> with the identifiers for the defined instances of Product_variants in S3000L (Product_variant_identifier).

Business rule decision point - Multiple identifiers for product variants: If product variants have multiple identifiers, decide which identifier to use to populate the attribute <inspection@id>.

− For <productAttribute@id= 'productConfiguration'>, populate the element <enumeration> with the identifiers for the defined instances of Product_variant_realization in S3000L (Product_variant_realization_identifier).

− For <productAttribute@id='serialNumber'>, let the element <enumeration> be blank.

Also refer to the mapping for the attribute <productAttribute@id> above.

<applicCrossRefTable> <condCrossRefTableRef>

Reference to the CCT data module for this project.


<applicCrossRefTable> <productCrossRefTableRef>

Reference to the PCT data module for this project.


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


5.3 Condition cross-reference table Table 10 describes the elements and attributes in the S1000D element <condCrossRefTable> in the CCT Schema.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


Table 10 condCrossRefTable - Elements and attributes





<condCrossRefTable> <condTypeList>

A list of common types of conditions which will be used as a basis for defining specific conditions.

Condition_by_identifier, Condition_type, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase

AD DEX reference for Condition_by_identifier: − DEX3AD section


AD DEX reference for

The elements in S3000L that can be regarded as being candidates for populating the condition type list in S1000D are:

− Condition_by_identifier

− Condition_type

− Maintenance_level_type

− Maintenance_location

− Operating_location_type

− Operating_location

− Breakdown_element

− Part

− User

− Customer

− Contract

− Product_usage_phase

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






Condition_type: − DEX3AD section

Applicability statement assertion - Template table #406 if the condition type value is represented as a property in the DEX

− DEX3AD section Applicability statement assertion - Template table #400 if the condition type value is represented as a class value in the DEX

AD DEX reference for Maintenance_level_type: − DEX3AD section


AD DEX reference for Maintenance_location: − DEX3AD section

Applicability statement assertion and its reference to DEX3AD

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






section Task assignment - Template table #152

AD DEX reference for Operating_location_type: − DEX3AD section


AD DEX reference for Operating_location: − DEX3AD section


AD DEX reference for Breakdown_element: − DEX3AD section

Applicability statement assertion and its references to either DEX1AD section Breakdown element realization (Template

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






tables #130 and #150), or DEX1AD section Aggregated breakdown element (Template table #170)

AD DEX reference for Part: − DEX3AD section

Applicability statement assertion and its references to DEX1AD section Part - Template tables #50 and #80


AD DEX reference for User: − DEX3AD section


AD DEX reference for Customer: − DEX3AD section


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






assertion and its references to DEX1AD section Product and Project - Template table #19

AD DEX reference for Contract: − DEX3AD section




<condCrossRefTable> <condTypeList> <condType>

Is used to define a single condition type of the Product.

A fixed mapping in between the entities and attributes in S3000L and condition types in S1000D is required. The mapping for the attribute <condCrossRefTable><condTypeList><condType@id> below defines a proposed mapping.

<condCrossRefTable> <condTypeList> <condType@id>

The identifier of the element <condType>.

Condition_type_name, Condition_by_iden

The following business rule is recommended for mapping between Applicability_statements in S3000L, and the definition of condition types in S1000D:

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






tifier, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase

Condition_type_name

− Define one instance of the element <condType> per instance of defined Condition_type in S3000L and populate the attribute <condType@id> with the Condition_type_name.

Note The value that is to populate the attribute <condType@id> is exchanged in two different ways using DEX3AD. This is due to that the condition type value can be defined as either a property value or as a class value. If the condition type value is represented as a property then use the value defined in DEX3AD section Applicability statement by assertion of condition parameter - Template table #406 input parameter ‘property_class_name’ to populate the attribute <condType@id>. If the condition type value is represented as a class value then use the value defined in DEX3AD section Applicability statement by assertion of condition parameter - Template table #400 input parameter ‘para_class’ to populate the attribute <condType@id>.

Condition_by_identifier

− Define one instance of the element <condType> which identifies valid values for Condition_by_identifier applicability statements. Populate the attribute <condType@id> with ‘serviceBulletin’

Maintenance_level_type, Maintenance_location, Operating_location_type, and Operating_location

− Define one instance of the element <condType> which contains all instances of Maintenance_level_type,

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






Maintenance_location, Operating_location_type and Operating_location. Populate the attribute <condType@id> with ‘location’

Breakdown_element

− Define one instance of the element <condType> which contains all relevant instances of Breakdown_element. Populate the attribute <condType@id> with ‘positionInProduct’

Part

− Define one instance of the element <condType> which contains all relevant instances of Part. Populate the attribute <condType@id> with ‘partNumber’

User

− Define one instance of the element <condType> which contains all relevant instances of User. Populate the attribute <condType@id> with ‘userOrganization’

Customer

− Define one instance of the element <condType> which contains all relevant instances of Customer. Populate the attribute <condType@id> with ‘customerOrganization’

Contract

− Define one instance of the element <condType> which contains all relevant instances of Contract. Populate the attribute <condType@id> with ‘contract’

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






Product_usage_phase

− Define one instance of the element <condType> which contains all relevant instances of Product_usage_phase. Populate the attribute <condType@id> with ‘productUsagePhase’

<condCrossRefTable> <condTypeList> <condType> <name>

The name of the condition type.

Condition_type_name, Condition_by_identifier, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase

For mapping information refer to element <condType@id> above. Proposed names for the respective instance of the element <condType><name> are:

Condition_type_name

− The value that is to populate the element <condType><name> for the respective Condition_type must be the same value as is used to populate the attribute <condType@id>. (DEX references: DEX3AD section Applicability statement by assertion of condition parameter - Template tables #406 and #400)


− The instance of the element <condType> which defines valid values for Condition_by_identifier must populate the element <name> with the fixed string value ‘Service bulletin type’


− The instance of the element <condType> which defines all relevant instances of Maintenance_level_type, Maintenance_location, Operating_location_type and Operating_location must populate the element <name> with the fixed string value ‘Location for task performance’

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






Breakdown_element

− The instance of the element <condType> which defines all relevant instances of Breakdown_element must populate the element <name> with the fixed string value ‘Position in product (end item)’

Part

− The instance of the element <condType> which defines all relevant instances of Part must populate the element <name> with the fixed string value ‘Part numbered item’

User

− The instance of the element <condType> which defines all relevant instances of User must populate the element <name> with the fixed string value ‘User organization’

Customer

− The instance of the element <condType> which defines all relevant instances of Customer must populate the element <name> with the fixed string value ‘Customer’

Contract

− The instance of the element <condType> which defines all relevant instances of Contract must populate the element <name> with the fixed string value ‘Contract’

Product_usage_phase

− The instance of the element <condType> which defines all relevant instances of Product_usage_phase must populate the element <name> with the fixed string value ‘Product usage phase’

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condCrossRefTable> <condTypeList> <condType> <descr>

Further clarification of the meaning of the condition type,


For more mapping information refer to also<condType@id> above. Proposed descriptions for the respective instance of the element <condType><descr> are:

Condition_type_name

− The value that is to populate the element <condType><descr> for the respective Condition_type can be retrieved from the Reference Data Library (RDL). The value to use must be the description for the respectice class used to populate the attribute <condType@id>. (DEX references: DEX3AD section Applicability statement by assertion of condition parameter - Template tables #406 and #400)


− The instance of the element <condType> which defines valid values for Condition_by_identifier must populate the element <descr> with the fixed string value ‘Service bulletin type’


− The instance of the element <condType> which defines all relevant instances of Maintenance_level_type, Maintenance_location, Operating_location_type and Operating_location must populate the element <descr> with the fixed string value ‘Location for task performance’

Breakdown_element

− The instance of the element <condType> which defines all relevant instances of Breakdown_element must populate the element

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<descr> with the fixed string value ‘Position in product (end item)’

Part

− The instance of the element <condType> which defines all relevant instances of Part must populate the element <descr> with the fixed string value ‘Part numbered item’

User

− The instance of the element <condType> which defines all relevant instances of User must populate the element <descr> with the fixed string value ‘User organization’

Customer

− The instance of the element <condType> which defines all relevant instances of Customer must populate the element <descr> with the fixed string value ‘Customer’

Contract

− The instance of the element <condType> which defines all relevant instances of Contract must populate the element <descr> with the fixed string value ‘Contract’

Product_usage_phase

− The instance of the element <condType> which defines all relevant instances of Product_usage_phase must populate the element <descr> with the fixed string value ‘Product usage phase’

<condCrossRefTable> <condTypeList> <condType>

Allowable values for the condition type.

Condition_type_class_value, Condition_type_pr

For more mapping information refer to <condType@id> above. Proposed allowable values for the respective instance of the attribute <condType> <enumeration@applicPropertyValues>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<enumeration @applicPropertyValues>

operty_value, Condition_by_identifier, Maintenance_level_type_name, Maintenance_location_name, Operating_location_type_name, Operating_location_name, Breakdown_element_identifier, Part_identifier, Organization_name (User and Customer), Contract_identifier and Product_usage_phase

are: Condition_type_class_value and Condition_type_property_value

− The values that are to populate the attribute <condType><enumeration@applicPropertyValues> for the respective instance of Condition_type, can be retrived from the defined property and class values which are referenced by the respective Condition_type (DEX references: DEX3AD section Applicability statement by assertion of condition parameter - Template tables #405 for Condition_type_class_value, and and Template table #406 Condition_type_property_value).

Note Property values should concatenate both the value itself and its unit, eg ’16-30 Miles_per_hour’ which can be a defined value range for a Wind speed property.


− The instance of the element <condType> which defines valid values for Condition_by_identifier must populate the attribute <enumeration@applicPropertyValues> with the values that are referenced by Condition_by_identifier (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter - Template tables #409)

Note Proposed values in Template table #409 are ‘Pre_activity_state’ and ‘Post_activity_state’, which would result in the value <enumeration

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






applicPropertyValues=”Pre_activity_state”|”‘Post_activity_state”> of the attribute <enumeration@applicPropertyValues>

Maintenance_level_type_name, Maintenance_location_name, Operating_location_type_name, and Operating_location_name

− The instance of the element <condType> which defines instances of Maintenance_level_type, Maintenance_location, Operating_location_type and Operating_location must populate the attribute <enumeration@applicPropertyValues> with the names, or codes, that identifies the organization, or type of organization, which are referenced by any applicability statement (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter Template table #400, and its reference to DEX3AD section Task assignment - Template tables #152, #154, #156 and #158).

Breakdown_element_identifier

− The instance of the element <condType> which defines instances of Breakdown_element, must populate the attribute <enumeration@applicPropertyValues> with the Breakdown_element_identifiers which are referenced by any applicability statement (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter Template table #400, and its reference to either:

o DEX1AD section Hardware element realization - Template table #130 for

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






hardware elements o DEX1AD

section Breakdown aggregated element - Template table #170 for aggregated elements

o DEX1AD section Breakdown zone element- Template table #183 for zone elements

Part_identifier

− The instance of the element <condType> which defines instances of Part, must populate the attribute <enumeration@applicPropertyValues> with the Part_identifiers which are referenced by any applicability statement (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter Template table #400, and its reference to either:

o DEX1AD section Hardware part- Template table #50 for hardware parts

o DEX1AD section Software part - Template table #80 for software parts

Organization_name (User)

− The instance of the element <condType> which defines instances of User must populate the attribute <enumeration@applicPropertyValues> with the names that identifies the user organizations which are referenced by any applicability statement (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter Template table #400, and its reference to DEX1AD section Product and Project - Template table

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






#22) Organization_name (Customer)

− The instance of the element <condType> which defines instances of Customer must populate the attribute <enumeration@applicPropertyValues> with the names that identifies the customer organizations which are referenced by any applicability statement (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter Template table #400, and its reference to DEX1AD section Product and Project - Template table #19)

Contract_identifier

− The instance of the element <condType> which defines instances of Contract must populate the attribute <enumeration@applicPropertyValues> with the Contract_identifiers which are referenced by any applicability statement (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter Template table #400, and its reference to DEX1AD section Product and Project - Template table #15)

Product_usage_phase

− The instance of the element <condType> which defines instances of Product_usage_phase must populate the attribute <enumeration@applicPropertyValues> with the values that are used to define Product_usage_phase (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter - Template tables #410)

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condCrossRefTable> <condList>

A list of specific conditions which have an effect on the applicability of technical data.


For more mapping information refer to also<condType@id> above.

<condCrossRefTable> <condList> <cond>

Identification of the generic type of condition that the specific condition is based on

Condition_type_name, Condition_by_identifier, Maintenance_level_type, Maintenance_locat

For mapping between Applicability_statements in S3000L, and the definition of conditions in S1000D: Condition_type_name

− Define one instance of the element <condList><cond> per instance of defined Condition_type in S3000L (refer to the mapping defined for attribute <condTypeList><condType@id> above.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






ion, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase

Note There will be a one to one relationship between the elements defined for Condition_types under the element <condTypeList><condType> above, and the elements defined for Condition_types defined in the element <condList><cond>


− Define one instance of the element <condList><cond> per instance of Condition_by_identifier


− Define one instance of the element <condType> for Maintenance_level_type, Maintenance_location, Operating_location_type and Operating_location.

Note There will be a one to one relationship between the elements defined for Maintenance_level_type, Maintenance_location, Operating_location_type and Operating_location, under the element <condTypeList><condType> above, and the elements defined for Maintenance_level_type, Maintenance_location, Operating_location_type and Operating_location defined in the element

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condList><cond>

Breakdown_element

− Define one instance of the element <condType> for Breakdown_element.

Note There will be a one to one relationship between the elements defined for Breakdown_element under the element <condTypeList><condType> above, and the elements defined for Breakdown_element defined in the element <condList><cond>

Part

− Define one instance of the element <condType> for Part. Note

There will be a one to one relationship between the elements defined for Part under the element <condTypeList><condType> above, and the elements defined for Part defined in the element <condList><cond>

User

− Define one instance of the element <condType> for User. Note

There will be a one to one relationship between the elements defined for User under the element <condTypeList><condType> above, and the elements defined for User defined in the element <condList><cond>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






Customer

− Define one instance of the element <condType> for Customer. Note

There will be a one to one relationship between the elements defined for Customer under the element <condTypeList><condType> above, and the elements defined for Customer defined in the element <condList><cond>

Contract

− Define one instance of the element <condType> for Contract. Note

There will be a one to one relationship between the elements defined for Contract under the element <condTypeList><condType> above, and the elements defined for Contract defined in the element <condList><cond>

Product_usage_phase

− Define one instance of the element <condType> for Product_usage_phase.

Note There will be a one to one relationship between the elements defined for Product_usage_phase under the element <condTypeList><condType> above, and the elements defined for Product_usage_phase defined in the element

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condList><cond>

<condCrossRefTable> <condList> <cond@condTypeRefId>

Identification of the generic type of condition that the specific condition is based on


For mapping refer to the element <condList><cond> above. Values are to be populated according to the values defined for the attribute<condTypeList><condType@id> above. Note

There must be one instance of the element <condList><cond> per instance of Condition_by_identifier, which refers back to the attribute <condTypeList><condType@id> defined for Condition_identifier

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condCrossRefTable> <condList> <cond@id>

Condition_type_name, Condition_identifier, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase

For mapping refer to the element <condList><cond> above. Note

Values are to be populated according to the mapping defined in the attribute <condTypeList><condType@id> above except for instances of Condition_by_identifier.

Instances of the element <condList><cond> which defines instances Condition_by_identifier must populate the attribute <cond@id> with the respective Condition_identifier (DEX reference: DEX3AD section Applicability statement by assertion of condition parameter - Template tables #408)

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condCrossRefTable> <condList> <cond> <name>

Name of the condition. Condition_type_name, Condition_name, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase


Values are to populated according to the mapping defined for element <condTypeList><condType><name> above except for instances of Condition_by_identifier.

Instances of the element <condList><cond> which defines instances of Condition_by_identifier must populate the element <name> with the respective Condition_name). Note

Condition_name is not included in the current version of DEX3AD.

<condCrossRefTable> <condList> <cond> <displayName>

Text which can be used to help automated generation of human readable display text on an applicability annotation.

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5






<condCrossRefTable> <condList> <cond> <descr>

Further clarification of the meaning of the condition.

Condition_type_name, Condition_description, Maintenance_level_type, Maintenance_location, Operating_location_type, Operating_location, Breakdown_element, Part, User, Customer, Contract and Product_usage_phase


Values are to be populated according to the mapping defined for element <condTypeList><condType><descr> above except for instances of Condition_by_identifier.

Instances of the element <condList><cond> which defines instances of Condition_by_identifier must populate the element <descr> with the respective Condition_description). Note

Condition_description is not included in the current version of DEX3AD.

<condCrossRefTable> <condList><cond><refs>

Reference additional material with the condition.

N/A

<condCrossRefTable> <incorporation>

The incorporation status of technical conditions in the documentation

N/A

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 5


6 Common information repository The possible population of data modules following the CIR Schema will be investigated in a future issue of S1003X.

End of data module

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Chapter 6

S3000L data required to populate S1000D data modules

Table of contents Page 1 S3000L data required to populate S1000D data modules .............................................. 3 1.1 Summary of data from S3000L required by S1000D ...................................................... 3 1.2 Business rules ................................................................................................................. 4 2 Units of functionality ........................................................................................................ 4 2.1 S3000L UoF Project ........................................................................................................ 4 2.1.1 Contract ........................................................................................................................... 5 2.1.2 Customer ......................................................................................................................... 6 2.1.3 User ................................................................................................................................. 6 2.1.4 Product_variant................................................................................................................ 7 2.1.5 Block_of_serialized_items ............................................................................................... 8 2.2 UoF Product Usage ......................................................................................................... 9 2.2.1 Maintenance_level_type .................................................................................................. 9 2.2.2 Maintenance_location .................................................................................................... 10 2.2.3 Operating_location ........................................................................................................ 11 2.2.4 Operating_location_type ................................................................................................ 11 2.3 UoF Breakdown Structure ............................................................................................. 12 2.3.1 Breakdown ..................................................................................................................... 13 2.3.2 Breakdown_element_usage_in_breakdown ................................................................. 13 2.3.3 Breakdown_element ...................................................................................................... 14 2.3.4 Breakdown_element_relationship ................................................................................. 15 2.4 UoF Part ........................................................................................................................ 15 2.4.1 Hardware_part ............................................................................................................... 17 2.4.2 Hardware_part_operational_authorized_life ................................................................. 18 2.4.3 Software_part ................................................................................................................ 18 2.5 UoF Breakdown Element Realization ............................................................................ 20 2.5.1 Hardware_element (see section on UoF Breakdown Structure) ................................... 21 2.5.2 Hardware_element_revision .......................................................................................... 22 2.5.3 Hardware_element_realization ...................................................................................... 22 2.5.4 Software_element_realization ....................................................................................... 22 2.6 UoF Breakdown Zone Element ..................................................................................... 22 2.6.1 Zone_element ................................................................................................................ 23 2.6.2 Hardware_element_in_zone_relationship ..................................................................... 24 2.7 UoF Product Variant Applicability .................................................................................. 24 2.7.1 Product_variant_applicability ......................................................................................... 24 2.7.2 Product_variant_realization_applicability ...................................................................... 24 2.7.3 Product_variant_realization ........................................................................................... 25 2.8 UoF LSA-FMEA and Special Events ............................................................................. 26 2.8.1 Special_event ................................................................................................................ 28 2.8.2 LSA_failure_mode ......................................................................................................... 28 2.8.3 Product_usage_phase ................................................................................................... 28 2.9 UoF LSA Candidate Task Requirement ........................................................................ 29 2.9.1 Authority_driven_task_requirement ............................................................................... 30 2.10 UoF Task ....................................................................................................................... 30 2.10.1 Task ............................................................................................................................... 33 2.10.2 Task_change ................................................................................................................. 34 2.10.3 Warning_caution_or_note ............................................................................................. 34 2.10.4 Subtask .......................................................................................................................... 35 2.10.5 Subtask_timeline ........................................................................................................... 36

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.10.6 Subtask_by_definition ................................................................................................... 36 2.10.7 Subtask_in_zone ........................................................................................................... 37 2.10.8 Subtask_target_item ...................................................................................................... 37 2.10.9 Subtask_objective_state ................................................................................................ 37 2.10.10 Subtask_circuit_breaker_state ...................................................................................... 38 2.10.11 Circuit_breaker .............................................................................................................. 38 2.11 UoF Task Resources ..................................................................................................... 40 2.11.1 Task_material_resource ................................................................................................ 42 2.11.2 Resource_specification ................................................................................................. 42 2.11.3 Task_personnel_resource ............................................................................................. 43 2.11.4 Trade ............................................................................................................................. 43 2.11.5 Skill ................................................................................................................................ 44 2.11.6 Skill_level ....................................................................................................................... 44 2.12 UoF Task Usage (Part 1) ............................................................................................... 45 2.12.1 Planned_task_usage ..................................................................................................... 47 2.12.2 Sampling_by_ratio ......................................................................................................... 47 2.12.3 Task_limit ....................................................................................................................... 47 2.12.4 Discrete_task_limit......................................................................................................... 47 2.12.5 Periodic_task_limit ......................................................................................................... 47 2.12.6 Initial_task_limit ............................................................................................................. 47 2.12.7 Repeat_task_limit .......................................................................................................... 47 2.12.8 Subsequent_repeat_relationship ................................................................................... 48 2.12.9 Parameter_threshold ..................................................................................................... 48 2.12.10 Event_threshold ............................................................................................................. 49 2.12.11 Task_related_threshold ................................................................................................. 50 2.13 UoF Security Classification ............................................................................................ 50 2.13.1 Security_class ................................................................................................................ 51 2.14 UoF Document ............................................................................................................... 51 2.14.1 S1000D_pulication_module ........................................................................................... 54 2.14.2 External_document ........................................................................................................ 54 2.14.3 Document_assignment .................................................................................................. 55 2.15 UoF Remark .................................................................................................................. 55 2.15.1 Remark .......................................................................................................................... 56 2.16 UoF Applicability Statement .......................................................................................... 57 2.16.1 Applicability_statement .................................................................................................. 59 2.16.2 Logical_operator subclasses AND and OR, respectively .............................................. 59 2.16.3 Condition_by_identifier .................................................................................................. 59 2.16.4 Condition_type ............................................................................................................... 60 2.16.5 Condition_type_class_value .......................................................................................... 60 2.16.6 Condition_type_property_value ..................................................................................... 60


List of figures 1 S3000L UoF Project ........................................................................................................ 52 S3000L UoF Product Usage ............................................................................................ 93 S3000L UoF Breakdown Structure ................................................................................ 134 S3000L UoF Part ........................................................................................................... 165 S3000L UoF Breakdown Element Realization .............................................................. 216 S3000L UoF Breakdown Zone Element ........................................................................ 23

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


7 S3000L UoF Product Variant Applicability .................................................................... 258 S3000L UoF LSA-FMEA and Special Events ............................................................... 279 S3000L UoF LSA Candidate Task Requirement ........................................................... 3010 S3000L UoF Task .......................................................................................................... 3211 S3000L UoF Task Resources ....................................................................................... 4112 S3000L UoF Task Usage (Part 1) ................................................................................. 4613 S3000L UoF Security Classification .............................................................................. 5114 S3000L UoF Document ................................................................................................. 5315 S3000L UoF Remark ..................................................................................................... 5616 S3000L UoF Applicability Statement ............................................................................. 58

References

Table 1 References




S2000M International specification for material management


1 S3000L data required to populate S1000D data modules 1.1 Summary of data from S3000L required by S1000D

This chapter summarizes data elements in S3000Lwhich can be used to populate the elements in the S1000D maintenance procedure, maintenance planning information, applicability cross-reference table and conditions cross-reference table, data modules. This summary is defined from an S3000L perspective, and ordered by the S3000L unit of functionalities.

Note − S1000D maintenance procedure Schema is referred to as PROCED in the defined

usages for the respective S3000L class and attribute below − S1000D maintenance planning information Schema is referred to as SCHEDUL in the

defined usages for the respective S3000L class and attribute below − S1000D applicability cross-reference table is referred to as APPLICCROSSREFTABLE

in the defined usages for the respective S3000L class and attribute below − S1000D conditions cross-reference table is referred to as CONDCROSSREFTABLE in

the defined usages for the respective S3000L class and attribute below

Each S3000L Unit of Functionality (UoF) contains a short description of the UoF and the data model as defined in S3000L. Classes and attributes which can be used to populate (or derive a value which can populate) at least one element in any of the S1000D schemas within scope for S1003X are highlighted with blue boxes and lines, respectively. However, other classes and attributes may also be of interest, eg for navigational purposes.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


1.2 Business rules Business rules required for a seamless integration between S3000L and S1000D are discussed per S3000L UoF. These business rules also serve as the rules for tailoring the DEX1AD and DEX3AD.

2 Units of functionality 2.1 S3000L UoF Project

The first data elements defined during Logistics Support Analysis (LSA) are those required for defining the project (often referred to as the LSA program) and the product in focus (often referred to as the end item).

A project can be related to one or many contracts, where contracts can be organized into a chain of associated contracts, eg subcontracts.

Each contract is associated with at least one customer and one contractor. Each contract includes one or many contracted product variants, where a contracted product variant relates to a specific variant of a generic product.

A contracted product variant may also include information on the quantity of contracted product variant and/or the serial number range, as known by the customer.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN-B6865-S1003X0019-002-01

Fig 1 S3000L UoF Project

Data elements required by the S1000D procedural, maintenance planning and/or applicability schemas are:

2.1.1 Contract Contract can be used to derive:

− Any instance of the attribute <applic><assert@applicPropertyIdent> in the PROCED and SCHEDUL schemas, including the identification and status section

− Any instance of the attribute <applic><assert@applicPropertyType> in the PROCED and SCHEDUL schemas, including the identification and status section

− CONDCROSSREFTABLE <condCrossRefTable><condTypeList><condType@id>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− CONDCROSSREFTABLE <condCrossRefTable><condTypeList> <condType><name>

− CONDCROSSREFTABLE <condCrossRefTable><condTypeList> <condType><descr>

− CONDCROSSREFTABLE <condCrossRefTable><condList> <cond@condTypeRefId>

− CONDCROSSREFTABLE <condCrossRefTable><condList><cond@id> − CONDCROSSREFTABLE <condCrossRefTable><condList><cond><name> − CONDCROSSREFTABLE

<condCrossRefTable><condList><cond><descr>

Contract_identifier can be used to populate:

− Any instance of the attribute <applic><assert@applicPropertyValues> in the PROCED and SCHEDUL schemas, including the identification and status section

− CONDCROSSREFTABLE <condCrossRefTable><condTypeList><condType> <enumeration@applicPropertyValues>

2.1.2 Customer Customer can be used to derive:



− CONDCROSSREFTABLE <condCrossRefTable><condTypeList><cond@id>






Organization_name (inherited from Organization) can be used to populate:



2.1.3 User User can be used to derive:

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6










Organization_name (inherited from Organization) can be used to populate:



2.1.4 Product_variant Product_variant can be used to derive:



− APPLICCROSSREFTABLE <applicCrossRefTable><productAttributeList> <productAttribute@id>

− APPLICCROSSREFTABLE <applicCrossRefTable><productAttributeList> <productAttribute><name>

− APPLICCROSSREFTABLE <applicCrossRefTable><productAttributeList> <productAttribute><displayName>

Product_variant_identifier can be used to populate:

− <dmIdent><dmCode@modelIdentCode> − Any instance of the attribute <applic><assert@applicPropertyValues> in

the PROCED and SCHEDUL schemas, including the identification and status section − APPLICCROSSREFTABLE

<applicCrossRefTable><productAttributeList> <productAttribute><enumeration@applicPropertyValues>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.1.5 Block_of_serialized_items Block_of_serialized_items can be used to derive:





− APPLICCROSSREFTABLE <applicCrossRefTable><productAttributeList> <productAttribute><enumeration@applicPropertyValues>

Serial_number_lower_bound (Block_of_serialized_items) can be used to populate:


Serial_number_upper_bound (Block_of_serialized_items) can be used to populate:


Use of Product variant identification (Product_variant_identifier) must include 'Model_identification_code'.

Business rule decision point - Choice of organization identifier:

− Determine which Organization_identifier to use for populating the corresponding S1000D elements if organizations have multiple Organization_identifiers and Organization_names.

Business rule decision point - Use of Products within Products:

− Decide how to use of Products within Products, and how to apply model identification codes for Products within Products.

Business rule decision point - Strategy for defining system difference:

− Define a strategy for defining system difference (use of Product_variant_applicability, Breakdown_element_identifiers or Breakdown_element_relationships).

Business rule decision point - Use of block serialized items:

− Decide how to use of Block_of_serialized_items at different product levels for nested products.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.2 UoF Product Usage The UoF Product Usage defines the conditions under which the contracted product variant is to be operated and maintained. This includes, for example, maintenance levels and operating locations.

ICN-B6865-S1003X0020-002-01

Fig 2 S3000L UoF Product Usage

Data elements required by the S1000D procedural, maintenance planning and/or applicability Schemas are:

2.2.1 Maintenance_level_type Maintenance_level_type can be used to derive:





S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6






Maintenance_level_type_name can be used to populate:


− SCHEDUL <maintAllocation><maintAllocationGroup><maintQualifier> <maintLevelGroup><maintLevel@maintLevelCode>

− SCHEDUL <maintAllocation><maintAllocationGroup> <componentAssyGroup> <maintQualifier><maintLevelGroup> <maintLevel@maintLevelCode>

− SCHEDUL <maintAllocation><maintPlanning><toolsList> <toolsListGroup> <maintLevel@maintLevelCode>


2.2.2 Maintenance_location Maintenance_location can be used to derive:









Maintenance_location_name can be used to populate:


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6



2.2.3 Operating_location Operating_location can be used to derive:









Operating_location_type_name can be used to populate:



2.2.4 Operating_location_type Operating_location_type can be used to derive:









S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Operating_location_name can be used to populate:



Business rule decision point - Use of maintenance level types:

− Decide on the use of maintenance level types, maintenance locations, operating location types and operating locations.

2.3 UoF Breakdown Structure The UoF Breakdown Structure can be used to define one or many types of breakdowns for a specific Product. A breakdown can be eg functional, physical, system, zonal, or hybrid ie being a mixture of these.

Each breakdown can have one or many breakdown revisions (design iterations), where each breakdown revision references the breakdown element revisions that are included in the specific revision of the breakdown. These references are done using the Breakdown_element_usage_in_breakdown class. These references to the breakdown element (revisions) are then organized hierarchically using the Breakdown_element_structure class.

Using this construct, a defined breakdown element (revision) can be part of many breakdowns and revisions thereof. A breakdown element (revision) can then be positioned differently in the respective breakdown and revision thereof. Eg one and the same breakdown element (revision) can be used in both a functional and physical breakdown.

However, each instance of Breakdown_element_usage_in_breakdown and Breakdown_element_structure are unique for a specific breakdown revision, and can therefore only be used once.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN-B6865-S1003X0021-002-01

Fig 3 S3000L UoF Breakdown Structure


2.3.1 Breakdown Breakdown_type can be used to derive:

− <dmStatus><systemBreakdownCode> in the identification and status section − <dmStatus><functionalItemRef> in the identification and status section − SCHEDUL <maintAllocation><maintAllocationGroup> − SCHEDUL

<maintAllocation><maintAllocationGroup><groupNumber>

2.3.2 Breakdown_element_usage_in_breakdown Breakdown_element_usage_in_breakdown is used with the Breakdown_element_structure and can be used to derive:

− <dmStatus><systemBreakdownCode> in the identification and status section

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.3.3 Breakdown_element Breakdown_element (Hardware_element/Software_element/ Aggregated_element/Zone_element)can be used to derive:



− SCHEDUL <taskDefinition><equipGroup><equp> − SCHEDUL <maintAllocation><maintAllocationGroup> − CONDCROSSREFTABLE

<condCrossRefTable><condTypeList><cond@id> − CONDCROSSREFTABLE <condCrossRefTable><condTypeList>

<condType><name> − CONDCROSSREFTABLE <condCrossRefTable><condTypeList>

<condType><descr> − CONDCROSSREFTABLE <condCrossRefTable><condList>

<cond@condTypeRefId> − CONDCROSSREFTABLE <condCrossRefTable><condList><cond@id> − CONDCROSSREFTABLE <condCrossRefTable><condList><cond><name> − CONDCROSSREFTABLE


Breakdown_element_identifier can be used to either derive or populate:

− <dmIdent><dmCode@systemDiffCode> in the identification and status section − <dmIdent><dmCode@systemCode> in the identification and status section − <dmIdent><dmCode@subSystemCode> in the identification and status section − <dmIdent><dmCode@subSubSystemCode> in the identification and status

section − <dmIdent><dmCode@assyCode> in the identification and status section − <dmIdent><dmCode@disassyCode> in the identification and status section − <dmIdent><dmCode@disassyCodeVariant> in the identification and status

section − <dmStatus><systemBreakdownCode> in the identification and status section − <dmStatus><functionalItemRef@functionalItemNumber> in the

identification and status section − Any instance of the attribute <applic><assert@applicPropertyValues> in

the PROCED and SCHEDUL schemas, including the identification and status section − PROCED <preliminaryRqmts><productionMaintData>

<accessPointRef@ accessPointNumber> − SCHEDUL <maintAllocation><maintAllocationGroup@id> − SCHEDUL

<maintAllocation><maintAllocationGroup><groupNumber> − CONDCROSSREFTABLE

<condCrossRefTable><condTypeList><condType> <enumeration@applicPropertyValues>

Breakdown_element_name can be used to either derive or populate:

− <dmTitle><techName> in the identification and status section

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− <functionalItemRef><name> in the identification and status section − PROCED <preliminaryRqmts><productionMaintData>

<accessPointRef><name> − SCHEDUL <taskDefinition><name> − SCHEDUL <maintAllocation><maintAllocationGroup>

<componentAssy><name>

2.3.4 Breakdown_element_relationship Breakdown_element_relationship_type can be used to derive:

− <dmIdent><dmCode@systemDiffCode> in the identification and status section − <dmIdent><dmCode@systemCode> in the identification and status section − <dmIdent><dmCode@subSystemCode> in the identification and status section − <dmIdent><dmCode@subSubSystemCode> in the identification and status

section − <dmIdent><dmCode@assyCode> in the identification and status section − <dmStatus><systemBreakdownCode> in the identification and status section − PROCED

<preliminaryRqmts><productionMaintData><accessPointRef> − SCHEDUL

<maintAllocation><maintAllocationGroup><groupNumber>

Business rule decision point - Strategy for the product breakdown:

− Define the strategy for the product breakdown and identification of its breakdown elements and possible realizations thereof, ie parts. This is required in order to populate (or derive) the values of the elements <dmCode>, <systemBreakdownCode>, and <functionalItemRef>, as well as the different types of breakdown element names using the elements <techName> and <functionalItemRef><name>. This also includes the use of the S3000L attribute Breakdown_type.

Business rule decision point - Strategy for relating multiple Breakdowns:

− Define the strategy for relating multiple Breakdowns (if required), eg relating a functional Breakdown with a physical Breakdown, a design Breakdown with an S1000D Breakdown.

Business rule decision point - Defining access panels:

− Define the strategy for defining access panels.

Business rule decision point - Choice of identifier name:

− Determine which identifier and name, respectively, to use for populating the corresponding S1000D elements if breakdown elements have multiple Breakdown_element_identifiers and Breakdown_element_names.

2.4 UoF Part The UoF Part is used to represent hardware items as well as software.

Part is an abstract class, ie an instance of a Part needs to be either a Hardware_part or a Software_part.

Parts can be used to realize breakdown elements in a breakdown of a product, as well as play the role of a resource in one or many tasks.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Parts can be organized into Bill-of-Materials (BOM), ie parts can consist of other parts.

Materials (often hazardous) are defined separately, and are then associated with the Parts in which it is being used.

ICN-B6865-S1003X0022-002-01

Fig 4 S3000L UoF Part


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.4.1 Hardware_part Hardware_part can be used to derive:

− Any instance of the attribute <applic><assert@applicPropertyIdent in the PROCED and SCHEDUL schemas, including the identification and status section








Part_identifier (inherited from Part) can be used to either derive or populate:

− <dmIdent><dmCode@systemCode> in the identification and status section − <dmIdent><dmCode@subSystemCode> in the identification and status section − <dmIdent><dmCode@subSubSystemCode> in the identification and status


section − <dmStatus><functionalItemRef@manufacturerCodeValue> in the


the PROCED and SCHEDUL schemas, including the identification and status section − PROCED <preliminaryRqmts><reqSupportEquips>

<supportEquipDescrGroup> <supportEquipDescr><identNumber><manufacturerCode>

− PROCED <preliminaryRqmts><reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr><identNumber> <partAndSerialNumber><partNumber>

− PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup> <supplyDescr><identNumber><manufacturerCode>

− PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup> <supplyDescr><identNumber> <partAndSerialNumber><partNumber>

− PROCED <preliminaryRqmts><reqSpares><spareDescrGroup> <spareDescr><identNumber><manufacturerCode>

− PROCED <preliminaryRqmts><reqSpares><spareDescrGroup> <spareDescr><identNumber><partAndSerialNumber><partNumber>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <taskDefinition><equipGroup><equip><identNumber> <manufacturerCode>

− SCHEDUL <taskDefinition><equipGroup><equip><identNumber> <partAndSerialNumber><partNumber>

− SCEHDUL <timeLimitInfo><equipGroup><equip><identNumber> <manufacturerCode>

− SCEHDUL <timeLimitInfo><equipGroup><equip><identNumber> <partAndSerialNumber><partNumber>


Part_name (inherited from Part) can be used to populate:

− <dmTitle><techName> in the identification and status section − PROCED <preliminaryRqmts><reqSupportEquips>

<supportEquipDescrGroup> <supportEquipDescr><name> − PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup>

<supplyDescr><name> − PROCED <preliminaryRqmts><reqSpares><spareDescrGroup>

<spareDescr><name> − SCHEDUL <taskDefinition><equipGroup><equip><name> − SCEHDUL <timeLimitInfo><equipGroup><equip><name> − SCHEDUL

<maintPlanning><maintAllocationGroup><componentAssyGroup> <componentAssy><name>

− SCHEDUL (maintPlanning) <maintPlanning><toolsList><toolsListGroup><name>

2.4.2 Hardware_part_operational_authorized_life Hardware_part_operational_authorized_life can be used to either derive or populate:

− SCHEDUL <timeLimitInfo> − SCHEDUL <timeLimitInfo><timeLimit><limitType>

<threshold@thresholdUnitOfMeasure> − SCHEDUL

<timeLimitInfo><timeLimit><limitType@limitUnitType> − SCHEDUL <timeLimitInfo><timeLimit><limitType>

<threshold><thresholdValue> − SCHEDUL <timeLimitInfo><timeLimit><limitType><threshold>

<tolerance@toleranceLow> − SCHEDUL <timeLimitInfo><timeLimit><limitType><threshold>

<tolerance@toleranceHigh>

2.4.3 Software_part Software_part can be used to derive:


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6









Part_identifier (inherited from Part) can be used to either derive or populate:

− <dmIdent><dmCode@systemCode> in the identification and status section − <dmIdent><dmCode@subSystemCode> in the identification and status section − <dmIdent><dmCode@subSubSystemCode> in the identification and status


section − <dmStatus><functionalItemRef@manufacturerCodeValue> in the


the PROCED and SCHEDUL schemas, including the identification and status section − CONDCROSSREFTABLE

<condCrossRefTable><condTypeList><condType> <enumeration@applicPropertyValues>

Part_name (inherited from Part) can be used to populate:

− <dmTitle><techName> in the identification and status section

Business rule decision point - Product breakdown and identification of its Breakdown elements:

− Define the strategy for the product breakdown and identification of its Breakdown elements and possible realizations thereof, ie parts. This is required in order to enable the population of the different types of breakdown element identifiers defined in S1000D, ie <dmCode>, <systemBreakdownCode> and <functionalItemCode>, as well as the different types of breakdown element names <techName> and<functionalItemRef><name>. This also includes the use of the S3000L attribute Breakdown_type.

Business rule decision point - Choice of identifier name:

− Determine which identifier and name, respectively, to use for populating the corresponding S1000D elements if parts have multiple Part_identifiers and Part_names.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Business rule decision point - Populating limit type:

− Determine how to populate <timeLimitInfo><timeLimit><limitType> using Hardware_part_operational_authorized_life.

2.5 UoF Breakdown Element Realization The UoF Breakdown Element Realization is used to:

− Define hardware and software breakdown elements along with their realizations in terms of hardware and software parts, respectively.

− Distinguish hardware and software breakdown elements from other types of breakdown elements such as systems, zones, etc.

Note The Hardware_element and Software_element classes are both specializations of the class Breakdown_element which means that, wherever the class Breakdown_element is being used in the data model, Hardware_element or Software_element can be used instead.

Note The Hardware_element_revision and Software_element_revision classes are both specializations of the class Breakdown_element_revision which means that, wherever the class Breakdown_element_revision is being used in the data model, Hardware_element_revision or Software_element_revision can be used instead.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN-B6865-S1003X0023-002-01

Fig 5 S3000L UoF Breakdown Element Realization


2.5.1 Hardware_element (see section on UoF Breakdown Structure) Hardware_element_type can be used to either derive or populate:

− PROCED <preliminaryRqmts><productionMaintData><accessPointRef>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− PROCED <preliminaryRqmts><productionMaintData><accessPointRef@ accessPointTypeValue>

2.5.2 Hardware_element_revision Functional_replaceability can be used to derive:

− SCHEDUL <maintAllocation><maintAllocationGroup>

Repairability can be used to derive:

− SCHEDUL <maintAllocation><maintAllocationGroup>

2.5.3 Hardware_element_realization Hardware_element_realization can be used to derive:

− <dmStatus><functionalItemRef@manufacturerCodeValue> in the identification and status section

− SCHEDUL <taskDefinition><equipGroup><equip>

2.5.4 Software_element_realization Software_element_realization can be used to derive:

− <dmStatus><functionalItemRef@manufacturerCodeValue> in the identification and status section

Business rule decision point - Values for hardware element type:

− Define valid values for Hardware_element_type.

2.6 UoF Breakdown Zone Element The UoF Breakdown Zone Element is used to distinguish between zonal breakdown elements and other types of breakdown elements (eg hardware, software).

Note: Zone elements can be used to define eg defined zones within a product as well as generic work areas, eg mechanical workshop.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN-B6865-S1003X0024-002-01

Fig 6 S3000L UoF Breakdown Zone Element


2.6.1 Zone_element Breakdown_element_identifier (inherited from Breakdown_element) can be used to populate:

− PROCED <preliminaryRqmts><productionMaintData> <zoneRef@zoneNumber>

Breakdown_element_name (inherited from Breakdown_element) can be used to populate:

− PROCED <preliminaryRqmts><productionMaintData><zoneRef><name>

− PROCED <preliminaryRqmts><productionMaintData><workArea>

Zone_element_type can be used to derive:

− PROCED <preliminaryRqmts><productionMaintData><zoneRef> − PROCED <preliminaryRqmts><productionMaintData><workArea>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.6.2 Hardware_element_in_zone_relationship Hardware_element_in_zone_relationship can be used to derive:


Business rule decision point - defining zones and work areas:

− Define the strategy for defining zones and work areas.

2.7 UoF Product Variant Applicability The UoF Product Variant Applicability enables the definition of product models which are available or delivered to the customer in different configurations or variations. A variation or configuration of a product is defined by applying restrictions to the generic product breakdown and its breakdown elements realizations, respectively.

Note Product data standards, eg ISO 10303 often use the term effectivity to describe product design related restrictions, where the restriction defines the planned usage of components in the context of a particular product configuration.

The Product Variant Applicability UoF enables specification of valid use of:

− Breakdown elements in the context of a Breakdown_revision. − Parts in the context of a particular Product_variant_realization (also often

referred to as a Product configuration).

This UoF defines two types of product design related applicabilities:

2.7.1 Product_variant_applicability The Product_variant_applicability:

− Constrains the usage of a Breakdown_element_revision within a Breakdown_revision to a specific Product_variant (also known in GEIA-STD-0007 as Usable On Code).

− Constrains the zonal location (Zone_element_revision) for a Hardware_element_revision to a specific Product_variant.

2.7.2 Product_variant_realization_applicability The Product_variant_realization_applicability:

− Constrains a Hardware_element_realization, Software_element_ realization and/or Parts_list_entry to a specific realization of a Breakdown_revision.

Note Information regarding Product_variant_applicabilities, and Product_variant_realization_applicabilities, are often received from the design department as part of the product definition. This information often originates from of some kind of PDM-system.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0026-002-01

Fig 7 S3000L UoF Product Variant Applicability


2.7.3 Product_variant_realization Product_variant_realization can be used to derive:



S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6





Product_variant_realization_identifier can be used to populate:

− Any instance of the attribute <applic><assert@applicPropertyValues> in the PROCED and SCHEDUL schemas, including the identification and status section .

− APPLICCROSSREFTABLE <applicCrossRefTable><productAttributeList> <productAttribute><enumeration@applicPropertyValues>

Business rule decision point - Defining system difference:

− Define the strategy for defining system difference (use of Product_variant_applicability, Breakdown_element_identifiers or Breakdown_element_relationships).

2.8 UoF LSA-FMEA and Special Events The UoF LSA-FMEA and Special Events supports the recording of portions of the results from the following LSA activities:

− LSA - FMEA (Failure Mode and Effect Analysis) − Damage analysis − Special event analysis − Testability analysis.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0027-002-01

Fig 8 S3000L UoF LSA-FMEA and Special Events

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6



2.8.1 Special_event Special_event_title can be used to populate:

− SCHEDUL <taskDefinition><limit@limitCond> − SCHEDUL <taskDefinition><limit><trigger>


<inspectionDefinition><inspection><limit@limitCond> − SCHEDUL <inspectionDefinition><inspection><limit><trigger>

<threshold@thresholdUnitOfMeasure>

2.8.2 LSA_failure_mode LSA_failure_mode_description can be used to populate:

− SCHEDUL <taskDefinition><limit@limitCond> − SCHEDUL <taskDefinition><limit><trigger>


<inspectionDefinition><inspection><limit@limitCond> − SCHEDUL <inspectionDefinition><inspection><limit><trigger>

<threshold@thresholdUnitOfMeasure>

2.8.3 Product_usage_phase Product_usage_phase can be used to derive or populate:

− Any instance of the attribute <applic><assert@applicPropertyIdent> in the PROCED and SCHEDUL schemas, including the identification and status section.

− Any instance of the attribute <dmStatus><applic><assert@applicPropertyType> in the PROCED and SCHEDUL schemas, including the identification and status section

− Any instance of the attribute <dmStatus><applic><assert@applicPropertyValues> in the PROCED and SCHEDUL schemas, including the identification and status section








S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Business rule decision point - Values for the special event title:

− Define valid values for Special_event_title.

Business rule decision point - Values for the product usage phase:

− Define valid values for Product_usage_phase.

2.9 UoF LSA Candidate Task Requirement The LSA Candidate Task Requirement UoF supports early recordings of task requirements, which will be refined during the detailed maintenance task analysis, software and data loading analysis, etc.

Objectives for documenting task requirements are eg to:

− Produce input to the LSA review, and together with the customer define maintenance concepts for the respective LSA candidate, before any detailed task analysis is being carried out.

− Identify product design changes that will result in increased maintainability, testability, etc.

A task requirement can also be associated with the source for the requirement, ie the driver for the task. The requirement for a task may be derived from any type of logistics support analysis task.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0028-002-01

Fig 9 S3000L UoF LSA Candidate Task Requirement


2.9.1 Authority_driven_task_requirement Task_requirement_authority_source_type can be used to populate:

− SCHEDUL <taskDefinition><rqmtSource@sourceOfRqmt>

Business rule decision point -Use of authority driven task requirement:

− Define how to use of Authority_driven_task_requirement.

Business rule decision point - Values for task requirement authority source type:

− Define valid values for Task_requirement_authority_source_type.

2.10 UoF Task The UoF Task supports a detailed definition of a task, both maintenance task and operational task.

The Task procedure is described using a set of Subtasks. A Subtask can either be defined within the Task under consideration, or be a Task in its own right which is referenced via Subtask_by_reference.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Note A Subtask that is being defined and described within a Task cannot be referenced by any other Task.

There is also the possibility to define a time line (schedule) for the Subtasks contained within a Task. This can be used for the purpose of optimizing resource requirements and/or be the basis for creating job cards in eg a fleet management system.

Note The Task UoF has been designed to support integration between S3000L and the S1000D procedure and schedule schemes, respectively.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0029-002-01

Fig 10 S3000L UoF Task


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.10.1 Task Task_identifier can be used to populate:

− <authoritInfoAndTp><techPubBase> in the identification and status section − SCHEDUL <taskDefinition@taskIdent> − SCHEDUL

<taskDefinition><limit><trigger><refs><externalPubRef> <externalPubRefIdent><externalPubCode>

− SCHEDUL <inspectionDefinition><inspection@id> − SCHEDUL

<inspectionDefinition><inspection><limit><trigger><refs> <externalPubRef><externalPubRefIdent><externalPubCode>

− SCHEDUL <inspectionDefinition><taskGroup><taskItem@taskName>

Task_revision_identifier can be used to populate:

− <authoritInfoAndTp><techPubBase> in the identification and status section

Task_revision_status can be used to populate:

− <techStandard><techPubBase> in the identification and status section

Task_name can be used to derive:

− <dmTitle><infoName> in the identification and status section − PROCED

<preliminaryRqmts><reqCondGroup><reqCondNoRef><reqCond> − PROCED <closeRqmts><reqCondGroup><reqCondNoRef><reqCond> − PROCED <mainProcedure><proceduralStep><title> − SCHEDUL <taskDefinition><task><taskTitle> − SCHEDUL <taskDefinition><task><taskDescr> − SCHEDUL <taskDefinition><limit>

<inspectionType@inspectionTypeCategory> − SCHEDUL

<taskDefinition><limit><trigger><refs><externalPubRef> <externalPubRefIdent><externalPubTitle>

− SCHEDUL <taskDefinition<limit><trigger> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <inspectionDefinition><inspection><limit> <inspectionType@inspectionTypeCategory>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger><refs> <externalPubRef><externalPubRefIdent><externalPubTitle>

− SCHEDUL <inspectionDefinition><taskGroup><taskItem><task><taskTitle>

− SCHEDUL <inspectionDefinition><taskGroup><taskItem> <task><taskDescr>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <maintAllocation><maintAllocationGroup><maintQualifier> <maintFunction@function>

− SCHEDUL <maintAllocation><maintAllocationGroup> <componentAssyGroup> <maintQualifier><maintFunction@function>

Information_code can be used to derive or populate:

− <dmIdent><dmCode@infoCode> in the identification and status section − <dmIdent><dmCode@infoCodeVariant> in the identification and status section − SCHEDUL <taskDefinition@taskCode>

Task_duration can be used to calculate:

− PROCED <preliminaryRqmts><productionMaintData> <taskDuration@startupDuration>

− PROCED <preliminaryRqmts><productionMaintData> <taskDuration@procedureDuration>

− PROCED <preliminaryRqmts><productionMaintData> <taskDuration@closeupDuration>

− PROCED <preliminaryRqmts><productionMaintData> <taskDuration@unitOfMeasure>

Task_total_labour_time can be used to populate:

− SCHEDUL <maintAllocation><maintAllocationGroup><maintQualifier> <maintLevelGroup><maintLevel>

− SCHEDUL <maintAllocation><maintAllocationGroup> <componentAssyGroup><maintQualifier><maintLevelGroup> <maintLevel>

S1000D_task_type can be used to derive or populate:

− PROCED or SCHEDUL (<taskDefinition>, <inspectionDefinition>, <timeLimitInfo> and <maintAllocation>) scheme

− SCHEDUL <taskDefinition><limit> <inspectionType@inspectionTypeCategory>

2.10.2 Task_change Task_change_description can be used to populate the elements:

− <dmStatus><reasonForUpdate> in the identification and status section

2.10.3 Warning_caution_or_note Warning_caution_or_note can be used to derive or populate the elements:

− PROCED <preliminaryRqmts><reqSafety><noSafety> − PROCED <preliminaryRqmts><reqSafety><safetyRqmts><warning>

<warningAndCautionPara>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− PROCED <preliminaryRqmts><reqSafety><safetyRqmts><caution> <warningAndCautionPara>

− PROCED <preliminaryRqmts><reqSafety><safetyRqmts><note><notePara>

− PROCED <mainProcedure><proceduralStep><warning> <warningAndCautionPara>

− PROCED <mainProcedure><proceduralStep><caution> <warningAndCautionPara>

− PROCED <mainProcedure><proceduralStep><note><notePara>

Warning_caution_or_note_type can be used to distinguish between the elements:

− Use of <warning>, <caution> or <note>

2.10.4 Subtask Subtask_identifier can be used to populate:

− SCHEDUL <inspectionDefinition><taskGroup> <taskItem@taskSequenceNumber>

Subtask_role can be used to derive the elements:


− PROCED <preliminaryRqmts><productionMaintData><workArea> − PROCED <preliminaryRqmts><reqCondGroup><noCond> − PROCED <closeRqmts><reqCondGroup><noCond> − PROCED

<preliminaryRqmts><reqCondGroup><reqCondNoRef><reqCond> − PROCED <closeRqmts><reqCondGroup><reqCondNoRef><reqCond> − PROCED <preliminaryRqmts><reqCondGroup><reqCondPm><pmRef> − PROCED <closeRqmts><reqCondGroup><reqCondPm><pmRef> − PROCED

<preliminaryRqmts><reqCondGroup><reqCondExternalPub> − PROCED <closeRqmts><reqCondGroup><reqCondExternalPub> − PROCED

<preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <reqCond>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker><reqCond>

− PROCED <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup>

− PROCED <preliminaryRqmts><reqPersons> − PROCED <preliminaryRqmts><reqSupportEquips> − PROCED <preliminaryRqmts><reqSupplies> − PROCED <preliminaryRqmts><reqSpares>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− PROCED <preliminaryRqmts><reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr><reqQuantity>

− PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup> <supplyDescr><reqQuantity>

− PROCED <preliminaryRqmts<reqSpares><spareDescrGroup><spareDescr> <reqQuantity>

− PROCED <preliminaryRqmts><reqSafety> − PROCED <mainProcedure> − PROCED <mainProcedure@independentCheck>

− PROCED <mainProcedure><proceduralStep> − SCHEDUL <taskDefinition@skillLevelCode>

− SCHEDUL <taskDefinition><refs> − SCHEDUL

<maintAllocation><maintAllocationGroup><maintQualifier> <maintLevelGroup><maintLevel>


2.10.5 Subtask_timeline Subtask_time_line_event and Subtask_timeline_lag can be used to derive:







2.10.6 Subtask_by_definition Subtask_name can be used to either derive or populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondNoRef><reqCond>

− PROCED <closeRqmts><reqCondGroup><reqCondNoRef><reqCond>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− PROCED <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <reqCond>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker><reqCond>

− PROCED <mainProcedure><proceduralStep><title>

Information_code can be used to derive:

− <dmIdent><dmCode@infoCodeVariant> in the identification and status section


Subtask_description can be used to populate:

− PROCED <mainProcedure><proceduralStep><para>

Subtask_duration can be used to derive:




− PROCED <preliminaryRqmts><productionMaintData> <taskDuration@unitOfMeasure>

Maintenance_location_code can be used to populate:

− <dmIdent><dmCode@itemLocationCode> in the identification and status section

2.10.7 Subtask_in_zone Subtask_in_zone can be used to derive:


2.10.8 Subtask_target_item Subtask_target_item can be used to derive:


− PROCED <preliminaryRqmts><productionMaintData><workArea>

2.10.9 Subtask_objective_state Subtask_objective_state can be used to either derive or populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondNoRef><reqCond>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− PROCED <closeRqmts><reqCondGroup><reqCondNoRef><reqCond> − PROCED <mainProcedure><proceduralStep@independentCheck>

2.10.10 Subtask_circuit_breaker_state Subtask_objective_state (inherited from Subtask_objective_state) can be used to either derive or populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerAction>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr><circuitBreakerRef@circuitBreakerAction

− PROCED <mainProcedure><proceduralStep> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerAction>

2.10.11 Circuit_breaker Circuit_breaker_identifier can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerNumber>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerNumber>

− PROCED <mainProcedure><proceduralStep> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr> <circuitBreakerRef@circuitBreakerNumber>

Circuit_breaker_type can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr><circuitBreakerRef@circuitBreakerType>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


<circuitBreakerDescr> <circuitBreakerRef@circuitBreakerType>

− PROCED <mainProcedure><proceduralStep><circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup><circuitBreakerDescr> <circuitBreakerRef@circuitBreakerType>

Circuit_breaker_name can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr><name>

− PROCED <closeRqmts><reqCondGroup><reqCondCircuitBreaker> <circuitBreakerDescrGroup><circuitBreakerDescrSubGroup> <circuitBreakerDescr><name>

− PROCED <mainProcedure><proceduralStep><circuitBreakerDescrGroup> <circuitBreakerDescrSubGroup> <circuitBreakerDescr><circuitBreakerName>

All instances of Subtask, within a Task of type “Package” in S3000L, must be Subtask_by_reference.

Business rule decision point - Rules for procedural and packaged tasks:

− Define rules for organizing “Procedural” and “Packaged” tasks.

Business rule decision point - Rules for task name:

− Define rules for Task_name, based on S1000D Information code names.

Business rule decision point - Use of S1000D information codes:

− Determine how to use of S1000D information codes to categorize S3000L Tasks and Subtask_by_definition, and rules for letting more than one Task, being associated with a specific instance of Breakdown_element or Part, having the same Information_code.

Business rule decision point - Use of information codes:

− Define rules for letting more than one subtask within a Task having the same Information_code.

Business rule decision point - Use of project specific information codes:

− Define rules defining project specific “Not given” information codes.

Business rule decision point - Mapping S1000D information codes to task codes:

− Decide on the mapping between S1000D information codes and SCHEDUL <taskDefinition@taskCode>.

Business rule decision point - Rolling up different task durations:

− Define rules for summarizing (roll-up) the different types of S1000D task_Durations.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Business rule decision point - Populating no safety:

− Decide how, in the absence of Warning_caution_or_note (where Warning_caution_or_note_type = 'Warning') associated with the Task itself or with any of its subtasks populate PROCED <preliminaryRqmts><reqSafety><noSafety>.

Business rule decision point - Checking subtasks:

− Define rules for indicating that a subtask must be checked, by use of either a dedicated Task_personnel_resource (role = 'Quality_assurance'), or by Subtask_objective_state ('Task_checked').

Business rule decision point - Mapping information codes:

− Decide on the mapping between S1000D information codes and <mainenanceAllocation><maintFunction@function> values.

2.11 UoF Task Resources The UoF Task Resources supports a detailed definition of resources needed, either per subtask, or aggregated per task.

Task resources can be either:

− Material resources, eg spares, tools, consumables − Facilities, eg hangars, power − Personnel resources, eg defined skills − Documents.

Material and facility resources can be defined both in terms of specifications, and in terms of actual parts.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0030-002-01

Fig 11 S3000L UoF Task Resources


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.11.1 Task_material_resource Task_material_resource_quantity can be used to populate:


− PROCED <preliminaryRqmts><reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr><reqQuantity@unitOfMeasure>


− PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup> <supplyDescr><reqQuantity@unitOfMeasure>


− PROCED <preliminaryRqmts<reqSpares><spareDescrGroup><spareDescr> <reqQuantity@unitOfMeasure>

Task_material_resource_category can be used to derive:

− PROCED <preliminaryRqmts><reqSupportEquips> − PROCED <preliminaryRqmts><reqSupplies> − PROCED <preliminaryRqmts><reqSpares>

2.11.2 Resource_specification Resource_specification_identifier can be used to populate:

− PROCED <preliminaryRqmts><reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr><natoStockNumber><fullNatoStockNumber>

− PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup> <supplyDescr><natoStockNumber><fullNatoStockNumber>

− PROCED <preliminaryRqmts><reqSpares><spareDescrGroup> <spareDescr><natoStockNumber><fullNatoStockNumber>

− SCHEDUL <taskDefinition><equipGroup><equip><natoStockNumber> <fullNatoStockNumber>

− SCEHDUL <timeLimitInfo><equipGroup><equip><natoStockNumber> <fullNatoStockNumber>

− SCHEDUL <maintAllocation><maintPlanning><toolsList> <toolsListGroup> <natoStockNumber><fullNatoStockNumber>

− SCHEDUL <maintAllocation><maintPlanning><toolsList> <toolsListGroup> <toolRef@toolNumber>

Resource_specification_name can be used to populate:

− PROCED <preliminaryRqmts><reqSupportEquips> <supportEquipDescrGroup> <supportEquipDescr><name>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− PROCED <preliminaryRqmts><reqSupplies><supplyDescrGroup> <supplyDescr><name>

− PROCED <preliminaryRqmts><reqSpares><spareDescrGroup> <spareDescr><name>

2.11.3 Task_personnel_resource Task_personnel_resource_role can be used to either derive or populate:

− PROCED <preliminaryRqmts><reqPersons><personnel> − PROCED <preliminaryRqmts><reqPersons><person> − PROCED <preliminaryRqmts><reqPersons><person@man>

− PROCED <mainProcedure@independentCheck>

− PROCED <mainProcedure@skillLevelCode>

− PROCED <mainProcedure><proceduralStep@independentCheck>

− SCHEDUL <taskDefinition><supervisorLevel> − SCHEDUL <inspectionDefinition><taskGroup>

<taskItem@skillLevelCode>

Task_number_of_personnel_resource can be used to populate:

− PROCED <preliminaryRqmts><reqPersons><personnel@numRequired>

Task_personnel_resource_labour_time can be used to populate or calculate:

− PROCED <preliminaryRqmts><reqPersons><personnel><estimatedTime>

− PROCED <preliminaryRqmts><reqPersons><personnel> <estimatedTime@unitOfMeasure>

− PROCED <preliminaryRqmts><reqPersons><person><estimatedTime> − PROCED <preliminaryRqmts><reqPersons><person>

<estimatedTime@unitOfMeasure>

− SCHEDUL <maintAllocation><maintAllocationGroup><maintQualifier> <maintLevelGroup><maintLevel>


2.11.4 Trade Trade_name can be used to populate:

− PROCED <preliminaryRqmts><reqPersons> <personnel><personCategory@personCategoryCode>

− PROCED <preliminaryRqmts><reqPersons> <person><personCategory@personCategoryCode>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <taskDefinition@skillType>

− SCHEDUL <taskDefinition><supervisorLevel@supervisorLevelCode>

2.11.5 Skill Skill_code can be used to populate:

− PROCED <preliminaryRqmts><reqPersons><personnel><trade> − PROCED <preliminaryRqmts><reqPersons><person><trade> − SCHEDUL

<taskDefinition><supervisorLevel@supervisorLevelCode>

2.11.6 Skill_level Skill_level_name can be used to populate:

− PROCED <preliminaryRqmts><reqPersons> <personnel><personSkill@skillLevelCode>

− PROCED <preliminaryRqmts><reqPersons> <person><personSkill@skillLevellCode>

− PROCED <mainProcedure@skillLevelCode>

− PROCED <mainProcedure><proceduralStep@skillLevelCode>

− SCHEDUL <taskDefinition@skillLevelCode>

− SCHEDUL <inspectionDefinition><taskGroup> <taskItem@skillLevelCode>

Business rule decision point - Values for task material resource category:

− Define valid values for Task_material_resource_category.

Business rule decision point - Populating no support equipment:

− Define rules for how the absence of Task_material_resources populates PROCED <preliminaryRqmts><noSupportEquips>.

Business rule decision point Use of task personnel resource role:

− Decide on the use of Task_personnel_resource_role, and valid values.

Business rule decision point - Checking subtasks:

− Decide on rules for indicating that a subtask must be checked, by use of either a dedicated Task_personnel_resource (role = 'Quality_assurance'), or by Subtask_objective_state ('Task_checked').

Business rule decision point - Values for skill codes:

− Define valid values for Skill_code.

Business rule decision point - Values for trade names:

− Define valid values for Trade_name.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Business rule decision point - Values for skill level codes:

− Define valid values for Skill_level.

2.12 UoF Task Usage (Part 1) The UoF Task Usage (Part 1) supports detailed definitions for:

− Identifying the breakdown element or part on which an operational or rectifying task is to be performed.

− What initiates an operational or rectifying task to be performed on a breakdown element or a part (task limits).

− Where the operational or rectifying task is to be performed.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0031-002-01

Fig 12 S3000L UoF Task Usage (Part 1)

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6



2.12.1 Planned_task_usage Planned_task_usage can be used to derive:

− SCHEDUL <taskDefinition><equipGroup><equip>

2.12.2 Sampling_by_ratio Sampling_method_ratio can be used to populate:

− SCHEDUL <taskDefinition><limit><sampling> − SCHEDUL <inspectionDefinition><inspection><limit><sampling>

2.12.3 Task_limit Task_limit_description can be used to populate:

− SCHEDUL <taskDefinition><limit@limitCond>

− SCHEDUL <inspectionDefinition><inspection><limit@limitCond>

2.12.4 Discrete_task_limit Discrete_task_limit can be used to derive:

− SCHEDUL <taskDefinition><limit@limitTypeValue>

− SCHEDUL <taskDefinition><limit><trigger@releaseEvent>

− SCHEDUL <inspectionDefinition><inspection><limit@limitTypeValue>

− SCHEDUL <inspectionDefinition><inspection><limit> <trigger@releaseEvent>

2.12.5 Periodic_task_limit Periodic_task_limit can be used to derive:



2.12.6 Initial_task_limit Initial_task_limit can be used to derive:


2.12.7 Repeat_task_limit Repeat_task_limit can be used to derive:


− SCHEDUL <taskDefinition><limit><limitRange> − SCHEDUL

<inspectionDefinition><inspection><limit@limitTypeValue>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <inspectionDefinition><inspection><limit><limitRange>

2.12.8 Subsequent_repeat_relationship Subsequent_repeat_relationship can be used to derive:

− SCHEDUL <taskDefinition><limit><limitRange> − SCHEDUL

<inspectionDefinition><inspection><limit><limitRange>

2.12.9 Parameter_threshold Parameter_threshold can be used to derive:


Threshold_value can be used to populate:

− SCHEDUL <taskDefinition><limit><threshold@thresholdUnitOfMeasure>

− SCHEDUL <taskDefinition><limit><threshold><thresholdValue> − SCHEDUL <taskDefinition><limit><threshold>

<tolerance@toleranceLow>

− SCHEDUL <taskDefinition><limit><threshold> <tolerance@toleranceHigh>

− SCHEDUL <taskDefinition><limit><limitRange><limitRangeFrom> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <taskDefinition><limit><limitRange><limitRangeFrom> <threshold> <thresholdValue>

− SCHEDUL <taskDefinition><limit><limitRange><limitRangeTo> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <taskDefinition><limit><limitRange><limitRangeTo> <threshold> <thresholdValue>

− SCHEDUL <taskDefinition><limit><trigger> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <taskDefinition><limit><trigger><threshold> <thresholdValue>

− SCHEDUL <taskDefinition><limit><trigger><threshold> <tolerance@toleranceLow>

− SCHEDUL <taskDefinition><limit><trigger><threshold> <tolerance@toleranceHigh>

− SCHEDUL <inspectionDefinition><inspection><limit> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <inspectionDefinition><inspection><limit> <threshold><thresholdValue>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <inspectionDefinition><inspection><limit><threshold> <tolerance@toleranceLow>

− SCHEDUL <inspectionDefinition><inspection><limit><threshold> <tolerance@toleranceHigh>

− SCHEDUL <inspectionDefinition><inspection><limit><limitRange> <limitRangeFrom><threshold@thresholdUnitOfMeasure>

− SCHEDUL <inspectionDefinition><inspection><limit><limitRange> <limitRangeFrom><threshold><thresholdValue>

− SCHEDUL <inspectionDefinition><inspection><limit><limitRange> <limitRangeTo> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <inspectionDefinition><inspection><limit><limitRange> <limitRangeTo> <threshold><thresholdValue>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger> <threshold@thresholdUnitOfMeasure>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger> <threshold> <thresholdValue>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger> <threshold> <tolerance@toleranceLow>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger> <threshold> <tolerance@toleranceHigh>

2.12.10 Event_threshold Event_threshold_number_of_event_occurrences can be used to derive or populate:


− SCHEDUL <taskDefinition><limit@limitCond>

− SCHEDUL <taskDefinition><limit><trigger><threshold> <thresholdValue>


− SCHEDUL <inspectionDefinition><inspection><limit@limitCond>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger> <threshold> <thresholdValue>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.12.11 Task_related_threshold Task_related_threshold can be used to derive:

− SCHEDUL <taskDefinition><limit><trigger><refs><externalPubRef>

− SCHEDUL <inspectionDefinition><inspection><limit><trigger><refs> <externalPubRef>

Business rule decision point:

− Define valid unit of measures for Parameter_threshold attribute Threshold_value.

Business rule decision point - Use of tasks, failure modes and special events:

− Decide on the use of Tasks, LSA failure modes and Special events as thresholds and triggers.

Business rule decision point - Use of the ‘Whichever comes first’ value:

− Decide on the use of 'Whichever comes first' value for all threshold and triggers.

Business rule decision point - Definition for sampling:

− Define all sampling using percentage.

2.13 UoF Security Classification The UoF Security Classification supports the assignment of security classes to objects that needs special handling with respect to, availability, distribution, presentation etc.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0032-001-01

Fig 13 S3000L UoF Security Classification


2.13.1 Security_class Security_class can be used to either derive or directly populate:

− <dmStatus><security@securityClassification> in the identification and status section

− PROCED <mainProcedure@securityClassification>

− PROCED <mainProcedure><proceduralStep@securityClassification>

Business rule decision point - Applying security classifications:

− Define rules for applying Security_class per Breakdown_element, Part, Task_requirement, Task or Subtask_by_definition, and how these can be propagated into the different <mainProcedure@securityClassification> attributes.

2.14 UoF Document The UoF Document supports a flexible way of assigning documents to different types of objects in the data model.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Note There are some previously proposed (even mandatory) associations with the Document class in the data model. This UoF adds the ability to define any type of additional Document information which is of relevance for an instance of the classes that implements the Document_assignment_interface. An example of additional Document information can be 'Design_document' for a Part. This is not explicit in the data model but can be added using this UoF, by defining the Document_assignment_role of class Document_assignment as 'Design_document'.

Note The S3000L data model defines two specializations of Document:

− S1000D data modules, which just contains information for being able to identify a specific instance of a data module

− S1000D publication modules, which just contains information for being able to identify a specific publication module instance

− External documents, which contains more metadata about the document itself.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0033-002-01

Fig 14 S3000L UoF Document


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.14.1 S1000D_pulication_module Publication_module_code can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondPm><pmRef> <pmRefIdent><pmCode>

− PROCED <closeRqmts><reqCondGroup><reqCondPm><pmRef> <pmRefIdent><pmCode>

− SCHEDUL <taskDefinition><refs><pmRef><pmRefIdent><pmCode>

Publication_module_issue_number can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondPm><pmRef> <pmRefIdent><issueInfo@issueNumber>

− PROCED <closeRqmts><reqCondGroup><reqCondPm><pmRef> <pmRefIdent><issueInfo@issueNumber>

− SCHEDUL <taskDefinition><refs><pmRef><pmRefIdent> <IssueInfo@issueNumber>

Publication_module_title can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondPm><reqCond>

− PROCED <closeRqmts><reqCondGroup><reqCondPm><reqCond>

2.14.2 External_document Document_identifier can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent><externalPubCode>

− PROCED <closeRqmts><reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent><externalPubCode>

− SCHEDUL <taskDefinition><rqmtSource@sourceIdent>

− SCHEDUL <taskDefinition><refs><externalPubRef> <externalPubRefIdent> <externalPubCode>

Document_title can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent><externalPubTitle>

− PROCED <closeRqmts><reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent><externalPubTitle>


S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <taskDefinition><refs><externalPubRef> <externalPubRefIdent> <externalPubTitle>

Document_issue_identifier can be used to populate:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent> <externalPubIssueInfo> <externalPubIssue>

− PROCED <closeRqmts><reqCondGroup><reqCondExternalPub> <externalPubRef><externalPubRefIdent> <externalPubIssueInfo> <externalPubIssue>

− SCHEDUL <taskDefinition><rqmtSource><issueInfo@issueNumber>

− SCHEDUL <taskDefinition><refs><externalPubRef> <externalPubRefIdent> <externalPubIssueInfo><externalPubIssue>

Document_issue_date can be used to populate:

− SCHEDUL <taskDefinition><rqmtSource><issueDate@year> − SCHEDUL <taskDefinition><rqmtSource><issueDate@month> − SCHEDUL <taskDefinition><rqmtSource><issueDate@day>

2.14.3 Document_assignment Document_assignment_role can be used to derive:

− PROCED <preliminaryRqmts><reqCondGroup><reqCondPm>

− PROCED <closeRqmts><reqCondGroup><reqCondPm>

− PROCED <preliminaryRqmts><reqCondGroup><reqCondExternalPub>

− PROCED <closeRqmts><reqCondGroup><reqCondExternalPub>


Business rule decision point - Values for document assignment roles:

− Define permitted values for Document_assignment_role, and how to use these across the ASD specifications.

2.15 UoF Remark The UoF Remark supports a flexible way of assigning remarks to instances of almost any class in the data model.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN- B6865-S1003X0034-002-01

Fig 15 S3000L UoF Remark


2.15.1 Remark Remark_text can be used to populate:

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


− SCHEDUL <taskDefinition><limit><remarks><simplePara>

− SCHEDUL <taskDefinition><remarks><simplePara>

− SCHEDUL <inspectionDefinition><inspection><limit> <remarks><simplePara>

− SCHEDUL <inspectionDefinition><inspection><remarks><simplePara>

− SCHEDUL <timeLimitInfo><timeLimit><remarks><simplePara>

Business rule decision point - Use of remarks:

− Decide how to use remarks.

2.16 UoF Applicability Statement The Condition_type class defines types of conditions to be used in applicability statements, where the specific type of condition to be used cannot be derived from any other class being defined within the S3000L data model.

Note Examples on condition types that cannot be derived from the use of any other class in the S3000L data model, and therefore needs to be defined as instances of Condition_type, are:

− Service_bulletin − Operational_environment − Operational_scenario − Operational_state

Note An example of a class in the data model which can be used to define a condition is the Customer class. The values that can be used in a condition are the instances of that class, ie the values already exist in the LSA database.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


ICN-B6865-S1003X0035-002-01

Fig 16 S3000L UoF Applicability Statement

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6



2.16.1 Applicability_statement Applicability_statement_identifier can be used to populate:

− <referenceApplicGroup><applic@id> in the identification and status section − Any instance of the attribute <XXX@applicRefId> in the PROCED and SCHEDUL

schemas, including the identification and status section. Applicability_statement_description can be used to populate:

− Any instance of <applic><displayText><simplePara> in the PROCED and SCHEDUL schemas, including the identification and status section.

2.16.2 Logical_operator subclasses AND and OR, respectively Logical_operator subclasses AND and OR can be used to derive:

− Any instance of <applic><evaluate@andOr> in the PROCED and SCHEDUL schemas, including the identification and status section.

2.16.3 Condition_by_identifier Condition_by_identifier can be used to derive:







Condition_identifier can be used to populate:

− Any instance of the attribute <applic><assert@applicPropertyIdent> in the PROCED and SCHEDUL schemas, including the identification and status section CONDCROSSREFTABLE <condCrossRefTable><condList><cond@id>

Condition_name can be used to populate:

− CONDCROSSREFTABLE <condCrossRefTable><condList><cond><name>

Condition_description can be used to populate:

− CONDCROSSREFTABLE <condCrossRefTable><condList><cond><descr>

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


2.16.4 Condition_type Condition_type can be used to derive:



Condition_type_name can be used to populate:





− CONDCROSSREFTABLE <condCrossRefTable><condList><cond@id> − CONDCROSSREFTABLE <condCrossRefTable><condList><cond><name>

− CONDCROSSREFTABLE <condCrossRefTable><condList><cond><descr>

2.16.5 Condition_type_class_value Condition_type_class_value can be used to populate:



2.16.6 Condition_type_property_value Condition_type_property_value can be used to populate:


− CONDCROSSREFTABLE <condCrossRefTable><condTypeList><condType> <enumeration@applicPropertyValues

Business rule decision point - Product attributes and conditions in applicability:

− Define permitted product attributes and conditions that can be used in applicability statements.

Business rule decision point - task generality in applicability:

− Define task generality and usage of applicability for eg task, subtask, task resource and task usage.

S1003X-B6865-01003-00 S 1003X-B6865-01003-00


Chap 6


Business rule decision point Use of condition types and condition type values:

− Define Condition_types and Condition_type_values.

End of data module

S1003X-B6865-01003-00


Chap 7


Chapter 7

S1000D feedback to S3000L

Table of contents Page S1000D feedback to S3000L ......................................................................................................... 1 References ..................................................................................................................................... 1 1 S1000D feedback to S3000L ........................................................................................... 1


References

Table 1 References




1 S1000D feedback to S3000L In producing the technical publications using S1000D a set of additional data is created, as well as data coming from S3000L being refined. This can mean that eg tasks coming out of S3000L can be either split into multiple data modules, or be a single data module. In order to document the S3000L tasks in the resulting S1000D data modules the corresponding data modules must have the <techPubBase> element populated with the S3000L task identifications, ie task_identifier including identifier_set_by_organization, task_revision_identifier, and optionally task_revision_status.

Therefore the key data to be exchanged from an S1000D CSDB back to the S3000L data base is the cross references between the S1000D data modules codes and its corresponding S3000L task identification. This includes the information being defined in the elements <dmCode>, <language>, <issueNumber> and <techPubBase> within the <identAndStatusSection>.

End of data module

S1003X-B6865-01003-00


Chap 8


Chapter 8

Use of DEX for S1000D and S3000L data exchange

Table of contents Page Use of DEX for S1000D and S3000L data exchange .................................................................... 1 References ..................................................................................................................................... 1 1 Use of DEX for S1000D and S3000L data exchange ..................................................... 1


List of figures 1 Tailoring of the aerospace and defense DEX using S1003X .......................................... 2

References

Table 1 References


S3000L data required to populate S1000D data modules Chap 6





1 Use of DEX for S1000D and S3000L data exchange The aerospace and defense DEX1AD and DEX3AD provide a standard method for providing product and task data defined by S3000L. The exchange of data between S3000L and S1000D represents a subset of these DEX. S1003X provides a roadmap for tailoring these DEX. Fig 1 shows the use of the DEX and S1003X to exchange product and task data.

S1003X-B6865-01003-00


Chap 8


ICN-B6865-S1003X0036-001-01

Fig 1 Tailoring of the aerospace and defense DEX using S1003X

The tailoring details are defined in the Chap 6 S3000L data required to populate S1000D data modules.

End of data module

S1003X-B6865-01003-00


Chap 9


Chapter 9

Samples with S1000D and S3000L instantiations

Table of contents Page 1 Introduction ...................................................................................................................... 2 1.1 Purpose ........................................................................................................................... 2 2 Introduction ...................................................................................................................... 2 2.1 Key concepts ................................................................................................................... 2 2.2 S1000D Schedule Schemas and S3000L ....................................................................... 2 2.2.1 S1000D Schema.............................................................................................................. 2 2.2.2 S3000L model .................................................................................................................. 3 3 Examples with S1000D and S3000L instantiations ......................................................... 4 3.1 Simple case ..................................................................................................................... 4 3.1.1 Threshold equals, Repeat case. ...................................................................................... 5 3.1.2 Threshold does not equal, Repeat. ................................................................................. 5 3.2 One time only case .......................................................................................................... 5 3.3 Whichever comes first case ............................................................................................. 5 3.4 Sampling, repeat and threshold case .............................................................................. 5 3.5 Subsequent, repeat (trigger) case ................................................................................... 5 3.6 Multiple trigger case ........................................................................................................ 5 3.7 Threshold after trigger using threshold case ................................................................... 5 3.8 Trigger and whichever comes first case .......................................................................... 5 Threshold after trigger using <refs> ................................................................................ 5 3.9 case ................................................................................................................................. 5 3.10 Subsequent repeat (limit range) case ............................................................................. 6 3.11 More than one threshold case ......................................................................................... 6 3.12 Complex cases ................................................................................................................ 6 3.12.1 Complex case, two groups case ...................................................................................... 6 3.12.2 Complex case with notes ................................................................................................. 6

List of tables 1 References ...................................................................................................................... 2 2 Simple case - Threshold equals - Repeat ....................................................................... 7 3 Simple case - Threshold does not equal - Repeat .......................................................... 8 4 One time only ................................................................................................................... 9 5 Whichever comes first ................................................................................................... 10 6 Sampling, repeat and threshold..................................................................................... 11 7 Subsequent - Repeat (trigger) ....................................................................................... 13 8 Multiple trigger ............................................................................................................... 14 9 Threshold after trigger using threshold .......................................................................... 15 10 Trigger and whichever comes first ................................................................................. 16 11 Threshold after trigger using <refs> .............................................................................. 17 12 Subsequent repeat (limrange) ....................................................................................... 18 13 More than one threshold ................................................................................................ 20 14 Complex case - Two groups .......................................................................................... 21 15 Complex case with notes ............................................................................................... 23

S1003X-B6865-01003-00


Chap 9


List of figures 1 S1000D Limit schema ..................................................................................................... 32 S3000L Uof Task Usage (Part 1) .................................................................................... 4

References

Table 1 References




1 Introduction 1.1 Purpose

The purpose of this chapter is to present threshold and inspection examples with the corresponding S1000D and S3000L instantiation.

2 Introduction The examples deal with limits and thresholds as defined in the schedule (maintenance planning) Schema and its inspection definition, task definition and time limit branches, using the elements <inspectionDefinition>, <taskDefinition> and <timeLimitInfo>, respectively. identAndStatusSection

2.1 Key concepts The key concepts addressed in these examples are:

− Limit

• Perform once • Periodic • On condition

− Threshold (with variations) − Trigger (with variations) − Sampling − Whichever comes first

2.2 S1000D Schedule Schemas and S3000L 2.2.1 S1000D Schema

On the S1000D side of these examples are elements and attributes that are defined in the inspection definition branch of the schedule Schema, and specifically the element <limit>. Refer to Fig 1.

S1003X-B6865-01003-00


Chap 9


ICN-B6865-S1003X0037-001-01

Fig 1 S1000D element <limit>

2.2.2 S3000L model On the S3000L side of these examples is the S3000L model abstract that represents the Unit of Functionality (UoF) Task Usage (Part 1). Refer to Fig 2.

S1003X-B6865-01003-00


Chap 9


ICN-B6865-S1003X0038-001-01

Fig 2 S3000L Uof Task Usage (Part 1)

3 Examples with S1000D and S3000L instantiations The examples given show the mapping between S1000D and S3000L covering the key concepts described at Para 2.1

3.1 Simple case

.

There are two types of simple case examples given.

S1003X-B6865-01003-00


Chap 9


3.1.1 Threshold equals, Repeat case The threshold equals, repeat case is a limit that triggers a task to be performed at a threshold that has a given value and the interval between the thresholds is equal (eg perform the task every 1000 flight hours). Refer to Table 2.

3.1.2 Threshold does not equal, Repeat The threshold does not equal, repeat case is a limit that triggers a task is be performed at thresholds that have given values and the intervals between them are not equal (eg perform the task at 5000 flight hours the first time and then every 1000 flight hours thereafter). Refer to Table 3.

3.2 One time only case The one time only case is a limit that triggers a task to be performed once when the threshold occurs (eg perform the task once at 2000 flight hours). Refer to Table 4.

3.3 Whichever comes first case The whichever comes first case is a limit that triggers a task to be performed at threshold "A" or threshold "B", whichever occurs first and then repeated at the next occurrence of threshold "A" or threshold "B", whichever occurs first (eg perform the task at 2000 flight hours or at the one year point, whichever comes first and repeat the task every 2000 flight hours or at the one year point whichever comes first). Refer to Table 5.

3.4 Sampling, repeat and threshold case The sampling, repeat and threshold case is a limit that triggers a task to be performed on a sample of the fleet at a given threshold and then repeated at regular thresholds on another sample or all of the fleet. (eg perform the task on 50% of the fleet at 2000 flight hours and at the next 2000 flight hours, perform the task on the remaining 50% and at the next 2000 flight hours, perform the task on all the fleet). Refer to Table 6.

3.5 Subsequent, repeat (trigger) case The subsequent, repeat (trigger) case is a limit that triggers a task to be performed at threshold "A", then repeated at every occurrence of that threshold until a given limit is reached. The task is then performed repeatedly at a threshold "B" (eg perform the task every 6000 miles until 30000 miles and then every 3000 miles thereafter). Refer to Table 7.

3.6 Multiple trigger case The multiple trigger case is a limit that triggers a task to be performed after a given number of a different task has been performed (perform the task at the 6th oil change). Refer to Table 8.

3.7 Threshold after trigger using threshold case The threshold after trigger using threshold case is a limit that triggers a task to be performed at a given threshold after a different task has been performed at its threshold (eg perform the task 500 miles after the brake check task that is performed every 3000 miles). Refer to Table 9.

3.8 Trigger and whichever comes first case The trigger and whichever comes first case is a limit that triggers a task to be performed at either a given threshold or after a given task (eg perform the task at 4000 flight hours or after the engine has been changed, whichever comes first). Refer to Table 10.

3.9 Threshold after trigger using references case The threshold after trigger using the element <refs> case is a limit that triggers a task to be performed at a given threshold after a different referenced task has been performed (eg perform the task at 6000 miles after the (refer to oil change) task). Refer to Table 11.

S1003X-B6865-01003-00


Chap 9


3.10 Subsequent repeat (limit range) case The subsequent repeat (limit range) case is a limit that triggers a task to be performed at every occurrence of threshold "A", until a given limit and then repeated at every occurrence of threshold "B" (eg perform the task every 8000 flight hours until 48000 flight hours and then repeat the same task every 4000 flight hours). Refer to Table 12.

3.11 More than one threshold case The more than one threshold case is when a limit triggers a task to be performed at threshold "A" and then the same task is performed at threshold "B", where both thresholds start from the same point (eg perform the task at 8000 flight hours. Perform the task again at 48000 flight hours (ie 40000 flight hours after the task is performed the first time)). Refer to Table 13.

3.12 Complex cases There are two types of complex case examples given.

3.12.1 Complex case, two groups case The complex case, two groups case is a limit that triggers a task to be performed after threshold "A" or threshold "B", whichever comes first.

The task is then performed repeatedly at every occurrence of threshold "C" or threshold "D", whichever come first until limit "1" or limit "2" is reached, whichever comes first.

The task is then performed repeatedly at every occurrence of threshold "E" or threshold "F", whichever comes first.

For example:

− Perform the task at 6000 miles or at the six month point (whichever comes first). − Repeat the same task at every 12000 miles or at every occurrence of the next one year

point (whichever comes first) until 50000 miles or the five year point (whichever comes first). − Then repeat the same task every 6000 miles or every occurrence of the next six month

point (whichever comes first).

Refer to Table 14.

3.12.2 Complex case with notes The complex case with notes is a limit that triggers a task to be performed at threshold "A" or threshold "B" and at either threshold a note is applied. The same task is then performed repeatedly at every occurrence of threshold "C" or every occurrence of threshold "D" or at the vendor’s recommendation. Refer to Table 15.

S1003X-B6865-01003-00


Chap 9


Table 2 Simple case - Threshold equals - Repeat

Threshold Repeat

1000 FH 1000 FH

Perform at 1000 flight hours and repeat every 1000 flight hours thereafter.

S1000D mapping S3000L mapping

<limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>1000</thresholdValue> </threshold> </limit>

An instance of Periodic_task_limit with no instance of initial_threshold, a repeat association with an associated instance of Repeat_task_limit which has a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "1000" and Unit = "Flight_hour".

0 1000 2000 3000 40000 1000 2000 3000 4000

S1003X-B6865-01003-00


Chap 9


Table 3 Simple case - Threshold does not equal - Repeat

Threshold Repeat

5000 FH 10000 FH

Perform at 5000 flight hours and repeat every 10000 flight hours thereafter.


<limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>5000</thresholdValue> </threshold> </limit>

<limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>10000</thresholdValue> </threshold> </limit>

An instance of Periodic_task_limit with an instance of initial_threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to Value = "5000" and Unit = "Flight_hour" and a repeat association with an associated instance of Repeat_task_limit which has a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "10000" and Unit = "Flight_hour".

0 5000 10000 15000 200000 5000 10000 15000 20000

S1003X-B6865-01003-00


Chap 9


Table 4 One time only

Threshold Repeat

2000 FH N/A

Perform at 2000 flight hours.


<limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>2000</thresholdValue> </threshold> </limit>

An instance of Discrete_task_limit with no instance of the trigger association and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "2000" and Unit = "Flight_hour".

0 2000 3000 4000 50000 2000 3000 4000 5000

S1003X-B6865-01003-00


Chap 9


Table 5 Whichever comes first

Version Threshold Repeat

1 2000 FH 2000 FH

1 1 YR 1 YR

Repeat at every 2000 flight hours or 1 year, whichever comes first.


<limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>2000</thresholdValue> </threshold> <threshold thresholdUnitOfMeasure="YR"> <thresholdValue>1</thresholdValue> </threshold> </limit>

An instance of Periodic_task_limit with no instance of initial_threshold and a repeat association with an associated instance of Repeat_task_limit which has two instances of threshold, ie two associated instances of Threshold_definition where the first instance is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "2000" and Unit = "Flight_hour". The second instance is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "1" and Unit = "Year".

0 2000 3000 4000 5000

0

FH

YR

1 2 3 4

0 2000 3000 4000 5000

0

FH

YR

1 2 3 41 2 3 4

S1003X-B6865-01003-00


Chap 9


Table 6 Sampling, repeat and threshold

Sampling Threshold Repeat 20% 4000 FH 8000 FH All 20000 FH 4000 FH

First check at 4000 FH on 20% on the fleet, then repeat at every 8000 flight cycles on 20% of the fleet, until 20000 flight hours for all the fleet after which repeat every 4000 flight hours on the whole fleet.


<limit limitTypeValue="PO">

<sampling>20</sampling> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>4000</thresholdValue> </threshold> </limit> <limit limitTypeValue="PE"> <sampling>20</sampling> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>8000</thresholdValue> </threshold> <limitRange> <limitRangeFrom> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>4000</thresholdValue> </threshold>

An instance of Periodic_task_limit with an associated instance of Sampling_by_ratio (which is a specialization of Sampling) with the attribute Sampling_method_by_ratio set to the value = "20" and Unit = "Percentage" and an initial_threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "4000" and Unit = "Flight_hour" and two instances of the repeat association, ie it has two associated instances of Repeat_task_limit where the first instance of Repeat_task_limit has a threshold which is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "8000" and Unit = "Flight_hour". The second Repeat_task_limit has a threshold which is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "4000" and Unit = "Flight_hour".

The two instances of Repeat_task_limit are associated with each other via an instance of Subsequent_repeat_relationship with the preceding association is associated with the first instance of Repeat_task_limit and the succeeding

0 4k 8k 12k 16kFH

20k 24k 28k 32k 36k

20% 100%

0 4k 8k 12k 16kFH

20k 24k 28k 32k 36k

20% 100%

S1003X-B6865-01003-00


Chap 9


<limitRangeto> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>20000</thresholdValue> </threshold> </limit> <limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>4000</thresholdValue> </threshold> <limitRange> <limitRangeFrom> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>20000</thresholdValue> </threshold> </limitRangeFrom> </limitRange> </limit>

association is associated with the second instance of Repeat_task_limit and the trigger association is associated with an instance of Parameter_threshold with the attribute Threshold_value set to the value = "20000" and Unit = "Flight_hour".

S1003X-B6865-01003-00


Chap 9


Table 7 Subsequent - Repeat (trigger)


1 8000 FH 8000 FH

2 48000 FH 4000FH

Repeat at every 8000 flight cycles until 48000 flight cycles after which repeat every 4000 flight cycles.


<limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue></threshold> <limitRange><limitRangeFrom> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>0</thresholdValue> <limitRangeto><threshold thresholdUnitOfMeasure="FH"> <thresholdValue>48000</thresholdValue></limit> <limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>4000</thresholdValue></threshold> <trigger releaseEvent="After"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>48000</thresholdValue> </threshold></trigger></limit>

An instance of Periodic_task_limit with no instance of initial_threshold and two instances of the repeat association, ie it has two associated instances of Repeat_task_limit where the first instance of Repeat_task_limit has a threshold which is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "8000" and Unit = "Flight_cycle". The second Repeat_task_limit has a threshold which is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "4000" and Unit = "Flight_cycle". The two instances of Repeat_task_limit are associated with each other via an instance of Subsequent_repeat_relationship where the preceding association is associated with the first instance of Repeat_task_limit. The succeeding association is associated with the second instance of Repeat_task_limitand the trigger association is associated with an instance of Parameter_threshold with the attribute Threshold_value set to the value = "48000" and Unit = "Flight_cycle".

0 8k 16k 24k 32k 40k 48k 56k 64k 72k0 8k 16k 24k 32k 40k 48k 56k 64k 72k

S1003X-B6865-01003-00


Chap 9


Table 8 Multiple trigger

Trigger Threshold Repeat

After 5 engine

changes

N/A N/A

Perform after 5 engine changes


<limit limitTypeValue="PO"> <trigger releaseEvent="After"> <threshold

thresholdUnitOfMeasure="Engine Change"> <thresholdValue>5</thresholdValue> </threshold> </trigger> </limit>

There are two alternative ways to represent this. The first is to make an implicit reference to the "Engine change" Task which is an instance of Discrete_task_limit with no instance of the trigger association and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "5" and Unit = "Engine_change". 2. Explicit reference to the "Engine change" Task (preferred) with an instance of Discrete_task_limit with no instance of the trigger association and a threshold where the Threshold_definition is an instance of Task_related_threshold which is associated with the instance of Task that describes the "Engine Change" and the attribute Event_threshold_number_of_event_occurrences set to the value = "5" (which is inherited from Event_threshold).

Engine changes................................Engine changes................................

S1003X-B6865-01003-00


Chap 9


Note If the example would have described "every fifth engine change" then use Periodic_task_limit

Table 9 Threshold after trigger using threshold


After engine

changes

10 Hrs N/A

Perform 10 hours after engine changes


<limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="Hours"> <thresholdValue>10</thresholdValue> <trigger releaseEvent="After"> <refs><dmRef>...dmc of Engine Change..> </trigger> </limit>

There are two alternative ways to represent this: 1. Implicit reference to the "Engine change" Task which is an instance of Discrete_task_limit with a trigger where the associated Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "1" and Unit = "Engine_change" and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute

Threshold_value set to the value = "10" and Unit = "Hour".

FC

10 Hours

Engine Change

FC

10 Hours

Engine Change

10 Hours

Engine Change

S1003X-B6865-01003-00


Chap 9


2. Explicit reference to the "Engine change" Task (preferred) which is an instance of Discrete_task_limit with a trigger where the associated Threshold_definition is an instance of Task_related_threshold which is associated with the instance of the Task that describes the "Engine Change". The attribute Event_threshold_number_of_event_occurrences is set to the value = "1" (which is inherited from Event_threshold) and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "10" and Unit = "Hour". Note If the example would have described "every fifth engine change" then use Periodic_task_limit.

Table 10 Trigger and whichever comes first

Trigger Threshold in trigger

Repeat

After engine

changes

40.000 FC N/A

Perform after 40000 flight cycles or 1 engine change, whichever comes first.


FC0 8k 16k 24k 32k 40k 48k 56k 64k 72k

FC0 8k 16k 24k 32k 40k 48k 56k 64k 72k

S1003X-B6865-01003-00


Chap 9


<limit limitTypeValue="PO"> <trigger releaseEvent="After"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>40000</thresholdValue> </trigger> <trigger releaseEvent="After"> <refs><dmRef>...dmc of Engine Change..> </trigger> </limit>

There are two alternative ways to represent this: 1. Implicit reference to the "Engine change" Task which is an instance of Discrete_task_limit with no instance of the trigger association and two instances of threshold association, ie it has two associated instances of Threshold_definition where the first instance of Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "1" and Unit = "Engine_change". The second instance of Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "40000" and Unit = "Flight_cycle". 2. Explicit reference to the "Engine change" Task (preferred) which is an instance of Discrete_task_limit with no instance of the trigger association and two instances of threshold association, ie it has two associated instances of Threshold_definition where the first instance of Threshold_definition is an instance of Task_related_threshold which is associated with the instance of the Task that describes the "Engine Change". The attribute Event_threshold_number_of_event_occurrences is set to the value = "1" (which is inherited from Event_threshold). The second instance of Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "40000" and Unit = "Flight_cycle".

Table 11 Threshold after trigger using <refs>

Perform 10 hours after engine change 10 Hours

Engine Change

10 Hours

Engine Change

S1003X-B6865-01003-00


Chap 9



After engine

changes

10 Hrs N/A


<limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="Hours"> <thresholdValue>10</thresholdValue> <trigger releaseEvent="After"> <refs>[engine change reference]</refs> </trigger> </limit>

An instance of Discrete_task_limit with a trigger where the associated Threshold_definition is an instance of Task_related_threshold which is associated with the instance of the Task that describes "Engine Change" and the attribute Event_threshold_number_of_event_occurrences set to the value = "1" (which is inherited from Event_threshold) and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value is set to the value = "10" and Unit = "Hour".

Table 12 Subsequent repeat (limrange)

Repeat at every 8000 flight cycles until 48000 flight cycles after which repeat every 4000 flight cycles

0 8k 16k 24k 32kFC

40k 48k 56k 64k 72k0 8k 16k 24k 32kFC

40k 48k 56k 64k 72k

S1003X-B6865-01003-00


Chap 9



1 8000 FC 8000 FC

2 48000 FC 4000 FC


<limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue> <limitRange> <limitRangeFrom> <threshold <thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue> <limitRangeto> <threshold <thresholdUnitOfMeasure="FC"> <thresholdValue>480000</thresholdValue> </limit> <limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>4000</thresholdValue></threshold> <limitRange> <limitRangeFrom> <threshold <thresholdUnitOfMeasure="FC"> <thresholdValue>48000</thresholdValue> </limit>

An instance of Periodic_task_limit with no instance of initial_threshold and two instances of the repeat association, ie it has two associated instances of Repeat_task_limit where the first instance of Repeat_task_limit has a threshold which is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "8000" and Unit = "Flight_cycle". The second Repeat_task_limit has a threshold which is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "4000" and Unit = "Flight_cycle". The two instances of Repeat_task_limit are associated with each other via an instance of Subsequent_repeat_relationship with the preceding association is associated with the first instance of Repeat_task_limit and the succeeding association is associated with the second instance of Repeat_task_limit The trigger association is associated with an instance of Parameter_threshold with the attribute Threshold_value set to the value = "48000" and Unit = "Flight_cycle". Note The same representation as defined under the example on "Subsequent Repeat (trigger) " above

S1003X-B6865-01003-00


Chap 9


Table 13 More than one threshold

Version Threshold -

1 8000 FC -

2 48000 FC -

Perform at 8000 flight cycles. Perform again at 48000 flight cycles.


<limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue> </threshold> </limit> <limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>48000</thresholdValue> </threshold> </limit>

Note The value "PO" of the attribute limitTypeValue of the element <limit> is always “from the beginning”

One instance of Discrete_task_limit with no instance of the trigger association and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "8000" and Unit = "Flight_cycles".

A second instance of Discrete_task_limit with no instance of the trigger association and a threshold where the Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "48000" and Unit = "Flight_cycles".

FC0 8k 16k 24k 32k 40k 48k 56k 64k 72k0 8k 16k 24k 32k 40k 48k 56k 64k 72k

S1003X-B6865-01003-00


Chap 9


Table 14 Complex case - Two groups


1 8000 FC 4000 FC

1 16000 FH 8000 FH

2 48000 FC 8000 FC

2 96000 FH 16000 FH

After 8000 flight cycles or 16000 flight hours (whichever comes first), repeat every 4000 flight cycles or 8000 flight hours (whichever comes first) until 48000 flight cycles or 96000 flight hours (whichever comes first), after which repeat every 8000 flight cycles or 16000 flight hours (whichever comes first).


<limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>4000</thresholdValue> </threshold> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>8000</thresholdValue> </threshold> <limitRange> <limitRangeFrom> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue> </threshold>

An instance of Periodic_task_limit with two instances of initial_threshold associations, ie two associated instances of Threshold_definition where the first instance is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "8000" and Unit = "Flight_cycle".

The second instance is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "16000" and Unit = "Flight_hour".

Two instances of the repeat association, ie the Periodic_task_limit has two associated instances of Repeat_task_limit where the first instance of Repeat_task_limit has two instances of the threshold association, ie it has two associated instances of Threshold_definition where the first instance of

0 8k 16k 24k 32kFC

40k 48k 56k 64k 72k

0 16k 32k 48k 64k 80k 96k 112k 128k 144k

0 8k 16k 24k 32kFC

40k 48k 56k 64k 72k

0 16k 32k 48k 64k 80k 96k 112k 128k 144k

S1003X-B6865-01003-00


Chap 9


</limitRangeFrom> <limitRangeto> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>480000</thresholdValue> </threshold> </limitRangeto> <limitRange> <limitRangeFrom> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>16000</thresholdValue> </threshold> </limitRangeFrom> <limitRangeto> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>960000</thresholdValue> </threshold> </limitRangeto> </limitRange> </limit> <limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue> </threshold> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>16000</thresholdValue> </threshold> <limitRange> <limitRangeFrom> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>48000</thresholdValue> </threshold> </limitRangeFrom>

Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "4000" and Unit = "Flight_cycle".

The second instance of Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "8000" and Unit = "Flight_hour".

The second instance of Repeat_task_limit has two instances of the threshold association, ie it has two associated instances of Threshold_definition where the first instance of Threshold_definition is an instance of Parameter_threshold withthe attribute Threshold_value set to the value = "8000" and Unit = "Flight_cycle".


The two instances of Repeat_task_limit are associated with each other via an instance of Subsequent_repeat_relationship where the preceding association is associated with the first instance of Repeat_task_limit. The succeeding association is associated with the second instance of Repeat_task_limit There are two instances of the trigger association ie the Subsequent_repeat_relationship has two associated instances of Threshold_definition where the first instance of Threshold_definition is an instance of Parameter_threshold with the attribute Threshold_value set to the value = "48000" and Unit = "Flight_cycle".


S1003X-B6865-01003-00


Chap 9


</limitRange> <limitRange> <limitRangeFrom> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>96000</thresholdValue> </threshold> </limit>

Note Neither the element <limrange> nor the element <trigger> are repeatable elements so cannot express two version groupings.

Table 15 Complex case with notes


1 8000 F C 4000 F C

1 1 6 0 0 0 F H 8 0 0 0 F H

1 A N D N O T E 1 O R V R

First check at 8000 FC or 16000 FH and apply NOTE 1, then repeat at every 4000 flight cycles or 8000 flight hours or according to Vendor Recommendation. 0 4k 8k 12k 16k

FC20k 24k 28k 32k 36k

0 8k 16k 24k 32kFH

40k 48k 56k 64k 72kAND NOTE 1 OR VR OR VR OR VR OR VR OR VR OR VR OR VR

0 4k 8k 12k 16kFC

20k 24k 28k 32k 36k

0 8k 16k 24k 32kFH

40k 48k 56k 64k 72kAND NOTE 1 OR VR OR VR OR VR OR VR OR VR OR VR OR VR

S1003X-B6865-01003-00


Chap 9



<limit limitTypeValue="PO"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>8000</thresholdValue> </threshold> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>16000</thresholdValue> </threshold> </limit> <limit limitTypeValue ="PO"> <remarks> <simplePara>NOTE 1</simplePara> </remarks> </limit> <limit limitTypeValue="PE"> <threshold thresholdUnitOfMeasure="FC"> <thresholdValue>4000</thresholdValue> </threshold> <threshold thresholdUnitOfMeasure="FH"> <thresholdValue>8000</thresholdValue> </threshold> <remarks> <simplePara>EG</simplePara> </remarks> </limit>

Note There is currently no way to represent Threshold_definition as textual description in S3000L.

End of data module