On February 17th, 2021 we held a webinar to introduce many of the new features of the hardware lifecycle model. We ran out of time during the Q&A session, so in this blog, I’d like to answer all of the remaining questions that came in. The most asked question was if the slides/presentation will be available, and the answer is yes! The slides and recording can be seen on the PRICE® Resource Library – click here.
Q: When will TruePlanning 16 SR2 be available for download?
A: TruePlanning 16 SR2 is available now. This version contains all the improvements shown in the webinar, except for the Future Work discussed at the end. Contact your solutions architect for information on how to upgrade to the latest version, or call us at 1-800-437-7423.
Q: Does the new HL object mean lifecycle parameters no longer appear in Hardware Component/COTS? How does the latest version handle importing of legacy projects with existing life cycle data inputs?
A: Yes, the lifecycle parameters no longer appear in Hardware Component and COTS. When you import a legacy project containing Hardware Component/COTS including lifecycle, TruePlanning will automatically add the new Hardware Lifecycle model to your PBS, create the linkages with your existing PBS, and transfer all the inputs/data. The model should run automatically upon importing into the new version, including Hardware Lifecycle costs.
Q: It sounded as if the optimal maintenance/support concept is determined for each modeled component independently. Is it possible to look at the overall optimal concept (for the system in total), which may not be optimal concept for some individual components?
A: Great suggestion! This can be done in TPXL or TruePlanning, but currently requires 28 runs (one for each maintenance concept). We will add a 1-click button to run this analysis into the TPXL addon for the next update.
Q: Where do you include planned component maintenance based on product usage (frequency) versus dormancy usage for electronics?
A: In the next version, we’re working on improvements for modeling scheduled maintenance activities, which can be scheduled based on either product usage or calendar time, for when maintenance is required even if the system is dormant. In the current version, this can be modeled by using a separate instance of the Hardware Lifecycle model, which “operates” fulltime, and has an MTBF that aligns with actual time between the dormant system’s maintenance activities.
Q: Will LTB quantities for each obsolete part be included in the obsolescence reporting?
A: Yes, total quantities purchased during an LTB will be displayed on the Metrics, and you will be able to model spares storage costs which spike at LTB, then decrease as your stock depletes.
Q: Can I set Ao and back into maintenance concept and loading?
A: Not yet, but the new architecture of this model should allow us to implement this feature. We are working on this for the next major update.
Q: LCC are based on assumptions of current technology – when a new innovation/upgrade is infused – how do you account for the changes?
A: A technology upgrade causes many changes relevant to lifecycle estimating, including:
- Elimination of obsolete parts, use of new readily available parts
- Introduction of new desired features and functions
- Performance improvement
- Increased reliability (higher MTBF)
- Size decrease
- Additional cost of non-recurring technology refresh
- Additional cost of re-qualification
Many of these changes are accounted for by a change in Manufacturing Complexity. The technology improvement model built into the Hardware models is used to quantify the difference in Manufacturing Complexity over time for a given equipment type. By default, the technology model-adjusted manufacturing complexity will be used for further calculations, although the estimator will have inputs available to modify slope of technology improvement. With a new manufacturing complexity value, we can run the existing algorithms to estimate the new MTBF (or the estimator can input it), and we can estimate the additional non-recurring costs of the development and re-qualification activities.
Q: Can we see a ‘ramp down’ ie part of the fleet is retired before 40 years?
A: With constant failure rates, you can model a ramp down of the fleet by reducing the “Number of System Deployments” in later years. With non-constant failure rates, each cohort is tracked separately so that the percentage of the fleet subject to increased wearout failures can be assessed. In a future version, we will look into adding the ability to remove units from specific cohorts, so that a selective ramp down can be modeled while still capturing wearout failure costs for those remaining in service.
Q: Can the model do LORA? I never heard it explicitly said today but optimizing on 28 maintenance concepts seems like it is exactly that. If yes, how does TP capability compare to LORA tools such as OPUS and COMPASS?
A: The short answer is: Yes, the Hardware Lifecycle (HL) model can do level of repair analysis (LORA), with some caveats. HL is intended for acquisition management and strategic decision-making, not day-to-day O&S management. For US DOD programs, affordability assessment is required at Milestone B and C decision points, while the design is still subject to change and before the system has begun full-scale manufacturing. The trade-off alternatives used to provide costs for the affordability analyses are generated in MS B and C – and include the level-of-repair decisions and alternatives, and HL is designed to support this decision making. The HL model does not go down to the level of a complete bill of materials for every unique part/module, but rather applies at an LRU level, while applying average costs of Module/Part-level repairs. However, TruePlanning is very well suited for estimating development and manufacturing costs for a variety of alternatives, as opposed to making these costs throughputs, which is generally the case for day-to-day O&S management tools.
If you have any more questions, feel free to email us @ firstname.lastname@example.org or reach out to your solutions architect. Thank you!