LOGISTIC SUPPORT ANALYSIS DEFENCE STANDARD

Transcription

1 COMMONWEALTH OF AUSTRALIA AUSTRALIAN DEFENCE STANDARD Issue 1 Dated 02 December 2002 LOGISTIC SUPPORT ANALYSIS DEFENCE STANDARD * PUBLISHED UNDER AUTHORITY DEPARTMENT OF DEFENCE

2 DOCUMENT MANAGEMENT INFORMATION This page lists the ownership and areas responsible for providing technical approval for this Standard. It also lists applicable documents that should be read in conjunction with this Standard. The information below needs to be reviewed for currency and applicability as per the 5-year review cycle detailed in the Defence Standardisation Manual (STANMAN). Sponsor: Approving Authority: Applicable Documents: PM CLSD_LOG Directorate of Logistics Support and Engineering RAAF Williams LAVERTON VIC 3027 Under Secretary Defence Materiel Defence Materiel Organisation Russell Offices CANBERRA ACT 2600 DI(G) LOG (to be issued) Defence Policy for Supportability Analysis DI(G) LOG 03-6, Defence Policy for Integrated Logistic Support DEF(AUST)5692, Logistic Support Analysis Record Requirements for the ADO MIL-STD A, Logistic Support Analysis (cancelled) MIL-STD B, DOD Requirements for a Logistic Support Analysis Record (cancelled) MIL-STD-1390D, Level of Repair Analysis (cancelled) MIL-STD-1629A, Procedures for Performing a Failure Mode, Effects and Criticality Analysis (cancelled) MIL-STD-2173, Reliability-Centered Maintenance Requirements for Naval Aircraft, Weapon Systems and Support Equipment (cancelled) ANSI/EIA-632, Processes for Engineering a System IEEE Std , IEEE Standard for the Application and Management of the Systems Engineering Process ii

3 DEF(AUST) 5691 AMENDMENT LIST Amendment Effected No Date of Issue Signature Date Incorporated Revision Note dated 02 December 2002 is an original document. Historical Record The first edition of this document was authored by the following: Mr David Edgelow, Ms Sharna-Leigh Fayle, WOFF Lex Woods. iii

4 Blank Page iv

5 AUSTRALIAN DEFENCE STANDARD LOGISTIC SUPPORT ANALYSIS 02 DECEMBER Logistic Support Analysis (LSA) is a selected application of systems engineering techniques, originally developed by the United States Department of Defense (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 the Australian Defence Organisation (ADO), expands LSA as a Life Cycle Discipline to enable the benefits of consistent analytical techniques to be readily applied to major and minor projects, modifications, In-service analysis for logistic optimisation, and disposal. 2. LSA describes the process for identifying and analysing the functional supportability requirements consistent with the goals of the Integrated Logistic Support (ILS) Program. LSA also describes the process for the coordinated development of logistic related task data, and the processing of that data to define logistic resource requirements. LSA defines analytical process for the preparation for In-service support and disposal, and the interface with Supportability Assessments (Supportability Test and Evaluation). 3. This standard contains information for the analysis activities that are selectively conducted as part of a Logistic Support Analysis Program conducted in accordance with ADO policy. 4. DEF(AUST)5692 provides the standard for structure of a Logistic Support Analysis Record for collecting, storing and reviewing LSA data. The ADO s LSA Manual contains Procedural Guidance for the application and conduct of Logistic Support Analysis and Logistic Support Analysis Record related activities for the Australian Defence Organisation and its Defence Industry suppliers. v

6 DEF(AUST) 5691 Blank Page vi

7 DEF(AUST) 5691 CONTENTS Document Management Information Amendment list Contents ii iii vi CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5 LOGISTIC SUPPORT ANALYSIS INTRODUCTION TO LOGISTIC SUPPORT ANALYSIS 1-1 INTRODUCTION TO THE LSA STANDARD 1-1 DEFINITIONS AND ACRONYMS 1-3 REFERENCES 1-3 AMENDMENTS 1-4 LSA PROGRAM REQUIREMENTS GENERAL REQUIREMENTS 2-1 LOGISTIC SUPPORT ANALYSIS ACTIVITIES 2-3 INDE OF LOGISTIC SUPPORT ANALYSIS ACTIVITIES 2-4 Annexes: A. General Application Guidance for LSA Programs B. LSA Process Flow LSA PROGRAM PLANNING AND MANAGEMENT ACTIVITIES INTRODUCTION 3-1 LSA STRATEGY (LM1) 3-1 LSA PLAN (LM2) 3-2 MANAGEMENT AND ANALYSIS REVIEWS (LM3) 3-4 Annex: A. Guidance for LSA Program Planning and Management Activities FUNCTIONAL LOGISTICS REQUIREMENTS ACTIVITIES INTRODUCTION 4-1 USE STUDY (FL1) 4-1 FUNCTIONAL REQUIREMENTS IDENTIFICATION (FL2) 4-3 COMPARATIVE ANALYSIS (FL3) 4-4 STANDARDISATION OPPORTUNITIES (FL4) 4-6 TECHNOLOGICAL OPPORTUNITIES (FL5) 4-8 SUPPORT SYSTEM ALTERNATIVES (FL6) 4-10 REQUIREMENTS EVALUATIONS AND TRADEOFFS (FL7) 4-11 FUNCTIONAL REQUIREMENTS DEFINITION (FL8) 4-14 Annex: A. Guidance for Functional Logistics Requirements Activities PHYSICAL RESOURCE REQUIREMENTS ACTIVITIES INTRODUCTION 5-1 TASK ANALYSIS (PL1) 5-1 RESOURCE EVALUATIONS AND TRADEOFFS (PL2) 5-5 DEFINITION OF RESOURCE PACKAGE (PL3) 5-7 TRANSITION ANALYSIS (PL4) 5-8 POST PRODUCTION SUPPORT ANALYSIS (PL5) 5-9 DISPOSAL ANALYSIS (PL6) 5-11 Annex: A. Guidance for Physical Resource Requirements Activities vii

8 CHAPTER 6 SUPPORTABILITY ASSESSMENT ACTIVITIES INTRODUCTION 6-1 ST&E STRATEGY (SA1) 6-1 EVALUATION OF FUNCTIONAL REQUIREMENTS (SA2) 6-2 VERIFICATION OF PHYSICAL CHARACTERISTICS AND RESOURCES (SA3) 6-3 IN-SERVICE SUPPORTABILITY ASSESSMENTS (SA4) 6-6 Annex: A. Guidance for Supportability Assessment Activities Glossary Acronyms and Abbreviations Obtaining Defence Standards Document Improvement Proposal i xvii xix xx viii

9 CHAPTER 1 Introduction CHAPTER 1 LOGISTIC SUPPORT ANALYSIS INTRODUCTION TO LOGISTIC SUPPORT ANALYSIS 1.1 Logistic Support Analysis (LSA) has been developed to provide an analytical foundation for the application of Integrated Logistic Support (ILS) and the achievement of ILS goals. LSA is applied in support of ILS throughout the life cycle of a Capability to achieve an optimised balance between preparedness and Life Cycle Cost, while meeting program requirements and constraints. Policy 1.2 The policy requirement for the conduct of LSA by the ADO is defined in DI(G) LOG (to be issued), Defence Policy on Supportability Analysis. Definition 1.3 The ADO definition of LSA is: Logistic Support Analysis is the selective application of scientific and engineering efforts undertaken, as part of the Systems Engineering, design, support development, and In-Service Engineering Support processes, to assist in complying with Supportability and other Integrated Logistic Support (ILS) objectives through an iterative process of definition, synthesis, tradeoff, test, and evaluation. Goals of Logistic Support Analysis 1.4 The goals of the LSA discipline are to adopt a uniform and traceable process for the conduct of activities necessary to: Purpose a. ensure that Supportability requirements are an integral part of system requirements and design, b. define an integrated set of support requirements that are concurrent with the system design, c. define the optimal physical resource requirements, and d. develop and prepare attendant data products from a consistent information source. INTRODUCTION TO THE LSA STANDARD 1.5 The purpose of this standard for Logistic Support Analysis (LSA) is to describe the standards for the general requirements for LSA in the Australian Defence Organisation (ADO) and its Defence Industry Suppliers throughout the materiel life cycle. Scope 1.6 The scope of this standard is to define the generic requirements for the conduct of an LSA Program in and for the ADO, and the LSA Activities, data and guidance to achieve the goals of LSA throughout the material life cycle for projects of varying complexity. 1.7 This standard is applicable to the implementation of LSA on all Defence major materiel acquisition projects, modification/upgrade projects and capability updates where there is a requirement to plan for and implement logistic support. LSA Activities are applicable from initial development of capability options through whole of life until disposal, covering each phase in the materiel life cycle. This includes projects that have the opportunity to influence the design of a new system/equipment for improved Supportability, the selection of a supportable existing design, modification/upgrade to existing systems/equipment enabling

10 improved Supportability, development and modification of the In-service support system, and the optimisation of logistic resources. 1.8 This standard is applicable to both Requiring Authority and Performing Activity organisations. Generally the term Requiring Authority refers to the Government (Defence) organisation and the Performing Activity refers to the Contractor. However, when the Contractor requires LSA to be undertaken by subcontractor, the Contractor becomes the Requiring Authority and the subcontractor is the Performing Activity. Likewise, if one Defence organisation requires LSA Activities to be conducted by another Defence organisation the two organisations may be described as Requiring Authority and Performing Activity respectively. In an Integrated Product Team (IPT) environment, it is feasible for the IPT to both perform the functions of determining requirements and conduct the required analysis, constituting both the Requiring Authority and Performing Activity functions respectively. Structure 1.9 The requirements for LSA have been divided into two parts, this standard addresses the requirements for an LSA Program, DEF(AUST)5692 details the ADO requirements for a Logistic Support Analysis Record (LSAR) This standard is organised as follows: a. The definition and goals of Logistic Support Analysis and the scope of this standard, Chapter 1 (this chapter); b. Requirements for establishing and conducting a Logistic Support Analysis Program, Chapter 2; c. Logistic Support Analysis Activity definitions, organised in the following groups: (1) LSA Program Planning and Management, Chapter 3; (2) Functional Logistics Requirements Activities, Chapter 4; (3) Physical Resource Requirements Activities, Chapter 5; and (4) Supportability Assessment Activities, Chapter 6. Annexes to Chapters 2 through 6 provide guidance to the requirements of those chapters. Scope of Performance 1.11 The Performing Activity shall only comply with the requirements of this standard to the degree specified in the applicable contract or other document of agreement. The LSA Activities shall be tailored and focussed to meet the individual needs of each program. General 1.12 This standard defines the general requirements for LSA Activities which, when performed in a logical and iterative nature, comprise the LSA process. The Activities are structured for maximum flexibility in their application. In addition to the general requirements and Activities descriptions, generic application guidance is contained in the Annexes to provide rationale for the selection and tailoring of the Activities to meet program objectives in a cost-effective manner This document is intentionally structured to discourage indiscriminate application. Tailoring is forced by requiring that specific Activities be selected and that the Requiring Authority provides essential information relative to the selected Activities to focus the analysis effort in support of achieving a program's ILS goals. The user must be aware that when the LSA process, or a portion of it, is implemented contractually, the ILS/LSA section of the Statement of Work and deliverable data only forms part of the requirement. In addition, Mission System Supportability Characteristics and Support System requirements and objectives must be appropriately integrated and embodied in specifications, contract provisions, tender evaluation criteria, instructions to tenderers, and other sections of the solicitation documents as appropriate Defence Mission System acquisitions are directed toward achieving the best balance between performance, life cycle cost, schedule, and Supportability. Coordinating analysis that determines all ILS 1-2

11 resource requirements, is essential for optimising the effectiveness of a Defence capability. This has necessitated planning and analysis to establish system constraints, design goals, thresholds and criteria for the pursuit of design, operational, and support approaches which optimise the balance between life cycle costs and the resources required to operate and maintain systems effectively MIL-STD A was prepared by the United States Department of Defense to identify analysis requirements and foster their cost-effective application during system acquisition. The standard extends on the basis of MIL-STD A to provide an LSA process applicable to the whole of life of a capability, for concept development, capital acquisitions, In-service management, modification projects, capability updates and disposal. Definitions DEFINITIONS AND ACRONYMS 1.16 For commonly used LSA terms refer to the LSA Glossary at the end of this standard. Acronyms 1.17 For commonly used LSA Acronyms and Abbreviations refer to the LSA Acronym list at the end of this standard. Policies REFERENCES 1.18 DI(G) ADMIN 05-1 Defence Capability Management Cycle DI(G) LOG 03-2 Defence Policy on Computer-aided Acquisition and Logistic Support DI(G) LOG 03-4 Defence Policy on Life Cycle Cost Analysis DI(G) LOG 03-6 Defence Policy on Integrated Logistic Support DI(G) LOG 08-4 Defence Policy on Configuration Management DI(G) LOG 08-6 Defence Policy on Reliability, Availability and Maintainability DI(G) LOG Defence Policy on Materiel Standardisation DI(G) LOG (to be issued) Defence Policy on Supportability Analysis. Military Standards 1.26 MIL-STD A Logistic Support Analysis (cancelled) MIL-STD B DOD Requirements for a Logistic Support Analysis Record (cancelled) UK DEF STAN Integrated Logistic Support MIL-STD-1390D, Level of Repair Analysis (cancelled) MIL-STD-1629A, Procedures for Performing a Failure Mode, Effects and Criticality Analysis (cancelled) MIL-STD-2173, Reliability-Centered Maintenance Requirements for Naval Aircraft, Weapon Systems and Support Equipment (cancelled). Other References 1.32 ANSI/EIA-632, Processes for Engineering a System. 1-3

12 1.33 IEEE Std , IEEE Standard for the Application and Management of the Systems Engineering Process MIL-HDBK-502 Acquisition Logistics MIL-PRF Logistics Management Information Jones, J.V., Integrated Logistic Support Handbook, 2nd Ed, McGraw Hill Inc, Blanchard, B.S., Logistics Engineering and Management, 5th Ed, Prentice-Hall International, AMENDMENTS 1.38 If (this standard) requires amendment, please refer to the inside back cover, or contact the following: DDLSE-MPS (ESD) Bldg L475 RAAF Williams Maher Road LAVERTON, Victoria

13 CHAPTER 2 Establishing an LSA Program CHAPTER 2 LSA PROGRAM REQUIREMENTS GENERAL REQUIREMENTS 2.1 An effective LSA Program shall be established and maintained as a part of, and to provide analytical support to, the ILS Program. The LSA Program shall be planned, integrated, developed and conducted in conjunction with other requirements definition, design, development, production, transition, Inservice support, and disposal functions, to cost effectively achieve ILS Program objectives. The LSA Program shall be established consistent with the phase of the materiel life cycle and the complexity and maturity of the Mission System. Procedures shall be established to ensure that the LSA Program is an integral part of Systems Engineering and Integrated Logistic Support processes. The LSA Program shall include the management and technical resources, plans, procedures, schedules and controls for the performance of LSA requirements. Program Interfaces 2.2 Interfaces between the LSA Program and each of the following areas shall be identified in ILS and LSA management plans: a. a project's individual programs for each ILS element; b. In-service engineering and support organisations; and c. other Life Cycle Disciplines including System Engineering and ILS. 2.3 Maximum use shall be made of analyses and data resulting from requirements of other System Engineering and analytical programs to satisfy LSA input requirements. Activities and data required by LSA, which are also required by other standards and specifications of the program, shall be coordinated and combined to the maximum extent possible. LSA data shall be based upon, and traceable to, other Integrated Logistic Support and System Engineering data and activities where applicable. The shared activities and data may include, but are not limited to: a. Systems Engineering; b. Reliability, Availability and Maintainability engineering; c. Failure Modes, Effects and Criticality Analysis; d. Reliability Centered Maintenance; e. Verification and Validation; and f. Life Cycle Costing Analysis. Design and performance information shall be captured, disseminated, and formally controlled from the beginning of concept studies and the design effort, to serve as the audit trail for logistic support resource planning, design tradeoff study inputs, and LSA documentation preparation. LSA Process 2.4 A systematic and comprehensive analysis shall be conducted on an iterative basis through all phases of the materiel life cycle to satisfy supportability objectives (supportability includes all elements of ILS, as defined in DI(G) LOG 03-6, required to operate and support the Mission System, supportability objectives are objectives derived from ILS Program goals). The level of detail of the analyses and the timing of LSA Activity performance shall be tailored for each LSA Program and shall be responsive to ILS Program goals, schedules and milestones.

14 2.5 LSA Activities represent logical work activities within particular areas of an LSA Program. Steps are used to break the Activities down into smaller logical units of work. Steps within an Activity are presented in the most likely order for application, although many will repeat within an iteration of an Activity. Some Steps will occur concurrently, and some may be omitted depending on program requirements. 2.6 Guidance for the application of analysis Activities and Steps by life cycle phase is provided in Chapter 2, Annex A Table 1. Chapter 2 Annex B illustrates the typical application of LSA Activities for the complete materiel life cycle, with more detailed flow diagrams of the first three phases. Tailoring of Activity Descriptions and Focus of Effort 2.7 Individual LSA Activities defined in chapters 3, 4, 5 and 6 shall be selected to meet the specific program ILS goals, characteristics, design maturity, and life cycle phase. The selected LSA Activities and descriptions shall be further defined for the LSA Program to focus analysis effort conducted under each selected Activity to meet specific ILS goals. 2.8 Application guidance and rationale for selecting Activities and focussing Activity descriptions to fit the needs of a particular program are included in Chapter 2, Annex A. These sources of guidance do not establish requirements and are not contractual unless explicitly incorporated into an individual program's contractual documentation. LSA Program Management 2.9 Primary responsibility for LSA Program planning, management, and review rests with the concept and acquisition project team ILS Managers, managers in minor projects responsible for ILS, and In-service capability support managers Management procedures shall be established to assure continuing assessment of analysis results and to allow for Mission System design, Support System development and LSA Program adjustments as required. Feedback and corrective action procedures shall be established, in management plans, which include controls to assure that deficiencies are documented and corrected. Supportability assessments shall be conducted throughout the materiel life cycle to demonstrate, within stated confidence levels, the validity of the analyses performed and the products developed from the analyses, and to adjust the analysis results and products as applicable. Analysis shall be conducted throughout the materiel life cycle in response to modifications, update programs, In-service monitoring, and changes to Mission System use and operating environment to adjust results and products as applicable. Quantitative Requirements 2.11 The LSA Program shall develop quantitative requirements for Mission System supportability and the supportability related requirements of the enabling Support Systems. Quantitative requirements, once defined, shall be used in developing measurable supportability design requirements and Support System requirements for specification documents, and verification and validation activities Quantitative supportability and supportability related design requirements for the Mission System shall be included in appropriate sections of the system or end item specifications, other requirements documents and contracts, as appropriate. Subordinate values that combine to form an established quantitative requirement but are not individually established by the Requiring Authority shall be established by the Performing Activity from analysis undertaken in accordance with a Statement of Work. Requirements shall be defined in terms related to reliability, availability and maintainability, the demand for logistic support resources, and life cycle costs, as applicable to the type of Mission System. LSA Documentation and Data Requirements 2.13 LSA documentation shall consist of all data resulting from analysis Activities conducted under LSA and shall be the primary source of validated and integrated design related supportability data pertaining to a Mission System. LSA documentation shall be developed and maintained commensurate with design, support, and operational concept development, and shall be updated to reflect changes or the availability of better information based on testing, configuration changes, operational concept changes, support concept changes, and In-service experience Accumulated LSA documentation shall provide an audit trail of supportability and supportability related design analyses and decisions, and shall be the basis for actions and documents related to workforce requirements, training programs, provisioning, maintenance planning, resource allocations, 2-2

15 funding decisions, and other logistic support resource requirements. Configuration control procedures shall be established over LSA documentation updates to assure proper coordination with System Engineering, other analytical programs, and the development of ILS documents using LSA data Deliverable documentation shall be as specified in applicable Data Item Descriptions (DIDs) cited in the Contract Data Requirements List (CDRL). When the Requiring Authority requires the delivery of analysis outputs for each LSA Activity and Step, then appropriate DIDs and delivery information must be included in the CDRL Logistic Support Analysis Record Format. The Logistic Support Analysis Record (LSAR) is a subset of LSA documentation and LSAR data elements shall conform to the requirements of DEF(AUST)5692. Deliverable LSAR data shall be as specified in a DID (or DIDs) cited on the CDRL. General LOGISTIC SUPPORT ANALYSIS ACTIVITIES 2.17 LSA Activities are organised into four Activity Groups: a. LSA Program Planning, Management and Control, b. Functional Logistics Requirements Definition, c. Physical Resource Requirements, and d. Supportability Assessments The order in which LSA Activities have been presented does not enforce a set sequence in which they are conducted. Many Activities are iterative and may be repeated a number of times during the LSA Program and will often occur concurrently with other LSA Activities. An LSA Program is not required to undertake each LSA Activity, and shall only undertake those Activities that are essential or represent value for money in achieving the ILS Program goals. Guidance for tailoring and focussing an LSA Program is contained in Chapter 2 Annex A. Individual LSA Activities are described in Chapters for each of the Activity Groups listed above Table 2-I identifies the general purpose of each LSA Activity Group and the individual Activities and Steps contained in each group. Table 1 of Chapter 2, Annex A contains additional columns to indicate the applicability of each Activity and Step to the first three LSA goals and the related levels of design freedom; ie., design of the Mission System, the design of Support Systems, and the determination of logistic resource requirements. Method of Reference to LSA Activities 2.20 For ease of reference, LSA Activities and Steps may be referred to using the convention of a group code, Activity Number and Step Number. Group codes are: a. LM - LSA Program Planning and Management (LSA Management) b. FL - Functional Logistics Requirements (Functional LSA) c. PL - Physical Resource Requirements (Physical LSA) d. SA - Supportability Assessments 2.21 Within a group, Activities and Steps are referred to in numerical order. For example: a. Use Study - FL1 b. Task Analysis / Task Identification (Step 1) - PL The complete list of LSA Activities and Steps and the applicable referring codes are included in Table 2-1 of the "Index of Logistic Support Analysis Activities" section of this Chapter. 2-3

16 Activity Descriptions 2.23 A description for each LSA Activity is contained in Chapters 3, 4, 5 and 6. Each description has been structured into four parts, as follows: a. Purpose. The purpose provides the objectives and general reason for performing an activity. b. Steps. Each Activity description contains a series of Steps that are components of the Activity. It is not intended that all Steps within an Activity must be accomplished in the sequence presented. The sequence of Activities and Steps undertaken should be tailored to the individual LSA Program. Where applicable, the Steps have been organised in a generic order for performance within each application of the Activity, although some Steps may be repeated within a single iteration of their Activity. For some Activities, all Steps may not be necessary to achieve the desired objectives of the Activity. In these cases, the LSA Strategy shall specify the applicable Activity and Step requirements. (See Chapter 2 Annex A for guidance on Tailoring and Focussing). c. Inputs. The Activity inputs identify the general information required to define the scope of and perform each Activity. Input information that shall be specified by the Requiring Authority in the SOW is annotated by an asterisk (*). d. Outputs. The Activity output identifies the expected results from performance of the Activity When an element of the Activity input or output is only applicable to certain Steps of the Activity, the applicable Step numbers are identified in parentheses following the element. Where Step numbers are not listed, that element (of the input or output) is applicable to the Activity as a whole. INDE OF LOGISTIC SUPPORT ANALYSIS ACTIVITIES 2.25 Table 2-1 lists all LSA Activities and Steps within each Activity. The last column identifies the reference code for each Activity and Step. Activity Group LSA PROGRAM PLANNING AND MANAGEMENT Purpose Activity / Step Ref. Code To provide effective planning and management to the LSA Program. LSA Strategy Step 1: Develop Early LSA Strategy Step 2: Prepare Cost Estimates Step 3: Update LM1 LM1.1 LM1.2 LM1.3 LSA Plan Step 1: Develop LSA Plan. Step 2: Update LM2 LM2.1 LM2.2 Management and Analysis Reviews Step 1: Establish Review Procedures Step 2: Contribute to Design Reviews Step 3: Contribute to Program Reviews Step 4: Conduct ILS Reviews Step 5: Conduct LSA Guidance Conferences Step 6: Conduct LSA Reviews LM3 LM3.1 LM3.2 LM3.3 LM3.4 LM3.5 LM3.6 FUNCTIONAL LOGISTIC REQUIREMENTS To provide a systematic process for the development of functional logistic requirements. Use Study Step 1: Identify Supportability Factors Step 2: Quantify Supportability Characteristics Step 3: Conduct Field Visits Step 4. Develop Use Study Report Step 5: Update FL1 FL1.1 FL1.2 FL1.3 FL1.4 FL1.5 Functional Requirements Identification Step 1: Identify Functional Requirements Step 2: Determine Characteristics of Requirement Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Requirements Step 5: Perform Risk Assessment Step 6: Update FL2 FL2.1 FL2.2 FL2.3 FL2.4 FL2.5 FL

17 Activity Group Purpose Activity / Step Ref. Code Comparative Analysis Step 1: Identify Comparative Candidates Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL3 FL3.1 FL3.2 FL3.3 FL3.4 FL3.5 FL3.6 Standardisation Opportunities Step 1: Identify Standardisation Opportunities Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL4 FL4.1 FL4.2 FL4.3 FL4.4 FL4.5 FL4.6 Technological Opportunities Step 1: Identify Technological Opportunities Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL5 FL5.1 FL5.2 FL5.3 FL5.4 FL5.5 FL5.6 Support System Alternatives Step 1: Identify Support System Alternatives Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL6 FL6.1 FL6.2 FL6.3 FL6.4 FL6.5 FL6.6 Requirements Evaluations and Tradeoffs Step 1: Determine Evaluation and Tradeoff Criteria Step 2: Determine System Supportability Requirements Step 3: Determine Support System Requirements Step 4: Determine Comparative Baseline Step 5: Assess Opportunities and Alternatives Step 6: Perform Sensitivity and Risk Analysis Step 7: Update FL7 FL7.1 FL7.2 FL7.3 FL7.4 FL7.5 FL7.6 FL7.7 Functional Requirements Definition Step 1: Define Characteristics and Requirements Step 2: Define Objectives and Risks Step 3: Address Intellectual Property Step 4: Address Joint Forces and Interoperability Step 5: Define Constraints and Other Requirements Step 6: Document Requirements Step 7: Update FL8 FL8.1 FL8.2 FL8.3 FL8.4 FL8.5 FL8.6 FL8.7 PHYSICAL RESOURCE REQUIREMENTS To develop the logistic resource package, plan deployment of logistic resources, disposal and Post Production Support. Task Analysis Step 1: Identify Tasks Step 2: Determine Task Characteristics Step 3: Identify New and Critical Resources Step 4: Optimise Task Attributes Step 5: Document Task Analysis Step 6: Update PL1 PL1.1 PL1.2 PL1.3 PL1.4 PL1.5 PL1.6 Resource Evaluations and Tradeoffs Step 1: Determine Tradeoff Criteria Step 2: Determine Non-economic Criteria Step 3: Conduct Evaluations and Tradeoffs Step 4: Perform Sensitivity & Risk Analysis Step 5: Update PL2 PL2.1 PL2.2 PL2.3 PL2.4 PL2.5 Definition of Resource Package Step 1: Compile Resource Package Step 2: Develop ILS Products Step 3: Identify Provisioning Requirements Step 4: Document in Management Plans PL3 PL3.1 PL3.2 PL3.3 PL

18 Activity Group Purpose Activity / Step Ref. Code Transition Analysis Step 1: Identify Existing Resources Step 2: Conduct Early Fielding Analysis Step 3: Identify Resource Deficiencies Step 4: Assess the Impact of Resource Shortfalls Step 5: Resolve Personnel Deficiencies Step 6: Document in Transition Plan PL4 PL4.1 PL4.2 PL4.3 PL4.4 PL4.5 PL4.6 Post Production Support Analysis Step 1: Identify Post-Production Support Candidates Step 2: Identify Alternatives for Post-Production Support Step 3: Monitor Production and Support Activities Step 4: Identify Reprovisioning Requirements PL5 PL5.1 PL5.2 PL5.3 PL5.4 Disposal Analysis Step 1: Identify Candidates for Disposal Step 2: Identify Resources for Re-allocation Step 3: Identify Special Disposal Requirements Step 4: Identify and Evaluate Options for Disposal Step 5: Document in Disposal Plan PL6 PL6.1 PL6.2 PL6.3 PL6.4 PL6.5 SUPPORTABILITY ASSESSMENTS To provide supportability assessments of requirements and ILS products. ST&E Strategy Step 1: Establish ST&E Strategy Step 2: Prepare Cost Estimates Step 3: Update Evaluation of Functional Requirements Step 1: Establish Measurable Requirements Step 2: Validate and Verify Requirements Step 3: Assess Requirements Allocation Step 4: Update and Determine Corrective Actions SA1 SA1.1 SA1.2 SA1.3 SA2 SA2.1 SA2.2 SA2.3 SA2.4 Verification of Physical Characteristics and Resources Step 1: Identify Supportability Assessment Candidates Step 2: Establish and Document T&E Criteria Step 3: Review Logistic Data Step 4: Review Logistic Products Step 5: Conduct Logistic Demonstrations Step 6: Update and Determine Corrective Actions SA3 SA3.1 SA3.2 SA3.3 SA3.4 SA3.5 SA3.6 In-service Supportability Assessments Step 1: Plan In-service Assessments Step 2: Conduct In-service Assessments Step 3: Validate Against User Requirements Step 4: Assess Changed User Requirements Step 5: Update and Determine Corrective Actions SA4 SA4.1 SA4.2 SA4.3 SA4.4 SA4.5 Table 2-1: Index of Logistic Support Analysis Activities Annexes: A. General Application Guidance for LSA Programs B. LSA Process Flow 2-6

19 ANNE A TO CHAPTER 2 GENERAL APPLICATION GUIDANCE FOR LSA PROGRAMS INTRODUCTION 1. The purpose of this Annex is to provide rationale and preliminary guidance for the planning of an LSA Program. This annex is to be used to guide tailoring of the LSA Program in the most cost-effective manner to meet an individual program's ILS goals. When planning an LSA Program this annex should be reviewed before reviewing the Guidance for LSA Activities in the Annex A of each of Chapters 3, 4, 5 and This annex contains no requirements and is not intended for contractual application. This annex should not be referenced or implemented in contractual documents. 3. This annex contains the following sections: a. LSA Program Requirements; b. Objectives and Constraints; c. Strategy in Developing Analysis Requirements; d. Factors Impacting Analysis Strategy; e. Selecting LSA Activities based on Design Influence; f. Application by Project Phase; g. LSA Documentation and Data Requirements; and h. Modelling. LSA Process LSA PROGRAM REQUIREMENTS 4. LSA is an iterative process based on the application of the Systems Engineering philosophy to the specific requirements of analysis for developing Mission System/equipment (end product) Supportability Characteristics and the associated Support Systems (enabling products). Unlike Systems Engineering, LSA is focussed primarily on analysis aspects, while the management and control processes for LSA are implemented by ILS management, via the LSA Strategy, LSA Plan and applicable management meetings. LSA may be viewed in terms of a System Engineering transformation process as shown in Figure Like the ILS discipline that LSA provides analytical support for, LSA is a multidisciplinary activity with many interfaces. Therefore LSA must interact with each ILS element to analyse and determine optimum and holistic solutions for achieving ILS goals. As an iterative process the input - output relationships and associated interfaces change depending on the stage in the life cycle. Supported by LSA management and enabling Activities, the LSA process can be divided into two general parts: a. Supportability Analysis, comprising Functional Logistics Requirements and Physical Resource Requirements, and b. Supportability Assessment, comprising Verification and Validation processes such as Supportability (Suitability) Test and Evaluation Activities.

20 Figure 1 LSA as a Transformation Process Supportability Analysis 6. This portion of the LSA process commences at the system level to affect design and operational concepts; identify gross logistic support resource requirements of alternative concepts; and to relate design, operational, and supportability characteristics to system preparedness and life cycle costing objectives. The system level analysis begins with requirements identification of user operational and support requirements and is characterised by Use Studies, Comparative Analysis and system driver identification. 7. The functional analysis continues to identify requirements, determines the functions required to support the identified requirements, and identifies and assesses risk. Implementation methods to meet supportability characteristics and Support System requirements include: a. the identification of technological and standardisation opportunities; b. tradeoffs between support, operational and Mission System design concepts; and c. tradeoffs between alternative support concepts. 8. Alternative support concept tradeoffs may include organic versus contractor support, built-in test versus external test, equipment complexity versus technical knowledge and training, and by varying the numbers of maintenance levels or the supply chain structure. Once system level tradeoffs are made, the next iterations apply analysis to lower system indenture levels and move towards Support System optimisation within the framework established by the system level analysis. 9. The physically oriented analysis defines the logistic support resource requirements of the system through the integrated analysis of all operator, maintenance and support functions and the individual tasks involved, to determine task frequencies, task times, personnel and skill requirements, and the required support resources. Optimisation is achieved at this level through allocation of functions and tasks to specific maintenance levels, repair versus discard analyses, maintenance scheduling based on RCM, and formulating design recommendations to optimise maintenance times, and logistic support resource optimisation. 10. Data from Physical LSA is used as a primary input into the development of data products associated with each ILS element including various provisioning lists, personnel and training requirements, and technical manuals. This assures compatibility and consistency between ILS element data products and permits the use of common data that applies to more than one ILS element. 2A-2

21 Supportability Assessment 11. This part of the LSA process is conducted throughout the Mission System's life cycle to demonstrate, within stated confidence levels, the validity of the analysis and products developed from the analysis, and to adjust the analysis results and products as required. 12. This part of the process starts with early planning for assessment including validation of required system supportability characteristics and the requirements for complementary Support Systems. Requirements validation is followed by verification as the Contractor's specified solutions are assessed against contracted requirements. 13. The assessment process continues through development, acquisition, deployment stages including the verification of data products and system deliverables through the supportability components of Development, Production, Acceptance, and Operational Test and Evaluation, often referred to as "suitability testing". Supportability assessments continue In-service with both continuous monitoring and/or discrete testing of operations and support functions. Key Interfaces 14. Some of the LSA Activities where interfaces play a key role are listed below along with the relevant interfacing activities: a. Comparative Analysis. Interfacing activities - design engineering, reliability, maintainability, safety, human engineering and each ILS element. b. Functional Requirements Identification. Interfacing activities - design engineering, reliability, maintainability, safety, human engineering and each ILS element. c. Evaluations and Tradeoff of Requirements. Interfacing activities - design engineering, reliability, maintainability, safety, human engineering, cost estimating, and each ILS element. d. Task Analysis. Interfacing activities - reliability, maintainability, human engineering, safety and each ILS element. e. Resource Evaluations and Tradeoffs. Interfacing activities design engineering, reliability, maintainability, safety, human engineering, cost optimisation, and each ILS element. f. Definition of Resource Requirements. Interfacing activities - design engineering and each ILS element. 15. Coordinating the above interfaces between LSA Activities and other program activities is a major management challenge that requires resolution through personnel in both managerial and working level / analytical processes. Steps within each LSA Activity have been structured to facilitate the interfacing requirement of relevant functions. 16. Initially, during Defence requirements identification and functional analysis, interfaces will be described through the ILS Plan and to some extent the LSA Strategy. When Performing Activity involvement begins the management and implementation of these interfaces is to be documented as appropriate. Where the Performing Activity is a contractor these details are recorded in the Integrated Support Plan (ISP) for overall management and the LSA Plan for managing individual LSA Activities and Steps. When the Performing Activity is an internal organisation, these interfaces are recorded in the ILSP. 17. Inputs and Outputs of System Level LSA. System level LSA involves analysis at the system/equipment level for system operation and support (Requirements Evaluations and Tradeoffs, Step 2). System level LSA is an input to and subset of these tradeoffs and is in turn a collection, synthesis, and system analysis of inputs from various specialised areas. Figure 2 shows some of these major relationships in input-output form. The outputs from the system level LSA impact the interfacing activities in that they constitute boundary conditions or goals for specialised engineering programs, ILS element concepts and plans, and future iterations of the LSA process. 2A-3

22 Figure 2 System Level LSA 18. Refinement and Extension of the System Level LSA. As the development of concepts for prime equipment (or later modifications) progresses, the LSA process is extended through further iterations to lower indenture levels with the input-output concept still functioning. Boundary conditions, constraints, and objectives are refined and expanded in detail based on inputs from specialised engineering and ILS element areas. Additionally, the Support System is optimised within the boundaries and objectives established. Specific tradeoffs within engineering specialties and ILS elements are conducted to provide specific boundaries for follow-on efforts. For example: a. the first (system level) iteration of tradeoffs between alternative maintenance concepts is followed by training concepts; b. the next iteration has preliminary maintenance allocations then training needs (requirements) analysis; c. then training costs may go into economic LORA modelling with the results identifying exactly which maintenance tasks require training for each maintenance level; and d. as a result of LORA, maintenance plans and training syllabi would be developed for the optimised and approved maintenance and training solution. This example includes the transition to physical analysis with greater levels of detail that is bound by the outputs of the functional system level analysis. While only two ILS elements are used in the example, the process applies to all product based ILS elements. 19. Task Analysis Interfaces. The determination of physical logistic resource requirements is based on the detailed analysis of operations, maintenance and support tasks. LSA is structured to serve an analytical function that determines the resource requirements stemming from each ILS element. Accordingly, this LSA function interfaces with and provides source data for engineering and functional specialties regarding operator, maintainer and support personnel task requirements. This source data is intended to serve as input to the analytical requirements of these specialties. 20. Definition of Resource Requirements. This step in the LSA process involves identification of all logistic resource requirements. Resource definition requires much input from design and specialised engineering areas, and all resource requirements are summarised in the LSA Record. The resource requirements are then available as input into ILS Program and individual ILS Element Plans for the development and delivery of support resources. 2A-4

23 ILS PROGRAM OBJECTIVES AND CONSTRAINTS 21. The objectives for an LSA Program usually aim to achieve the optimum balance between capability preparedness, cost and support, in accordance with the individual ILS goals for that program. Hence LSA is a tool that can be used to provide direct input into the supportability and cost factors associated with a system/equipment and therefore significant input into system/equipment decisions. While specific criteria and emphasis vary from one ILS Program to another, there are three primary system level issues that consistently affect acquisition and In-service support decisions, and are analysed in detail by the LSA process. These issues are personnel constraints, system preparedness and Life Cycle Cost. These issues are described below. Personnel Constraints 22. Personnel considerations have a significant influence on the operation and support of all major and many smaller system/equipment projects. Personnel is a unique element of ILS in that resources for other ILS elements can usually be purchased, however Personnel cannot be acquired easily and specialised skills will often take years to develop both within Defence and industry. Acquiring specialist skills through industry support can be restricted as contractors may face similar skill development periods as Defence, but with an overriding commercial imperative. The difficulty in acquiring the Personnel resource and the on-going emphasis to limit the size of the Defence workforce are likely to continue, hence careful management will be required. 23. Personnel resources are not only the most difficult ILS Element to develop, but also one of the most significant cost drivers of any program. The Personnel dilemma is of such magnitude that it must be approached through the design process or through the selection of designs with low personnel overheads, as well as applying the traditional approach of optimising existing workforce resources. Personnel numbers and the skill level demands for new systems must be managed like any other major design parameter, beginning with analysis of the earliest operation and support concepts for the new system/equipment. LSA effort should be planned to assess personnel requirements in support of achieving set targets and key milestones of the decision process for each program. System Preparedness Objectives 24. System supportability related design parameters (such as Reliability, Maintainability & Testability (RM&T)), logistic support resources (such as spares, tools and personnel), and logistic system parameters (such as resupply time and work hours to repair) must be related to system preparedness objectives. These objectives should enunciate both the needs for a system to be available when required, and the ability to sustain the system for as long as required. Such objectives will vary from system to system and from peacetime to wartime. 25. Operational availability is useful as a peacetime measure of preparedness, although it cannot be used for contractual purposes as there are many variables in operation and support that are outside the Contractor s control. More appropriate measures of system preparedness for contractual purposes or investigating areas for improving the logistic Support System must be based on lower level system supportability characteristics and Support System parameters as de facto measures for availability. 26. Mission/deployment availability, sortie rates (surge and sustained), duration of deployment and independent operation are often key parameters for a wartime capability, but for contractual purposes can only be modelled. System preparedness measures must be considered as design parameters and along with performance, schedule, and cost they must be managed accordingly, beginning with the earliest conception of new systems/equipment. Preparedness can be modelled In-service to assess the benefits of implementing Support System improvements or to develop modification/upgrade requirements. Life Cycle Cost Objectives 27. It is necessary to consider support investment, operating and support costs, and disposal costs, as well as other acquisition costs, in major system acquisitions and when optimising a system/equipment and its support for the whole of the system's life cycle. Similar importance applies to minor projects and modifications, although the scope for reducing Life Cycle Cost (LCC) will be more restricted. 28. LCC estimates can compare the total life cycle costs of research and development, investment, deployment, operations, support, and disposal for various system alternatives or alternatives within a system. The cost estimation methodology should explicitly address the resource requirements to achieve specified 2A-5

24 levels of preparedness for given assumptions concerning system RM&T characteristics, usage rates, operating scenarios and non-economic constraints such as limits to workforce skills and personnel numbers. 29. Various segments of LCC Analysis (LCCA), particularly for operating and support costs, are vital to effective requirements and resource evaluations and tradeoff decisions. Cost uncertainty in some areas of resource requirements, such as personnel and energy requirements, is such that sensitivity analysis needs to be included in LCCA. All major elements of life cycle costs are to be addressed in comparisons of complete system/equipment and Support System options with the objective is to minimise LCC while meeting project objectives and constraints, such as system preparedness and personnel objectives. Introduction STRATEGY IN DEVELOPING ANALYSIS REQUIREMENTS 30. The key to a productive and cost effective LSA Program is in the clear alignment with ILS goals and the concentration of effort on those Activities which will provide the most benefit to the program. The identification of how LSA Activities are applied to an individual program and the concentration of effort is documented in the LSA Strategy, with additional detail of the Performing Activity s effort contained in the LSA Plan. The generic goals of LSA are to: a. Ensure that supportability requirements are an integral part of system requirements and design, b. Define an integrated set of support requirements that are concurrent with the system design, c. Define the optimal physical resource requirements, and d. Develop and prepare attendant data products from a consistent information source. 31. These generic LSA goals must be translated into more specific objectives appropriate for achieving the ILS goals of each individual program. The earlier in a program that LSA can be employed to pursue ILS goals the greater the potential benefits; as it is during the early stages when there is greatest scope to improve capability preparedness, achieve personnel constraints, and reduce Life Cycle Costs. 32. In pursuing program ILS goals, most LSA Activities and Steps will be undertaken in some form, the primary difference between individual programs is the level of detail and effort required from each Activity and the subject matter to which those activities are focussed. Accordingly, LSA Activities must be tailored, focussed and scheduled to effectively achieve ILS goals. The guidance in the following paragraphs details the strategy for developing analysis requirements by tailoring and focussing LSA Activities. Scheduling of activities naturally follows the focussing effort. Tailoring LSA Activities 33. Tailoring LSA Activities includes two functions. Firstly there is the modification of LSA Activities and Steps to meet the contractual requirements of a project where the generic descriptions in Chapters 3 to 6 do not meet the individual program's needs. The second tailoring function involves the selection of the LSA Activities and Steps required to achieve ILS Program goals and objectives. These two functions are explained below. 34. In the majority of cases there will be no need to undertake the first tailoring function to modify Activity and Step descriptions; focussing LSA Activities and Steps is usually sufficient to explain the particular analysis requirements of an Activity within an individual LSA Program (see Focussing LSA Activities below). 35. The second function of tailoring (the selection of Activities and Steps) is necessary to identify which Activities, and Steps within Activities, will not be undertaken as part of the individual LSA Program. The majority of LSA Activities are structured as a logical sequence of Steps however some Steps are optional or can repeat within the conduct of an Activity. Additionally, some Steps are only applicable at certain stages of a program and may not be applicable if that program only deals with a segment of the development or procurement process. 36. Figure 3 portrays a general tailoring logic tree that may be followed in selecting Activities and Steps. This flow chart represents a typical project and the resulting tailored selection should be evaluated against the requirements for an individual program. 2A-6

25 Figure 3 LSA Tailoring Logic 37. Table 1 correlates with Figure 3 with respect to the coverage of design influence, and should be reviewed for further confirmation of Activity/Step selection. The initial selection of Activities and Steps can be adjusted for the following considerations: a. The amount of design freedom; b. Time phasing adjustments if program is "fast track"; 2A-7

26 c. Work already done; d. Data availability and relevancy; e. Time and resource availability; f. Policy directives; g. Desired activities outside the scope of the LSA standard; and h. Procurement considerations. 38. If an LSA Activity or Step is not feasible or will only provide limited benefit in achieving ILS goals, then it may be deselected. If when dealing with a limited budget, an Activity or Step is of benefit but not as significant as others that will achieved greater benefit, then the decision may be made to deselect the less beneficial activity. Where an Activity or Step is removed from the program the reasons for this should be documented and ILSM (or project manager) approval obtained. Focussing LSA Activities 39. The focussing of LSA is the description of how, and in which materiel life cycle phase or stage of an acquisition program, the tailored Activities and Steps will be applied in support of achieving ILS goals and evaluating risk. After the initial tailoring is complete, focussing is needed to concentrate effort in areas that have the greatest potential to improve supportability, preparedness or reduce cost, and to specify other requirements of the LSA Program, such as deliverables. 40. As LSA is an iterative and multidisciplinary process, Activities to be applied are often repeated with a focussed strategy describing how Activities are to be applied for the relevant area of analysis and as applicable to each phase of a program s schedule. Table 2 identifies Activities and Steps applicable to each stage of the development and engineering activity. Table 2 is based on a theoretical program and only shows general application, Activities must be scheduled to suit the specific requirements of each LSA Program. Other considerations under focussing should include: a. specification of analysis Activities such that they can be assigned to the most appropriate organisation; b. specification of models and associated data to be used; c. specification of areas or activity requiring approval; d. analysis requirements for technologies associated with different functional systems; and e. design freedom. 41. The Requiring Authority should ensure that the analysis needs are defined to obtain the best return on investment, while avoiding nugatory effort. Models and definitions to be used for a particular analysis should be specified where possible, especially in a competitive environment where each option being analysed must be considered on an equal basis. 42. The following section discusses the planning and development of the LSA Strategy and the factors impacting the analysis strategy. FACTORS IMPACTING ANALYSIS STRATEGY 43. Level of Design Freedom. The level of Design Freedom and the Design Influence to be exercised are key considerations in analysis selection and focussing. Design freedom is related to program considerations such as phasing; for example the design of the Mission System should only be addressed in the pre-design stages to avoid expensive rework. 44. The objective of most FELSA Activities in a development project is to influence selection of design characteristics to achieve improvements in preparedness through supportability characteristics, and reduced life cycle cost. Alternately, if the design options are fixed, emphasis is placed on determining the most supportable design for achieving preparedness goals and reducing life cycle cost. 2A-8

27 45. Product update programs may limit design freedom to specific subsystems unless other areas are open to redesign (including replacement with off-the-shelf items) where it can be shown that beneficial improvements can be made, hence Activities may focus on identifying those areas. 46. Fast track programs tend to bring forward or move back various analysis options, use existing technology and include plans for later product improvements rather than implement designs based on new technology; thus the level of design freedom may be reduced. 47. The LSA goal of causing supportability to be an integral part of system/equipment requirements and design is best achieved if designers are guided by a holistic Systems Engineering approach, that includes supportability objectives, when commencing the design effort. Technical information generated and documented during the design process must be disseminated among designers and supportability specialists to identify interface problems between design concepts, operators, maintainers, Support Systems, and infrastructure. Technical design information such as diagnostic features, electro/mechanical interfaces, reliability estimates, item functions, adjustment requirements, and interconnectors, which determine supportability characteristics, should be an integral part of system and subsystem design documentation. The Performing Activity's LSA Plan should describe the generation, control, and approval of this type of information. 48. Design Freedom may exist for the Support System but not the Mission System or equipment. LSA objectives and effort should be focused accordingly, as many Activities are applied to both the system/equipment design and associated Support Systems development. In this instance, the LSA Strategy and Plan would focus LSA Activities, that apply to both Mission and Support System, towards Support System oriented analysis. 49. Type of LSA Program. LSA Programs include new development programs, integration programs, offthe-shelf procurements, product modifications, capability update programs and in-service monitoring programs. True off-the-shelf programs are rare, most equipment procurement programs are integration programs involving the modification and integration and of various off-the-shelf systems and subsystems. Integration programs are actually development programs dealing with design through selection of systems and subsystems instead of modules and components, hence development and integration programs usually apply the same LSA Activities focussed according to design freedom, which is discussed in this section above. 50. Comparing a major Mission System with a minor equipment program would show differences in Activity and Step selection and focusing. For example, a more limited and focused preparedness analysis may be appropriate for an equipment contract, and the alternative support concepts may be restrained by established Support Systems or elements of existing Support Systems. 51. Preparedness goals must be a primary management focus beginning with program initiation. If such goals are ambitious, one focus of the early analyses should be toward preparedness related system design and support objectives, such as reliability and turnaround time. Systems and equipments that have large support personnel demands or which have high In-service Operations and Support (O&S) costs present greater investment opportunities for improvement than those with low demands or costs and, therefore, should receive greater consideration in selecting preliminary analysis objectives. 52. Within a type of LSA Program the scope impacts the LSA objectives and hence Activity selection and focusing. On a modification or update program, potential analysis objectives might focus on, (1) support risks on the changed part of the system/equipment, and (2) opportunities for improvement of supportability characteristics within the area of change. New or high technology efforts imply increased risk in attainment of supportability goals, and the consequent need for analysis to reduce these risks. Modernisation using proven technology may have less risk and still offer opportunity to reduce logistic support burdens. Such considerations impact the objectives and determination of analysis requirements. 53. LSA Program Stage or Phase. Focussing LSA Activities often includes describing the level of analysis for each applicable stage of the LSA Program. For Functional LSA Activities this may begin with requirements identification and the functional analysis of concepts, and move on to define system and then subsystem functional requirements as the program progresses. Iterations of Physical LSA Activities may start with analysis at the top physical level of the chosen system/equipment and progress down to the lowest level of repairable items. Activities should be focussed to describe the analysis for successive applications and documented in revisions of the LSA Strategy. Individual stages of a program, where Activity focussing may be applied are: a. Early Concept - for analysis of various capability options; 2A-9

28 b. Concept - for analysis of functional requirements and ways to implement the preferred capability option; c. Acquisition pre-contract - to further develop the Commonwealth's functional requirements; d. Contract to Detailed/Critical Design Review - Contractor's functional analysis and design for the Mission System; e. Contract to Support System Detailed Design Review - Contractor s functional analysis and design for the Support System; f. Support System Detailed Design Review to introduction into Service - determination of physical resource requirements; g. In-Service monitoring - to confirm supportability effectiveness and identify areas for improvement; h. In-Service modifications - to analyse logistic requirements for analysis; and i. Disposal preparations. 54. Time and Resource Availability. To influence design, LSA requires resources in the form of people, money and some tools (requirements database, models, etc). Do not specify Activities whose results would not be available in time to affect design, unless the potential improvement can be scheduled as part of a preplanned upgrade. Fast track programs, as their name implies, tend to reduce the time available for design influence at the lower level and hence restrict design influence to the selection of supportable systems and subsystems. 55. While it may be Defence policy to investigate (and fund) preparedness and support considerations in the front end of procurement programs due to the long term impact on capability and cost; nevertheless resources are constrained in practice. If program funds are short the LSA Program should use in-house capabilities as much as possible to perform activities such as early scoping the analysis effort, Comparative Analysis, and driver identification, and then only focus on the areas providing maximum possible returns. 56. Another approach when funds are short is to capitalise on the interrelationship between analysis Activities and Steps. This approach requires a small closely integrated team to perform analysis across a range of areas to maximise results on the interrelationships. The down side of this approach is the loss of indepth analysis available through a larger number of specialist teams conducting trade studies and analysis in their specialist areas. This scaled down approach also loses precision since judgements are substituted for the hard data of detailed analysis 57. If the in-house capability is limited (ie. limited staff) but funds are available, then certain Activities might be accomplished by contractors or consultants with specialist expertise. In this instance it is still up to Defence to direct, coordinate and integrate these analysis activities to ensure that cost effective analysis is undertaken that is cognisant of, and progresses toward, achieving the individual program LSA objectives and ILS goals. 58. Work Already Done. Work already accomplished in a previous project phase or stage should influence analysis selection and focussing. Likewise, useful analysis results may be available from a similar or technically related system already fielded either locally or overseas. If underlying requirements and resulting analysis were applicable, work from another project should be assessed and adapted as necessary to save on repeated effort. Previously completed work should be assessed for its contribution to achieving the program s objectives and adjustment to the required analysis made to economise on effort. Program initiation or requirements documents may prescribe objectives or constraints that have restricted the scope of the previous analysis effort and these should be assessed for realism and applicability to the new program before accepting them as limiting factors. 59. Past Experience and Historical Data. When implementing a procurement project, update or modification program the use of historical data and the past experience with In-service systems is an important component that can influence the selection and focussing of analysis. Activities to investigate and resolve known problems or drivers from previous systems offer a potential return. In this instance past experience contributes to the understanding through early Comparative Analysis. The availability, accuracy, and relevancy of experience and historical databases on similar existing systems are crucial for accomplishment of some analysis activities. Available databases must be examined to determine if 2A-10

29 extensive work is needed to provide focus or relevancy. If such databases are not available, a special sample data effort may be considered, particularly if the needed data is in an area of possible high returns for the analysis effort. 60. Procurement Considerations. The Requiring Authority must decide and specify the LSA Activities that are to be done solely by the Requiring Authority, those that may involve both parties, those that are to be performed solely by the Performing Activity, and any to be conducted by an independent agency. Once the analysis is assigned, the applicable LSA Activities can be focussed and work requirements written into procurement documentation, ie., the Statement of Work. It is useful to allow prospective Performing Activities, under the bidding terms of the procurement or in a risk reduction phase, to recommend changing the analysis activity selection and focus to provide a more detailed analysis definition and schedule suited to their proposal(s). Additionally, prospective Performing Activities should be encouraged to propose and make use of cost-effective analysis and data generation procedures; these efforts should become a factor in the assessment of cost reductions and the proposer s ability to perform the LSA Program. 61. Acquisition program LSA objectives, particularly for phased procurements, must be considered in preparing procurement documents. For example, in the early stages of a phased procurement the LSA Program will specifically exclude certain physical LSA Activities. In this instance an indication of what will be expected in latter phases should be included and appropriate analysis and data collected to plan for the next phase(s); the contractor should also be given the opportunity to contribute to the selection and focussing of analysis activities in the next phase. 62. The nature of the procurement may force the Performing Activity to undertake some analysis activity in order to make a rational and competitive bid. In this instance the Requiring Authority should provide guidance as to the extent of analysis required, conscious of keeping requirement for unpaid work to a minimum; eventually high costs of tendering are passed back to Defence and reduce competition. SELECTING LSA ACTIVITIES BASED ON DESIGN INFLUENCE Activity Group LSA PROGRAM PLANNING AND MANAGEMENT Purpose Activity / Step Ref. To provide effective planning and management to the LSA Program. LSA Strategy Step 1: Develop Early LSA Strategy Step 2: Prepare Cost Estimates Step 3: Update LM1 LM1.1 LM1.2 LM1.3 Mission System Design Design Influence Support System Design Logistic Requirement's MIL-STD A Task 101 LSA Plan Step 1: Develop LSA Plan. Step 2: Update LM2 LM2.1 LM Management and Analysis Reviews Step 1: Establish Review Procedures Step 2: Contribute to Design Reviews Step 3: Contribute to Program Reviews Step 4: Conduct ILS Reviews Step 5: Conduct LSA Guidance Conferences Step 6: Conduct LSA Reviews LM3 LM3.1 LM3.2 LM3.3 LM3.4 LM3.5 LM FUNCTIONAL LOGISTIC REQUIREMENTS To provide a Use Study systematic process Step 1: Identify Supportability Factors for the development Step 2: Quantify Supportability of functional logistic Characteristics requirements. Step 3: Conduct Field Visits Step 4. Develop Use Study Report Step 5: Update FL1 FL1.1 FL1.2 FL1.3 FL1.4 FL Functional Requirements Identification Step 1: Identify Functional Requirements Step 2: Determine Characteristics of Requirement Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Requirements Step 5: Perform Risk Assessment Step 6: Update FL2 FL2.1 FL2.2 FL2.3 FL2.4 FL2.5 FL (subtasks 1 to 3) 2A-11

30 Activity Group Purpose Activity / Step Ref. Comparative Analysis Step 1: Identify Comparative Candidates Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL3 FL3.1 FL3.2 FL3.3 FL3.4 FL3.5 FL3.6 Mission System Design Design Influence Support System Design Logistic Requirement's MIL-STD A Task 203 Standardisation Opportunities Step 1: Identify Standardisation Opportunities Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL4 FL4.1 FL4.2 FL4.3 FL4.4 FL4.5 FL Technological Opportunities Step 1: Identify Technological Opportunities Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL5 FL5.1 FL5.2 FL5.3 FL5.4 FL5.5 FL Support System Alternatives Step 1: Identify Support System Alternatives Step 2: Determine Characteristics Step 3: Identify Drivers Step 4: Evaluate and Tradeoff Step 5: Perform Risk Assessment Step 6: Update FL6 FL6.1 FL6.2 FL6.3 FL6.4 FL6.5 FL Requirements Evaluations and Tradeoffs Step 1: Determine Evaluation and Tradeoff Criteria Step 2: Determine System Supportability Requirements Step 3: Determine Support System Requirements Step 4: Determine Comparative Baseline Step 5: Assess Opportunities and Alternatives Step 6: Perform Sensitivity and Risk Analysis Step 7: Update FL7 FL7.1 FL7.2 FL7.3 FL7.4 FL7.5 FL7.6 FL (functional application) Functional Requirements Definition Step 1: Define Characteristics and Requirements Step 2: Define Objectives and Risks Step 3: Address Intellectual Property Step 4: Address Joint Forces and Interoperability Step 5: Define Constraints and Other Requirements Step 6: Document Requirements Step 7: Update FL8 FL8.1 FL8.2 FL8.3 FL8.4 FL8.5 FL8.6 FL PHYSICAL RESOURCE REQUIREMENTS To develop the Task Analysis logistic resource Step 1: Identify Tasks package, plan Step 2: Determine Task Characteristics deployment of Step 3: Identify New and Critical Resources logistic resources, Step 4: Optimise Task Attributes disposal and Post Step 5: Document Task Analysis Production Support. Step 6: Update PL1 PL1.1 PL1.2 PL1.3 PL1.4 PL1.5 PL and parts of 401 Resource Evaluations and Tradeoffs Step 1: Determine Tradeoff Criteria Step 2: Determine Non-economic Criteria Step 3: Conduct Evaluations and Tradeoffs Step 4: Perform Sensitivity & Risk Analysis Step 5: Update PL2 PL2.1 PL2.2 PL2.3 PL2.4 PL (physical application) 2A-12

31 Activity Group Purpose Activity / Step Ref. Definition of Resource Package Step 1: Compile Resource Package Step 2: Develop ILS Products Step 3: Identify Provisioning Requirements Step 4: Document in Management Plans PL3 PL3.1 PL3.2 PL3.3 PL3.4 Mission System Design Design Influence Support System Design Logistic Requirement's MIL-STD A Task 401 (parts of) Transition Analysis Step 1: Identify Existing Resources Step 2: Conduct Early Fielding Analysis Step 3: Identify Resource Deficiencies Step 4: Assess the Impact of Resource Shortfalls Step 5: Resolve Personnel Deficiencies Step 6: Document in Transition Plan PL4 PL4.1 PL4.2 PL4.3 PL4.4 PL4.5 PL Post Production Support Analysis Step 1: Identify Post-Production Support Candidates Step 2: Identify Alternatives for Post- Production Support Step 3: Monitor Production and Support Activities Step 4: Identify Reprovisioning Requirements PL5 PL5.1 PL5.2 PL5.3 PL Disposal Analysis Step 1: Identify Candidates for Disposal Step 2: Identify Resources for Re-allocation Step 3: Identify Special Disposal Requirements Step 4: Identify and Evaluate Options for Disposal Step 5: Document in Disposal Plan PL6 PL6.1 PL6.2 PL6.3 PL6.4 PL6.5 new SUPPORTABILITY ASSESSMENTS To provide supportability assessments of requirements and products. ST&E Strategy Step 1: Establish ST&E Strategy Step 2: Prepare Cost Estimates Step 3: Update Evaluation of Functional Requirements Step 1: Establish Measurable Requirements Step 2: Validate and Verify Requirements Step 3: Assess Requirements Allocation Step 4: Update and Determine Corrective Actions SA1 SA1.1 SA1.2 SA1.3 SA2 SA2.1 SA2.2 SA2.3 SA (functional) Verification of Physical Characteristics and Resources Step 1: Identify Supportability Assessment Candidates Step 2: Establish and Document T&E Criteria Step 3: Review Logistic Data Step 4: Review Logistic Products Step 5: Conduct Logistic Demonstrations Step 6: Update and Determine Corrective Actions SA3 SA3.1 SA3.2 SA3.3 SA3.4 SA3.5 SA (physical application of subtasks 2 to 4) In-service Supportability Assessments Step 1: Plan In-service Assessments Step 2: Conduct In-service Assessments Step 3: Validate Against User Requirements Step 4: Assess Changed User Requirements Step 5: Update and Determine Corrective Actions SA4 SA4.1 SA4.2 SA4.3 SA4.4 SA (extension to subtasks 5 and 6) Table 1 Index of Logistic Support Analysis Activities 63. The last column of Table 1 indicates the origins of these LSA Activities from MIL-STD A Tasks. The Design Influence columns of this table indicate the applicability of each Activity and Step to the first three LSA goals and the related levels of Design Freedom in design of the Mission System, the design of Support Systems and the determination of logistic resource requirements. Design Influence requires the Design Freedom, desire, and resources to influence the design. The design influence columns can be described as: 2A-13

32 a. Mission System Design. Design of the Mission System / end item can be influenced for improved supportability characteristics. This may includes improving RM&T characteristics; standardisation of parts, materials and software modules and languages; transportability; improving accessibility; safety; etc. This is applicable to development and integration type projects and some off-the-shelf projects where the most supportable of competing designs may be chosen. b. Support System Design. Design of the Support System and/or selection of the Support System elements. This includes the ability to change support concepts, eg., the number of maintenance levels, the mix of local industry versus foreign support, electronic versus paper technical manuals, etc. c. Logistics Requirements. Essentially there is no design influence of either the Mission System(s) or the Support Systems. Essentially the LSA Program will concentrate on optimising the resource package for the intended user environment. 64. The logistics requirements column applies also to programs with either, or both, Mission and Support System design freedom. Introduction APPLICATION BY LIFE CYCLE PHASE 65. LSA was initially developed for application on major development projects in the US military, however the benefit of applying LSA techniques in other situations has also been recognised. LSA is now applicable to non-developmental and off-the-shelf acquisitions, In-service modifications and update projects. LSA also has application in non-procurement activities including In-service monitoring, analysis, resource optimisation activities, and preparing for disposal. Concept 66. LSA conducted in the Concept phase is usually called Front End Logistic Support Analysis (FELSA). FELSA provides analytical support into the investigation of alternative support concepts associated with different capability options. This may be followed by a more detailed assessment of the preferred capability option leading to the identification of supportability requirements of a Functional Baseline system, and the estimated gross logistics requirements of its Support System. 67. FELSA provides both qualitative and quantitative support concept information for inclusion in a number of early project management and approval documents. FELSA also provides broad quantitative estimates for Life Cycle Costing Analysis and Reliability, Availability and Maintainability Analysis. FELSA is primarily conducted by the Requiring Authority s Concept Development staff, often drawing on advice from Acquisition and In-service support staff, operating units, and industry. Acquisition 68. An acquisition project's requirements for, and demands from, an LSA Program varies significantly with the complexity of the system/equipment being purchased, maturity of design, purchase cost, and other factors including existing systems, budgets, schedules, and operational urgency. For the majority of projects most LSA Acquisition phase Activities will be undertaken in some form, however the level of detail required and effort conducted under each Activity changes significantly depending on individual project factors. 69. Pre-Contract LSA. Pre-contract LSA should be focussed on identifying and developing the functional requirements for solicitation and specification documents. Building on analysis performed during Concept, the next iteration of LSA aims to add greater definition and quantitative measures to requirements identified earlier. This entails requirements identification at a more detailed level than before, functional analysis, synthesis, tradeoff of alternatives, and an initial requirements validation. LSA in this period is usually undertaken at system and subsystem levels. 70. The pre-contract period is also the time to refine the LSA Strategy to identify analysis to be conducted by the Performing Activity(ies) through an appropriately tailored Statement Of Work. The solicitation documents are used to gain information on how potential contractors would implement stated support concepts, identify new support concepts, and identify new concepts for improving the supportability characteristics of the proposed system/equipment. The tendered documents, such as an outline ILS/LSA 2A-14

33 Plan, can also be used to assess the potential Contractors understanding and ability to perform the LSA Activities required to achieve the program's ILS goals and implement logistic requirements. 71. Post-Contract LSA. Post-contract LSA Activities performed by the Contractor are guided by the approved LSA Plan, in accordance with the SOW. Depending on the program, Functional LSA Activities will continue to be applied to investigate and develop system supportability characteristics, identify systems/subsystems that achieve supportability requirements, and investigate and develop alternative Support System concepts. 72. The allocation of a system/equipment s functional requirements to its physical components is conducted by the Contractor as part of the overall Systems Engineering process and is not explicitly covered by an LSA Activity. However the allocation of supportability characteristics to a design should be assessed to ensure supportability requirements are correctly understood and translated into a physical solution. This assessment includes the understanding of failure criticality, such as what constitutes technical and mission critical failures, and may also involve reliability and maintainability roll-up calculations. Other characteristics such as the likely achievement of standardisation and interoperability objectives may be assessed. Initial Physical LSA Activities may be required to assess the likelihood of the system meeting its functional requirements, such as a top level Task Analysis to support gross estimates of the personnel required for onequipment maintenance. 73. In the period immediately following Detailed/Critical Design Review, when the design enters full configuration control, Functional LSA Activities for the system should be concluding while Physical LSA Activities are becoming established. Functional LSA Activities for design of the Support System will normally lag the Mission System design and be concluded by the Support System Detailed Design Review. Analysis then focuses on the development of the physical solution for the required Support Systems, including detailed maintenance and support plans, and the development of the logistic resource package required to support the new system/equipment through life. 74. Physical analysis is a 'task centric' process, meaning it is based around the identification and analysis of all applicable operator, maintenance, and other support tasks, and the ILS resources required to perform those tasks. This process usually starts at the top level of system/equipment indenture and works down through the breakdown structure until it is determined that the applicable tasks are no longer of interest as the item will be discarded on failure or not maintained by Defence. There are exceptions to this, including: a. when analysis proceeds further if the support tasks are to be performed by a third party contracted directly to Defence instead of via the prime acquisition contractor; b. when Defence wishes to keep the option of third party support available for later in the life cycle; c. when Defence wishes to enable the third party support to be re-contracted under competitive conditions or transferred to in-house support; and d. when Defence is required to verify that support contractors are adequately established to provide specialist support to In-service units (this includes establishing local industry involvement, particularly for new industry capabilities). 75. Once the tasks have been analysed the resource requirements for all tasks are aggregated to determine the total resource package for the system. Resources include all physical ILS elements, ie., personnel, training, documentation, spares, S&TE, etc. 76. The LSA Program should not repeat (and pay again for) analysis which has already been performed on existing systems or components, if the earlier analysis is applicable. Analysis used for another customer should have considered that customers operating environment, annual operating requirement, and their support environment including trade skills, facilities, standardisation programs, etc. Hence the existing analysis may require significant rework before it is suitable. The Logistic Support Analysis Record is designed to facilitate the task centric analysis of logistic resource determination and can assist in automating the update of existing data. 77. Following the task centric resource analysis described above, attention is focussed on the requirements for preparing the receiving units for the arrival of the new system/equipment using Transition Analysis and the long-term availability of spares and resources using Post Production Support analysis. The disposal of items and consumables during the In-service phase and eventual disposal of the complete system are planned using Disposal Analysis. 2A-15

34 78. Across this period, late in the Acquisition Phase and transition into Service, LSA Supportability Assessments of the physical system/equipment and Support System deliverables are undertaken to confirm achievement of specified requirements and LSA objectives. In-Service 79. There are several aspects to In-service LSA including follow-on activities from acquisition, smaller scale acquisition programs for modifications and updates, and analysis based on In-service experience and for operational changes. 80. LSA Activities following initial acquisition are varied depending on the individual program. These Activities will often focus on completing Supportability Assessment Activities that could not be conducted in the period when the acquisition program was active and equipment was being deployed. The inability to complete Supportability Assessment Activities prior to the In-service phase is usually due to either: a. a steady state In-service environment was required to achieve a stable system reliability, full fleet assessments were necessary, and/or mature Support Systems were required; or b. the evaluation required a longer period of time to collect data than was available during the transition period. Another Activity following acquisition is the continuation of Post-Production Support analysis, which can remain on going for the life of the system/equipment. 81. In-Service modifications and updates can apply a similar LSA process to a major acquisition on a suitably reduced scale. The emphasis is still to achieve the best value for effort from the LSA Program and the LSA Activities should be selected and focussed accordingly. 82. LSA techniques can also be used In-service to review the results of In-service monitoring or a change in the user requirements. The periodic assessment of reliability trends, maintainability and the nature of failures can contribute to the planning for modifications and upgrades or the re-provisioning of spares or other resources where usage has been higher than expected and will not be available for the applicable life span. The In-service Manager should have oversight of impending changes to user requirements, operating environments, and the rate of effort, and may initiate LSA Activities to assess and prepare for these changes accordingly. Disposal 83. Disposal Analysis includes the preparation for disposal of the system/equipment. This application is primarily conducted by the In-service Support agency however success is often dependent on analysis performed during the Acquisition phase to identify hazardous materials, environmental or other considerations. In the lead up to disposal the In-service Support agency plans the disposal including the identification or resources available for the replacing system; an input to the replacement system's Use Study. LSA Activities by Life Cycle Phase 84. The following table identifies the general applicability of LSA Activities during the Life Cycle phases, as discussed above. Disposal Analysis, for system retirement, should be conducted during the In-service Phase in the lead up to disposal; hence there is no Disposal Phase in Table 2. 2A-16

35 Life Cycle Phase / LSA Activity Concept Acquisition In-service Pre- Contract Contract to DDR/SSDDR SSDDR to In-service LSA PROGRAM PLANNING AND MANAGEMENT LSA Strategy G G S LSA Plan S G U S Management and Analysis Reviews S G G FUNCTIONAL LOGISTICS REQUIREMENTS Use Study G G U S Functional Requirements Identification G G S S Comparative Analysis G G S Standardisation Opportunities S G G U S Technological Opportunities S G G Support System Alternatives S G G U S Requirements Evaluations and Tradeoffs G G G U S Functional Requirements Definition S G G U S PHYSICAL RESOURCE REQUIREMENTS Task Analysis S S G S Resource Evaluations and Tradeoffs S S G S Definition of Resource Package S G S Transition Analysis S G S Post Production Support Analysis G S Disposal Analysis S G S SUPPORTABILITY ASSESSMENTS ST&E Strategy S G U U S Evaluation of Functional Requirements S G G S Verification of Physical Characteristics and Resources S G S In-service Supportability Assessments G Key: G - Generally Applicable (unless moved or removed due to program specific requirements) S - Selectively Applicable U - Update only Table 2 LSA Activities by Life Cycle Phase LSA DOCUMENTATION AND DATA REQUIREMENTS 85. The development and maintenance of good documentation covering the results of LSA Activities serve the following purposes: a. Provides an audit trail of analyses performed and decisions made that effect the supportability of a system or equipment; b. Provides analysis results for input into follow-on analysis activities later in the materiel life cycle; c. Provides source data for use by ILS element functional managers and a standard method of recording ILS element data from functional managers; d. Provides input into management documents for the acquisition program and In-service capability support; e. Helps prevent duplication of analyses; and f. Provides an experience database for use during In-service management and on future acquisition programs. 2A-17

36 86. The individual analysis Activities of an LSA Program may be performed by a Government and/or Contractor organisation, or by third party service providers. Analysis documentation must be developed to the degree that will allow another organisation to use the analysis results as input data to perform other LSA Activities, or as input to conduct the same Activity to a more detailed level in a later phase. Procedures must be established to provide for the data interchange between the Performing Activities and the receiving Requiring Authority. 87. A Data Item Description (DID) is used to define and describe the analysis data, results, and structure required to be furnished by a contractor. Where analysis is performed by Government organisations the results should be documented in an equivalent format to the applicable DID to assure compatibility of documentation between the Government and Contractors. Standard DIDs are structured to identify the range of data that can be documented in a report. The Requiring Authority can usually add to or reduce these requirements by modifying the standard DIDs to make them appropriate for use in their project. 88. When a contractor performs LSA Activities, documentation that the contractor will be obligated to deliver to the Government will be specified in the Contract Data Requirements List (CDRL). Likewise, preliminary analysis results may be called for in response to tender and specified in the Tender Data Requirements List (TDRL). For both the TDRL and CDRL, the appropriate DIDs should be cited. By appropriately tailoring the CDRL and DIDs the Requiring Authority can structure the deliverable data products to cost effectively meet program requirements. 89. There is a considerable distinction between data and the formatting of presented data. Data can be presented in a wide variety of formats, and care needs to be taken to ensure that the same data is not acquired (and paid for) in duplicate, due to requests for data in different formats. Because of these factors, LSA Program data and data formatting requirements must be carefully scoped to meet program needs in a cost-effective manner. Factors which affect data and documentation costs include the following: a. Timing of preparation and delivery. Data should be delivered in a timely manner to support the current analysis and verification activities. Repeat delivery of the same data should be avoided. b. Use of the data by, or provided by, the Performing Activity. The less use, the more expensive per application when compared with other data. Hence if not absolutely necessary some data may be eliminated as not being cost effective. c. Special formatting requirements. d. Degree of detail required. e. Degree of research required to obtain the data. f. Accuracy and amount of verification required. g. Duration of responsibility for data contents. h. Availability and accuracy of source data from which to construct documentation. For example, inaccurate schematics will increase the cost of technical manuals through unnecessary rework. i. Re-use of existing data and documentation. j. Intellectual Property constraints. 90. Data and data documentation costs can be effectively controlled by the following methods: a. Screening requirements prior to preparation of solicitation documents. Each data requirement should be reviewed for data content, end use, formatting needs, scheduled delivery, and estimated cost to eliminate duplication and assure proper integration and scheduling of requirements. ILS management generally performs this function. b. Using contractor format whenever possible. This generally reduces acquisition costs but must be evaluated against the In-service use of that data. Contractor formats may also provide important insights to contractor controls, checks, and balances between design and LSA functions. Additionally, reformatting requirements often result in a distillation of original data that can result in misleading or incomplete information. 2A-18

37 c. Involve potential bidders in briefings and planning conferences prior to issue of a solicitation document. This helps assure that data and data documentation requirements are realistic and that maximum use is made of data already available. d. Defining data applicability. There will be different data requirements for Mission and Support System components based on the level of indenture, type of system, design status, and support concept. Documenting these differences reduces ambiguity and associated increases in contract risk and cost. Introduction MODELLING 91. The utility of models to perform some aspects of LSA is almost in direct proportion to equipment complexity. For complex systems, a model is almost mandatory in order to relate the system or equipment's design, operational, and support parameters to system performance. Models are defined as systematic, analytical processes used to predict system outputs and characteristics. They can vary from simple analytical equations to a complex simulation model covering multiple end item environments, Support Systems, and all levels of maintenance. Benefits and Considerations 92. As a general rule, models used early in the life cycle would be system level models requiring a small amount of input data. Later in the acquisition process, as the design becomes better defined and the preferred support concept is established, a more detailed model would be more applicable. The models used should only be as complex as required to analyse the problem at hand. Applicable models, which can accept the level of data available at the time and appropriate to the complexity of the task, should be used wherever practical to enhance the timeliness of results; ie., less complex models should be used rather than waiting too long for the necessary data to populate a more complex model. 93. When system preparedness, life cycle cost, or other models are specified in tendering documents, the Requiring Authority needs to assess the proposal to evaluate the bidder's understanding of the model and its results. Modelled estimates and resulting data should be traceable from the operation and support concepts, and consistent with the Tenderer's RAM predictions, Mission and Support System design. 94. The benefits of modelling are the ability to solve complex numerical problems, and provide traceable and reproducible analytical results. The primary considerations are the suitability of the model to the situation being analysed and the operator's understanding of the model. Application 95. Through the conduct of Functional LSA, models should be applied to the development of alternative concepts and the likely impact on achieving the applicable ILS goals. During Physical LSA Activities, including the In-service phase, more detailed models are used to optimise the Support System and resource requirements. 96. Models used during Functional LSA are generally applied to Life Cycle Cost and Availability predictions. Models for predicting Availability will either directly calculate availability based on R&M and Administrative and Logistics Delay Times (ALDT) values, or apply a simulation of the system/equipment in its In-service environment. A directly calculated availability model provides exact and reproducible results, but should only be regarded as accurate as the input data. The simulation approach estimates the success of achieving availability based on simulating deployment or operational conditions, use, reliability, supportability characteristics, and available support resources. Each simulation is likely to produce a slightly different result and several "runs" of the simulation should be performed to examine the spread of results and an average result. 97. Additional specialist models may be applied to specific LSA Activities. These can include models for storing and performing reliability and maintainability roll-up calculations when RM&T values allocated to the functional system breakdown structure are being evaluated. The LSAR can also be used to hold and model a baseline comparison system for the new system/equipment, using standard reports to extract resource requirements. The application of the LSAR in this way is largely dependent on the availability of sufficient data. 2A-19

38 98. During the Physical LSA Activities, models will normally deal with a greater level of detail and will be applied to the determination of physical resource requirements. Again the models are based on LCC or RAM predictions, or a component thereof, eg., Level of Repair Analysis assesses the cost of maintenance. Models are applied to a number of LSA Activities with the primary models performing or supporting Level of Repair Analysis and Repairable Item Optimisation activities. 99. Models may also be developed to enhance the realism of results calculated by the LSAR standard reports. For example, LSAR calculations for personnel and skill requirements do not consider external factors such as time for off-equipment tasks such as general service training, or the need to construct shifts, watches on ships, provide supervision, administration, or career progression. Additional, but quite simple models can be developed to consistently enhance these calculated factors for realistic workforce planning. Recording Results 100. Results of modelling from which decisions will be made must be recorded along with input values, sources of estimates, and any assumptions needed to perform the modelling. Often it is inefficient to record all input values for each use of a model in a delivered report, instead the input data set should be saved and delivered and only high level assumptions and data sources reported. For simple models such as spreadsheets the whole spreadsheet will be archived, more complex models normally allow for the project data set to be stored in a separate data file. 2A-20

39 ANNE B TO CHAPTER 2 LSA PROCESS FLOW 1. This Annex contains typical flow diagrams for the LSA Process. The flow charts are only indicative, as the LSA process will vary from program to program, depending on individual program requirements. 2. Figures contained in this Annex include: a. Figure 1: LSA Life Cycle Flow; b. Figure 2: Concept Phase LSA - FELSA; c. Figure 3: Acquisition - Pre-Contract; d. Figure 4: Acquisition - Contract Effective Date to System Definition Review; e. Figure 5: Acquisition - SDR to Support System Detailed Design Review; f. Figure 6: Acquisition - SSDDR to Transition; g. Figure 7: In-service LSA - Optimisation; and h. Figure 8: In-service LSA - Modifications and Updates. 3. It should be noted that LSA is an iterative process and, for clarity, not all possible iterations have been shown in Figure1. For example, Functional Logistics Requirements Activities may be repeated several times, each time in greater detail. Hence LSA application in the Concept Phase, which replicates the more formal first stage of the Acquisition Phase, has not been included in Figure 1 but appears in Figure Improvement Opportunities which become optional solutions in later stages of investigation are grouped in a single box, signifying that not only are they performed in a similar timeframe but also that they must be compared and evaluated against each other; only the options with the sufficient benefits will be pursued. The boxes encompassing the first three Physical Resource Requirements Activities signifies that these interrelated Activities are evaluated as one complete process by the ST&E Activities SA3.3 and SA3.4 (Verification of Physical Characteristics and Requirements, Steps 3 and 4). 5. Figures 7 and 8 are representative of two different applications of LSA during the In-service Phase.

40 LSA LIFE CYCLE FLOW 2B-2 Figure 1 LSA Life Cycle Flow Diagram