How can Integrated Logistics Support (ILS) Engineering influence System Design?
System design for defense services should be based on user/customer requirements and basic ILS requirements can and should support minimum LCC (Life Cycle Cost) by meeting the following requirements:-
- Number of Maintenance levels
- Maintenance Support personals capabilities
- Maintenance Training limitations
- Technical Manuals limitations
- Field Reliability
- Mean Time to Repair at each Maintenance level
By my experience, the above list is ordered according to importance.
The first requirement, the number of maintenance levels, should be in place before detail design starts as it is almost impossible to modify later during the detail design stage.
Any fielded system should be supported by existing maintenance personal with known abilities and learning potential and addressed early on in the detailed design phases.
Today, for example, we judge a smart phone on how simple it is to operate and maintain without using a manual or training because this concept is already implemented in modern design, and applies to other consumer products such as cameras and home appliances. The current crop of maintainers joining the military service today have had this kind of experience.. Thus, the design team needs to be aware of this constraint – detailed, large technical repair manuals and long training should become a thing of the past!
In past years, measureable reliability, MTTR and MTBD (Mean time between Demands) were, traditionally, at the top of support requirements. Today they occupy the bottom of the list.
Today the way the industry predicts reliability is based on methods that were developed and implemented during the Second World War. For example, using these antiquated methods to predict reliability of a family vehicle we would see reliability predictions for less than 10 hours; random failures are rare and we should produce better predictions!
Today, in the defense electronic industry, commercial components are used without screening before assembly to meet military environment requirements while Environment Stress Screening (ESS) is only done at final Acceptance Test Procedure (ATP). Unfortunately the yield achieved in production forecasts the field performance but, in my experience, 100% of failures that popup during final test in production FRACAS also appear in the field while the rest of the field failures are either introduced by the maintainer/operator or Can Not Duplicate (CND). In short, these types of failures should be eliminated by good design and training.
In practice, during the establishment of the system, the top level configuration support requirement should drive the number of maintenance levels and, additionally, how and by whom the system will be supported and operated. Once these requirements are established, detail design can start, it is difficult to influence the top system configuration once detail design started.
Summary: The first four requirements – Maintenance levels, Maintenance personel capabilities, Maintenance Training and Technical Manuals – should influence the design, through a rigorous system engineering process, at the initial stage of top level system configuration. The next step should be to push the realization of high yields at final production stage (integration, ESS and final ATP); achieve these high yields by screening components that will be used to assemble the various subassemblies.
In my past company, the RAMS (Reliability, Availability, Maintainability and Safety) group was for many years managed by the VP of Quality and then moved to be under the VP of Engineering. In both situations, the RAMS group suffered from low recognition in the company. RAMS main contribution during development in the defense electronics industry was to support CDR (Critical Design Review) by submitting predictions of Reliability, Availability, Maintainability and Safety to the presented system configuration in the CDR. Unfortunately the engineering effort was ready only a few hours before the CDR, and the RAMS presentation never addressed the latest system configuration. These facts derived from poor communication between system engineers and mathematicians in RAMS group.
When I was promoted to Director of Integrated Logistics Support (ILS), I proposed to move the RAMS group to my department. This organization change created a new situation. A new relationship was established in the ILS Engineering department between RAMS mathematicians and ILS engineers as “supplier” and “customer”, respectively. The goal for moving the RAMS group to the ILS department was to reduce product sustain cost, and the results were visible; the added value of the RAMS mathematicians was recognized company wide. As a result of the RAMS group being recognized for added value in the company, the communication and collaboration before CDR improved. Additionally, the ability to influence system configuration for optimum supportability by ILS department improved.( On the March 2013 RM&S news letter I addressed “ILS Influences System Design”
According to my experience in the defense industry it is common that the customer is DOD / Armed force HQ / Main contractor, and the users are active and reserve military personnel.
The question is how to market services to legacy systems and new fielded systems effectively to the users and satisfying the supplier’s direct customer (DOD / Armed Force HQ).
The way the Armed Forces are structured, the user is the end customer; however the needs are defined by HQ, and the personnel at HQ are experienced officers that plan to address future needs. In this situation, the user’s current issues, especially with legacy systems that are sustain only, are almost not heard.
I used to visit the users of my company’s products (airborne, naval and ground systems) periodically (as Integrated Logistics Support Director) and asked what we should do better. Usually 80% of the opportunities for improvements presented by the users were done in a very short time with no cost to the user and customer (DOD / Armed Force HQ), and the remaining 20% were discussed with the customer (Armed Force) and in most cases created new business to the company and effectively increased user’s and customer’s satisfaction with my company’s product / services. This made us the preferred supplier for future contracts for service and new developments.
My experience in the defense industry
I used to:-
- Forecast Repair & Return (R&R) work load and sales based on the user’s planned flight hours and Line replacement Unit (LRU) filed Mean Time Between Demand (MTBD)
- Identify LRU MTBD drivers from periodic FRACAS (failure reporting, analysis and corrective action system ) reviews
- Monitored customer’s future R&R funding
Unfortunately the customer’s future funding did not match with my forecast. This was a red flag that the system my company supports will be unaffordable down the road. The business management believed that if the customer needs these systems, there will be funding.
From analyzed R&R cost driver it appeared possible that inserting new technology could replace / eliminate LRUs and reduce the total user cost. The dilemma in the company was that reducing system (life Cycle Cost) LCC would lower the sales forecast, but not doing the right thing may bring a new party that may take our market share. This discussion took a few years, and eventually my opinion that if we will not do the right thing somebody else will do it was adopted.
In my opinion this delay would not happen if our system support was covered under a multiyear PBL contract.
According to my experience, the current way the USG funded R&R is: next year working funds = last year actual repair cost *([next year plan flight hours]/ [last year actual flight hours]).
This method drives few budgeting shorts on the USG side:-
- Holding repairs at the yearend by the user to save this year’s spending reduces the budget for next year.
- Next year’s contract budget will be too low, driving longer negotiation, and missing date for signing the new contract drives lower funding for coming years.
An unrealistic budget usually creates more unfulfilled back orders and may mean an Aircraft On Ground (AOG) or mission cancelled.
The common way to overcome this issue according to my experience was a contract spanning a few years that may exhaust before the contract end period of performance. This solution will push the problem a few years down the road.
A better option is a multiyear PBL contract with contractor obligation to reduce user total cost by X% every year and commit for availability performance. This formula will motivate the R&R provider to invest to reduce LCC.
United States Government Product Quality Deficiency Report (USG PQDR) process improvement
According to my experience, the current USG PQDR logistics process is not efficient and it hurts the users and the suppliers. This topic was discussed many times with my partners in the US Navy and US Air Force, and we all had the same understanding but no power to modify the USG DCMA PQDR logistics process.
Below is a description of the current PQDR logistics time line:-
- The user experiences an issue with a new delivery (“bad out the box”) and fills a PQDR form.
- The supplier receives an email from DCMA (Defense Contract Management Agency) with a request to authorize return product under PQDR.
- The supplier agrees to receive the PQDR item for repair or replacement (within one working day).
- DCMA authorizes / instructs the user to ship the unserviceable item(s) to the supplier. This process stage takes, according to my experience, between 3 to 10 months due to internal USG DCMA processes.
- The supplier evaluates the returned product under PQDR after repair/replace and submits a report according to the PQDR requirements, including a request for shipping instructions (within 30 days usually).
- DCMA sends shipping instructions to the supplier within 1 to 2 months.
There is no reason for a 12+ months process time to address PQDR. Also there are a few facts that make this process more painful.
- 10% to 50% of return PQDRs are CND (Can Not Duplicate)
- The services do not manage stocks according to “first in first out”. I have seen “bad out the box” returned a few years after it sold. In such cases it will be very painful for the supplier if there is a need for corrective action such as a product recall. For the user, the product may now be outside of the product requirements and there may be need to close the PQDR without resolution.
- In case the user needs immediate replacement from the USG supply chain, the user will have to pay the cost of new product.
The supplier should aim to address any “bad out the box” as fast as possible, implement if needed any corrective action to the ongoing production ASAP, and if needed recall similar sold items.
The proposed new PQDR process:-
- By definition (contract) the supplier authorizes/agrees to accept any PQDR and will cover shipping cost from the user to the supplier (for a limited period depending on product shelf life/requirements for storage free of failure).
- USG will field new products based on “first in first out”.
- Return item shipping address under PQDR after repair/replacement will be defined in the PQDR papers that came with the return item.
- USG (DCMA) will authorize to return the item(s) to the user after reviewing the closing report.
I hope my proposed process will open discussion between all parties involved to create better logistics PQDR process.
I volunteer to use my expertise in this field to be the facilitator for this topic discussion.
I would like to share my lesson learned from many years of Integrated Logistic Engineering in the Electronics Defense industry.
One of the main goals is to have the best LORA report before a new system is fielded. There are a few challenges when developing a new system LORA.
- Unknown field reliability for spare parts and consumables.
- 2. Unknown future cost for spares and consumables.
- Support Equipment (SE) for LRU & SRU may not be designed yet.
World class design objective is to develop reliable system with minimum foot print:-
- All fielded spares are consumables ( very high reliability, unrepairable and low cost)
- No need (or minimum) for field SE or special tools
- Minimum Operation & Support (O&S) documentation needed.
- Minimum Operation & Support (O&S) Training needed.
- Two level maintenance, O/L and Depot.
Unfortunately these objectives are hard to achieve and may be verified only after deployment.
To verify the new design meets system requirements the supplier uses high cost sophisticated test equipments that should not be used in the field.
The developer / manufacture (supplier) shoot for high production yield and try to save time by verifying each part not separately but at system level proof of design.
At this situation the preferable way to address LORA is using COMPSS STAT tool. During the design stage the system configuration, LRU, SRU, parts and consumables data are inputted to the COMPASS tool. Engineering estimates (reliability, parts cost, SE cost, documentation cost and training cost) are also inputted. By taking this approach we will have an idea regarding the system Life Cycle Cost (LCC) and there is still possibility to influence the system configuration to drive down the system LCC.
The next steps, as the development proceeds and after deployment will be to periodically update the COMPASS STAT with better data and refined maintenance tasks at each repair level including distribution of spares and consumables.
See below system design process with Integrated Logistics Support (ILS) Engineering roll.
In the defense industry, the ILS manager’s objective is to launch new systems that are reliable and supportable from day one. In my experience in the industry, the challenge I observed is that all world class systems demonstrated poor reliability when fielded and full operational capability could not be observed.
The predicted reliability (MTBF, or failure rate) is usually done and presented at CDR (Critical Design Review) assuming that all future failures are random failures, but unfortunately more than 95% of the real failures are due to marginal design! These for some reason did not appear in various lab tests, but pop up after the system fielded.
I exercised RI (Reliability Improvement) tasks including FRACAS (Failure Reporting, Analysis and Corrective Action System) on various systems (JHMCS, IAF F16 mission computer, C&C for Missile Patrol Ships and more..) and reached improved reliability for new systems at least 20 times within 2 to 3 years. After +30 years in Defense Electronics Industry, I wish to share my experience. (Better reliability performance could be demonstrated down the road via future technology upgrades).
The key for world class systems is the ability to reach the system’s actual reliability and capability as soon as possible, and to make it happen there is a need for both user cooperation and the supplier’s full commitment.
The user will cooperate if the user loves the new system due to improved operational capability when the new system launches, and better support relative to systems in use. The user is not one of the parties on contract! If the user will feel uncomfortable with the new fielded system it will be almost impossible for the supplier to improve the system reliability and capabilities and it may push the new fielded system out of service I know of a few projects that failed because their main objectives were to create a second source or option to reduce cost to the customer without addressing user direct benefit. The supplier objective is always to address this when planning to field a new system at the very beginning, while establishing requirements for the system.
The primary objective of the new system is to improve operational capability, but logistic footprint must also be addressed by the supplier.
The supplier Integrated Logistics Support needs to drive the user to love the new fielded system on day one, by implementing the following objectives:
- Excellent training for operators and maintainers. (the goal is to build system that require as little training as possible)
- Excellent documentation for operators and maintainers. ( the goal is to build systems that require “light” documentation)
- Minimal logistics footprint relative to systems already in use.
- Excellent R&R (repair and return) process with full visibility to the users and the customer (include FRACAS).
These design objectives should be addressed as early as possible while the new system requirements are being developed.