Capability Updates, Upgrades, and Modernization

Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The INCOSE Systems Engineering Handbook (INCOSE 2011) and Systems Engineering and Analysis (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification.

Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. engineering change proposals (ecp) are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. form, fit, function, and interface (f3i) is an important principle for upgrades where backward compatibility is a requirement.

Product and service modernization occurs for many reasons. For example:

• The system or one of its subsystems is experiencing reduced performance, safety, or reliability.
• A customer or other stakeholder may desire a new capability for the system.
• Some of the system components may be experiencing obsolescence, including the lack of spare parts.
• New uses for the system require modification to add capabilities not built into the originally deployed system.

The first three reasons above are discussed in more detail in the INCOSE UK Chapter Guidebook (2010).

Topic Overview

Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineering performing modernization to tailor the normal development process steps to fit the situation.

The UK chapter of the INCOSE developed supplementary guidance to the INCOSE Systems Engineering Handbook. (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.

Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.

Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:

• type of system (space, air, ground, maritime , and safety critical);
• missions and scenarios of expected operational usage;
• policy and legal requirements that are imposed by certain agencies or business markets;
• product or service life cycle costs;
• electromagnetic spectrum usage expected, including change in RF emissions;
• system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;
• understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;
• system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and
• the amount of regression testing to be performed on the existing software.

Key processes and procedures that should be considered during product and service modernization include:

• legislative policy adherence review and certification;
• safety critical review;
• engineering change management and configuration control;
• analysis of Alternatives;
• warranty and product return process implementation; and
• availability of manufacturing and supplier sources and products.

Application to Product Systems

Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The INCOSE Systems Engineering Handbook emphasizes the use of failure modes and effects criticality analysis (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes.

Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. OSD AT&L provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.

Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.

If system documentation is not available, reverse engineering is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's Modernizing Legacy Systems (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.

Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation.

During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.

It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.

Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.

Application to Service Systems

Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change.

Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas.

Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's Systems Engineering Guidebook for Intelligent Transportation Systems (ITS) (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.

Software modernization is discussed in the SWEBoK (Abran, 2004).

Application to Enterprises

Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned.

Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system.

The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.

As an example, the global positioning system (GPS) is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.

The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.

Other Topics

The Vee Model for Modifications

Figure 1 below illustrates how the standard vee model would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the INCOSE UK Chapter Guidebook points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.

A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory.

The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements.

Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)

There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.

Practical Considerations

As pointed out by the INCOSE UK Chapter Guidebook (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it.

The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements.

The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).

Application of Commercial-off-the-Shelf Components

One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost.

The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).

References

Works Cited

Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. SWEBOK: Guide to the Software Engineering Body of Knowledge. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok

Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Caltrans and USDOT. 2005. Systems Engineering Guidebook for Intelligent Transportation Systems (ITS), ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.

INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

INCOSE UK Chapter. 2010. Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2, issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23.

MDIT. 2008. System Maintenance Guidebook (SMG), version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38.

Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA.

OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/

Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. Modernizing Legacy Systems. Boston, MA, USA: Pearson Education.

Primary References

Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Caltrans and USDOT. 2005. Systems Engineering Guidebook for Intelligent Transportation Systems (ITS), ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.

INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

Jackson. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” Journal of Integrated Design and Process Science 11(2).

OUSD(AT&L). 2011. “Logistics and Materiel Readiness On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.

Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. Modernizing Legacy Systems. Boston, MA, USA: Pearson Education.

Additional References

Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. SWEBOK: Guide to the Software Engineering Body of Knowledge. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok

Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18.

Casetta, E. 2001. Transportation Systems Engineering: Theory and methods. New York, NY, USA: Kluwer Publishers Academic, Springer.

DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.

Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in Standard Handbook of Powerplant Engineering. New York, NY, USA: McGraw Hill.

FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).

FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.

Finlayson, B., and B. Herdlick. 2008. Systems Engineering of Deployed Systems. Baltimore, MD, USA: Johns Hopkins University: 28.

IEC. 2007. Obsolescence Management - Application Guide, ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302.

IEEE. 2010. IEEE Standard Framework for Reliability Prediction of Hardware. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.

IEEE. 1998. IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332.

IEEE. 2008. IEEE Recommended practice on Software Reliability. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633.

IEEE. 2005. IEEE Standard for Software Configuration Management Plans. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828.

INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE).

INCOSE UK Chapter. 2010. Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2, issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23.

Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore.

ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC).

Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” Journal of Design and Process Science 11(2): 91-108, 110.

Jackson, S. 1997. Systems Engineering for Commercial Aircraft. Surrey, UK: Ashgate Publishing, Ltd.

Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.

Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD).

Mays, L. (ed). 2000. "Chapter 3" in Water Distribution Systems Handbook. New York, NY, USA: McGraw-Hill Book Company.

MDIT. 2008. System Maintenance Guidebook (SMG), version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38.

NAS. 2006. National Airspace System (NAS) System Engineering Manual, version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1.

NASA. 2007. Systems Engineering Handbook. Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.

Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA.

Reason, J. 1997. Managing the Risks of Organizational Accident. Aldershot, UK: Ashgate.

Ryen, E. 2008. Overview of the Systems Engineering Process. Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT).

SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International.

Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.

SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.

SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

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