You are on page 1of 50

Ministry of Defence

Defence Standard 00-44


Issue 1 Publication Date 31 January 2007

Reliability and Maintainability


Data Collection and Classification
DEF STAN 00-44 Issue 1

Contents

Foreword ..........................................................................................................................................................iv
Introduction.......................................................................................................................................................v
1 Scope ....................................................................................................................................................1
2 Warning.................................................................................................................................................1
3 Normative References .........................................................................................................................1
4 Definitions.............................................................................................................................................2
SECTION 2 DATA COLLECTION, INCIDENT SENTENCING AND DATA CLASSIFICATION ......................3
5 Data Collection .....................................................................................................................................3
6 Incident Sentencing.............................................................................................................................3
6.1 Introduction ......................................................................................................................................3
6.2 Incident Sentencing Methodology .................................................................................................4
6.3 Incident Sentencing Committee (ISC)............................................................................................5
6.4 Managerial Responsibilities ...........................................................................................................5
6.5 Advantages of Incident Sentencing...............................................................................................5
7 Data Classification...............................................................................................................................6
7.4 Cause ................................................................................................................................................6
7.5 Significance......................................................................................................................................6
7.6 Frequency.........................................................................................................................................7
7.7 Chargeability ....................................................................................................................................7
8 Investigation and Remedial Action ....................................................................................................7
Annex A Incident Sentencing - Sea .............................................................................................................8
A.1 Introduction ......................................................................................................................................8
A.2 Foreword...........................................................................................................................................8
A.3 Tailoring Of Codes.........................................................................................................................10
A.4 Incident Sentencing Procedure....................................................................................................10
A.5 Mission Codes................................................................................................................................10
A.6 Corrective Action Codes ...............................................................................................................11
A.7 Cause/Activity Codes ....................................................................................................................12
A.8 Chargeability Codes ......................................................................................................................17
Annex B Incident Sentencing - Land ............................................................................................................19
B.1 Introduction ....................................................................................................................................19
B.2 Foreword.........................................................................................................................................19
B.3 Tailoring of Codes .........................................................................................................................21
B.4 Incident Sentencing Procedure....................................................................................................21
B.5 Mission Codes................................................................................................................................24
B.6 Corrective Action Codes ...............................................................................................................25
B.7 Cause/Activity Codes ....................................................................................................................26
Unclassified
ii
DEF STAN 00-44 Issue 1

Annex C Incident Sentencing - Air................................................................................................................32


C.1 Introduction ....................................................................................................................................32
C.2 Foreword.........................................................................................................................................32
C.3 Incident Sentencing Procedure....................................................................................................34
C.4 Mission Codes................................................................................................................................35
C.5 Maintenance Codes .......................................................................................................................36
C.6 Attributability Codes .....................................................................................................................37
C.7 Cause/Activity Codes ....................................................................................................................37

Figures

Figure 1 Sentencing Steps Flow Chart - Land ..........................................................................................23

Tables

Table 1 Incident Sentencing Codes - Sea ..................................................................................................9


Table 2 Incident Sentencing Codes - Land ..............................................................................................20
Table 3 Incident Sentencing Codes - Air..................................................................................................33

Unclassified
iii
DEF STAN 00-44 Issue 1

Foreword
AMENDMENT RECORD

Amd No Date Text Affected Signature and Date

REVISION NOTE

This standard is raised to Issue 1 to update its content.

HISTORICAL RECORD

This standard supersedes the following:

Def Stan 05-59 Issue 2 dated 28 November1988

Def Stan 05-63 Issue 1 dated 18 October 1984

Def Stan 00-44 (Part 1) Issue 2 dated 9 June 1995

Def Stan 00-44 (Part 2) Issue 1 dated 29 April 1994

Def Stan 00-44 (Part 3) Issue 1 dated 29 August 1997

Def Stan 00-44 (Part 4) Issue 1 dated 10 September 1995

a) This standard provides requirements for MOD practices and procedures for, and provides guidance to
the MOD for, the collection and classification of Reliability and Maintainability (R&M) data. This standard
addresses data classification and incident sentencing in general, both within the MOD and/or MOD
contracts.

b) This standard has been produced on behalf of the Defence Material Standardization Committee (DMSC)
by Committee for Defence Equipment Reliability and Maintainability (CODERM) and reflects the
conclusions of consultants among the relevant authorities within the MOD and within Industry

c) This standard has been agreed by the authorities concerned with its use and is intended to be used
whenever relevant in all future designs, contracts, orders etc. and whenever practicable by amendment
to those already in existence. If any difficulty arises which prevents application of the Defence Standard,
UK Defence Standardization (DStan) shall be informed so that a remedy may be sought.

d) Any enquiries regarding this standard in relation to an invitation to tender or a contract in which it is
incorporated are to be addressed to the responsible technical or supervising authority named in the
invitation to tender or contract.

e) Compliance with this Defence Standard shall not in itself relieve any person from any legal obligations
imposed upon them.

f) This standard has been devised solely for the use of the Ministry of Defence (MOD) and its contractors
in the execution of contracts for the MOD. To the extent permitted by law, the MOD hereby excludes all
liability whatsoever and howsoever arising (including, but without limitation, liability resulting from
negligence) for any loss or damage however caused when the standard is used for any other purpose.

Unclassified
iv
DEF STAN 00-44 Issue 1

Introduction
In the procurement of Defence equipment, emphasis is being placed on the capability and achievement of
R&M requirements, in order to realise better availability and reduced life-cycle costs. An important element to
achieve this is the assessment of the achieved R&M during the design, development, production and in-
service phases, both to monitor progress, and for contractual purposes. R&M characteristics are assessed
using a system for collecting, sentencing and classifying incident data.

In accordance with Defence Standard 00-40 Pt 1 “The Supplier shall establish and maintain a Data
Reporting, Analysis and Corrective Action System (DRACAS) throughout the design, development and
production phases of the contract. The system shall be a documented closed-loop system for reporting,
collecting, recording, analysing, categorising, and investigating data and taking timely, effective corrective
action. A DRACAS shall be applied to all non-conformances and failures relating to design, manufacturing
and test processes that occur during any project activity whether conducted at the premises of the contractor
or elsewhere. Operational and usage data, together with operating conditions, shall also be recorded.”

The content of this standard addresses the incident data collection, analysis and classification requirements
of the above requirement.

An incident (defined in Defence Standard 00-49) is defined as “any event indicating a possible non-
conformance with the specification” and therefore includes observations, maintenance actions, defects and
failures. Incidents are recorded in an R&M data recording system which includes all usage and incident data.

Incident sentencing is the first part of the data classification process in which the raw incident data is
allocated a summary code according to defined rules and criteria. Data classification is then carried out, in
which sentenced incident data is sorted into different categories, (e.g. cause, significance, maintenance
requirement, etc) applicable to the R&M parameters being assessed. Data classification may however be
undertaken as a one stage process of reviewing raw incident data and sorting it into the required categories.
However, the two stage process has the advantage that different classifications are readily obtained without
the need to re-examine the raw incident data.

During the design, development and production phases the collection, sentencing and classification of
incident data is commonly carried out by the contractors, upon which, they will carry out the required
corrective action. Equally important is the requirement to assess and where necessary restore the reliability
of equipment in-service where weaknesses have not been detected before delivery. To enable the
assessment of incidents of in-Service equipment, it is necessary to have feedback of data from the user. The
results of such assessments should also be used as a feedback into the design and development of next
generation equipment so as to avoid similar conditions in future equipments.

Each of the Services has a comprehensive in-service incident reporting and R&M data recording system
which has been developed to meet its own specific requirements. Although these systems differ in detail,
each aims to provide data which can be used to form a basis for deciding on corrective action, data for
reliability studies and maintenance data for resource management. Alternatively, it may be more appropriate
for the contractor to manage the process and therefore to continue with the R&M data recording system and
sentencing and classifying process used during the previous phases of the procurement.

The purpose of this Defence Standard is to provide guidance on the collection of incident data and describes
the MOD incident sentencing and classification methodology which shall be used for MOD procurement
programmes. This Standard is intended to be part of the contractual documentation of a project and should
be referenced in the appropriate documents.

Unclassified
v
DEF STAN 00-44 Issue 1

This page Intentionally left blank

Unclassified
vi
DEF STAN 00-44 Issue 1

Reliability and Maintainability Data Collection and


Classification

1 Scope

1.1 This Standard provides general guidance for the collection of R&M data and describes, in general, the
common aspects of data classification and incident sentencing to be used within the MOD and on MOD
contracts.

1.2 Guidance is given on the data reporting necessary to support data classification and incident
sentencing. The classifications (categories) noted in Def Stan 00-40 (Part 1) are defined.

1.3 Guidance is given on incident sentencing and the use of a summary code. The role of the Incident
Sentencing Committee (ISC) within the R&M Panel system is described.

1.4 Where standard methods for incident sentencing have been adopted they are detailed in the Standard
and are available to MOD departments. This Standard can thus be used in contracting for R&M.

1.5 This Standard defines and describes the standardized methodology applicable to MOD equipment for
sentencing incidents arising where information is gathered for MOD R&M purposes. The methodology is
applicable to procurement programmes, whether within the MOD or contracted, and to in-service R&M
assessment programmes. A standardized approach has been adopted because equipments are rarely used
in isolation, and it is often necessary to compare or use results from the R&M assessment of more than one
equipment and/or source. Standardization has the further advantage of consistency of approach which is to
the mutual benefit of the MOD and its contractors.

1.6 This Standard does not seek to replace contractors’ own data coding methodologies for identifying
incidents or fault conditions/patterns or failure modes. Such methodologies are as diverse as the equipment
the MOD procures and are usually aimed at providing information for the internal use of that contractor.

2 Warning
The Ministry of Defence (MOD), like its contractors, is subject to both United Kingdom and European laws
regarding Health and Safety at Work. All Defence Standards either directly or indirectly invoke the use of
processes and procedures that could be injurious to health if adequate precautions are not taken. Defence
Standards or their use in no way absolves users from complying with statutory and legal requirements
relating to Health and Safety at Work.

3 Normative References

3.1 The publications shown below are referred to in the text of this standard. Publications are grouped and
listed in alpha-numeric order.

Def Stan 00-40 Reliability & Maintainability

Part 1 (ARMP-1) Management Responsibilities and Requirements for Programmes and Plans

Part 2 (ARMP-2) General Application Guidance on the Use of Part 1 (ARMP-1)

Def Stan 00-41 Reliability and Maintainability MOD Guide to Practices and Procedures

Def Stan 00-43 Reliability and Maintainability Assurance Activity


Unclassified
1
DEF STAN 00-44 Issue 1

Part 1: In-Service Reliability Demonstrations


Part 2: Maintainability Demonstrations

Def Stan 00-49 Reliability & Maintainability MOD Guide to Terminology Definitions

Def Stan 21-16 Requirements for the In-Service Collection and Analysis of ARM Data for Naval
Systems

3.2 Reference in this Standard to any normative references means in any Invitation to Tender or contract
the edition and all amendments current at the date of such tender or contract unless a specific edition is
indicated.

3.3 In consideration of clause 3.2 above, users shall be fully aware of the issue and amendment status of
all normative references, particularly when forming part of an Invitation to Tender or contract. Responsibility
for the correct application of standards rests with users.

3.4 DStan can advise regarding where normative references documents are obtained from. Requests for
such information can be made to the DStan Helpdesk. How to contact the helpdesk is shown on the outside
rear cover of Def Stans.

4 Definitions

4.1 For the purpose of this Defence Standard the definitions given in Def Stan 00-49 apply, together with
the following:

4.1.1 Failure: A failure is an event that prevents the equipment from performing within previously specified
limits.

4.1.2 Observation: Technical observations from hands-on personnel are used for keeping a record of
problems which are not defects or failures in their own right. For example, an item may be superficially
degraded but still fully capable of operating satisfactorily. These records are useful in anticipating failures
from progressive, worsening conditions. The observation of a degradation condition may initiate a design
review, even though failure has not arisen.

4.1.3 Test or Trial: The terms test or trial are used to denote any exercise used to provide data for the
estimation of equipment R&M. Examples include, but are not limited to, development trials, reliability
qualification tests (RQT), performance tests and in-service reliability demonstrations (ISRDs).

4.2 For the purposes of this Part of the Standard the term “equipment” is used for convenience. It should
be interpreted to mean the appropriate level of platform/ system/subsystem/equipment being considered.

NOTE To be consistent with the Def Stan 00-40 through 00-49 Series of Standards, the abbreviation “R&M” has
been used in this Def Stan, albeit that the acronym “ARM”, for Availability, Reliability & Maintainability, is more commonly
used in the Royal Navy.

Unclassified
2
DEF STAN 00-44 Issue 1

SECTION 2 DATA COLLECTION, INCIDENT SENTENCING AND DATA


CLASSIFICATION

5 Data Collection

5.1 The information required for incident sentencing and then data classification is provided through the
use of an R&M data recording system that should record all usage and incident data. Incident data is defined
as any event indicating a possible non-conformance with the specification. Both usage and incident data
comprise a variety of individual data elements which need to be recorded and may also report actions such
as modifications, and scheduled and preventative maintenance. Each incident shall be identified with a
unique reference. The scope and method by which these data are to be collected should be fully defined
before data collection commences.

5.2 An example of existing R&M Data recording systems is TRANMAN, a commercially available fleet
management tool. For In-service use, JAMES1 (Joint Asset Management and Engineering System 1) is the
preferred tool, and will likely replace TRANMAN. These tools typically interface with proprietary In Service
Management Systems (ISMS) and facilitate DRACAS.

5.3 Care should be taken when assessing the R&M characteristics of equipment, to ensure that the actual
equipment data is collected and not the host equipment/system data.

5.4 When selecting data for collection, the appropriate metric must be defined in order to preserve the
integrity of the derived reliability information. Selection of an inappropriate metric will severely affect the
perceived system reliability. Some examples of metrics currently in use are:

a) Operating hours

b) Elapsed time

c) Flying hours

d) Cycles

e) Distance

f) Calendar

g) Environment

5.5 As data collection can be a time consuming task, reporting forms should be kept simple and
unambiguous, and the use of automatic data capture methods, elapsed time indicators, etc are
recommended where they can be shown to be cost effective.

5.6 Each service has its own set of defect reporting regulations and procedures. The appropriate service
regulations and procedures should be considered when determining the approach to defect reporting in-
service. It may however be more appropriate to continue with the R&M data recording system used during
the previous phases of the procurement. This decision should be made as early as possible.

6 Incident Sentencing

6.1 Introduction

6.1.1 This section describes the incident sentencing methodology, its purpose and how it simplifies and
improves the process of data classification.

6.1.2 R&M programmes generate large amounts of incident data which requires quick and accurate
assessment. The process is simplified by dividing it into two stages, the first being to sort the raw incident
Unclassified
3
DEF STAN 00-44 Issue 1

data according to formal sentencing rules, and the second to classify the sentenced incident data into the
required categories for R&M assessment.

6.1.3 Incident sentencing involves the allocation of a summary code to all recorded incidents using a
formal procedure. The sentence summarises the incident according to defined rules and failure criteria which
are derived from the System Requirement Document (SRD). For the detailed sentencing process applicable
to each of Land, Sea and Air see annexes A, B and C respectively. For other purposes such as project
management, both for the contractor or the purchaser, it may be desirable to summarise additional data and
this can be done with additional codes. To avoid confusion, these additional codes should be kept separate.

6.1.4 Failure criteria need to be established for each equipment being considered and when the R&M
parameters being assessed are subject to contract action they should be stated in the contract.

6.1.5 Specific failure criteria should be applied to individual systems, and each system shall have its
system boundary defined. In the case of complex systems, particularly those that have redundancy and
where the sub-systems are geographically spread or able to be configured in various ways, the system
should be broken down into smaller, more readily understood subsystems. These sub-systems may then be
sentenced and assessed individually, and subsequently modelled to obtain the reliability of the complete
system.

6.1.6 The incident sentencing methodology described in this part of the Standard is, in general, applicable
to any equipment operated and maintained by any personnel under any conditions. It is necessary that the
methodology be expressed in this way as the MOD operates a wide range of equipment in many different
ways and it allows the methodology and its attendant terminology to be readily adapted to suit the needs of
any project.

6.2 Incident Sentencing Methodology

6.2.1 The sentencing of incidents is a relatively simple matter where the considerations are entirely
objective, but becomes more complex where subjective judgments have to be made.

6.2.2 Incident sentencing is typically completed in two stages, preliminary and formal:

a) Preliminary sentencing is usually undertaken by the data collection authority and involves the initial
allocation of an incident sentencing code at the same time as the data is incorporated into the
equipment/project database see paragraph 5.2. This preliminary sentence, assigned by the data
collection authority, does not constitute an authoritative codification because it is based solely on the
judgement of an individual and, usually, on incomplete information.

b) Formal sentencing is normally carried out by the Incident Sentencing Committee (ISC) see clause 6.3.
Nevertheless, the allocation of a preliminary sentence to all incidents is a useful expedient for reducing
discussion on routine incidents where the sentencing code is clear, and is a useful start to discussion
enabling the ISC to concentrate on matters where the coding is unclear or contentious.

6.2.3 As a project develops it will become apparent that certain incidents will, if the sentencing is
consistent, always be ascribed a common coding. It is good practice to keep a list of these codes in a
Precedence List. This will make for quick and consistent coding at the ISC, although care needs to be
exercised to ensure that the precedent is relevant to the incident in question.

6.2.4 The incident sentencing methodology should be tailored as necessary to suit the project. Tailoring of
Codes is described in detail in each of the annexes A, B and C It is essential that the tailored incident
sentencing methodology should be fully defined and made available to all stakeholders before data collection
commences in order to avoid conflict of opinions on the interpretation of incident data.

6.2.5 Detailed explanations of the incident sentencing methodologies used in the three Branches of the
MOD can be found in the following Annexes:

a) Annex A of this Standard addresses incident sentencing for MOD Sea Systems equipment during
development under MOD contracts and in-service within the MOD.

b) Annex B of the Standard addresses incident sentencing for MOD Land Systems equipment during
development under MOD contracts and in-service within the MOD.
Unclassified
4
DEF STAN 00-44 Issue 1

c) Annex C of the Standard addresses incident sentencing for Air Systems equipment during development
under MOD contracts and in-service within the MOD.

6.3 Incident Sentencing Committee (ISC)

6.3.1 Where the assessed R&M characteristics have contractual implications an ISC is the most effective
method of sentencing incidents.

6.3.2 The ISC should be a multi-disciplinary team (e.g. design, maintenance, operations and quality) and
should include representatives from the prime contractor, the design authority, MOD project management,
R&M advisers and the user. The exact composition of an ISC will vary, but it is vital to ensure that adequate
expertise is available to enable informed discussion and thereby to ensure that incidents are correctly
sentenced.

6.3.3 The prime function of an ISC is to examine and sentence all incidents. The ISC may also revise
previously sentenced incidents in response to new information; in part the committee does this by instigating
investigations into the causes of failures. The composition and terms of reference of an ISC should be
agreed at the beginning of a project and specified in the R&M plan. It is important that the members become
familiar, not only with the general rules and procedures for sentencing incident data, but also with the project
specific information. Such information might include the system boundary, failure definition, and tailoring of
the incident sentencing methodology for the specific project.

6.3.4 Once incidents have been formally sentenced, the sentence can only be changed by the ISC and/or
the R&M Panel. Incidents that have been sentenced by the ISC are submitted to the R&M Panel for
ratification.

6.3.5 ISC meetings should be an open forum for discussion of all facts relating to the incidents being
sentenced, and should invite contributions from all members. The Chairman of the ISC shall, normally, be a
member of the MOD project management team. Sentencing is facilitated by observing the following:

a) The ISC should have adequate representation and authority, and contain adequate technical expertise;

b) The sentencing procedures should be familiar to and understood by all members of the ISC.

6.3.6 Formal voting is not used in incident sentencing. Where a consensus cannot be reached then
sentencing may be deferred if further investigation is required. If a consensus still cannot be reached then
the incident should be sentenced by the Chairman; and the MOD Project Manager shall be advised
accordingly.

6.3.7 Referring incidents to the R&M Panel for sentencing is not recommended and should be rarely used.
In general, the ISC is better fitted to sentence incidents.

6.4 Managerial Responsibilities

6.4.1 Ultimate responsibility for data classification and incident sentencing lies with the MOD Project
Manager, who generally delegates it to the R&M Panel and thence to the ISC.

6.4.2 The managerial responsibilities and requirements in contracting for R&M shall be carried out in
accordance with responsibilities listed in Def Stan 00-40 (Part 1) (ARMP- 1). This may require the contractor
to establish and maintain a Data Reporting, Analysis and Corrective Action System (DRACAS). The need for
a standardized approach to incident sentencing is met by calling up the appropriate clauses of Def Stan 00-
41 (Clause 25 DRACAS) for inclusion in the contractor’s DRACAS for the contracted R&M programme.

6.5 Advantages of Incident Sentencing

6.5.1 The advantages of using codes to summarise incident data are:

a) The implications of the incident are determined by addressing clearly defined questions;

Unclassified
5
DEF STAN 00-44 Issue 1

b) The FRB/ISC must be impartial and where consensus is achieved, resulting codes are impartial. Where
a consensus is not reached the MoD Chairman would refer the incident to the R&M Panel, although this
is not recommended and should rarely be used;

c) By using a formal system, reasons for classification can be traced;

d) Use of a formal system ensures standardization which permits the use of results from different tests and
sources;

e) Allows many classifications to be made by sorting combinations of the summary code.

7 Data Classification

7.1 Data classification is a general term used to describe the process by which incidents are examined
and classified for the purpose of R&M assessment. It is performed to quantify R&M from the recorded data in
accordance with defined criteria such as those set out in an R&M plan. R&M assessment is a separate and
subsequent exercise from data classification. Data classification should allow trends to be identified, by
categorising failures by both the failed part and the failure mode.

7.2 Defence Standard 00-40 Pt 1 states “The Supplier shall prepare and structure a data classification
system to ensure that all events, such as non-conformances and failures are accurately and completely
categorised as to cause, criticality/significance, environment, frequency and chargeability. The Supplier shall
agree the criteria for the classification of data with the Purchaser at the outset of the design.”

7.3 Equipments are rarely used in isolation, and it is often necessary to directly compare, or use, data
from more than one equipment and/or source. Consequently, it is desirable that a common method of data
classification is used. Of equal importance is the need to use a viable system that can be contractually
enforced.

7.4 Cause

7.4.1 In all phases of a project it is essential that every effort is made to establish the exact cause of an
incident, and that all data relating to the incident are recorded. It is only by the thorough investigation of an
incident that problems can be highlighted and the necessary corrective action taken. Typical failure causes
are listed below - this list is not exhaustive:

a) Inadequacy of design;

b) Quality of manufacture;

c) Inadequate procedures;

d) No fault found;

e) Human error (operator or maintainer);

f) Secondary failure.

7.5 Significance

7.5.1 The effect that an incident has upon the performance of equipment determines its significance. The
two most important categories of significance are mission and basic failures. An incident that prevents
equipment from performing one or more of its mission essential functions may be categorised as a mission
failure. An incident that requires corrective maintenance may fall into the category of basic failure. Generally,
mission failures are also counted as basic failures. The criteria for establishing significance should be
defined before data recording commences, especially regarding safety critical failures which may not always
prevent equipment from performing one or more of its mission essential functions yet are regarded as
significant incidents.

Unclassified
6
DEF STAN 00-44 Issue 1

7.6 Frequency

7.6.1 It is the frequency with which failures occur that is used to establish failure rates, to assess reliability
growth and to establish reliability levels. To do this each incident needs to be uniquely recorded in such a
manner that an accurate count of failures can be made. Care should be taken to ensure that individual
failures are not counted more than once as a result of related incidents, e.g. repair. It should be noted that in
this context frequency means the sum of all failures of an item not the sum of the failure modes.

7.7 Chargeability

7.7.1 This is primarily concerned with establishing which incidents are attributable to aspects of the project
for which the contractor is responsible. This includes all aspects of design, manufacture, operation and
maintenance of items produced by the contractor including Contractor Furnished Equipment (CFE). A
contractor would not normally be responsible for Government Furnished Equipment (GFE), excepting
interfaces and any detrimental effect that installation has on R&M of the GFE. The criteria for establishing
chargeability should be defined before data recording commences.

8 Investigation and Remedial Action

8.1 In general, investigations are carried out under contract. For the Army, the majority of investigations
are carried out by the design authority following initial investigation by the relevant REME equipment branch.

8.2 After completion of their investigation, the contractor or the MOD will propose remedial measures to
prevent recurrence of the condition or measures to alleviate the effects. This solution may involve a change
in operating or maintenance procedure or, more often, a modification to improve or replace items related to
the defect/failure/fault. The procedures for proposal, design, proving and promulgation of modifications again
vary from Service to Service.

Unclassified
7
DEF STAN 00-44 Issue 1

Annex A
Incident Sentencing - Sea

A.1 Introduction
This section provides comprehensive guidance on the rules, terminology and definitions which are
acceptable and appropriate to the sentencing of incident data arising in the Sea Systems.

A.2 Foreword

A.2.1 Incident sentencing involves the allocation of a summary coding (the incident sentencing code) to
all recorded incidents. The incident sentencing code comprises four alpha-numeric characters and each
character represents a different criterion identified from the incident data. Allocation of these codes requires
objective assessment of each incident according to these criteria and allows the relevance of each incident
to any R&M assessment to be determined. The four criteria are identified below:

a) First Character: MISSION CODE: This code summarises the implications of an incident on the mission
capability of the equipment.

b) Second Character: CORRECTIVE ACTION CODE: This code identifies whether or not corrective
action is required, and, for a shipborne equipment, whether or not it is repairable at sea or alternatively
whether it is shore-based.

NOTE The term “Corrective Action” has been used in this Standard to take account of software incidents. If an
equipment becomes unavailable due to a software problem, even if for only a short period prior to reset, this counts as a
corrective action for R&M analysis purposes and shall be recorded.

c) Third Character: CAUSE/ACTIVITY CODE: This code summarises either the cause of an incident or
the nature of a reported activity, e.g. scheduled maintenance.

d) Fourth Character: CHARGEABILITY CODE: This code summarises whether or not the incident is
chargeable to the contractor(s), as governed by the wording of the contract or ground rules for the
assessment. The term chargeability has no direct financial connotation.

A.2.2 This degree of coding represents the minimum level of information required to codify the basic
criteria of an incident. Strings of more than four characters are capable of coding incidents according to
additional criteria. This extra information maybe desirable, e.g. for contractor’s project management
purposes, but it does not form an essential part of an incident sentencing code and, if required, shall be
recorded using additional characters rather than by adapting these four characters.

A.2.3 The sentencing codes and their corresponding descriptions are shown in Table 1. Detailed
explanations of each code, and rules of application, are given in clauses A.5 to A.8. These codes are
generally applicable to all types of equipment regardless of their role. Adaptation of the codes for specific
projects is dealt within clause A 3, Tailoring of Codes.

A.2.4 The sentencing codes are written as a serial without breaks e.g. 1RAC.

A.2.5 Failures and defects are identified by examination of the sentencing codes. Failures are denoted by
a sentencing code with letters in the first and third character positions. Defects are denoted by a sentencing
code with letters in the second and third character positions. Defects include all failures that require
corrective action, i.e. that have a letter in the second and third character positions. A chargeable failure or
defect is denoted by a failure or defect, as defined above, and a letter in the fourth character.

Unclassified
8
First Character Second Character Third Character Fourth Character

Mission Code Clause Corrective Action Code Clause Cause/Activity Code Clause Chargeability Code Clause

A Non-Missionworthy A5.2 R Repairable at Sea A6.2 A Hardware Problem A7.2 C Chargeable A8.2
B Missionworthy, Impaired A5.3 N Non-Repairable at Sea A6.3 B Software Problem A7.3
S Shore-Based Equipment A6.4 D Hardware Change A7.4 1 Non-Chargeable A8.3
Table 1 Incident Sentencing Codes - Sea

1 Missionworthy A5.4 V Undefined A6.5 E Software Change A7.5 2 Unresolved A8.4


F Not Established A7.6
1 No Corrective Action A6.6 G Pre-Life Failure A7.7
H Inadequate Procedures A7.8
Unclassified

J Inadequate Installation A7.9


N No Fault Found A7.10
V Under Investigation A7.11

1 Accident/Human Error A7.12


2 Secondary Event A7.13
3 Post-Life Failure A7.14
6 Scheduled Maintenance A7.15

DEF STAN 00-44 Issue 1


7 Recording Action A7.16
9
DEF STAN 00-44 Issue 1

A.3 Tailoring Of Codes

A.3.1 The incident sentencing methodology described in this Standard is applicable to all types of
equipment. However, the incident sentencing codes (listed in Table 1) may cover too wide a range or not
cover all the needs of a project. This can be overcome by tailoring the codes to suit the particular project,
R&M requirement and/or equipment. It would be impracticable to note all of the possible code permutations
here but further guidance and some essential rules are given below.

A.3.2 Tailoring of codes shall be done through the R&M Panel, as part of the production of the project’s
R&M Plan, and shall be agreed with all parties before the commencement of R&M testing. Advice shall be
sought from the relevant MOD R&M specialists before any changes to the incident sentencing codes are
made.

A.3.3 When codes are added, the existing format shall be adhered to, ie where letters indicate
significance in the assessment of R&M and numbers do not. An example of when additional codes might be
required is where multiple contractors, rather than a single prime contractor, are involved. In this case,
further letters may be added in the fourth character position to denote the various contractors. Although the
meaning of existing codes and their associated characters shall not be changed, alteration of titles to make
them project specific is permissible.

A.4 Incident Sentencing Procedure

A.4.1 To sentence incidents the following are required:

a) A definition of failure (and, if appropriate, fault and/or defect) for each equipment being considered;

b) The system boundary for each equipment being considered (and, later, a model of the complete
equipment may be required to calculate higher system level reliability);

c) A definition of what incidents are chargeable as governed by the wording of the contractor ground rules
for the trial;

d) All available information about every incident, including the equipment elapsed time;

e) Maintenance records and build standard information;

f) Terms of Reference and composition of the ISC to undertake the sentencing procedure;

g) A project specific Incident Sentencing Handbook, if necessary;

h) A means of storing the data and the sentencing codes given.

A.4.2 The sentencing of incidents is a relatively simple matter where the considerations are entirely
objective, but becomes more complex where subjective judgments have to be made. The subjective
allocation of the mission code is avoided by ensuring that the mission failure criteria are fully defined before
the start of the project and relate to performance requirements.

A.4.3 There is no single “sentencing procedure”. At an early stage it maybe helpful to follow a number of
pre-determined decision steps but very often familiarity with an equipment and the R&M requirements will
enable a sentencing code to be assigned without following a formal procedure. The sentencing codes are
then assigned by referring to the detailed explanations provided in clauses A.5 to A.8.

A.5 Mission Codes

A.5.1 The mission code is the first character in the incident sentencing code and represents the
operational capability of the equipment immediately after the incident occurred. The mission code is
instrumental in determining failure significance of the equipment. The definitions given below are typical
Unclassified
10
DEF STAN 00-44 Issue 1

examples. For each particular project the failure definitions to be used shall be specified in the contractual
documentation or ground rules for the assessment.

A.5.2 MISSION CODE A: NON-MISSIONWORTHY

A.5.2.1 The equipment is Non-Missionworthy if it is unable to continue its mission and fulfil and sustain all
mission essential functions specified in the contractual documentation or ground rules for the assessment.

A.5.2.2 Incidents where the equipment is rendered non-missionworthy are sentenced using mission
code A.

A.5.3 MISSION CODE B: MISSIONWORTHY, IMPAIRED

A.5.3.1 The equipment shall be considered Missionworthy, Impaired if it can continue to perform its
primary function, albeit with degraded performance. However, if the system boundary is clearly defined it will
normally be found possible to sentence the incident using codes 1 or A.

A.5.3.2 Incidents where an equipment, although defective, can continue to operate are sentenced using
mission code B. Its degraded performance does not require the mission to be aborted although not all
aspects of the mission can be undertaken. Typically this would include engines operating on reduced power,
chilled water working at reduced flow rate, etc.

A.5.4 MISSION CODE 1: MISSIONWORTHY

A.5.4.1 The equipment shall be considered to be Missionworthy provided it can fulfil and sustain all
mission-essential functions specified in the contractual documentation or ground rules for the assessment.

A.5.4.2 The following incidents are sentenced using mission code 1:

a) Comments, scheduled preventive maintenance activities, observations, hardware changes, software


changes, i.e. information only records;

b) Incidents where the equipment remains fully missionworthy. These incidents are typically defects in non
mission-essential items or functions.

A.5.4.3 Observations and comments are sentenced with 11 in the first two characters. For example
comments on software are sentenced 11BC.

A.6 Corrective Action Codes

A.6.1 The corrective action code is the second character in the incident sentencing code and indicates
the requirement for corrective action. The corrective action code denotes the need for unplanned, corrective
or remedial activities, and enables cost estimation, scaling and planning activities to be carried out.

A.6.2 CORRECTIVE ACTION CODE R: REPAIRABLE AT SEA

A.6.2.1 Defects/Faults/Failures that require unplanned, corrective or remedial actions by the operator or
maintainer and which can be undertaken at sea using the spares, tools, facilities, documentation and skilled
manpower scheduled to be carried on board, or in an adjacent Forward Support Unit in the case of mine
warfare vessels are sentenced using corrective action code R.

Unclassified
11
DEF STAN 00-44 Issue 1

A.6.3 CORRECTIVE ACTION CODE N: NON REPAIRABLE AT SEA

A.6.3.1 Defects/Faults/Failures that require unplanned, corrective or remedial actions which cannot be
undertaken at sea due to lack of facilities and/or accessibility or lack of those stores, tools, documentation or
levels of skilled manpower scheduled to be carried on board, or, in the case of Mine Warfare Vessels,
available in an adjacent Forward Support Unit are sentenced using corrective action code N.

A.6.4 CORRECTIVE ACTION CODE S: SHORE BASED EQUIPMENT

A.6.4.1 Defects/Faults/Failures on equipment which is shore-based and hence for which an allocation of
code R or N would be inappropriate are sentenced using the corrective action code S.

A.6.4.2 The procedure for allocating responsibility for remedial action may either be included in the Terms
of Reference for the ISC or may take place in the subsequent phase of data classification.

A.6.5 CORRECTIVE ACTION CODE V: UNDEFINED

A.6.5.1 Defects/Faults/Failures on a shipborne equipment that require unplanned, corrective or remedial


action by the operator or maintainer but it is unknown whether such action can be undertaken at sea are
sentenced using corrective action code V. This code would most commonly be assigned early in a reliability
growth/development programme. All incidents with a code V should be investigated. The re-coding of
corrective action code V is highly desirable and should be updated by the ISC when new information
becomes available.

A.6.6 CORRECTIVE ACTION CODE 1: NO CORRECTIVE ACTION

A.6.6.1 The following incidents are sentenced using corrective action code 1:

a) Comments, observations, hardware changes, software changes, scheduled maintenance i.e.


information only records;

b) Incidents where no corrective action by the operator or maintainer is either required, or possible, e.g.
one-shot devices once launched. These incidents do not represent an in-service maintenance burden.
However, when considered with the other codes they may indicate unsatisfactory equipment
performance which cannot be overcome by unscheduled maintenance action.

A.7 Cause/Activity Codes

A.7.1 The cause/activity code is the third character in the incident sentencing code. It is used to indicate
either the cause of an incident or the nature of a reported activity, e.g. comment, scheduled maintenance.
The identification of a cause may often require extensive investigations and in these cases it is the practice
to assign an interim code V which is updated once investigations are complete.

A.7.2 CAUSE/ACTIVITY CODE A: HARDWARE PROBLEM

A.7.2.1 Incidents which are attributable to hardware problems or deficiencies, whether due to design or
quality causes are sentenced using cause/activity code A.

A.7.3 CAUSE/ACTIVITY CODE B: SOFTWARE PROBLEM

A.7.3.1 Incidents caused by the malfunction of software are sentenced using cause/activity code B. This
will include incidents where an equipment problem was corrected by operation of the reset, albeit that the
underlying software deficiency needs to be addressed.

Unclassified
12
DEF STAN 00-44 Issue 1

A.7.4 CAUSE/ACTIVITY CODE D: HARDWARE CHANGE

A.7.4.1 The cause/activity code D is used for information only records signifying a change in the standard
of the hardware following the implementation of a change to the design or quality of the equipment.
Hardware changes are sentenced 11DC or 11D1.

A.7.4.2 This code may be assigned when an equipment is under development but not when it has reached
its fixed build standard or Mod State Zero demonstration trials.

A.7.4.3 Hardware changes can be implemented in one of two ways:

a) As the corrective maintenance action in response to an incident. In these cases there shall be two
records:

1) A primary record - to describe the state, corrective action and cause of the incident;

2) A sub-record - to indicate that a hardware change has been implemented.

NOTE Normal rules apply for the sentencing of the primary record and the sub-record is sentenced as above. A star
may be added to the code to indicate that a related sub-record exists; in the case of a primary record, it is placed after
the 3rd character, e.g. ARA*C, and, in the case of the sub-record, it is placed after the 4th character, e.g. 11DC*.

b) As a separate record, not in direct response to an incident. These actions are primary incidents, not
relating to an incident or corrective action but to a change in equipment hardware build standard -
whether it be the fitting of a new part or reversion to an old design.

A.7.4.4 Sentencing codes are applied to individual incidents and separate records are required for each
equipment participating in a test that has had the hardware changed. Once a hardware change has been
adopted, this forms the updated equipment build standard; subsequent hardware problems on a modified
item are sentenced in the usual way using cause/activity code A.

A.7.5 CAUSE/ACTIVITY CODE E: SOFTWARE CHANGE

A.7.5.1 The cause/activity code E is used for information only records signifying a change to the software
following the implementation of a software modification to the equipment Software changes are sentenced
11EC or 1lE1.

A.7.5.2 This code may be assigned when an equipment is under development but not when it has reached
its fixed build standard or Mod State Zero demonstration trials.

A.7.5.3 Software changes can be implemented in one of two ways:

a) As the corrective action in response to an incident. In these cases there shall be two records:

1) A primary record - to describe the state, corrective action and cause of the incident;

2) A sub-record - to indicate that a software change has been implemented.

NOTE Normal rules apply for the sentencing of the primary record and the sub-record is sentenced as above. A star
may be added to the code to indicate that a related sub-record exists; in the case of a primary record, it is placed after
the 3rd character, e.g. ARB*C, and, in the case of the sub-record, it is placed after the 4th character, e.g. 11EC*.

b) As a separate record, not in direct response to an incident. These actions are primary incidents, not
relating to an incident or corrective action but to a change in the equipment software version.

A.7.5.4 Sentencing codes are applied on an individual basis and separate records are required for each
equipment participating in a test that has had the software change. Once a software change has been
adopted, this forms the software standard version and subsequent software problems are sentenced in the
usual way using the cause/activity code B.

A.7.6 CAUSE/ACTIVITY CODE F: NOT ESTABLISHED

Unclassified
13
DEF STAN 00-44 Issue 1

A.7.6.1 Incidents where the cause is unresolved and the incident is not, or is no longer, UNDER
INVESTIGATION are sentenced using cause/activity code F.

A.7.6.2 This code is assigned where there is doubt concerning the validity of the diagnosis of cause. It
may occasionally be assigned to incidents where no investigation is undertaken but the majority of
unestablished causes would be investigated and sentenced using the interim cause/activity code V.
Incidents UNDER INVESTIGATION are typically re-coded as NOT ESTABLISHED if results are
inconclusive.

A.7.7 CAUSE/ACTIVITY CODE G: PRE-LIFE FAILURE

A.7.7.1 Incidents attributable to the premature degradation of a life-limited item are sentenced using
cause/activity code G. This code indicates the failure of an item which has not achieved its specified life
before exchange.

A.7.7.2 This code is only applicable to assemblies with specified lives which have been defined and
agreed before the test. Furthermore, it is only applicable to defects/faults/failures of life-limited items which
are caused by wear or other progressive degradation mechanisms.

A.7.8 CAUSE/ACTIVITY CODE H: INADEQUATE PROCEDURES

A.7.8.1 The following incidents are sentenced using cause/activity code H:

a) Incidents attributable to incorrect or inadequate technical support literature, e.g. handbooks, Books of
Reference (BR), operating and maintenance instructions, etc;

b) Incidents caused by inadequately trained operators or maintainers. These events indicate shortcomings
in the operating/training procedures/documentation.

NOTE This code is only applicable to operating/training and maintenance procedures and not to quality, design,
manufacturing or installation procedures.

A.7.9 CAUSE/ACTIVITY CODE J: INADEQUATE INSTALLATION

A.7.9.1 Incidents attributable to equipment incorrectly installed are sentenced using cause/activity code J.
This includes not only defects/faults/failures caused directly during the installation process, but also those
which occurred subsequently during operation or maintenance as a result of the incorrect way in which the
equipment had been installed.

A.7.10 CAUSE/ACTIVITY CODE N: NO FAULT FOUND

A.7.10.1 Incidents where an equipment malfunctions in a specific manner but subsequent tests and
checks (see note below) are unable to replicate the fault are sentenced using cause/activity code N. The
tested (suspect) unit is either redeployed or returned to the spares holding. Caution should be used when
applying code N No Fault Found to satisfy the FRB that the operator/maintainer has accurately diagnosed
the problem. Any uncertainty would require a code V Under Investigation to be applied until the FRB
becomes satisfied.

NOTE The suspect unit may be tested in place or maybe removed and tested using separate test equipment. In
either case the original incident is sentenced using code N (the test and inspection activities are recorded as sub-records
and sentenced 1171). A star may be added to the N to indicate that a sub-record has been raised.

Unclassified
14
DEF STAN 00-44 Issue 1

A.7.10.2 NO FAULT FOUND fault conditions are a common occurrence with both mechanical and
electrical/electronic equipment, although they are a particular problem with electronic systems, e.g.
computers. Recurrent events should be placed under investigation and may require changes to the
equipment. Incidents sentenced using this code are those where a retest demonstrates the suspect unit to
be fully operational; these incidents are indicative of a number of potential problems, some examples are
listed below:

a) Problems which are remedied by the process of removal, stripping and testing - typical of these are
defects/faults/ failures of mechanical units;

b) Intermittent faults;

c) Some software errors;

d) Problems with the system integration, e.g. incompatibility between parts;

e) Problems resulting from strict setting-up tolerances, which are readily achieved under factory conditions
but more difficult in service.

A.7.11 CAUSE/ACTIVITY CODE V: UNDER INVESTIGATION

A.7.11.1 The following incidents are sentenced using cause/activity code V:

a) Incidents where the cause is undiagnosed and cannot be established by the ISC on the basis of the
available information, albeit further investigations may be instigated by the ISC. This application of the
code would be employed if, for example, the investigation was awaiting the removal and inspection of an
item;

b) Incidents where the cause is known but response action is held over pending further investigation at the
request of the ISC. This application of the code is typically employed where the cause is a software
problem but the exact details are not yet established. It is also used where the effect on the mission is
not yet clear.

A.7.11.2 The cause/activity code V is an interim coding typically assigned where there is no agreement
over cause or where the incident itself is to be scrutinised in greater detail. Investigations may be initiated for
a variety of reasons. Cause diagnosis is one reason but investigations may also be required to establish the
extent of a problem or its impact on the mission. Incidents sentenced using cause/activity code V are carried
over, presented and discussed at all subsequent ISC meetings until the incident is finally coded. Incidents
UNDER INVESTIGATION can be re-coded as NOT ESTABLISHED if the investigations into cause are not
conclusive.

A.7.12 CAUSE/ACTIVITY CODE 1: ACCIDENT/HUMAN ERROR

A.7.12.1 The following incidents are sentenced using cause/activity code 1:

a) Preventable accidents;

b) Inadvertent operation beyond performance limits;

c) Incidents resulting from culpable carelessness, misuse or abuse by the operators and/or maintainers.

NOTE The ACCIDENT/HUMAN ERROR cause diagnosis is not applicable to incidents arising from poor practices
during the manufacturing process or during other processes completed at places of manufacture or during installation.
Such incidents are sentenced as HARDWARE PROBLEMS, SOFTWARE PROBLEMS or INADEQUATE
INSTALLATION using cause/activity codes A, B or J.

Unclassified
15
DEF STAN 00-44 Issue 1

A.7.12.2 Incidents originally considered to be caused by human error should be re-assessed, and possibly
re-coded, if they recur frequently. Such recurrent events should be investigated to see whether they are
indicative either of a design weakness or of shortcomings in the operation/maintenance procedures or
training. Generally, equipment should be robust and capable of withstanding a “reasonable” degree of inept
handling and operation. That equipment which is unable to survive realistic in-service usage conditions is not
satisfactory and, in these cases, remedial design or procedural changes should be considered.

A.7.13 CAUSE/ACTIVITY CODE 2: SECONDARY EVENT

A.7.13.1 The following incidents are sentenced using cause/ activity code 2:

a) Where a chain of events with a common cause is established, the cause/activity code 2 is used to
sentence those events that were secondary to the primary incident. The primary incident shall be
sentenced to indicate the original cause, e.g. a lubrication pump might fail and subsequently cause a
gearbox to seize - the pump failure would be the primary cause, which would be sentenced in the
normal way, and the gearbox seizure would be the secondary event, sentenced using cause/activity
code 2;

b) Symptomatic or diagnostic events happening at different times or recorded by different people, e.g. low
oil pressure warning light illuminating some time before an oil pump had failed;

c) Incidents arising from operation outside the performance specification or as a result of an earlier failure.

NOTE 1 Cause/activity code 2 is not assigned to defects/ faults/failures of redundancy and reversionary-mode items,
as these will have separate causes.

NOTE 2 SECONDARY EVENT records shall refer to primary or related incidents, e.g. “Loss of electrical power, see
incident 1234/2”.

A.7.14 CAUSE/ACTIVITY CODE 3: POST-LIFE FAILURE

A.7.14.1 Cause/activity code 3 is used to sentence incidents arising from operation beyond the specified
life. Cause/activity code 3 is assigned to the three types of event listed below:

a) Incidents arising from equipment knowingly operated beyond the time at which it should be replaced.
This may occur either for trials expediency or with the deliberate intention of testing to failure limits or
“close to failure”. Cause/activity code 3 is applicable to life-limited items, expendable items and other
items which, in normal circumstances, would be replaced in accordance with planned maintenance
schedules or through condition monitoring;

b) Incidents arising from equipment which has, in error, been operated beyond the time at which it should
be replaced. This category of incidents applies specifically to failures of life-limited items which are
inadvertently operated beyond their specified life;

NOTE Incidents attributable to shortcomings in the technical support literature, i.e. operating and maintenance
instructions are sentenced using cause/activity code H, INADEQUATE PROCEDURES.

c) Cause/activity code 3 may also be assigned in exceptional cases to indicate degradation and failure
which has arisen as a direct result of operating or maintenance practices which are unrepresentative of
in-service usage conditions. This condition can typically arise during reliability growth testing. One
example of this would be the failure of a peripheral component caused by over-frequent removal to gain
access during testing. Further examples include failures arising from periods of accelerated or over-
stress testing.

A.7.14.2 This code is normally only applicable to assemblies with specified lives which have been defined,
and agreed, before the test. Furthermore, it is only applicable to defects/faults/failures of life-limited items
which are caused by wear or other progressive degradation mechanisms.

Unclassified
16
DEF STAN 00-44 Issue 1

A.7.15 CAUSE/ACTIVITY CODE 6: SCHEDULED MAINTENANCE

A.7.15.1 Scheduled maintenance activities and condition monitoring tasks that are specified in the
preventive maintenance schedule are sentenced using cause/activity code 6. Periodic services or planned
overhauls are typically sentenced 1R61.

A.7.16 CAUSE/ACTIVITY CODE 7: RECORDING ACTION

A.7.16.1 The following incidents are sentenced using cause/activity code 7:

a) Information only records;

1) Sub-records;

2) Maintenance and diagnostic sub-records;

3) Suggestions;

4) Software diagnostic checks;

5) Temporary maintenance;

6) Temporary modifications;

7) Observations;

8) Special maintenance.

b) Maintenance action on an item with limited life conducted as a result of stated condition monitoring
tasks, where it can be shown that the incident was not due to some other cause such as hardware
problem, etc.;

c) Incidents resulting from unpreventable circumstances;

d) Incidents resulting from deliberate operation when overdue for preventive maintenance.

A.7.16.2 Incidents arising from non-test activities, or during periods of operation outside specification, are
sentenced according to normal rules based on the four criteria: mission capability; corrective action
requirement; cause/activity; chargeability. These incidents may be distinguished by the use of an additional
trial relevance code, e.g. letters for relevant trials and numbers for non-relevant trials, or by excluding events
from an invalid period which would indicate activities and events not relevant to an assessment of R&M
achievement. Such additional characters will be defined in the document prepared to tailor this Standard for
the particular equipment trial period. Nevertheless R&M achievement is closely related to total cumulative
usage and this should not be used to artificially raise achievement by exclusion of invalid incidents whilst
including the invalid usage. Furthermore, exclusion of valid periods of data containing many defects/
faults/failures shall not be permitted because it will artificially inflate the apparent reliability.

A.8 Chargeability Codes

A.8.1 The chargeability code is the fourth character in the incident sentencing code and indicates whether
or not the incident is chargeable as governed by the contract or the ground rules of the assessment. This
code is primarily concerned with establishing which incidents are attributable to aspects of the project for
which the contractor is responsible. Where there is no contractor, the chargeability code may be omitted. As
stated in clause A.2.1(d), in this Standard the term chargeability has no direct financial connotation.

Unclassified
17
DEF STAN 00-44 Issue 1

A.8.2 CHARGEABILITY CODE C: CHARGEABLE

A.8.2.1 Incidents which are attributable to aspects of the project for which the contractor is responsible are
sentenced using chargeability code C. This includes all aspects of design, manufacture, operation and
maintenance of Contractor Supplied Items (CSI), otherwise referred to as Contractor Furnished Equipment
(CFE). A Contractor would not normally be responsible for Government Furnished Equipment (GFE),
excepting interfaces and any detrimental effects that installation has on the GFE. The criteria for establishing
chargeability should be defined before data recording commences.

A.8.2.2 Chargeability is mainly applicable to incidents that are defects/faults/failures, but can also be used
for other types of incident, e.g. observations of hardware problems.

A.8.3 CHARGEABILITY CODE 1: NON-CHARGEABLE

A.8.3.1 Incidents which are not attributable to aspects of the project for which the contractor is responsible
are sentenced using chargeability code 1.

A.8.4 CHARGEABILITY CODE 2: UNRESOLVED

A.8.4.1 Incidents where the chargeability cannot be resolved pending further investigation are sentenced
using chargeability code 2.

A.8.4.2 A chargeability code of 2 will normally be appropriate where a cause/activity code of V (Under
Investigation) has been allocated as the third character.

Unclassified
18
DEF STAN 00-44 Issue 1

Annex B
Incident Sentencing - Land

B.1 Introduction

B.1.1 This section provides comprehensive guidance on the rules, terminology and definitions which are
acceptable and appropriate to the sentencing of R&M test data.

B.2 Foreword

B.2.1 Incident sentencing involves the allocation of a summary coding to all recorded incidents. This
summary coding is known as an incident sentencing code. The incident sentencing code comprises three
alpha-numeric characters, each character representing a different criterion identified from the incident data.
Allocation of these codes requires objective assessment of each incident according to these criteria, and
allows the relevance of each incident to any R&M assessment to be determined. The three criteria are
identified below:

a) First Character: MISSION CODE: This code summarises the implications of an incident on the mission
capability of the equipment.

b) Second Character: CORRECTIVE ACTION: This code identifies the type and/or level of corrective
action required and the personnel involved, e.g. the user or support organization - such as REME.

NOTE The term “corrective action” has been used in this Standard to take account of software incidents. If an
equipment becomes unavailable due to a software problem, even if for only a short period prior to reset, this counts as a
corrective action for R&M analysis purposes and shall be recorded.

c) Third Character: CAUSE/ACTIVITY CODE: This code summarises either the cause of an incident or
the nature of a reported activity, e.g. scheduled maintenance.

B.2.2 This degree of coding represents the minimum level of information required to codify an incident.
Strings of more than three characters are capable of coding incidents according to additional criteria. This
extra information may be desirable, e.g. contractor’s project management purposes, but it does not form an
essential part of an incident sentencing code and if required shall be recorded separately.

B.2.3 The sentencing codes and their corresponding descriptions are shown in table B1. A detailed
explanation of each code and rules for its application are given in clauses B.5, B.6 and B.7. These codes are
generally applicable to all types of equipment regardless of their role. Adaptation of the codes for specific
projects is dealt with in clause B 3, Tailoring of Codes.

B.2.4 The summary code is written as a serial without breaks e.g. 1EA. The symbol * is used to indicate
any permissible character e.g. **A.

B.2.5 It should be noted that sentencing does not codify on the basis of failure significance. Mission and
basic failures are identified by examination of the summary code. Mission failures are denoted by letters in
the first and third character positions. Basic failures are denoted by letters in the second and third character
positions. Basic failures include all mission failures.

Unclassified
19
20

DEF STAN 00-44 Issue 1


First Character Second Character Third Character

Mission Code Clause Corrective Action Clause Cause/Activity Code Clause

1 Missionworthy B5.2 C REME Corrective Action B6.2 A Design Weakness B7.2


(Unroadworthy)
2 Missionworthy, Time Rule B5.3 B Quality Problem B7.3
D Crew Corrective Action B6.3
3 Missionworthy, Impaired B5.4 D Design Change B7.4
Table 2 Incident Sentencing Codes - Land

(Unroadworthy)
E Quality Change B7.5
E Maintainer B6.4
A Non-Missionworthy B5.5 F Not Established B7.6
F User B6.5
X Non-Missionworthy, Immobile B5.6 G Pre-Life Failure B7.7
V Undefined B6.6
H Inadequate Procedures B7.8
Unclassified

N No Fault Found B7.9


1 No Corrective Action B6.7
V Under Investigation B7.10

1 Human Error B7.11


2 Secondary Event B7.12
3 Post-Life Failure B7.13
6 Scheduled Maintenance B7.14
7 Recording Action B7.15
DEF STAN 00-44 Issue 1

B.3 Tailoring of Codes

B.3.1 The incident sentencing methodology described in this Standard is applicable to all types of
equipment/systems. However, the incident sentencing codes (listed in table B1) may cover too wide a range
or not cover all the needs of a project. This can be overcome by “tailoring” the codes to suit the particular
project, R&M requirement and/or equipment. It would be impracticable to note all of the possible code
variations here but further guidance and some essential rules are given below.

B.3.2 Tailoring of codes shall be done through the R&M Panel, as part of the production of the project’s
R&M plan, and shall be contractually agreed before the commencement of R&M testing. Before any changes
to the incident sentencing codes are made advice shall be sought from the relevant MOD R&M specialists.

B.3.3 When adding codes the existing format shall be adhered to, i.e. where letters indicate significance
in the assessment of R&M and numbers do not. The meaning of existing codes and their associated
characters shall not be changed. However, alteration of titles to make them project specific is permissible.
Some examples of changes to code titles are given below:

a) Mission code. e.g. where the term “Battleworthy” is commonly used it could be substituted for
“Missionworthy”.

b) Corrective Action code. Maintainer, code E, has been used as a generic title. This should be changed as
appropriate to reflect the relevant maintenance organization. In many cases it will be REME but
depending upon the equipment it would be some other organization, e.g. during trials would represent
the contractor's maintainers.

c) Corrective Action code. User, code F. Alternative titles may be used in place of user e.g. operator, crew,
rider. Code F is commonly used to describe the contractor's operators during trials.

B.3.4 Mission code X is specifically reserved for automotive equipment that is immobilized.

B.3.5 Corrective Action codes C (Technician Corrective Action) and D (crew Corrective Action) are
specifically reserved for Corrective Action relating to vehicle roadworthiness.

NOTE Corrective Action involving both the crew and REME technicians is sentenced using Technician Corrective
Action code C.

B.4 Incident Sentencing Procedure

B.4.1 This subject is introduced in clause 6 of the Standard.

B.4.2 The sentencing of incidents is a relatively simple matter where the considerations are entirely
objective, but becomes more complex where subjective judgments have to be made. The allocation of a
Corrective Action code, for example, is fairly straight forward as is the identification of a failure cause/activity
code - as long as sufficient information is available. The subjective allocation of the mission code is avoided
by ensuring that the mission failure criteria are fully defined before the start of the project and relate to
performance requirements.

B.4.3 There is no single “sentencing procedure”. In most cases it will be helpful to follow a number of pre-
determined decision steps but very often familiarity with an equipment and R&M requirement will enable a
sentencing code to be assigned without following a formal procedure. In practice, developing decision steps
to assist in the allocation of the mission code could be beneficial. However, the Corrective Action codes and
cause/activity codes are assigned by referring to the detailed explanations provided in clauses B.6 and B.7.

B.4.4 The following decision steps illustrate the considerations and decisions which may be necessary in
sentencing an incident. Steps 1 to 5 covering the allocation of the mission code are summarized in Figure 1.

a) Step 1: Is the incident a scheduled maintenance task or an information only record (e.g. comment,
observation)?

Unclassified
21
DEF STAN 00-44 Issue 1

⎯ NO: Step 2

⎯ YES: Mission code 1

b) Step 2: Examine the incident description. Consider:

⎯ The function of the failed/faulty item.

⎯ The degree of degradation.

⎯ The operational requirement.

⎯ Is the equipment able to continue its mission and fulfil and sustain all specified mission performance
levels? (refer to “Missionworthy” definition in B.5.2).

⎯ NO: Step 3

⎯ YES: Mission code 1

c) Step 3: Can the incident be rectified within the “Time Rule” allowance by the correct skill level using
specified equipment? (refer to “Time Rule” definition in B.5.3).

⎯ NO: Step 4

⎯ YES: Mission code 2

d) Step 4: Is the missionworthiness impaired as a result of the incident? (refer to “Missionworthy, Impaired”
definition in B.5.4).

⎯ NO: Step 5

⎯ YES: Mission code 3

e) Step 5: Is the equipment non-missionworthy as a result of the incident? (refer to “Non-Missionworthy”


definition in B.5.5).

⎯ NO: Error in sentencing, return to step 1.

⎯ YES: Mission code A

f) Step 6: Refer to “Corrective Action” codes in clause B.6.

⎯ Select appropriate code.

g) Step 7: Refer to “Cause/Activity” codes in clause B.7.

⎯ Select appropriate code.

Unclassified
22
DEF STAN 00-44 Issue 1

Figure 1 Sentencing Steps Flow Chart - Land

Unclassified
23
DEF STAN 00-44 Issue 1

B.5 Mission Codes

B.5.1 The mission code is the first character in the incident sentencing code and represents the
operational capability of the equipment at the time the incident occurred. The mission code is instrumental in
determining failure significance. The definitions given below are typical examples. For each particular project
the definitions to be used shall be specified in the contractual documentation.

B.5.2 MISSION CODE 1: MISSIONWORTHY

B.5.2.1 The equipment shall be considered to be missionworthy provided it can fulfil and sustain all
specified mission essential functions.

B.5.2.2 The following incidents are sentenced using mission code 1:

a) Comments, scheduled maintenance actions, observations, design changes quality changes, i.e.
information only records.

b) Incidents where the equipment remains fully missionworthy. These incidents are typically failures of non-
mission essential items or functions.

B.5.3 MISSION CODE 2: MISSIONWORTHY, TIME RULE

B.5.3.1 Faults that can be diagnosed and rectified by the user, unassisted and within the time rule
specified in the contractual documentation, using only specifically defined tools and spares.

B.5.3.2 Incidents where the remedial action is carried out by the user within a specified time, following laid
down procedures and using specifically defined tools and spares are sentenced using mission code 2.

B.5.3.3 Incidents diagnosed and rectified within the time rule allowance are considered to have no
adverse effect on missionworthiness. However, a number of these incidents occurring within a short time of
each other, on the same equipment, may eventually combine to cause loss of missionworthiness and shall
be considered for their combined effect. Specific rules concerning the cumulative effect of multiple “time rule”
corrective actions shall be defined in the contractual documentation for the project.

B.5.4 MISSION CODE 3: MISSIONWORTHY, IMPAIRED

B.5.4.1 Despite the loss or degradation of a sub-system function the equipment is able to continue its
mission and fulfil and sustain all specified mission essential functions.

B.5.4.2 Incidents which result in an impaired operational state of missionworthiness are sentenced using
mission code 3.

B.5.4.3 These incidents will affect operational effectiveness and are typically failures to mission essential
items which result in the operational performance of the equipment being reduced but remaining above an
essential minimum level.

B.5.5 MISSION CODE A: NON-MISSIONWORTHY

B.5.5.1 The equipment is unable to continue its mission and fulfil and sustain all mission performance
levels specified in the contractual documentation.

B.5.5.2 Incidents where the equipment is rendered non-missionworthy are sentenced using mission
code A.

B.5.6 MISSION CODE X: NON-MISSIONWORTHY, IMMOBILE

B.5.6.1 The equipment is unable to move and requires recovery or corrective action to rectify.

B.5.6.2 The following are sentenced using mission code X:

Unclassified
24
DEF STAN 00-44 Issue 1

a) Defects/faults/failures where the vehicle is rendered non-missionworthy and immobile;

b) Incidents where the vehicles are bogged and unable to progress under their own power.

B.6 Corrective Action Codes

B.6.1 The Corrective Action code is the second character in the incident sentencing code and indicates
the corrective action requirement. The Corrective Action code fulfils a need to represent logistic information
and enable cost estimation, scaling and planning activities to be carried out.

B.6.2 CORRECTIVE ACTION CODE C: REME CORRECTIVE ACTION (UNROADWORTHY)

B.6.2.1 The following are sentenced using Corrective Action code C:

a) Unscheduled Corrective Action requiring REME involvement which restores roadworthiness (irrespective
of missionworthy state);

b) Scheduled Corrective Action which requires REME involvement.

B.6.3 CORRECTIVE ACTION CODE D: CREW CORRECTIVE ACTION (UNROADWORTHY)

B.6.3.1 The following are sentenced using Corrective Action code D:

a) Unscheduled Corrective Action carried out by the crew to restore Roadworthiness (irrespective of
missionworthy state);

b) Scheduled Corrective Action completed by the crew.

B.6.4 CORRECTIVE ACTION CODE E: MAINTAINER

B.6.4.1 The following are sentenced using Corrective Action code E:

a) Unscheduled Corrective Actions involving the maintainer;

b) Scheduled maintenance involving the maintainer.

B.6.5 CORRECTIVE ACTION CODE F: USER

B.6.5.1 The following are sentenced using Corrective Action code F:

a) Unscheduled Corrective Actions only involving the user;

b) Scheduled maintenance activities only involving the user.

B.6.5.2 Corrective Actions involving both the user and the maintainer are Sentenced using the Corrective
Action code E.

B.6.6 CORRECTIVE ACTION CODE V: UNDEFINED

B.6.6.1 The following are sentenced using Corrective Action code V:

a) Unscheduled Corrective Actions arising from incidents where the in-Service Corrective Action
involvement is unknown;

b) Scheduled Corrective Action activities where the in-Service maintenance involvement is unknown.

B.6.6.2 This Corrective Action code would most commonly be assigned early in a reliability
growth/development programme. All incidents with a Corrective Action code V should be investigated. The
re-coding of Corrective Action code V is highly desirable and should be updated, by the ISC, when new
information becomes available.
Unclassified
25
DEF STAN 00-44 Issue 1

B.6.7 CORRECTIVE ACTION CODE 1: NO CORRECTIVE ACTION

B.6.7.1 The following are sentenced using Corrective Action code 1:

a) Comments, observations, design changes, quality changes, i.e. information only records;

b) Incidents where no Corrective Action is either required, or possible, e.g. single shot devices once
launched. These incidents do not represent an in-Service maintenance burden. However, when
considered with the other codes they may indicate unsatisfactory equipment performance which cannot
be overcome by unscheduled Corrective Action.

B.7 Cause/Activity Codes

B.7.1 The cause/activity code is the third and final character in the incident sentencing code. It is used to
indicate either the cause of an incident or the nature of a reported activity, e.g. comment, scheduled
maintenance. The identification of a cause may often require extensive investigations and in these cases it is
the practice to assign an interim code V which is updated once investigations are complete.

B.7.2 CAUSE/ACTIVITY CODE A: DESIGN WEAKNESS

B.7.2.1 The following are sentenced using cause/activity code A:

a) Incidents attributable to poor design;

b) Observations attributable to design (sentenced as 11A).

B.7.2.2 Technical problems which occur frequently are typically coded as DESIGN WEAKNESS,
indicating that the defect/fault /failure may be overcome by establishing and implementing a design change.

B.7.3 CAUSE/ACTIVITY CODE B: QUALITY PROBLEM

B.7.3.1 The following are sentenced using cause/activity code B:

a) Incidents attributable to poor quality control during manufacture/repair (see also B.7.11.1, NOTE);

b) Incidents attributable to the wrong selection of parts during manufacture/repair, e.g. components of the
wrong strike number/build standard;

c) Incidents arising on proprietary or off-the-shelf items, e.g. underpowered, undersized, misalignment,


poor function;

d) Observations attributable to quality (sentenced as 11B).

B.7.3.2 Quality problems can arise when manufactured items are out of specification. Clear evidence
should be produced to support these diagnoses.

B.7.4 CAUSE/ACTIVITY CODE D: DESIGN CHANGE

B.7.4.1 Information only records signifying a change in the equipment build standard following the
implementation of an engineering design change are sentenced using cause/activity code D.

B.7.4.2 This code should not be assigned during fixed build standard trials, e.g. demonstration trials.

B.7.4.3 Design changes can be implemented in one of two ways:

a) As the unscheduled corrective action in response to an incident. In these cases there shall be two
records:

1) A primary record – to describe the state, Corrective action and the cause of the incident;

Unclassified
26
DEF STAN 00-44 Issue 1

2) A sub-record – to indicate that a design modification has been implemented. Normal rules apply for
the sentencing of the primary record; the sub-record is sentenced 11D;

b) As a separate record, not in direct response to an incident. These actions are primary incidents, not
relating to an incident or corrective action but to a change in build standard - whether it be the fitting of a
new part or reversion to an old design.

B.7.4.4 Sentencing codes are applied on an individual basis and separate records are required for each
equipment participating in a test. Once a design change has been adopted this forms the updated equipment
build standard; subsequent design faults of a modified item are sentenced in the usual way using cause/
activity code A.

B.7.5 CAUSE/ACTIVITY CODE E: QUALITY CHANGE

B.7.5.1 Information only records signifying a change in the manufacturing process or a change of
component supplier are sentenced using cause/activity code E (quality changes are sentenced as 11E).

B.7.5.2 This code should not be assigned during fixed build standard trials, e.g. demonstration trials.

B.7.5.3 Quality changes can be implemented in one of two ways:

a) As the unscheduled corrective action in response to an incident. In these cases there shall be two
records:

1) a primary record – to describe the state, corrective action and the cause of the incident;

2) a sub-record - to indicate that a quality change has been implemented. Normal rules apply for the
sentencing of the primary record; the sub-record is sentenced 11E.

b) As a separate record, not in direct response to an incident. These actions are primary incidents, not
relating to an incident or corrective action but to a change in the production process or component
supplier. These records are sentenced 11E.

B.7.5.4 Sentencing codes are applied on an individual basis and separate records are required for each
equipment participating in a test. Once a quality change has been adopted this forms the standard
production method or component source; subsequent quality problems are sentenced using the
cause/activity code B.

B.7.6 CAUSE/ACTIVITY CODE F: NOT ESTABLISHED

B.7.6.1 The following is sentenced using cause/activity code F:

Incidents where the cause is unresolved and the incident is not, or is no longer, UNDER INVESTIGATION.

B.7.6.2 This code is assigned where there is doubt concerning the cause diagnosis. It may occasionally be
assigned to incidents where no investigations are undertaken but the majority of unestablished causes would
be investigated and sentenced using the interim cause/activity code V. Incidents UNDER INVESTIGATION
are typically re-classified as NOT ESTABLISHED if results are inconclusive.

Unclassified
27
DEF STAN 00-44 Issue 1

B.7.7 CAUSE/ACTIVITY CODE G: PRE-LIFE FAILURE

B.7.7.1 Incidents attributable to the premature degradation of a lifed item are sentenced using
cause/activity code G. This code indicates the failure of a lifed item which has not achieved its durability
target.

B.7.7.2 This code is only applicable to assemblies with durability targets; which shall be defined in the
R&M plan for the project. Furthermore, it is only applicable to defects/ faults/failures of life limited items which
are caused by wear or other progressive degradation mechanisms.

B.7.8 CAUSE/ACTIVITY CODE H: INADEQUATE PROCEDURES

B.7.8.1 The following are sentenced using cause/activity code H:

a) Incidents attributable to incorrect or inadequate technical support literature, e.g. handbooks, Army
Equipment Support Publications (AESPs),operating and corrective action instructions etc;

b) Incidents caused by inadequately trained operators or maintainers. These events indicate shortcomings
in the operating/training procedures/documentation.

NOTE This code is only applicable to operating/training and corrective action procedures and not to quality, design
or manufacturing procedures which would be sentenced using the appropriate cause/activity code.

B.7.9 CAUSE/ACTIVITY CODE N: NO FAULT FOUND

B.7.9.1 Incident where an equipment malfunctions in a specific manner but subsequent tests and checks
(see note below) are unable to replicate the fault are sentenced using cause/activity code N. The tested
(suspect) unit is either re-deployed or returned to the spares holding. Caution should be used when applying
code N No Fault Found to satisfy the FRB that the operator/maintainer has accurately diagnosed the
problem. Any uncertainty would require a code V Under Investigation to be applied until the FRB becomes
satisfied.

NOTE The suspect unit may be tested in place or may be removed and tested using separate test equipment. In
either case the original incident is sentenced using code N (the test and inspection activities are recorded as sub-records
and sentenced 117).

B.7.9.2 NO FAULT FOUND fault conditions are a common occurrence with both mechanical and
electrical/electronic items of equipment. Although they are a particular problem with electronic systems, e.g.
computers, recurrent events should be placed under investigation and may require changes to the system.
Incidents sentenced using this code are those where a re-test demonstrates the suspect unit to be fully
operational; these incidents are indicative of a number of potential problems, some examples are listed
below:

a) Problems which are remedied by the process of removal, stripping and testing - typical of these are
incidents of mechanical units;

b) Intermittent faults;

c) Software programming errors;

d) Problems with the system integration, e.g. incompatibility between parts;

e) Problems resulting from strict setting-up tolerances, which are readily achieved under factory conditions
but more difficult at Level 1 (User). Typical of these are incidents of electronic units.

B.7.10 CAUSE/ACTIVITY CODE V: UNDER INVESTIGATION

B.7.10.1 The following records are sentenced using cause/activity code V:

a) Incidents where the cause is undiagnosed and cannot be established by the ISC on the basis of the
available technical information, further investigations may be instigated by the ISC. This application of

Unclassified
28
DEF STAN 00-44 Issue 1

the code would be employed if, for example, the investigation was awaiting the removal and inspection
of an item;

b) Incidents where the cause is known but the incident is held over for further investigation at the request
of the ISC. This application of the code is typically employed where the cause is thought to be a design
weakness. It is also used where the effect on the mission is not clear;

c) Observations where the cause is unestablished or further investigations are required are coded 11V.

B.7.10.2 The cause/activity code V is a “catch-all” coding typically assigned where there is no agreement
over cause or where the incident itself is to be scrutinised in greater detail. Investigations may be initiated for
a variety of reasons. Cause diagnosis is one purpose but investigations may also be required to, for
example, establish the extent of a problem or its impact on the mission. Incidents sentenced using
cause/activity code V are carried over, presented and discussed at all subsequent meetings until the incident
is finally coded. Incidents UNDER INVESTIGATION are typically re-coded as NOT ESTABLISHED if the
investigations into cause are inconclusive.

B.7.11 CAUSE/ACTIVITY CODE 1: HUMAN ERROR

B.7.11.1 The following are sentenced using cause/activity code 1:

a) Incidents resulting from negligence, misuse or abuse by the operators and/or maintainers;

b) Inadvertent operation beyond performance limits, inadvertent/preventable accidents.

NOTE The HUMAN ERROR cause diagnosis is not applicable to incidents arising from poor practices during the
manufacturing process or during other processes completed at places of manufacture. Such incidents are sentenced as
QUALITY PROBLEMS using cause/activity code B.

B.7.11.2 Incidents originally considered to be caused by human error should be re-assessed, and possibly
re-coded, if they recur frequently and persistently. These recurrent arisings should be examined to see
whether they are indicative either of a design weakness or of shortcomings in the operation or maintenance
procedures. Generally, equipment should be robust and capable of withstanding a reasonable degree of
inept handling and operation. Those equipments which are unable to survive realistic in-Service usage
conditions are not satisfactory and in these cases remedial design or procedural changes should be
considered.

B.7.12 CAUSE/ACTIVITY CODE 2: SECONDARY EVENT

B.7.12.1 The following are sentenced using cause/activity code 2:

a) This code is used when the event was not the primary cause of an incident. A primary cause for an
incident shall be established in all cases and sentenced accordingly;

b) A chain of events with a common cause. These records correspond to a primary event and the primary
event shall be sentenced to indicate the original cause;

c) Symptomatic or diagnostic events, e.g. warning light, blown fuse;

d) Incidents arising from severe or harsh operation as a result of an earlier failure.

NOTE 1 Cause/activity code 2 is not assigned to defects/faults/ failures of redundancy and reversionary-mode items.

NOTE 2 SECONDARY EVENT records shall refer to primary or related incidents, e.g. “Loss of power, see incident
1234/2”.

Unclassified
29
DEF STAN 00-44 Issue 1

B.7.13 CAUSE/ACTIVITY CODE 3: POST-LIFE FAILURE

B.7.13.1 Cause/activity code 3 is used to sentence incidents arising from over-use or excessive use.
Failures arising after a durability target has been reached are coded in this manner. Cause/activity code 3 is
assigned to the three types of event listed below.

a) To codify incidents arising from equipment knowingly operated beyond the time at which it should be
replaced. This may occur either for trials expediency or with the deliberate intention of testing to failure
or “close to failure”. Cause/activity code 3 is applicable to lifed items, expendable items and other items
which, in normal circumstances, would be replaced in accordance with planned corrective action
schedules or through condition monitoring.

b) To codify incidents arising from equipment which has, in error, been operated beyond the time at which
it should be replaced. This category of incidents applies specifically to failures of lifed items which are
inadvertently operated beyond their specified life.

NOTE Incidents attributable to shortcomings in the technical support literature, i.e. operating and maintenance
instructions, are sentenced using cause/activity code H, INADEQUATE PROCEDURES.

c) Cause/activity code 3 may also be assigned, in exceptional cases, to indicate degradation and failure
which has arisen as a direct result of operating or corrective action practices which are unrepresentative
of in-Service usage conditions. This condition can typically arise during reliability growth testing. One
example of this would be the failure of a peripheral component caused by over-frequent removal to gain
access during testing. Further examples include failures arising from periods of accelerated or over-
stress testing.

B.7.14 CAUSE/ACTIVITY CODE 6: SCHEDULED MAINTENANCE

B.7.14.1 The following are sentenced using cause/activity code 6:

a) Scheduled maintenance activities and condition monitoring tasks;

b) Unscheduled maintenance activities not specified in the original or revised maintenance plans are
considered to be unscheduled maintenance and are sentenced accordingly using the appropriate
mission, corrective action and cause/activity code;

c) Comments indicating that periodic services or planned overhauls have taken place are typically
sentenced 1E6.

B.7.15 CAUSE/ACTIVITY CODE 7: RECORDING ACTION

B.7.15.1 The following are sentenced using cause/activity code 7:

a) incidents involving unscheduled corrective action on items with limited life but not subject to scheduled
corrective action, e.g. replacement of windscreen wiper blades - where it can be shown that the incident
was not due to some other cause such as design weakness or quality problem etc;

b) incidents resulting from unpreventable arisings;

B.7.15.2 INFORMATION ONLY RECORDS - sentenced as 11* include:

a) Sub-records;

b) Maintenance and diagnostic sub-records;

c) Suggestions;

d) Software diagnostic checks;

e) Temporary maintenance;

f) Temporary modifications;
Unclassified
30
DEF STAN 00-44 Issue 1

g) Comments;

h) Observations;

i) Special corrective action.

B.7.15.3 The appropriate cause/activity code should be chosen to reflect the nature of the record.
Generally the cause/activity code 7 would be used. However, records relating to, for example, comments on
design would be coded 11A.

NOTE Incidents arising from non-trials activities or during periods of extraneous operation are sentenced to normal
rules, based on the three criteria of mission capability, corrective action involvement and cause. These incidents may
also be distinguished by an additional trial relevance code which would indicate activities and events not relevant to an
assessment of R&M achievement. Nevertheless R&M achievement is closely related to total cumulative usage and this
code should not be used to artificially raise achievement by windowing of data.

Unclassified
31
DEF STAN 00-44 Issue 1

Annex C
Incident Sentencing - Air

C.1 Introduction

C.1.1 This section provides comprehensive guidance on the rules, terminology and definitions which are
acceptable and appropriate to the sentencing of R&M test data.

C.2 Foreword

C.2.1 Incident sentencing involves the allocation of a summary coding to all recorded events. This
summary coding is known as an event sentencing code. The incident sentencing code comprises the
Originators Reference Number (ORN), the Mission Failure code, the Line of Maintenance code, the
Attributability code and an optional Cause/Activity code. Allocation of these codes requires relevance of
each event to any R&M assessment to be determined. The four criteria are identified below:

a) First Character: MISSION CODE: This code indicates whether the incident caused the mission
undertaken by the aircraft and/or equipment to fail.

b) Second Character: MAINTENANCE CODE: This code identifies the level of maintenance at which
the incident was confirmed as a fault.

c) Third Character: ATTRIBUTABILITY CODE: This code indicates whether the confirmed fault was
attributable or not.

d) Fourth Character: CAUSE/ACTIVITY CODE: The ISC has the option of using this code which
summarises either the cause of an incident or the nature of a reported activity, e.g. scheduled
maintenance. If the Cause/Activity code is not used during incident sentencing the ISC should leave the
character space blank.

C.2.2 This degree of coding represents the minimum level of information required to codify an incident.
Strings of more characters are capable of coding incidents according to additional criteria. This extra
information may be desirable for contractor project management purposes, but it does not form an essential
part of an incident sentencing code and if required shall be recorded separately.

C.2.3 The sentencing codes and their corresponding descriptions are shown in table C1. A detailed
explanation of each code and rules for its application are given in clauses C 4, C.5, C.6 and C.7. These
codes are generally applicable to all types of aircraft and equipment regardless of their role.

C.2.4 The summary code is written as a serial without breaks e.g. AAAA.

C.2.5 It should be noted that Air systems sentencing codifies on the basis of failure significance.
Attributable mission and basic failures, as defined in Def Stan 00-40 (Part 1), and faults are identified by
examination of the summary code.

Unclassified
32
First Character Second Character Third Character Fourth Character

Mission Code Clause Maintenance Code Clause Attributability Code Clause Optional Cause/ Clause
Activity Code

st
A Mission Failure C4.2 A 1 Line C5.2 A. Attributable C6.2 A Design Weakness C7.2
nd
B Mission Success C4.3 B2 Line C5.3 B. Non-Attributable C6.3 B Quality Problem C7.3
rd
C 3 Line C5.4 C Design Change C7.4
th
Table 3 Incident Sentencing Codes - Air

1 No Mission Effect C4.4 D 4 Line C5.5 1 Not Relevant C6.4 D Quality Change C7.5
E No Fault Found C5.6 E Not Established C7.6
F Pre-Life Failure C7.7
1 No Maintenance C5.7 G Inadequate C7.8
Procedures
Unclassified

H No Fault Found C7.9


I Under C7.10
Investigation

1 Human Error C7.11


2 Secondary Event C7.12
3 Post-Life Failure C7.13
4 Planned C7.14
Maintenance
5 Recording Action C7.15

DEF STAN 00-44 Issue 1


33
DEF STAN 00-44 Issue 1

C.3 Incident Sentencing Procedure

C.3.1 This subject is introduced in Clause 6.3 of the Standard.

C.3.2 The sentencing of incidents is a relatively simple matter where the considerations are entirely
objective, but may become more complex where subjective judgements have to be made. The allocation of
a maintenance code, for example, is fairly straight forward as is the identification of a fault attributability and
cause/activity code - as long as sufficient information is available. The subjective allocation of the mission
code can be avoided by ensuring that mission failure criteria are fully defined before the start of the project.

C.3.3 There is no single sentencing procedure. In most cases it will be helpful to follow a number of pre-
determined decision steps but very often familiarity with an aircraft or equipment and R&M requirements will
enable a sentencing code to be assigned without following a formal procedure. In practice, developing
decision steps to assist in the allocation of the mission code could be beneficial. For aircraft, the mission
code decision is initially made by the aircraft captain and is based on the success of the mission undertaken.
This can often be a subjective decision; however, the final decision rests with the ISC once all the facts are
known. For equipments not aircraft based, such as ground based radars, missile system, communications
systems and field workshops, mission failure codes A and B can still be applied. However, the maintenance,
attributability and causes/activity codes are assigned by referring to the detailed explanations provided in
clauses C.5, C.6 and C.7.

C.3.4 The following decision steps illustrate the consideration and decisions which may be necessary in
sentencing an incident.

a) Step 1: Examine the incident description. Consider:

⎯ For aircraft, the mission code awarded by the aircraft captain.

⎯ The function of the failed/faulty item.

⎯ The degree of degradation.

⎯ The operational requirement of the undertaken mission.

⎯ Has the aircraft mission or flight been completed successfully, despite an incident caused by the air
platform or on-board equipment(s)? For ground systems equipment has the tasked operational
requirement been completed successfully despite an incident caused by the equipment? See clause
C.4 for guidance.

⎯ No: Mission code A, Step 2.

⎯ Yes: Mission code B, Step 2.

b) Step 2: Has the incident been confirmed as a fault at 1st Line?

⎯ No: Step 3.

⎯ Yes: Maintenance code A, Step 7.

c) Step 3: Has the incident been confirmed as a fault at 2nd Line?

⎯ No: Step 4.

⎯ Yes: Maintenance code B, Step 7.

Unclassified
34
DEF STAN 00-44 Issue 1

d) Step 4: Has the incident been confirmed as a fault at 3rd Line?

⎯ No: Step 5.

⎯ Yes: Maintenance code C, Step 7

e) Step 5: Has the incident been confirmed as a fault at 4th Line?

⎯ No: Step 6.

⎯ Yes: Maintenance code D, Step 7.

f) Step 6: Has the incident been found to be No Fault Found?

⎯ Yes: Maintenance code E, Step 9.

g) Step 7: Has the confirmed fault been sentenced as Attributable?

⎯ No: Step 8.

⎯ Yes: Attributability code A, Step 9

h) Step 8: Has the confirmed fault been sentenced as Non-Attributable?

⎯ Yes: Attributability code B, Step 9

i) Step 9: Has the incident cause/activity been established?

⎯ Yes: Optional use of Cause/Activity code using guidance at clause C.7.

C.4 Mission Codes

C.4.1 Mission codes are the 1st character in the incident sentencing code and represent whether the
incident had an effect on the capability of the aircraft or equipment which caused it to fail to carry out its
mission in accordance with the specification. For each particular project the definitions of mission success
and failure to be used shall be specified in the contractual documentation. The notes below are guidance to
assessors to illustrate the type of incidents which may constitute mission success and failure.

C.4.2 MISSION CODE A: MISSION FAILURE

C.4.2.1 The incident shall normally be considered to have been a mission failure if it caused the failure of
any of the specified mission critical functions.

C.4.2.2 For aircraft the following incidents would typically be sentenced using mission code A:

a) Those that affect aircraft safety critical equipment, in the air or on the ground that may lead to a mission
abort, aircraft return to base, emergency diversion or loss of aircraft.

b) Those that affect mission critical equipment of the air platform or the on-board equipments which
prevents achievement of the specified mission functions.

C.4.2.3 For ground systems equipment it should be used where incidents occurring in mission critical
equipment prevent total achievement of the specified mission functions.

Unclassified
35
DEF STAN 00-44 Issue 1

C.4.3 MISSION CODE B: MISSION SUCCESS

C.4.3.1 The incident shall normally be considered to have been a mission success provided the aircraft or
equipment satisfied all specified mission critical functions whilst executing its operational task or purpose.

C.4.3.2 Incidents where the aircraft or equipment has been able to carry out its mission in spite of event
occurrence are typically sentenced using mission code B. These incidents are typically faults in non mission-
critical items or functions.

C.4.4 MISSION CODE 1: NO MISSION EFFECT

C.4.4.1 The incident shall be coded as no mission effect when it occurs on an aircraft or equipment whilst
it is not being operated (i.e. scheduled maintenance actions, design changes, quality changes, information
only records), or the incident is not a fault but occurs whilst it is executing its operational task or purpose i.e.
comments or observations. This code would normally only be used in conjunction with some of the optional
cause/activity codes.

C.5 Maintenance Codes

C.5.1 Maintenance codes are the 2nd character in the incident sentencing code and indicate the Line of
Maintenance that provided the information.

C.5.2 MAINTENANCE CODE A: 1st LINE

C.5.2.1 This code is used when an incident which is a fault is confirmed at the 1st Line of Maintenance.

C.5.3 MAINTENANCE CODE B: 2nd LINE

C.5.3.1 This code is used when an incident which is a fault is confirmed at the 2nd Line of Maintenance.

C.5.4 MAINTENANCE CODE C: 3rd LINE

C.5.4.1 This code is used when an incident which is a fault is confirmed at the 3rd Line of Maintenance.

C.5.5 MAINTENANCE CODE D: 4th LINE

C.5.5.1 This code is used when an incident which is a fault is confirmed at the 4th Line of Maintenance.

C.5.6 MAINTENANCE CODE E: NO FAULT FOUND

C.5.6.1 Incidents where an equipment malfunctions in a specific manner during operational trialling but
subsequent tests and checks are unable to replicate the fault are sentenced using Maintenance code E. The
tested (suspect) unit is returned to the spares holding.

C.5.6.2 NO FAULT FOUND fault conditions are a common occurrence with both mechanical and
electrical/electronic items of equipment. Although they are a particular problem with electronic systems, e.g.
computers, recurrent incidents should be placed under investigation and may require changes to the system.
Incidents sentenced using the NO FAULT FOUND code are those where a re-test demonstrates the suspect
unit to be fully operational; these incidents are indicative of a number of potential problems, some examples
are listed below:

a) Problems which are remedied by the process of removal, stripping and testing - typical of these are
incidents occurring in mechanical units;

b) Intermittent faults;

c) Software programming errors;

d) Problems with the system integration, e.g. incompatibility between parts;

Unclassified
36
DEF STAN 00-44 Issue 1

e) Problems resulting from strict setting-up tolerances, which are readily achieved under factory conditions
but more difficult at 1st line - typical of these are faults and failures of electronic units.

C.5.7 MAINTENANCE CODE 1: NO MAINTENANCE

C.5.7.1 The following are sentenced using maintenance code 1:

a) Comments, observations, design changes, quality changes, i.e. information only records. These events
can only be indicated by using optional cause/activity codes.

b) Incidents where it is impossible to confirm a fault or establish it is no fault found, e.g. single-shot devices
which are launched and lost for fault investigation purposes.

C.6 Attributability Codes

C.6.1 Attributability codes are the 3rd character in the incident sentencing code and indicate whether the
confirmed mission failure or fault was attributable to the design or manufacture of the hardware, firmware or
software. Specific definitions of attributability and non-attributability are detailed within the terms of each
individual project contract. They are also duplicated in contractual documents such as In-Service
Demonstration Directives for the guidance of Assessment Teams and ISC’s.

C.6.2 ATTRIBUTABILITY CODE A: ATTRIBUTABLE

C.6.2.1 This code is used when an incident which is a mission failure or fault is to be sentenced as
attributable.

C.6.3 ATTRIBUTABILITY CODE B: NON-ATTRIBUTABLE

C.6.3.1 This code is used when an incident which is a mission failure or fault is to be sentenced as non-
attributable.

C.6.4 ATTRIBUTABILITY CODE 1: NOT RELEVANT

C.6.4.1 This code is used where the incident is not a mission failure or fault and is normally only used for
comments, observations, design changes, quality changes, i.e. information only records. These incidents
can only be indicated by using optional cause/activity codes.

C.7 Cause/Activity Codes

C.7.1 Cause/Activity codes are the 4th and final character in the incident sentencing code. They can be
used to indicate either the cause of an incident or the nature of a reported activity, e.g. comment, scheduled
maintenance. The identification of a cause may often require extensive investigations and in these cases it
is the practice to assign an interim code I, which is updated once investigations are completed.

C.7.2 CAUSE/ACTIVITY CODE A: DESIGN WEAKNESS

C.7.2.1 Incidents attributable to poor design are sentenced using cause/activity code A.

C.7.2.2 Technical problems which occur frequently are typically coded as a DESIGN WEAKNESS,
indicating that the fault/failure may be overcome by establishing and implementing a design change.

C.7.3 CAUSE/ACTIVITY CODE B: QUALITY PROBLEM

C.7.3.1 The following are sentenced using cause/activity code B:

a) Incidents attributable to poor quality control during manufacture/repair (see also NOTE at paragraph
C7.11.1);

Unclassified
37
DEF STAN 00-44 Issue 1

b) Incidents attributable to the wrong selection of parts during manufacture/repair, e.g. components of the
wrong part number/build standard;

c) Incidents attributable on proprietary or off-the-shelf items, e.g. underpowered, undersized, misaligned,


poor function.

d) Observations attributable to quality are sentenced to ORN 111B

C.7.3.2 Quality problems arise when manufactured items are out of specification. Clear evidence should
be produced to support these diagnoses.

C.7.4 CAUSE/ACTIVITY CODE C: DESIGN CHANGE

C.7.4.1 The following are sentenced using cause/activity code C:

a) Information only records signifying a change in the equipment build standard following the
implementation of a engineering design change;

b) Design changes are only sentenced as ORN 111C; no other combination is valid.

C.7.4.2 This code should not be assigned during fixed build standard trials, i.e. demonstration trials.

C.7.4.3 Design changes can be implemented in one of two ways:

a) As the corrective maintenance action in response to an incident. In these cases there shall be two
records:

1) The primary record - to describe the state, maintenance and the cause of the incident;

2) A sub-record to indicate that a design modification has been implemented. Normal rules apply for
the sentencing of the primary record; the sub-record is sentenced 111C.

b) As a separate record, not in direct response to an incident. These actions are primary incidents, not
relating to an incident or maintenance action but to a change in build standard - whether it be the fitting
of a new part or reversion to an old design.

C.7.4.4 Sentencing codes are applied on an individual basis and separate records are required for each
equipment participating in a test. Once a design change has been adopted this forms the updated build
standard; subsequent design faults of a modified item are sentenced in the usual way using cause/activity
code A.

C.7.5 CAUSE/ACTIVITY CODE D: QUALITY CHANGE

C.7.5.1 The following are sentenced using cause/activity code D:

a) Information only records signifying a change in the manufacturing process or a change of component
supplier;

b) Quality changes are only sentenced as 111D.

C.7.5.2 This code should not be assigned during fixed build standard trials, i.e. reliability and
maintainability demonstrations.

C.7.5.3 Quality changes can be implemented in one of two ways:

a) As the corrective maintenance action in response to an event. In these cases there shall be two
records:

1) The primary record - to describe the state, maintenance and the cause of the incident;

2) A sub-record - to indicate that a quality change has been implemented. Normal rules apply for the
sentencing of the primary record; the sub-record is sentenced 111D;
Unclassified
38
DEF STAN 00-44 Issue 1

b) As a separate record, not in direct response to an incident. These actions are primary incidents, not
relating to an incident or maintenance action but to a change in the production process or component
supplier. These records are sentenced 111D.

C.7.5.4 Sentencing codes are applied on an individual basis and separate records are required for each
equipment participating in a test. Once a quality change has been adopted this forms the standard
production method or component source; subsequent quality problems sentenced using the cause/activity
code B.

C.7.6 CAUSE/ACTIVITY CODE E: NOT ESTABLISHED

C.7.6.1 Incidents where the cause has not been established and the event is not UNDER
INVESTIGATION are sentenced using cause/activity code E.

C.7.6.2 The NOT ESTABLISHED cause code E is assigned where there is doubt concerning the cause
diagnosis. Cause/activity code E may occasionally be assigned to incidents where no investigations are
undertaken but the majority of unestablished causes would be investigated and sentenced using the interim
cause/activity code I. Incidents UNDER INVESTIGATION are typically re-classified as NOT ESTABLISHED
E if results are inconclusive.

C.7.7 CAUSE/ACTIVITY CODE F: PRE-LIFE FAILURE

C.7.7.1 Incidents attributable to the premature degradation of a lifed item are sentenced using
cause/activity code F. This code indicated the failure of a lifed item which has not achieved its durability
target.

C.7.7.2 The PRE-LIFED FAILURE cause code F is only applicable to assemblies with lifing specifications;
which should be defined in the R&M plan for the project. Care should be taken when applying this coding as
it is only applicable to events of life limited items which are caused by wear or other progressive degradation
mechanisms.

C.7.8 CAUSE/ACTIVITY CODE G: INADEQUATE PROCEDURES

C.7.8.1 The following are sentenced using cause/activity code G:

a) Incidents attributable to incorrect or inadequate technical support literature e.g. Handbooks, Air
Publications [AP’s], Operating and Maintenance Instructions etc;

b) Incidents caused by inadequately trained operators or maintainers. These events indicate faults in the
training procedures and/or the training documentation.

NOTE This code is only applicable to operating and maintenance procedures and not to quality, design or
manufacturing procedures.

C.7.9 CAUSE/ACTIVITY CODE H: NO FAULT FOUND

C.7.9.1 Incidents are sentenced with cause/activity code H when they meet the criteria in paragraph C.5.6.

C.7.10 CAUSE/CRITERIA CODE I: UNDER INVESTIGATION

C.7.10.1 The following records are sentenced using cause/activity code I:

a) Incidents where the cause is undiagnosed and cannot be established by the ISC on the basis of the
available technical information, further investigations may be instigated by the ISC. This application of
the code would be employed if, for example, the investigation was awaiting the removal and inspection
of an item;

b) Incidents where the cause is known but the event is held over for further investigation at the request of
the ISC. This application of the code is typically employed where the cause is thought to be a design
weakness. It is also used where the effect on the mission is not clear;

c) Observations where the cause is unestablished or further investigations are required are coded 111I.
Unclassified
39
DEF STAN 00-44 Issue 1

C.7.10.2 The cause/activity code I is a “catch-all” coding typically assigned where there is no agreement
over cause or where the incident itself is to be scrutinised in greater detail. Investigations may be initiated
for a variety of reasons. Cause diagnosis in one purpose but investigations may also be required to, for
example, establish the extent of a problem or its impact on the mission. Incidents sentenced using
cause/activity code I are carried over, presented and discussed at all subsequent meetings until the event is
finally coded. Events UNDER INVESTIGATION are typically re-coded as NOT ESTABLISHED if the
investigations into cause are inconclusive.

C.7.11 CAUSE/ACTIVITY CODE 1: HUMAN ERROR

C.7.11.1 The following are sentenced using cause/activity code 1:

a) Incidents resulting from negligence, misuse or abuse by the operators and/or maintainers;

b) Inadvertent operation beyond performance limits, inadvertent/preventable accidents.

NOTE The HUMAN ERROR cause diagnosis is not applicable to incidents arising from poor practices during the
manufacturing process or during other processes completed at places of manufacture. Such incidents are sentenced as
QUALITY PROBLEMS using cause/activity code B.

C.7.11.2 Incidents originally considered to be caused by human error should be re-assessed, and possibly
re-coded, if they recur frequently and persistently. These recurrent arisings should be examined to see
whether they are indicative either of a design weakness or of defects in the operation or maintenance
procedures. All installed items should be robust and capable of withstanding a reasonable degree of inept
handling and operation. Items which are unable to survive realistic in-Service usage conditions are not
satisfactorily and in these cases remedial design or procedural changes should be considered.

C.7.12 CAUSE/ACTIVITY CODE 2: SECONDARY EVENT

C.7.12.1 The following records are sentenced using cause/activity code 2:

a) This code is used when the event was not the primary cause of an event. A primary cause for an event
shall be established in all cases and sentenced accordingly;

b) A chain of events with a common cause. These records correspond to a primary event and the primary
event shall be sentenced to indicate the original cause;

c) Symptomatic or diagnostic events e.g. warning light, blown fuse;

d) Incidents arising from severe or harsh operation as a result of an earlier failure.

NOTE 1 Cause/activity code 2 is not assigned to events of redundancy and reversionary-mode items.

NOTE 2 SECONDARY EVENT records shall refer to primary or related incidents, e.g. “Loss of power, see event
1234/2”.

Unclassified
40
DEF STAN 00-44 Issue 1

C.7.13 CAUSE/ACTIVITY CODE 3: POST-LIFE FAILURE

C.7.13.1 Cause/activity code 3 is used to sentence incident arising from over-use or excessive use.
Failures arising after a lifing target has been reached are coded in this manner. Cause/activity code 3 is
assigned to the three types of event listed below.

a) To codify incidents arising from equipment knowingly operated beyond the time at which it should be
replaced. This may occur either for trials expediency or with the deliberate intention of testing to failure
or “close to failure”. Cause/activity code 3 is applicable to lifed terms, expendable items and other items
which, in normal circumstances, would be replaced in accordance with planned maintenance schedules
or condition monitoring.

b) To codify incidents arising from equipment which has, in error, been operated beyond the time at which
it should be replaced. This category of events applies specifically to failures of lifed items which are
inadvertently operated beyond their specified life.

NOTE incidents attributable to defects in the technical support literature, i.e. operating and maintenance
instructions, are sentenced using cause/activity code G, INADEQUATE PROCEDURES.

c) Cause/activity code 3 may also be assigned, in exceptional cases, to indicate degradation and failure
which has arisen as a direct result of operating or maintenance practices which are unrepresentative of
in-Service usage conditions. This condition should only arise during reliability growth testing. One
example of this would be the failure of a peripheral component caused by over-frequent removal to gain
access during testing. Further examples include failures arising from periods of accelerated or over-
stressed testing.

C.7.14 CAUSE/ACTIVITY CODE 4: PLANNED MAINTENANCE

C.7.14.1 The following are sentenced using cause/activity code 4:

a) Planned maintenance activities and condition monitoring tasks;

b) Comments indicating that periodic maintenance or scheduled overhauls have taken place are typically
sentenced 1214.

NOTE Unplanned maintenance activities not specified in the original or revised maintenance plans are considered
to be corrective maintenance.

C.7.15 CAUSE/ACTIVITY CODE 5: RECORDING ACTION

C.7.15.1 The following are sentenced using cause/activity code 5:

a) Incidents involving corrective maintenance action on items with limited life but not subject to scheduled
maintenance;

b) Incidents resulting from unpreventable arisings;

C.7.16 INFORMATION ONLY RECORDS - sentenced as ORN 1215 include:

a) Sub-records;

b) Maintenance and diagnostic sub-records;

c) Suggestions;

d) Software diagnostic checks;

e) Temporary modifications;

f) Comments;

g) Observations;
Unclassified
41
DEF STAN 00-44 Issue 1

h) Special maintenance.

NOTE Incidents arising from non-trials activities or during periods of extraneous operation are sentenced to normal
rules, based on the three criteria of mission capability, maintenance involvement, and cause. These incidents may also
be distinguished by an additional trial relevance code which would indicate activities and incidents not relevant to an
assessment of R&M achievement. Nevertheless, R&M achievement is closely related to total cumulative usage and this
code should not be used to artificially raise achievement by windowing of data.

Unclassified
42
DEF STAN 00-44 Issue 1

Inside Rear Cover

Unclassified
43
©Crown Copyright 2006

Copying Only as Agreed with DStan

Defence Standards are Published by and Obtainable from:

Defence Procurement Agency

An Executive Agency of The Ministry of Defence

UK Defence Standardization

Kentigern House

65 Brown Street

GLASGOW G2 8EX

DStan Helpdesk

Tel 0141 224 2531/2

Fax 0141 224 2503

Internet e-mail enquiries@dstan.mod.uk

File Reference

The DStan file reference relating to work on this standard is .

Contract Requirements

When Defence Standards are incorporated into contracts users are responsible for their correct
application and for complying with contractual and statutory requirements. Compliance with a Defence
Standard does not in itself confer immunity from legal obligations.

Revision of Defence Standards

Defence Standards are revised as necessary by an up issue or amendment. It is important that users
of Defence Standards should ascertain that they are in possession of the latest issue or amendment.
Information on all Defence Standards can be found on the DStan Website www.dstan.mod.uk,
updated weekly and supplemented regularly by Standards in Defence News (SID News). Any person
who, when making use of a Defence Standard encounters an inaccuracy or ambiguity is requested to
notify UK Defence Standardization (DStan) without delay in order that the matter may be investigated
and appropriate action taken.

You might also like