What went wrong with ILS and can IPS fix it?

What went wrong with ILS and can IPS fix it?  By Mark Willis, Head of IPS

Introduction

In November 2023, I was asked to contribute to the Tech Data World (TDW) Live event, which was held in Bristol, England. My presentation looked at the history of Integrated Logistic Support (ILS), why it developed a poor reputation, the origins of Integrated Product Support (IPS) and whether IPS could address the poor reputation of ILS.

Several of my LinkedIn contacts have asked if I would put the contents of my presentation in a paper for general consumption. This document is said paper.

The Origins of ILS

The purpose of ILS is to influence system and component design (and integration) from a support perspective; this purpose does not change with the move to IPS. There are a few things that we must not forget. Primarily, ILS (and IPS) is a systems engineering activity within the ‘by design’ disciplines – what we are trying to achieve is supportable by design. Secondly, in the world of Commercial Off The Shelf (COTS) systems or systems of systems, design influence is limited by the ‘off the shelf’ nature of the system components. However, the IPS engineer should be looking at Integration Influence – influencing the way the system is integrated from a support perspective.

ILS originated in the US Army in 1955 with Department of Defense (DoD) Directive 3232.1, which focused on readiness, support, and cost effectiveness. This focus has not changed with the advent of IPS. In 1964, DoD Directive 4100.035 was issued which expanded the scope and influence of the earlier Directive.

The first real ILS Standard was MIL STD 1388-1 which was published in 1973; 1388-1A was published in 1983. UK Ministry of Defence (MOD) copied 1388 with Defence Standard (Def Stan) 00-60 in 1993. Unlike other Def Stans at the time, 00-60 was a complex contracting document, effectively providing instruction to commercial officers on how to contract for ILS packages or services. The period 2001 to 2010 saw the Def Stan 00-60 Working Group attempt to improve usability of the document and in 2010 Issue 1 of Def Stan 00-600 was published. Def Stan 00-600 realigned with other Def Stans, but the resultant document had removed much of the useful commercial information. Recognising the information gap, UK MOD released Joint Services Publication (JSP) 886 Defence Supply Chain Manual of which Volume 7 is dedicated to ILS. JSP886 is widely recognised by UK ILS practitioners as an excellent source of ILS information. In 2016, against a UK MOD background of JSP rationalization, JSP886 was withdrawn. The Defence Logistic Framework (DLF) became primary UK MOD reference document in 2016. The document sits in the Knowledge in Defence area of the DE&S intranet and can only be seen by UK MOD, unless industry is granted access. There are continuing discussions about the efficacy of DLF in terms of the ILS/IPS discipline.

In US MIL STD 1388-1a/2b were cancelled on 29th November 1996 and replaced with Mil-Hdbk-502 and Mil-PRF-49506. Simultaneously, SAE issued GEIA-Std-0007 and TA-Std-0017 which were close approximations of MIL STD 1388.

Other standards of note – Def (Aust) 5691 (LSA)/5692 (LSAR) – MIL STD 1388 in another guise.

Why do we undertake ILS?

Aside from the ‘design influence from a support perspective’ statement, ILS is trying to achieve an optimal support solution. This means that we are trying to achieve an optimal balance between through life support costs and system availability – that is to say optimal bang for your buck.

Numerous studies have been undertaken into the proportion of through life cost expended during the in-service phase of the system lifecycle. Latest thinking is that 20% of through life cost is the capital cost of the project, where 80% of through life cost is spent during the in-service phase.

 Figure 1. The Through Life Cost Iceberg shows graphically the proportion spent during the in-service phase of the system life cycle.

A deal of debate has been undertaken around the precise figures quoted, but it is estimated that capital cost varies from 20% to 30% and the in-service costs vary from 70% to 80% of through life cost. Whichever end of the spectrum you choose, the in-service cost is a significant challenge and the one which offers the highest through life savings potential if the support solution is optimized.

At this stage, considering the foregoing, it may be opportune to ask the question: why is it, that when project cost pressures are felt, investment in the support solution is the first to be cut? The Customer may want a ‘shiny bright pointy thing’ but it is of no use to them if they cannot support it or deliver a mission effectively because the support solution has been neglected. That reason in isolation is sufficient justification for ILS.

Why did ILS fail?

The discussion around the perceived failure of ILS can be an emotive one, but the following is a list of some of the prominent reasons emerging from our research:

• OEMs (and MODs) did not employ their best engineers delivering ILS. ILS was seen as a product/customer support function and not seen as the cutting edge of engineering. This perception of ILS being a customer support function is interesting given the emergence of sustaining engineering as one of the new IPS elements.
• The early ILS Managers had a lack of expertise and were unwilling or fearful of tailoring the ILS process to suit the project requirements. Consequently, the result for the Customer was an all or nothing approach. Often no coherent support strategy had been developed. ILS plans were copied from previous projects with no intellect applied, which resulted in poor ILS Statements of Work and equally poor responses from the Contractor. The result being expensive and ineffective support solutions.
• Generally, there was a lack of positive publicity regarding the benefits of ILS so, OEMs (around the world) did not believe in ILS. OEMs believed ILS was something the Customer wanted ergo they could make money from it, but it was not something that they really understood or focused on.
• ILS and the supporting Logistic Support Analysis (LSA) processes were data hungry. In the early days there was limited data analysis and computing power, so the ILS practitioner was unable to feed the designers with timely results of the support analysis. Consequently, the ILS practitioner got left behind by the designers.
• To be effective in the design influence arena, ILS engineers must be collocated with the design team. ILS engineers were isolated (located somewhere else) so could not provide effective design influence. It is difficult to influence the designer unless you are sat alongside.
• Finally, ILS lacked the through life perspective; it stopped at the ‘in service’ phase. In hindsight, we have learnt that ILS must be a through life discipline. At the very least the LSA database must be kept up to date to feed publication changes.

So, where did IPS come from?

In 2009, the US DoD reiterated its commitment to life cycle product support. The following year (2010) it established in US Law the post of Product Support Manager under Section 805 of Public Law 111-84 National Defense Authorization Act for Fiscal Year 2010. To coincide with the Act, the Defense Acquisition University (DAU) published the Product Support Manager’s Guidebook which established the 12 IPS elements. In 2011, DAU issued the IPS Elements Guidebook which is an extensive guide to delivering the entirety of IPS.

What is IPS?

IPS consists of 12 elements per Figure 2 below:

Figure 2. IPS introduces 12 elements of a through life system support process.

Product Support Management is the development and implementation of product support strategies to ensure supportability is considered throughout the system life cycle through the optimization of the key performance outcomes of reliability, availability, maintainability, and reduction of total ownership costs. The scope of product support management planning and execution includes the enterprise level integration of all 12 integrated product support elements throughout the lifecycle.

Design Interface is the integration of the quantitative design characteristics of systems engineering (reliability, maintainability, etc.) with the functional logistics elements (IPS Elements). Design interface reflects the driving relationship of system design parameters to product support resource requirements. The basic items that need to be considered as part of the design interface include the following:

• Availability, Reliability and Maintainability (AR&M)
• Supportability
• Testability requirements
• Support equipment requirements
• Diagnostics/prognostics and health management
• IPS Elements
• Affordability
• Configuration Management
• Safety requirements
• Environmental and HAZMAT Requirements
• Human Systems Integration
• Corrosion Prevention and Control
• Anti-Tamper
• Habitability
• Disposal
• Legal Requirements

Facilities and Infrastructure are the permanent and semi-permanent real property assets required to support a system, including studies to define types of facilities or facility improvements, location, space needs, environmental and security requirements, and equipment. It includes facilities for training, equipment storage, maintenance, supply storage, ammunition storage, and so forth.

Computer Resources encompasses encompass the facilities, hardware, software, firmware, documentation, workforce, and personnel needed to operate and support mission critical information technology systems hardware/software systems.

Maintenance Planning and Management establishes maintenance concepts and requirements for the life of the system. It includes, but is not limited to, levels of repair, repair times, testability requirements, support equipment needs, workforce skills, facilities, Interservice, organic and contractor mix of repair responsibility, site activation, etc. This element has a great impact on the planning, development, and acquisition of other logistics support elements.

Workforce and Personnel involves the identification and acquisition of personnel (military & civilian) with the skills and grades required to operate, maintain, and support systems over their lifetime. Early identification is essential. If the needed workforce is an additive requirement to existing workforce levels of an organization, a formalized process of identification and justification must be made to higher authority. Add to this the necessity to train these people, new and existing, in their respective functions on the new system, and the seriousness of any delays in the accomplishment of this element becomes apparent. In the case of military requirements, workforce needs can, and in many cases do, ripple all the way back to recruiting quotas.

Packaging, Handling, Storage, and Transportation (PHS&T) is the combination of resources, processes, procedures, design, considerations, and methods to ensure that all system, equipment, and support items are preserved, packaged, handled, and transported properly, including environmental considerations, equipment preservation for short and long termshort- and long-term storage, and transportability.

Supply Support consists of all management actions, procedures, and techniques necessary to determine requirements to acquire, catalogue, receive, store, transfer, issue and dispose of spares, repair parts, and supplies. Simply, this means having the right spares, repair parts, and supplies available, in the right quantities, at the right place, at the right time, at the right price. The process includes provisioning for initial support, in addition to acquiring, distributing, and replenishing inventories.

Support Equipment is made up of all equipment (mobile or fixed) required to support the operation and maintenance of a system. This includes ground handling and maintenance equipment, tools, metrology, and calibration equipment, and manual and Automatic Test Equipment (ATE). During the acquisition of systems, program managers are expected to decrease the proliferation of support equipment into the inventory by minimizing the development of new support equipment and giving more attention to the use of existing government or commercial equipment.

Sustaining Engineering spans those technical tasks (engineering and logistics investigations and analyses) to ensure continued operation and maintenance of a system with managed (known) risk. Sustaining Engineering involves identification, review, assessment, and resolution of deficiencies throughout a system’s life cycle. Sustaining Engineering both returns a system to its baselined configuration and capability and identifies opportunities for performance and capability enhancement. It includes measurement, identification, and verification of system technical and supportability deficiencies, associated root cause analyses, evaluation of the potential for deficiency correction, and the development of a range of corrective action options.

Technical Data Management consists of recorded information of scientific or technical nature, regardless of form or character (such as equipment Technical Manuals (TMs) and engineering drawings), engineering data, specifications, standards, and Data Item Descriptions (DIDs). Technical Manuals, including Interactive Electronic Technical Manuals (IETMs) and engineering models or drawings, are the most expensive and probably the most important data acquisitions made in support of a system. TMs and IETMs provide the instructions for operation and maintenance of a system.

Training and Training Support consists of the policy, processes, procedures, techniques, training devices, and equipment used to train civilian and military personnel to acquire, operate and support a system. This includes individual and crew training, new equipment training, initial, formal, and on-the-job training.

The difference between ILS & IPS

Simply, IPS introduces a through life product support management approach to the support solution where ILS used to ‘finish’ at product delivery.

So, what really is different?

• The two new elements are “Product Support Management” and “Sustaining Engineering.” Both include an extensive life cycle management focus, andfocus and include activities and aspects that extend across the life cycle, often beyond the traditional logistics domain.
• The Maintenance Planning element expands to include Maintenance Management
• Infrastructure has been added to the Facilities element, expanding beyond what some perceived were primarily focused on “bricks and mortar” buildings.
• Computer Resources Support simply becomes Computer Resources, focused on supporting hardware and software, as well as support services necessary to ensure effective and affordable product support.
• The important word and common thread between ILS and IPS Elements is “Integrated.” Regardless of how many elements there are, or exactly how each is defined, to design, develop, deploy, and sustain an affordable, effective system support strategy, the elements of that support must be integrated:
• How does an action or decision relative to one IPS Element impact processes and outcomes in other IPS Elements?

IPS is no more than competent ILS practitioners and professional organizations were formerly delivering. To an extent, IPS has simply formalized erstwhile good ILS practice.

History of the ASD/AIA S series Specifications

The early concept of S1000D was established as an AECMA Specification early in the 1980s. NATO then led the establishment of an Initial Working Group for an ILS suite of specifications in 1993. In 2003, AECMA and AIA signed an MOU associated with S1000D. ASD formed in 2004. In 2007 the scope of the MOU was expanded to include civil aviation and the ATA specifications. Further expansion of the MOU took place in 2010 to encompass development of a suite of ILS specifications and the ILS Council was formed. In 2011 the SX000i Working Group was formed to provide an overarching ILS specification.

In 2019 the ILS Council agreed to adopt the term IPS, and the ILS Council became the IPS Council. In 2021, the IPS Council agreed to harmonize all the S series specifications and to adopt a Block Release process. The first block release was in 2022, with the second block release planned for 2024.

Currently, the following specifications are available or in the process of development:

• SX000i – International guide for the use of the S-Series of Integrated Product Support (IPS) specifications.(The overarching specification).
• S1000D – International specification for technical publications using a common source database.
• S2000M – International specification for material management – Integrated data processing
• S3000L – International specification for Product Support Analysis – PSA.
• S4000P – International specification for developing and continuously improving preventive maintenance.
• S5000F – International specification for in-service data feedback.
• S6000T – International specification for training analysis and design.

All specifications are accessible at no cost via the ASD website.

Can IPS fix the problems of ILS?
Yes, if we learn the lessons of the past.
Yes, if we take the discipline seriously…no more reinvention.
Yes, if we design an attractive career path for young practitioners.
Yes, if we commit early capital funding to the support solution…and don’t cut it when cash gets tight. Yes, if we exploit the data, decisions, and computational opportunities.
Yes, if we work as an integrated design team.
Yes, if we publicize the failures and successes.

Some good reading

• Logistics Engineering & Management – Blanchard
• Integrated Logistics Support Handbook – James V Jones
• Product Support Manager’s Guidebook – US DoD DAU
• Integrated Product Support (IPS) Elements Guidebook – US DoD DAU
• Systems Engineering and Analysis – Blanchard & Fabrycky
• Reliability & Maintainability Engineering – Eberling
• Systems Maintainability – Knezevic
• SX000i International Specification for Integrated Product Support – ASD/AIA

Final thoughts

There is no doubt that the development and implementation of an effective support solution will optimize through life cost. However, true optimization can only take place if the investment is made up front to develop an effective support solution alongside system design. Design for support is a pivotal systems engineering activity to minimize the support demand from a system in use. Design of support is an even more important activity to optimize the support/readiness of that system throughout its lengthy in-service life. Re-design of both during the full systems life cycle maximizes overall system effectiveness. Reducing investment in support solution development and improvement will reduce the effectiveness of the support solution, reduce availability, and increase through life cost – proven fact!