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 No Will the failure have a direct and adverse effect on environmental, health, security or safety? Will the failure have a direct and adverse effect on operations? Will the failure result in economic loss? (Cost of Failure + Damage > Cost of preventive task ) No No Will the failure be undetectable by the equipment Operators? Yes Yes Yes Yes Hidden Failure Safety/Environmental Failure Operations Failure Economic Failure Maintenance Task Analysis (MTA) If risk of failure is unacceptable, Re-design or redundancy is required, else: Look for a Preventive Maintenance Action Run to failure Redesign system, install redundancy, or Accept the risk of Failure No No No Is there an effective Condition-based technology or approach? (Hidden failures only) Is there an effective failure finding task? Is there an effective Interval based task? Yes Yes Yes Maintenance Task Description Define Corrective task or Operational Procedure Schedule and perform Failure-finding Task: Detective Develop and perform Condition-basedTask: Predictive Schedule and perform Interval-based Task: Preventive Corrective Maintenance Preventive Maintenance
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 . . .