Software

ILS, MRD, LORA Software available in Australia to perform Logistic Support Analysis and Maintenance Requirements Determination.

Sep 012016
 

Maintenance Requirements Determination or MRD is a fundamental part of Integrated Logistic Support.

MRD is the umbrella term for: Failure Modes Effects and Criticality Analysis (FMECA), Reliability Centred Maintenance (RCM), Maintenance Task Analysis (MTA) and Level of Repair Analysis (LORA).
FMEA, RCM, and MTA are also referred to as Maintenance Engineering Analysis (MEA).

 

Maintenance Requirements Determination Software: eMRD

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
 

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