LSA

Logistic Support Analysis LSA comprises six main areas. RAM, FMEA, FMECA, RCM, LORA and LCCA.

Logistic Support Analysis Software: eLSA
Logistic Support Analysis Record Software: LSAR

Sep 012016
 

Integrated Logistics Support Services

The ten ILS elements

The ten ILS elements

 

The ten areas of ILS:

Why is ILS Important to Defence ?
For Defence, it’s ensuring that:

  •  we provide the optimum Mission System to the user
  •  it’s provided to:
    •  the right person
    •  at the right place
    •  at the right time
  •  deliver it in best possible condition with the ability to fulfil its designed mission role under the stated operational conditions as per it’s mission profile.

Why is ILS Important to the Contractor / Service Provider ?
Knowing and understanding the ILS requirements permits the contractor to deliver what Defence needs to:

  •  accurately acquire and sustain the Materiel System through life at the greatest Operational Availability (Ao) for the best Total Cost of Ownership (TCO) to Defence and the Tax payer.

To do this in a cost effective manner, the contractor must be able to deliver equipment and supporting documentation:

  •  without duplication of effort or continuous rework
  •  delivering best ILS practice and product to Defence thereby enabling them to be viewed by Defence as a preferred tenderer for future work (Scorecard), and
  •  be internationally competitive in the Defence arena

The most attractive part for the contractors:

  •  Sustainment activities or Through Life Support (TLS) contracts for Defence materiel are often more lucrative than the supply of the original equipment
  •  TLS of the Mission System and many of the Support Systems are now being managed and maintained by the OEM.
  •  Generally, 20% to 30% of funds are spent in Acquisition and 70% to 80% spent in Sustainment.

How do you do ILS ?
You don’t “DO” ILS; you perform Logistic Support Analysis (LSA) tasks that allows you to achieve the ILS outcomes.
Those LSA Disciplines include:

  •  Reliability, Availability and Maintainability (RAM)
  •  Failure Modes, Effects & Criticality Analysis (FMECA) (done during design)
  •  Failure Modes & Effects Analysis (FMEA) (done after design to determine maintenance tasks)
  •  Reliability Centred Maintenance (RCM)
  •  Level Of Repair Analysis (LORA)
  •  Verification and Validation (V&V)
  •  Life Cycle Costing Analysis (LCCA)

So what is Logistics Support Analysis (LSA)?

LSA is a selected group of analytical techniques.
It is conducted continually throughout the Materiel Life Cycle (MLC).
It provides the data to support improvements to the efficiency of the Materiel System.
All data from the analysis is stored in the Logistic Support Analysis Record (LSAR).

Sep 012016
 

Systems Engineering

Systems Engineering is a design approach to achieve an integrated system that is designed from the start to accommodate the logistic support requirements.

Videos related to Systems Engineering

Logistics Engineering YouTube play

A System is a collection of elements or equipment that when combined produce an outcome not obtainable by the elements alone.
A Systems Integrator or Systems Engineer is tasked with integrating the elements, which may themselves be completely self-contained items or sub systems, so that they can be connected together or communicate with each other and work as a single functioning entity.
The elements (or sub systems) can include hardware, software, facilities, personnel, procedures, and documentation; ie. all things required to produce system-level outcome.
The outcomes typically include system-level functions and performance but may also extend to system qualities, system properties, system characteristics and system behaviours.
The total value of the system, beyond the sum of the independent parts, is usually created by the interconnections between the parts; eg automating the data transfer from a data reader, directly into the collating software that is able to make use of the data and provide a real time (graphical) display of the data just read, such as a bar scanner on a supermarket checkout.
System Engineering is a way of looking at the “big picture” when making design or operating decisions.
It is a way of achieving the operational functional and performance requirements in the intended environment over the planned life of the system.
Another way to put it would be; Systems Engineering is a way of thinking logically.
Often the system will have opposing constraints, which generally means something is compromised. Systems engineering attempts to look at the system holistically to determine the priorities of the functions and operabilities and thus minimise critical compromises while at the same time maximising functionality or performance.
The art of optimising the overall design without favouring one system/subsystem at the expense of another is an iterative process and may have inputs from many disciplines: electrical and electronics engineers, mechanical engineers, human factors engineers etc.
The ultimate result sought is a safe and balanced design that optimises the opposing interests and multiple, sometimes conflicting constraints.

Sep 012016
 

Logistics Support Analysis

The six areas of LSA

Videos related to Logistic Support for the International Space Station (ISS)

loading
Big Buck Bunny
00:00
--
/
--
youtube play
vimeo play

Logistics Support

  • Logistic Support Analysis - NASA
    Logistic Support Analysis - NASA
  • Logistic Support Analysis - NASA - 2
    Logistic Support Analysis - NASA - 2

 

Logistics Support Analysis Software:  eLSA

Logistics Support Analysis Record Software: LSAR

Sep 012016
 

The purpose of a Logistic Support Analysis Record (LSAR) is to provide a consistent information source to support the conduct of Logistics Support Analysis (LSA) and related analyses, and enable the development and preparation ILS data products.
An LSAR applied effectively support analysis and achieves the fourth goal of LSA for both project and In- service use, to: “Develop and prepare attendant data products from a consistent information source.”
The purpose of this standard is to define the requirements for the application of a Logistic Support Analysis Record for and by the Organisation.
Detail record Requirements
LSA documentation, including LSAR data, is generated as a result of the analysis specified for the LSA Program. As such, the LSAR shall serve as the main Integrated Logistic Support (ILS) technical database applicable to all materiel acquisition programs to satisfy the support acquisition.

Annex A of DEF(AUST)5692 establishes the Logistic Support Analysis Record (LSAR) relational table titles and data content and format to be produced by an LSAR relational Automated Data Processing (ADP) system:

  •  It defines all the relational tables that comprise an LSAR database.
  •  In a relational database system, information is organised in the form of tables.
  •  Categories or columns of information are listed across the top of each table.
  •  Individual sets of information are listed as rows.
  •  LSAR relational tables are two-dimensional matrices of related data.
  •  Tables are defined in terms of columns (or data element definitions (DED)) and rows (or multiple sets of the columnar data elements).
  •  Information in this format can be easily visualised and understood.

DEF(AUST) 5692
Logistic Support Analysis (LSA) is a selected application of system engineering techniques, originally developed by the United States Department of Defence (US DOD) to provide effective and consistent analytical processes for identifying and implementing supportability requirements for the development and acquisition of major capital equipment. LSA, as applied in Defence expands LSA as a life Cycle Discipline to enable the benefits of consistent analytical techniques to be readily applied to major minor projects, modifications, In- service analysis for logistic optimisation, and disposal.
A key enabler to the success of the LSA Program, and the fourth goal of LSA, is to use a consistent data source for analysis to ensure an integrated solution between LSA, Integrated Logistic Support and related disciplines. The LSAR was developed to fulfil this requirement. Defence has added functionality to the LSAR developed by the US DoD and defined in MIL-STD- 1388-2B.
DEF(AUST)5692 provides the definition of data elements and structure of the LSAR to enable the collection, storage, retrieval and review of the LSAR data.
The DEF(AUST)5692 is structured as follows:
· Chapter 1: LSAR Program Requirements
· Chapter 2: LSAR General Requirements
· Chapter 3: Detailed requirements for the Preparation of an LSAR.
· Annex A. Contains the LSAR relational tables necessary for the development of a relational LSAR database.
· Annex B. Contains a description and the required format for each LSAR standard report.
· Annex C. Explains assignment of the key data elements: LSA Control Number (LCN), Alternate LCN Code (ALC), Usable On Code (UOC).
· Annex D. Contains guidance for tailoring of the LSAR Data.
· Annex E. Contains an LSAR Data Element Dictionary providing definitions for all data specified by Annex A.
Chapter 3, Annexes A,B and E establish requirements and can be included/referenced in contractual documents. Annexes C and D provide guidance for the implementation of LSAR data entry and program application of the LSAR. The main annexes for this course are Annex A and C.
LSA data is generated in all phases of the system/equipment life cycle and is used as input to follow-on analyses and as an aid in developing logistics products.

 

Logistic Support Analysis Record Software: LSAR

Logistics Support Analysis Software: eLSA

Background and History
US DOD realised a need to store results of Logistic Support Analysis (LSA) in a single database.
They developed standards to create LSARs that provided a standardised method for compiling and storing logistic and logistic related data for a program.
The Australian Defence Force (ADF) began looking at using LSARs in the early 1990s.
They actually had copies of a MIL‑STD‑1388‑2A product called DILSA.
Australian Dept of Defence began looking at using LSARs in the early ‘90s with the establishment of the CAPLOG (Capital Logistics) project.
The CAPLOG project got serious about using LSARs and associated software apps in an attempt to truly apply the principles of Integrated Logistic Support (ILS).
The centre of the CAPLOG ‘hub’ was a MIL‑STD‑1388‑2B based LSAR.
The project selected Omega2B as the corporate application.
As the project matured, it was recognised that MIL‑STD‑1388‑2B in its current form would not fulfil the intended needs of the ADF for two main reasons:

  •  Legacy data needed to continue to be managed for some time (ended up being almost 15 years).
  •  The ADF wanted to use the LSAR ‘through life’. This meant continuous management of maintenance documentation and the configuration of significant items (Maintenance Managed Items).

As a result, AAP 5102.003 was developed (AAP stands for Australian Air Publication)
The ADF called their databases Weapon System Databases (WSDBs) as opposed to LSARs to highlight the difference between MIL‑STD‑1388‑2B and AAP 5102.003
Over time certain deficiencies were identified with AAP 5102.003 and these were addressed with the development of DEF(AUST)5692 (including an overhaul of MIL‑STD‑1388‑1A to become DEF(AUST)5691).

S1000D

 
Weapon System Databases (WSDB)

Aug 312016
 

Failure Modes Effects Criticality Analysis
Failure Modes Effects Criticality Analysis (FMECA) is the analysis of HOW the equipment can fail, what is the effect of failure and how critical is the failure.
It is designed to identify potential failure modes for an item or system, to assess the risks involved with those failures, to categorise and order in terms of importance, identify the criticality of the failure, and to identify and either put in place mitigations or institute corrective actions to address those that can be addressed.

Aug 312016
 

Level of Repair Analysis

What is Level Of Repair Analysis?

Level Of Repair Analysis combines two elements:

  •  Cost Analysis
  •  Repair Level Analysis

Cost Analysis determines Whether maintenance should be performed; which includes all costs incurred:

  • to establish and utilise a repair venue
  • the tooling required for the repair
  •  the skill of the repairer
  • in obtaining the Training required in order to perform the repair
  • in the Rates of pay of personnel conducting the repair
  • in the Cost of conducting the repair – i.e. time
  • in the Cost of the repair parts
  • in the Transport costs of getting the equipment to and from the repair base
  • in Other overheads

Repair Level Analysis (RLA) determines Where the maintenance should be performed; this in turn determines where the equipment can be repaired:

  • Operational/Organisational Level Maintenance •Light Grade Repair
  • Organic (On-board ship)
  • On the Flight Line

 

  • •Intermediate Level Maintenance •Medium Grade Repair – Mobile workshop
    •External (Along side dock )

 

  • •Deeper/Depot Level Maintenance •Heavy Grade Repair
    •Contractor (External )
    •Maintenance Depot

Level of Repair Analysis Software : eLORA

Aug 312016
 

Reliability Centred Maintenance
Reliability Centred Maintenance is the analysis and execution of Maintenance tasks focused on preventive replacements in order to maximise the operational period.

The focus on preventive maintenance is easily understood when consideration is given to the typical reactive type maintenance, ie “fix it when it breaks”.

In the typical reactive maintenance situation, the planned preventive maintenance gets delayed while resources are sidetracked performing emergency repairs to keep the system running after something has failed.

The delayed or cancelled preventive maintenance tasks then cause the system to be put at further risk due to it now operating beyond the planned / calculated maintenance periods. These operations beyond expected maintenance periods may place extra stress on the system, resulting in failure, diversion of maintenance resources to fix the failure, and a constant downward spiral in reliability. eg

  • An oil change that is normally scheduled to be performed at 250 operating hours gets postponed due to a separate failure elsewhere in the system.
  • The system is put back into service but the planned maintenance window for oil change has been missed and the system is now unable to be taken off-line for another 250 hours due to operational requirements.
  • So now the equipment has to run on the same oil for 500 hours rather than the planned 250.
  • If the original design did not allow for a maintenance period of twice the planned period, this may result in higher levels of contaminants and lower lubrication performance, and hence higher wear.
  • This higher level of wear may show up quickly in terms of an earlier failure of an associated piece of equipment, or it may not show up for years, instead resulting in perhaps a major overhaul at 5 years instead of the planned 10 year expected life.
  • Repeated maintenance delays may compound the unseen wear or degradation.
  • Had the oil change been able to be performed at the same time as the initial failure, the costs involved as a result of the early overhaul, or equipment failure, could probably have been avoided.

It is the desire to avoid this type of downward spiral that drives Reliability Centred Maintenance, particularly for system critical functions. (Sometimes a failure in a piece of equipment is not critical to the operation of the system, so repair on failure is acceptable. eg a light bulb failure when there is sufficient light from surrounding light bulbs to allow operations in the area to continue.)