Title:

Logistic Support Analysis (LSA)

Scope:
This document is applicable to the Division MLN, in all locations where this division resides for all new projects and bids with
LSA/ILS requirements

Purpose / Summary:
The purpose of this procedure is to provide a working level description of the Logistic Support Analysis (LSA) process during
all phases of the Bombardier Business Process with a focus on the engineering RAM/LCC part

Functions
Strategy, Markets and

Information Services
Product Introduction
Project Management

Capital Investment

Human Resources
Contracts & Legal
Product Planning

Communications
Health, Safety &
Manufacturing
Procurement

Environment
Maintenance
Operation &
Engineering

R = Responsible
Six Sigma
Services

(Process Owner)

Finance
Quality

Other

Other

Other
Sales

Bid

I = Involved

Process I I R I I I
Stakeholders
Process Characteristics
Suppliers Customers

Engineering INTERNAL CUSTOMERS: Product Introduction; Engineering

Suppliers (internal and external) / Procurement (documentation); Procurement; Project Management; Suppliers
Product Introduction / Services (Product Divisions); Services
EXTERNAL CUSTOMERS: Customer; Operator; Maintainer;
(Suppliers)
Inputs Outputs

LSA data, populated ELSA: Spares list (quantified & optimized); Tools
Requirements (ITT, customer, contracts, BT standards); Product
list; Skills list; Maintenance plan; Maintenance instructions; RAM/LCC
configuration; RAM/LCC analysis
data
Logistic support data (BLESS; Tech information, documentation)
Input and support to documentation; training and manuals
Feedback data

Process Performance Indicators

Populated ELSA
Responsible unit: Process owner: Document type: Confidentiality status : Original Language :

MLN S&A Procedure Internal EN

Organization and BTIP process structure prefix : Revision :
This document and its contents are the property of Bombardier Inc. or its
subsidiaries. This document contains confidential proprietary information. The
reproduction, distribution, utilisation or the communication of this document or any
part thereof, without express authorisation is strictly prohibited. Offenders will be
MLN-20-20-15- 00
held liable for the payment of damages. Doc ID-number : Document state :

© 2008(Year of release) Bombardier Inc. or its subsidiaries. All rights reserved

008742 Released

Filename: 008742 Rev 00 en

 Doc ID-number: 008742
Revision: 00

Table of Contents

Section Subject Page

1 Executive Summary 4
2 Involvement of Functions 4
3 Link to Other Processes 6
4 Link to the Business Phases 6
5 LSA high level Process Description 7
6 The LSA Detail level process Description 9

6.1 Set LSA objectives and strategy 10

6.1.1 Analyse LSA requirements 10

6.1.2 Determine Objective and strategy 10

6.1.2.1 LSA Strategy 10

6.1.2.2 LSA plan 10

6.2 Modelling 11

6.3 Breakdown & Distribute Objectives, Validate Feedback 12

6.3.1 Breakdown and distribute objectives 12

6.3.2 Receive data 13

6.3.2.1 External (Suppliers) approach 13

6.3.2.2 Internal approach 13

6.4 Perform LSA analyses; 14

6.4.1 Harmonisation 14

6.4.2 Optimization 15

6.5 Compile and Provide ILS data deliverables 15

6.5.1 Release internally 16

6.5.2 Release externally 16

6.6 LSA repetitive checks 16

6.6.1 Verify LSA compliance 17

6.6.2 Consider design change 17

6.6.3 Adapt LSA Objectives 18

6.6.4 Update Risks and Opportunities 18

6.6.5 Elaborate change and update LSA 18

6.6.6 Document & report 18

6.7 Populate ELSA 18

6.8 Handover / Freeze data 19

Confidential and proprietary Page 2 of 26

 Doc ID-number: 008742
Revision: 00

6.9 Demonstration / Measurements 19

7 Updates beyond the design freeze 20
8 Appendices 20
9 Definitions and Abbreviations 20
10 Reference documents 22
11 Archiving 22
12 Approval Information 23
13 Revision Log 23
ANNEX: LSA Deliverables 25

Confidential and proprietary Page 3 of 26

 Doc ID-number: 008742
Revision: 00

1 Executive Summary
A Logistic Support Analysis (LSA) process ensures that proper logistic support (LS) data is assembled,
analysed and stored to meet the overall Integrated Logistic Support (ILS) requirements of a project /
product. It addresses the engineering part within the overall ILS process by generating source data &
maintenance plans which drive other ILS elements such as training, documentation, provisioning, … .
The following benefits of utilizing this process are identified:
 To ensure that all logistic support data is brought together in a structured way and in harmony with a
product for a dedicated operational and services profile.
 To have common data storage & handling in ELSA (LS database & tool), thus providing a single
source / point of logistic support data;
 To have checkpoints (like AS-BID; AS- …) to allow traceability of the data evolution over time;
 To reduce the cost of ownership (e.g. operation and support)
 To provide the deliverables within engineering; other departments and business units;
 To ease transfer of data to future bids / projects or variants of existing projects;
 To strengthen the ILS competences of BT MLN;
 To increase efficiency and accuracy with less resources.

2 Involvement of Functions

In the following Table, Roles and Responsibilities are established in generic terms, enabling each
Department (PI, PM, RAM/LCC, …) to fulfil their tasks.

Project PM role to ensure that Departments work well together in respect of the overall contract. PM
Management manages the risks and opportunities.
(PM) PM shall also interface with Project Controller (Finance – PC) or with the Services department
depending on TSA / TSSSA, e.g. to discuss customer pricing of logistic support items. PM shall
approve the customer’s prices for logistic support.
Division1 Division RAM/LCC Department is the leader & co-ordinator of the LSA process with the support
RAM/LCC of the other departments.
Department Division RAM/LCC Department runs the process by means of assembling, verifying, analysing
and storing the logistic support data. More specifically, the Division RAM/LCC Department is
responsible for the following:
 Analysis of LSA requirements (customer / internal);
 Define for each Bid / Project, the overall and sub objectives on LSA scope (incl. RAM/LCC;
…);
 Collect and validate from suppliers (over procurement) and engineering all relevant data
information;
 Perform and update LSA analyses;
 Compile and Provide LS data deliverables to the customer, documentation services and PI;
Continuously / regular
 Verify / Demonstrate LSA compliance;
 Evaluate design, objectives, risks & opportunities
 Update the analysis when needed;

1 With division (+ department) is meant the department of the MLN OBU / Site that works on the project.
Confidential and proprietary Page 4 of 26
 Doc ID-number: 008742
Revision: 00

 Document the steps

 Populate ELSA database
 Handover / freeze data at milestones.
Division1 Throughout this process, Engineering (other than RAM/LCC department) is accountable for
Engineering providing logistic data (documentation, dimensions, weight, vehicle breakdown structure …).
(Supplier Engineering is responsible for the following:
Engineering)  Validating the parts list, quantities, dimensions and weights;
 Providing documentation on system functionalities;
 Providing documentation on physical installation of items;
 Pass on (from suppliers)/ Provide (BT concept) any other logistic support data;
 Participate in LSA analysis.
Division1 Throughout this process, PI is considered as the main internal customer, as the LS data serves
Product as input to the ILS process.
Introduction
(PI) PI is also responsible for the creation of the “Customer Service” section of the TRD/TRS to
ensure a back-to-back consideration of the ITT requirements for Product Introduction to the
suppliers. At this point the RAM/LCC department will be contacted to ensure completeness.

The role and responsibilities of PI are normally taken over by Services Division after warranty in
case of a TSA / TSSSA.
Services In case of a TSA / TSSSA, PI hands over certain tasks to Divisions Services.
This agreement will be made on project base, the default role and responsibility is with PI,
unless clearly agreed otherwise between PI and Services division.
As such reference may be made in this document to both PI and Services Division in order to
indicate that at least one of both will perform the (complete) task.
Services department, depending on TSA / TSSSA, shall discuss with PM, customer pricing of
logistic support items.
Procurement Throughout this process, Procurement ensures that logistic support data shall be delivered
according to the requirements by the Suppliers. Non-compliances, open items are efficiently
addressed and resolved.
All prices regarding logistic support (spares, tools, storage, training, documentation; …) shall be
negotiated by Procurement (Division procurement or Services procurement in case of TSA /
TSSSA).

 Note 1: Some Business Divisions have RAM/LCC departments. Other combinations/acronyms exist such
as: RAMS, RAMS/LCC, RAMSE/LCC, RM&S, or LCC, where R = Reliability, A = Availability, M =
Maintainability, S = Safety, E = Design for Environment, LCC = Life Cycle Cost. RAM/LCC is used in this
document to represent the RAM/LCC process. In MLN, the RAM/LCC functions are performed by the
S&DA (safety and design assurance) department within the Operating Business Units (OBUs/Sites).
 Note 2: Some projects require Integrated Logistic Support (ILS). Engineering RAM/LCC department is
preparing the input for the ILS elements during phases 2 – 4 (see figure 1). PI is responsible for the ILS
process. Co-ordination is needed between the RAM/LCC and PI in all phases in case of an ILS contract.

Confidential and proprietary Page 5 of 26

 Doc ID-number: 008742
Revision: 00

3 Link to Other Processes

The Design for RAM/LCC Process Procedure, -000251, documents the roles and responsibilities,
processes, activities, and tools that Bombardier Transportation puts in place to ensure that RAM/LCC
requirements are managed and complied with in all BT projects, products, and markets.

This process may overlap with the RAM/LCC process. It is not the intention of this process to repeat
completely nor to overrule the RAM/LCC process but to complement the process on specific LSA
matters.

The PI Integrated logistic Support Procedure, -000615, documents the roles and responsibilities,
processes, activities, and tools that Bombardier Transportation Product Introduction puts in place to
ensure that ILS requirements are managed and complied with in all BT projects, products, and
markets.

The FRACAS Procedure, -000299, documents the roles and responsibilities, processes, activities, and
tools that Bombardier Transportation puts in place to ensure that the RAM/LCC performance is
analysed and corrective actions are taken when judged necessary. The LSA process provides
elements to the FRACAS process to support the analysis and judgement.

The Engineering Change Request, (ECR) Procedure, -000450, documents the roles and
responsibilities, processes, activities, and tools that Bombardier Transportation puts in place to ensure
that modifications are managed and complied with in all BT projects, products, and markets. The ECR
procedure provides a notification to the RAM/LCC department to ensure that the LSA analysis &
outputs are updated accordingly.

4 Link to the Business Phases

1 Product
Strategy 2 Bid
3 Start-up
4 Design
5 Realization
6 Field
Support
1 2 3 1 2 3 4 1 2 3 1 2 3 1 2 3 4
Subphase

Beyond Contractual
Pre-Acceptance
Bid Finalization
Business Case
Product Option

Operation and

Product Support
Understanding

Qualification

Maintenance
1st Product
Negotiations
Assessment

Realization

Realization
Preparation
Preliminary

Warranty

Obligations
Marketing

Start-up

Detailed

Series
Design
Pre-Bid
Market

Design

Work

Market requirements
needs and possibilities

Logistic Support Analysis Process

PI ILS process ILS realisation

Product Service Performance Results

Figure 1 Links to the Business Phases

The diagram illustrates the different key process elements required to manage ILS requirements
performance throughout the product life cycle:

Confidential and proprietary Page 6 of 26

 Doc ID-number: 008742
Revision: 00

1) The analysis and definition of the market requirements and needs as well as possibilities and the
accurate assessment of the technical possibilities done in (the Product Strategy and) Bid Phases
(which must include use of actual in-service performance results called Product Service
Performance);
2) The product development process from the Bid Phase through the end of the design Phase to
ensure that product design and manufacturing include all the features needed to support
compliance with the RAM/LCC requirements (which benefit from Product Service Performance
results);
3) The outcome of the LSA is handed over to the PI for the realisation of the ILS in the Realisation
and Field Support Phases;
4) Finally, the closed loop information system which enables benefiting in the early project Phases
(Product Strategy through Design) from the Benchmarks & Lessons Learned in service to
improve, in the Bid and Design.

Product Introduction (PI) / Division Services handle the following Processes: “Integrated Logistic
Support” and “Product Service Performance Results” (Feedback of actual data).

5 LSA high level Process Description

The LSA process is an iterative process that may be performed with different levels of extend/detail
according to the phase and needs.

The LSA cycle (see LSA detail level process) is represented by 3 identical blocks labelled “LSA
(engineering ILS part)”.The LSA cycle may be repeated up to 3 times:

 at phase 1:for product strategy purposes;

 at phase 2: on a bid;
 from phase 3 onwards: on a project.

One shall pass through the cycle each time, yet with a different level of extend. The outcome of the
previous cycle can be transferred to the new cycle.

A first cycle is done during product strategy phase, where the LS data is established in an accelerated
way from the marked requirements.

The second cycle is during bid, where the LS data is established in an accelerated way and with
sufficient level of confidence, from the ITT.

The third cycle is during project design, where the bid LS data is reviewed, elaborated and detailed for
the project. The LS data from the bid will serve as basis.

At certain reference points (phase changes) there is a handover / freeze of the project data. The LSA
objectives may be demonstrated / measured at different phases:

 LSA type test demonstration: the one-off demonstration happens on a mock-up / prototype or first
built or on each train. This demonstration may be considered as part of the qualification.
 RAM/LCC demonstration: the LSA objectives are demonstrated / validated on the vehicles during
the warranty period and may be considered as a part of the validation or acceptance.
 In service LSA data: this approach is a long-term measurement on trains in operation.

Confidential and proprietary Page 7 of 26

 Doc ID-number: 008742
Revision: 00

LEGEND PREPARED BY Issued

Wim Vandenberghe
Trigger or
terminate
Decision Activity
Computerized
Process
Storage/
Filing
Online
Database
Document
Operation &
Inspection
Annotation
Sub
process
APPROVED BY 2007/12/01
Internal
M. Aourane YYYY/MM/DD
physical External AND Screen
Delay Inspection AND OR OR Condition Link Milestone
Connector transfer Connector Condition Display
DELIVERABLES
Page 1 of 3
NOTES & COMMENTS
This is an overview of the MLN LSA process. PROCESS NAME
The LSA engineering can be performed as 3 repeated blocks containing the same steps.
The following page shows the steps inside the LSA block.
Logistic Support Analysis
Note: LSA is considered as the engineering analysis part in ILS. The ILS process is owned by PI. ILS includes RAM/LCC, maintenance plan, special tools, spare parts, user documentation, training.

ID MLN-20-20-15-008742 Rev 00
1.1 1.2 1.3 2.1 2.2 2.3 2.4 3 4.1 4.2 4.3 5.1 5.2 5.3 6.1 6.2 6.3 6.4
Market Product Business Marketing Pre-Bid Bid Negotia- Start-up Preliminary Detailed Work 1st Product Qualification Series Pre- Warranty Operation & Prod. Supp.
Sub phases Under- Option Case Finalization tions Design Design Preparation Realization Realization Acceptance Maintenance Beyond
standing Assess- Contractual
ment obligations

Function Steps
Marketing, Market
Propose
Product analysis & RAM/LCC
products, White book
charac- benchmark
Planning + terization
business case
Sales

Sales Perform BB and bid

Supplier contact, Supplier performs tests

Supplier follow up
Procurement contract

LSA (engineering ILS part)

LSA (engineering ILS part)
RAM/LCC LSA (engineering ILS part)

LSA Type demonstration RAM/LCC demonstration Receive actual LSA data

RAM/LCC AS AS Speci- Contrac- AS Vali-

BID SOLD fied tual BUILT dated
handover
phases

System / Design, TRD Design, TRD Design, TRD

Production
Engineering
Systems Integration

Support ILS part Support ILS part ILS realisation, demonstration, validation Collect actual LSA data
PI / Div
Services
Process Mapping Template Version 0

ILS data collection

ILS Strategy Fix supplier requirements Packages Review ILS deliverables

Documentation Support docu- Create documentation & set up Training Training Update documentation
mentation part
Services
Project
Manage the project
management
file: 008742 LSA process+rev00+en.vsd

Figure 2: The LSA high level process

Confidential and proprietary Page 8 of 26

 Doc ID-number: 008742
Revision: 00

6 The LSA Detail level process Description

The detail process is shown in following 2 flowcharts:

 The first flowchart shows the major steps of one high level LSA cycle,

o During phase 1 & 2, some steps of the LSA cycle may be skipped or performed in an
accelerated, reduced way, according to the needs, time restraint and risk profile.

o On a project (thus from phase 3 start-up to 6 field support), the LSA cycle should be
performed in depth according to the project requirements.

Next paragraphs will describe in more detail the different steps, whilst indicating differences
between phases.

 The second flow chart represents the repetitive (continuous) compliancy checks and
consecutive actions. The steps of this flowchart shall be discussed as part of the repetitive
check and possible consequences (see §6.6)

Remark: During the whole process the data will be continuously fed and stored in ELSA, from
which it can be shared with other departments. The ELSA tool is designed to support
the LSA process by recording LS data and by facilitating LSA.
Process Mapping Template Version 0

Figure 3: The LSA detail level process

Confidential and proprietary Page 9 of 26

 Doc ID-number: 008742
Revision: 00

6.1 Set LSA objectives and strategy

6.1.1 Analyse LSA requirements

Depending on the phase, the LSA requirements are to be derived from

 the expected market requirements at product strategy phase;
 the invitation to tender (ITT) at bid phase;
 the contract (as negotiated after bid) at Start-up / Design phases.
 Variation Orders (VO)

The project specific requirements may concern:

 Operational profile;
 LCC targets (cap);
 Maintainability limitations (ref. RAM3 Service and Operating concept) which may require a
depot visit under the responsibility of PI.
 Reliability / Availability performance requirements;
 (LSA) Analyses to perform
 LS deliverables (as required by the customer)
 RAM/LCC and LS demonstrations
 ….

6.1.2 Determine Objective and strategy

6.1.2.1 LSA Strategy

Based on the LSA requirements, a LSA strategy shall be determined. This strategy serves only for
internal BT use. The strategy may / should include following elements:

 the base assumptions / decisions;

 the LSA objectives: compliance / derogations;

Remark: in most cases, the LSA objectives will be identical to the (customer) requirements.
As consequence of a compliancy check (see §6.6), these values may be reviewed.

 risk & opportunities, may also provide desired margins, mitigations, escape clauses, caps &
provisions;

 communication strategy.

The LSA strategy shall need to be aligned with the overall PI ILS process. PI is in charge of adapting
the “customer service” section of the TRD and RAM/LCC for the “Design section” chapter 4 of the
TRD.

6.1.2.2 LSA plan

The purpose of the LSA plan is to communicate the BT LSA approach taken on this project to the
customer. The LSA plan shall identify
 The bid / project specific requirements as interpreted by BT;
 The approach taken by BT to meet the requirement, including references to the tools and
methods (decision criteria and logic) used during LSA;
Confidential and proprietary Page 10 of 26
 Doc ID-number: 008742
Revision: 00

 The breakdown & description of level of detail, utilizing e.g. the LORA to determine the
correct level of breakdown;
 The draft maintenance plan;
 The deliverables: A list of LSA deliverables will be set-up / customized per project. There are
numerous types of deliverables (see annex for a non-exhaustive list). Each deliverable will
have a label, short description, indication of the phase/planning and nominal “customer”.

Remark: the LSA plan may be incorporated into the RAM/LCC Performance plan (Program
plan) (RAM16)

Remark: For the marketing / pre-bid phases, it is not mandatory to define an LSA plan.

6.2 Modelling

The model of a concept / train / product, is compiled bottom-up by systems chosen from either:

 Carry-over design, with no or minimal modifications

 Modified design but based on an existing / standard solution

 New design with no or limited fall-back on earlier designs.

The different systems need to be integrated into the project by adapting the product / systems due to
project specifics and other (product) considerations, such as:

 Operational conditions: utilisation factor e.g. differences in mileage, operating hours,

environmental factors, … .

 Maintenance constraints

o Depot: number of depots and their facilities (tools, lifting, roof access, shore supply,
…)

o Personnel: skills, night shift, …

o Maintenance philosophy; for ex. max. level of maintenance; in/out house; ...

o ...

 Legislation: safety regulations, …

Remark: the RAM3 Service and Operating concept may be elaborated further in order to detail
specific conditions and constrains per system.

Before supplier selection BT may perform the adaptation at own initiative. Once the supplier is
selected the adaptation should be performed by the suppliers in order to have a back-to-back.

The model is also used to evaluate different configurations (redundancies, car types) and (types of)
systems with preference to standard solutions and proven designs.

At the end of this activity, the outcome shall be checked for compliance (see §6.6). The (final) model
established at bid phase shall be handed over as the “AS-BID” data.

Confidential and proprietary Page 11 of 26

 Doc ID-number: 008742
Revision: 00

6.3 Breakdown & Distribute Objectives, Validate Feedback

6.3.1 Breakdown and distribute objectives

The overall LSA objectives of the project will be dispersed as criteria and requirements over the
different systems / sub-systems / supplier’s delivery scope and entered to the different TRD/TRSs.

More strict sub-targets may be set in order to meet the overall target and provide a margin. The risk
is that suppliers may respond non-compliant. Proper allocations need to be foreseen for the BT parts
interfacing with the systems e.g. cabling, structure, … .

The following list is a non-exhaustive list of what might be considered / set as criteria and
requirements:

 Criteria / Objectives:

o The base parameters (and tolerance) on system utilisation and maintenance plan

o RAMS Performance linked to severity, functional failure modes, …

o LCC caps with possible split up over types of maintenance, labour and cost

o MTTR, reparability, testability, …

o Tools: need for special tools

o Skills

o Weight and dimensions

 Requirements: analysis to perform, resulting in deliverables (including a schedule : plan)

o To establish a program: supplier’s RAMS plan

o To create a Reliability block diagram: RBD

o To perform a FMEA: FMEA

o To perform maintainability, … checks: checklists

o To deliver the logistic support data: spare parts, tools, skills, storage and handling…

o To optimize maintenance: maintenance task analysis, RCM, LORA, spares quantity

o To calculate the RAM/LCC: BLESS

o …

Remark: the suppliers shall also need to deliver documentation, manuals & training.

The WBS product breakdown is used as the LSA breakdown / decomposition reference and enables
re-usability of the data.

At product strategy phase or bid phase, this step may be skipped or limited to the most relevant
systems, according to the needs, time restraint and risk profile.

Confidential and proprietary Page 12 of 26

 Doc ID-number: 008742
Revision: 00

6.3.2 Receive data

6.3.2.1 External (Suppliers) approach

The suppliers will reply to the requirements set in the TRD/TRSs by means of deliverables and
clause by clause comments. Purchase shall ensure the delivery of the requested data of the supplier
according to agreed delivery dates. All required data information outside the scope of the suppliers
should be provided by engineering.

A validation of Supplier LS data will be performed on:

 Correctness: is the data compliant to with the requirements;
 Accuracy: to compare the data against benchmark values and across suppliers;
 Completeness: is the dataset complete or is information completely or partially missing;
 Formatting: is the data provided in the right format;
 Proper coding: are the labels, codes correct and uniform so that proper grouping and
traceability of data can be assured.

Discrepancies shall be reported back to the supplier and considered as an open-point with the
supplier. Procurement will support the RAM/LCC department in the closure of these open points in a
timely manner.

The compliance to the objectives (overall and partial objectives) shall be made (see §6.6) and
adjustments can be made.

At product strategy phase or bid phase, one may enter in negotiation with suppliers when permitted
or needed. Should there be sufficient confidence in the used LS data and modelling then this step
may be skipped due to time restrictions.

During Start-up / preliminary design phase, the RAM/LCC department shall review, validate and
where needed negotiate, the LSA with the suppliers.

Suppliers may come up with different technical solutions. The solutions are check on their suitability
and in order to select the supplier, a comparison will be made between the different solutions /
suppliers in order to propose a preferred solution (could be part of a JDDP).

Once the solution is selected, the signed-off LS data with the supplier is considered as
“CONTRACTUAL” data. The agreed objective and requirements may / should be incorporated in
the TRD/TRS, hence creating a full compliance document.

During detailed design, the data shall be further elaborated, validated and checked for compliance.

Remark: all discussions with the supplier(s) happen under the acknowledgement of procurement.

Remark: BT may transform and feedback the supplier’s data in a BT format hence setting a uniform
BT platform (for ex. LCC data delivered by the supplier may be fed back in a BLESS format.).

6.3.2.2 Internal approach

The concept has an impact on the RAM/LCC & LSA and must be taken under consideration (e.g. M:
accessibility, clean ability, LS: spares, tooling…). The concept and vehicle design engineering
department shall be informed of the LSA requirements and these shall be checked during the design
reviews. The issues shall be handled as part of an open item list.

Confidential and proprietary Page 13 of 26

 Doc ID-number: 008742
Revision: 00

6.4 Perform LSA analyses;

6.4.1 Harmonisation

Based on the model set up in §6.2 ,BT takes the initiative to harmonize the LS data. The first step is
to prepare / harmonise the LS data by means of some RAM/LCC analyses. The analyses are set in
RAM/LCC performance plan and include for example:
 Reliability analysis
o To translate the System Severity List (SSL) to the contract requirements (conversion
from BT standards to customer specifics)
o To include the effect of redundancy (local (and global) effect & failure rate versus
train effect and failure rate)
o To consider/provide margins and reliability growth
o To identify risks and set-up mitigation plans;
o ….
 Maintainability analysis
o Accessibility analysis (including the installation constraints);
o MTTR analysis (including all on board (diagnostics) features);
o ….
 ….

After the RAM/LCC analyses, the LS data is ready for further LSA analysis (as set in LSA plan). The
following non-exhaustive list states some LSA activities as part of the harmonization.
o To harmonise maintenance tasks and maintenance plan, considering all project
constraints e.g.:
 To assure are safety checks are included;
 To check with operation procedures of customer
 …;
o Maintenance tasks analysis
o Analysis and (requirements) description of maintenance facilities
o Spares & tools list considering maintenance facilities;
o …

The result of the analyses is a full set of LS data and deliverables, harmonized to the project.

At product strategy phase or bid phase, BT performs the corrections to the data as appropriate.
When time permits or when needed, one shall check with the supplier / maintainer / operator
/customer.

During Start-up / design phase, BT shall instruct the supplier to elaborate the data considering the
specific operational profile, project constraints. A dialog is set up with the maintainer / operator
/customer.

At this point the basic logistic support data is gathered in harmony with the project. The
harmonization may already offer sufficient analyses and meet the objectives.

Confidential and proprietary Page 14 of 26

 Doc ID-number: 008742
Revision: 00

6.4.2 Optimization

After the harmonisation, it is possible to proceed with the core business of the LSA: to perform
additional analysis in order to optimise the results. The following non-exhaustive list contains
optimisation techniques / analyses that should be applied on the complete train or parts of the train
(systems) as judged necessary. As the customers requirements are gradually becoming more
severe, a full optimization / LSA exercise will become required in order to meet the LSA objectives /
requirements.
 Maintenance schedule by performing
o a RCM analysis
o maintenance optimization e.g. tasks grouping by skill, location, depot requirements,
vehicle state, …
 Level of maintenance by performing
o LORA analysis; Repair – discard analysis; LRU/SRU determination;
 Spare parts:
o quantity optimisation (by applying Erlang / Poisson or other proven market
algorithms …)
Remark: this is optimisation should always be performed.
o Logistic Differentiation: split up into different groups e.g. strategic stock,
consignment stock, rotation stock, contingency stock, …
 ….

Remark: the different techniques are often related and may affect each other.

In order to facilitate the optimisation, it may be required to make concept changes such as:
 Maintainability: reducing cost to maintain (e.g. tools to reduce maintenance task time,
change position of certain components, grouping of maintenance activities), facilitating
maintenance
 Diagnostics, CBM: facilitating fault finding and predictive & condition based maintenance
 Reliability growth,
 ….

At product strategy phase or bid phase, this step is not mandatory. Even during design, one may
want to reduce this step to a limited number of systems and analyses for an effective use of limited
resources.

6.5 Compile and Provide ILS data deliverables

During the LSA analysis intermediate results may be produced and released in order to
 Follow-up the status as requested internally / externally
 Monitor progress of the LSA process.
 Initiate discussions internally and externally, that result in feedback
 Allow other departments to proceed
 Document LSA related decisions taken.

Confidential and proprietary Page 15 of 26

 Doc ID-number: 008742
Revision: 00

6.5.1 Release internally

The LS data and analyses serve as input for other functions / divisions for ex.
 breakdown objective (criteria and requirements);
 Procurement (MLN / Services) can compile and / or populate the spare part list with prices;
 PI uses the spare parts list (with prices) to determine the spare parts costs for warranty
service;
 PI uses the tools list to determine the investment required for testing & maintenance..
 PI uses the skills requirements to have qualified personnel.
 Services uses the data (spares, tools, maintenance schedule and tasks, …) to determine
the cost of maintenance in case of maintenance contracts..

This information can be delivered at pre-determined time-points, on demand or by granting the

receiver access to the ILS database directly.

At product strategy phase or bid phase, these elements can be used by PI and Services to
substantiate their part of the bid.

During design the ILS data will be continuously updated, further elaborated and detailed. The final
release at end of design phase may be labelled “AS-built”.

During realization and field support, the LS data may still need to be updated after which the change
shall be released accordingly.

6.5.2 Release externally

At product strategy phase or bid phase, the LS data is normally only released externally as part of
the bid documents required by the bid. Exceptions may be required when working in a partnership.

During design phase, the number of releases shall be limited and delivered at predetermined
intervals.

6.6 LSA repetitive checks

As explained before, this flowchart is initiated repetitively during the detailed LSA process.

Confidential and proprietary Page 16 of 26

 Doc ID-number: 008742
Revision: 00

Process Mapping Template Version 0

Figure 4: LSA repetitive compliancy checks

6.6.1 Verify LSA compliance

The data shall be compared to the sub- and overall objectives. In case of compliance, the next task
in the detailed flowchart may be performed. When not compliant, corrective measures are to be
considered.

Remark: When checking for compliance, the phase of the process must be taken under
consideration e.g. should an RCM exercise be required, then the compliance regarding the
RCM objective should only be checked after the optimization.

At product strategy phase or bid phase, one normally only performs verification of the calculations.

During design the ILS data will be continuously verified and when needed corrections/mitigations are
initialized. When applicable, a demonstration plan shall be set up.

6.6.2 Consider design change

Should the current solution & design be non-compliant, then design changes: other solutions are to
be considered / requested.

The corrective measures shall preferably be identified in co-operation with suppliers in order to
respect the requirements.

In case no corrective measures are put in place, then proper provisions / contingencies must be
provides in the risk and opportunity plan.

Confidential and proprietary Page 17 of 26

 Doc ID-number: 008742
Revision: 00

6.6.3 Adapt LSA Objectives

At product strategy phase or bid phase, BT shall verify against the overall level of the requirements.
At this point BT can decide to diverge from the market / bid / project requirements by.
 Offering better than requested to increase competitive advantage.
 Offer worse than requested, should BT consider the requirements too risky.
 Not offering the topic, not taking a commitment.

The work done as part of LSA can/shall be used to substantiate the mandate and set the objective.

Any later change to the objectives is to be evaluated regarding the Risks and Opportunities.

6.6.4 Update Risks and Opportunities

While as any non-compliance already poses a risk for which proper provision / contingencies must
be provided, some measures to resolve the non-compliance involve other risks, especially when
decided without Supplier approval e.g.
 To change the design, as such one might deviate from a proven design
 To push back a maintenance interval (longer interval), higher risk for need of corrective
maintenance; risk of supplier declining warranty (non-compliance with suppliers proposed
maintenance scheme)
 To reduce the number of spares, higher risk of shortage; unavailability of spare
 To use benchmark values that are better than contractual values, risk of no back to back
with supplier when values are worse than benchmarked.
The risk and opportunities are to be discussed with PM.

6.6.5 Elaborate change and update LSA

The changes shall be simulated in the LSA tool and checked for their impact and effectiveness
before launching the change through the proper channel e.g. the ECR process.

6.6.6 Document & report

Throughout the process, the decisions taken shall be documented, that allows traceability on the
choices made as part of the LSA process.
The types report shall be determined by the deliverables requirements.

6.7 Populate ELSA

To facilitate this process, the ELSA tool is used. The LS data is to be captured in ELSA, therefore
allowing:
 Storage: the database offers a single point for all the LS data to be gathered and stored;
 Traceability: the LS data shall be marked with a status; phase; a reference to the source of
the data; …
 Sharing: the LS data can be shared between different users (user’s permissions may vary);
 Re-used: the LS data can be re-used (partially or complete) on other projects;
 Analysis: the tool offers some calculations / analysis capabilities;
 Reporting: the tool offers standard reporting.

Confidential and proprietary Page 18 of 26

 Doc ID-number: 008742
Revision: 00

6.8 Handover / Freeze data

With the internal release, the following milestones / hand-over points can be defined. The hand-over
data shall be marked and stored as follows:
 AS-BID: LS data as-used for the BBK and the bid;
 AS SOLD: This data is considered as the contractual LS data with the customer. In principle
it reflects the AS-BID except for changes during negotiations. This dataset is also referred to
as “AS-SOLD Agreement and specifications” dataset used at start-up phase..
 SPECIFIED: the LSA handed over for completion of the TRDs
 CONTRACTUAL: as-signed with the supplier
 AS-BUILT: status at end of design, frozen design
 VALIDATED: During Realization / Field Support (phases 5 & 6), the versions may evolve to
Validated: status after type test / validation / acceptance.

Once the project has demonstrated its performance and shall receive complete acceptance, the
contractual dataset is handed over to Division Service. From this point onwards the train manufacturer
(MLN) should no longer update the dataset and considers the contractual LSA tasks completed and
finished. In order to get the most accurate data for future bids / projects, there is a need to have
benchmark values from products in Service that offer a high degree of confidence.

At all stages, the “CURRENT” status will always reflect the latest status.

6.9 Demonstration / Measurements

As mentioned above there are 3 ways to demonstrate the LSA compliance.

 LSA type test demonstration: the one-off demonstration happens on a mock-up / prototype or
first built or on each train. This demonstration may be considered as part of the qualification.
 RAM/LCC demonstration: the LSA objectives are demonstrated / validated on the vehicles
during the warranty period and may be considered as a part of the validation or acceptance.
 In service LSA data: this approach is a long-term measurement on trains in operation.

The calculated values shall be verified as being compliant with the set LSA objectives. In many cases,
the customer may also require a demonstration. This demonstration may take different forms and
schedules:
 Theoretical demonstration: the compliance is demonstration by means of LS data & calculations
 One-off demonstration: the compliance is demonstrated by means of a one-off demonstration
either on a prototype or first built.
 Fleet demonstration: the compliance is checked on the fleet in service over a period of time.

This demonstration may be required for the complete vehicle or on a case by case basis e.g.
 To perform a demonstration on a system only because one suspects an issue / non-respect of
the target.
Remark: BT may also perform a demonstration on a better performing system (as per
compensation to worse performing systems in case of a fleet objective)
 Customer has set individual requirements for ex. Bogie replacement < 4 hrs.

The verification scope and manner is described in the project demonstration plan.

During realization and field support, the demonstration plans are normally executed. As some
demonstrations are not one-off demonstrations but demonstrations over a period of time, the FRACAS

Confidential and proprietary Page 19 of 26

 Doc ID-number: 008742
Revision: 00

process shall be applied for the validation. The data-set resorting from these demonstrations may be
labelled: “VALIDATED”.

The validated data is to be fed back as benchmark data.

7 Updates beyond the design freeze

Updates may be required after design phase due to e.g.

 Changes in design: Design changes may be caused due to several reasons but also when the
objectives are not met. This might result in:
o Adapted maintenance plan e.g..
 Perform early checks to increase reliability;
 Prolong intervals to reduce LCC …;
o Increase in spare part quantity e.g. when actual failure rate turns out to be much
higher than predicted;
o Change of concept e.g. bigger oil reservoir, a plastic element replaced by a metal;
o Change of spare parts prices e.g. reduce margin on spare part in order to respect
LCC cap;
o Change in labour times: e.g.. Time validations proof difference in allocated times;
o ….
 Changes in the operation for ex. annual hours in operation changes (outside acceptable
margin)
 Changes in maintenance for ex. due to new timetable trains, maintenance during day need to
be reduced
 Changes in legislation for ex. an employee may no longer lift more than … kg
 Errors during design for ex. train lifting not possible in depot A.

Remark: the FRACAS process shall initiate performance related changes. At this point certain LSA
analyses may be required to predict/simulate the impact. Design changes shall also be communicated
as part of the ECR process.

Remark: some changes may be initiated by variation orders.

8 Appendices

Annex 1: List of deliverables

9 Definitions and Abbreviations

Term Definition

BLESS Bombardier LCC Excel SpreadSheet

BTRAM Bombardier Transportation Rail Asset Management (also referred to

as MAXIMO)

CBM Condition Based Monitoring

Confidential and proprietary Page 20 of 26

 Doc ID-number: 008742
Revision: 00

EBOM Structured “Bill of Material” for product definition

EBOM extended Structured Bill of Material for Service/Maintenance (down to the

exchangeable unit for corrective maintenance)

ECR Engineering Change Request

ELSA Engineering Logistic Support Analysis tool / database

GRD General Requirement Document

iFMEA/RCM Integrated FMEA/RCM tool

ILS Integrated Logistic Support

LCM Low Cost Maintenance Process

LORA Level of Repair Analysis

LS Logistic Support

LSA Logistic Support Analysis: the analysis performed by engineering in

support of the overall ILS process

RCM Reliability Centred Maintenance

S-BOM Bill of Material for service/maintenance

SSL System Severity List

TRD Technical Requirement Document

TRS Technical Requirement Sheet

TSA Train Service Agreement

TSSSA Train Spare Supply Support Agreement

More definitions and abbreviations are defined in the Bombardier Transportation lexicon.

Confidential and proprietary Page 21 of 26

 Doc ID-number: 008742
Revision: 00

10 Reference documents
Doc ID-number Title
- 000251 “Design for RAM/LCC Process” Procedure
FRACAS process
ECR process
- 000615 PI – Integrated Logistic Support
- 000299 FRACAS process
- 000251 ECR process
- Other Industry guidelines
- EN 50126 Railway Applications – The specification and demonstration of Reliability, Availability,
Maintainability and Safety (RAMS), CENELEC European Committee for Electro technical
Standardization, Sept. 1999.
- IEC 60300-3-12 Dependability Management Part 3-12 Application guide - Integrated logistic support
- MIL-HDBK-502 Acquisition Logistic (handbook to MIL-STD-1388: Logistic Support Analysis)
- MIL-STD-1388 Logistic Support Analysis
RCM II Reliability-Centred Maintenance, second edition. ISBN 0 7506 3358 1, author: John
Moubray
The current status of each business process document is documented on the coversheet of the available
document in the respective database (e.g. in the eBTM).

11 Archiving

Business process documents shall be maintained and archived in accordance with 000005 Directive “Control
of Document/Data and Records” and 000350 Procedure “Archiving of Documents/Data and Records”.

Confidential and proprietary Page 22 of 26

 Doc ID-number: 008742
Revision: 00

12 Approval Information

Wim Vandenberghe / Ulf Westberg Approved and released through

Prepared : MLN & Metros Advanced S&A 2008-01-18
eBTM
Author

Mehenna Aourane / MLN & Metros Approved and released through

Verified : Advanced S&A 2008-01-18
eBTM
Sponsor

Ken King / MLN & Metros Director S&A Approved and released through
Approved : Verifies harmonisation with other process interfaces 2008-01-21
eBTM

BTIP

Bernd Hoppe / VP Technology Approved and released through

Released : 2008-01-21
Head of Function who owns the process eBTM

Process owner Signature Date (yyyy-mm-dd)

Translated by: Translation approved by: Translation languages:

- - -

13 Revision Log

Date of
Revision Description of changes
Release
0 2008-01-22 First release

Confidential and proprietary Page 23 of 26

ANNEX: LSA Deliverables

The LSA deliverables are quite extent. This is a non-exhaustive list of possible outputs that are
considered as part of the RAM/LCC, LS data & LSA scope. Some parts of the data may be repeated
through the different outputs, yet the LSA process and tool should ensure that integrity is preserved. Many
deliverables are also declared in the Design for RAM/LCC process (-000251), the respective RAM
numbers are indicated between brackets.

 Bid analysis / customer requirements (RAM2)

 Service and Operational Concept (RAM3)
 LSA Strategy
 LSA plan (could be part of RAM/LCC plan (RAM 16))
 Analyses
o RAM/LCC analysis (RAM 7)
 as input to TRD / TRS
 supplier selection
o LORA, LSA candidates
o iFMEA/RCM analysis (RAM 10)
o Maintenance Task Analysis
o Repair ability & Testability analysis
 Checklists (RAM 9): checklist on reliability, maintainability, clean ability, testability, …
 Spare parts list (RAM 17)
o Technical view: (for definitions see GRP-20-25-10-000847 GRD PI section)
 Corrective spares
 Main spares
 Consumable Spares
o Commercial view (for definitions see GRP-20-25-10-000847 GRD PI section)
 Initial spares
 Commissioning spares
 Warranty spares
 Top-up (ongoing) spares
o Other views/definitions:
 Strategic spare parts
 Consignment spares
 Overhaul spares
 …
 Tools list
o Special tools list (RAM 18)
o Test equipment

Filename: Filename: 008742 Rev 00 en

 Doc ID-number: 008742
Revision: 00

 Product / material list (cleaning, glue, paint, …)

 Package, storage and handling (of spares, tools)
 Depot(s) facilities (roof access; …), infrastructure description
 Skills list:
o List of personnel qualification
o Qualification criteria, training requirements
 Maintenance schedule / plan (RAM 19)
 Test plan and procedure (RAM15): Demonstration & Validation plan
 Test reports (RAM 32)

The following ILS deliverables are considered as outside the scope of LSA. The LSA process may
contribute to these deliverables, but it is not within the scope of the LSA process to deliver the following
deliverables.
 Training (RAM 23)
 Technical information/documentation
o Manuals
 Maintenance Manual
 Maintenance tasks instructions
 Maintenance schedule (RAM19)
 Operator & driver Manual
o Spare parts catalogue
o Drawings & specifications
o Exploded views,
 Warranty support

Confidential and proprietary Page 26 of 26