Transcript Integrating Through-Life Supportability Analysis within

IETMs
The Breeding, Care and Feeding of
Interactive Electronic Technical Manuals
Martin Passfield
Definitions



Technical Manual - includes the cataloguing of technical
information that defines and describes maintenance
activity necessary for the support of the IETM subject
equipment
 Could be paper, could be electronic
Electronic - presenting data via electronic media
 No other technology allows 'interactive'
Interactive - the communication between the Technical
Manual and the operator
 Highly subjective
 Many possibilities
Breeding IETM's

Original approach was 'classes' – 5 classes in
two types were defined:



Type I – classes 1-3: Basically electronic
implementations of a paper manual, offering
increasing levels of interactivity via hyperlinking and
SGML
Type II – classes 4 & 5: Based on a database, rather
than a paper script layout.
Modern approach is to use a functional matrix of
requirements, to specify those features required
in a particular IETM product
S1000D

This standard should (must?) be understood
and used to define IETM requirements.


Re-use of data is central to effectivness
Common Source Database used to efficiently store
applicable data



Modules identified by a Data Module Code (DMC) that
allows proper configuration management and use tracking
Useful in development as well as product support
Non-proprietary, distributable across IT systems
More than just a paper manual
The true power of IETM's comes when the
'electronic' capabilities of the platform are
employed. Examples are:
- JIT training, using video clips and 3D graphics
- Spares ordering direct from the IETM, with direct
reporting back of availability and wait time. This
would require some 'connectivity', like say, oh let
me guess – a smart phone app?
There will be plenty more 'gizmo' applications that
an old buzzard like me would not think of.
A little Canadian Culture . . .

Quotes from Professor Marshall McCluan:
 “The medium is the message”
 This is merely to say that the personal and social
consequences of any medium / that is, of any extension
of ourselves / result from the new scale that is introduced
into our affairs by each extension of ourselves, or by any
new technology.

“We drive into the future using only our rear view mirror.”
IETM's have
Medium, and they have Message
The Aim of all technical manuals is to:
Facilitate the communication of ideas and
concepts to the audience, and to direct the
audience in a particular course of action.
The facilitation of communication is
accomplished by the Medium, while the
direction of the audience is accomplished
by the Message.
Lets discuss the Medium first . . . .
The Care of IETM's
I
E TM
What could possibly go wrong?
Hardware – depending on the environment,
the hardware probably won't fail, but might
get destroyed.
Repair is therefore probably not required.
Replacement will be required.
So, lets just go and buy a new one . . . . .
An Imaginary Example
The year is 1987. The M113 has been in service
for about 20 years, and is long overdue for a
mid-life upgrade, to take it to its 30 year
expected life.
The far-sighted Army support personnel (avid
StarTrek fans, one and all) decide that an IETM
is required to support all the new radio's,
intercoms and other hi-tech stuff being fitted to
the vehicle.
The IETM is to be implemented on state-of-the-art
commercial equipment. Say hello to . . . .
The M113 IETM
The IETM is hosted on a Commodore 64,
supported by a mass-memory module (MMM)
which has limitless memory (its a cassette
drive). The illustrations are done in rastor
graphics, with 24 dpi (Dots per Inch) which is
supported by a specialized adjunct processor –
the wizardly Sinclair Z-80.
However, due to unforeseen circumstances, the
M113 was required to solder on, and on, and on,
and is now expected to remain in service until
2022.
So the moral of the story is . . . .
Because IETM hardware is “computery”, it is going
to be obsolete long before the system it
supports.
IETM hardware need careful support planning,
which recognises the realities of its nature. The
more 'COTS' the solution is, the shorter time it
will last. Given that a COTS computer has a
generational life of only about 2 1/2 years, our
M113 IETM will go through 14 generations of
computers prior to its (now) planned retirement
in 2022.
Yes, the software too . . . .
IETM's contain operating software, that also
has a life, which may also be short if its
commercial in nature. The software
loaded on the device, and the environment
that is used to integrate this software, and
support the load and display of the data,
must also be maintained.
The Feeding of IETM's
So, any technical manual requires data.
Where does this data come from? Two
competent sources:
Analysis of the maintenance needs, and
Experience in fixing the subject equipment
There may be other sources, but they may
not be competent.
The best source is a combination of the
above.
Analysis vs Experience
Analysis tends to
identify all the
obvious issues,
even those that
have low probability
of occurring
Experience tends to
be accurate for
common problems,
but is ignorant of
problems not
yet encountered
Developing the data
When looking at the source of data, there is
another consideration – data structure. A
formal analysis process will provide the
resulting data in some sort of structured
format, which, if correctly done, will
support incorporation into the IETM.
Experience based data may not be so
formally structured, and thus may thwart
hopes of providing a truly interactive (type
II) IETM.
Maintenance data development
Usually, for military products, technical
support requirements (including the data
ending up in the tech pub) is determined
by analysis, in particular, the process
known as Logistic Support Analysis.
At the core of LSA, the Maintenance Task
Analysis determines what should be done,
and the Maintenance task Description
process documents the task and all its
various necessary support resources.
Identify Item for
analysis
Identify Item’s
Function(s)
Describe Failures of
function(s)
Identify Failure Mode
(Cause) of the failure
Describe Failure Effect
(Symptom)
Failure Mode
and Effect
Analysis
(FMEA)
Failure Consequence
No
Will the failure have a direct and
adverse effect on environmental,
health, security or safety?
Will the failure be undetectable by
the equipment Operators?
Yes
Safety/Environmental
Failure
No
Will the failure result in
economic loss?
No
(Cost of Failure + Damage > Cost of
preventive task )
Yes
Yes
Operations Failure
Economic Failure
If risk of failure is unacceptable, Re-design or
redundancy is required, else:
Look for a Preventive
Maintenance Action
(Hidden failures only) Is there
an effective failure finding
task?
No
Is there an effective Condition- No
based
No
Is there an effective
Interval based task?
Yes
Develop and perform Condition-based
Schedule and perform Interval-
finding Task:
Task:
based Task:
Predictive
Preventive Maintenance
redundancy,
or
Yes
Schedule and perform Failure-
Detective
Redesign system, install
Accept the risk of Failure
technology or approach?
Yes
Maintenance
Task
Description
Will the failure have a
direct and adverse effect
on operations?
Yes
Hidden Failure
Maintenance
Task
Analysis
(MTA)
No
Preventive
Define Corrective task or
Operational Procedure
Corrective
Maintenance
Run to
failure
Eat the Premium catfood.
When a new system is introduced into service, the
new support solution, based on the best efforts
of the LSA team, is also introduced.
Sadly, even the most heroic LSA team will not get
everything right. Also, like any battle plan, the
intended maintenance schedule and procedures
may not fare well when actually performed in the
operating environment.
The solution to this is to perform Maintenance
Effectiveness Reviews (MER's)
Using the MER to improve the IETM.
The MER has the objective of 'tuning up' the
support solution to get the best
performance at the least cost. The IETM
can benefit from this activity, and is also a
powerful tool for the dissemination of the
updated maintenance activities.
How is all this accomplished in the real
world?
Over to you, Frank . . .