There are several definitions for logistics within systems engineering (SE) and the definition used will determine what activities are considered part of logistics. The SEBoK defines logistics as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user.
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations. Influence Inherent Supportability (Operational Suitability)
Sustainment influence requires an understanding of the [[concept of operations (ConOps) (glossary)|concept of operations (ConOps), system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and Life Cycle Cost (LCC), with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:
Architecture Considerations: The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.
Reliability Considerations: Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix failures. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.
Maintainability Considerations: The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are
- Modularity: Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.
- Interoperability: The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.
- Physical accessibility: The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.
- Designs that require minimum preventative maintenance including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.
- Embedded training and testing when it is determined to be the optimal solution from a Total Ownership Cost (TOC) and Materiel Availability perspective.
- Human Systems Integration (HSI) to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).
Support Considerations: Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.
Planning Sustainment Processes
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system.
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques.
Sustainment Analysis (Product Support Package)
The product support package documents the output of supportability analysis and includes details related to the following twelve elements (links below are to excerpts from (NATO RTO 2001):
- Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)
- Product/IT System/Medical System Support Strategies
- Lifecycle sustainment planning
- Requirements Management
- Total Ownership Costs (TOC) / Life Cycle Costs (LCC) planning & management
- Integration and management of product support activities
- Configuration Management
- Production & Distribution
- Energy, Environmental, Safety and Health (EESH) management
- Policies & Guidance
- Risk Management
- Design Interface
- Sustaining Engineering
- Failure Reporting, Analysis, and Corrective Action System (FRACAS)
- Value Engineering
- Diminishing Manufacturing Sources and Material Shortages
- Supply Support (materiel planning)
- Maintenance Planning
- Reliability Centered Maintenance (RCM)
- Maintenance Concepts
- Levels of Maintenance (Level of Repair Analysis)
- Conditioned Based Maintenance
- Prognostics & Health Management
- Support Equipment
- Technical Data
- Manpower & Personnel
- Training & Training Support
- Facilities & Infrastructure
- Packaging, Handling, Storage, & Transportation
- Computer Resources
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle, as illustrated in Figure 2.
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.
NATO RTO. 2001. Logistics Test and Evaluation in Flight Test. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf
Blanchard, B.S. 1998. Logistics Engineering and Management. Upper Saddle River, NJ, USA: Prentice Hall.
Blanchard, B. and Fabrycky, W. 2011. Systems Engineering and Analysis, 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.
Daganzo, C. 2005. Logistics Systems Analysis. 4th Edition. New York, NY, USA: Springer.
Fabrycky, W.J. and B.S. Blanchard. 1991. Life-Cycle Cost and Economic Analysis. Upper Saddle River, NJ, USA: Prentice-Hall.
Ghiani, G., Laporte, G., and Musmanno, R. 2004. Introduction to Logistics Systems Planning and Control. Hoboken, NJ, USA: Wiley-Interscience.
Jones, J.V. 1995. Integrated Logistics Support Handbook. New York, NY, USA: McGraw Hill.
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." IMA Journal of Management Mathematics. 9(4): 403.
Berkowitz, D., et al. 2005. Defining and Implementing Performance-Based Logistics in Government. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." International Journal of Production Economics 35(1-3): 293-297.
MITRE. 2011. "Integrated Logistics Support." Systems Engineering Guide. Accessed 11 March 2012 at [].
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." Engineering Management 47(1): 40-54.
Northrop Grumman Corporation. 2000. Logistics Systems Engineering. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." IEEE Transactions on Components and Packaging Technologies 23(4): 707-717.
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." Interfaces p. 7-17.
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.blog comments powered by Disqus