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 and Blanchard/Fabrcky 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 (glossary)" (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 (glossary)" (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.

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 difference is 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 UK chapter of the INCOSE developed supplementary guidance to the INCOSE Systems Engineering Handbook.[39] 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 peculiar 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 [25]
• System Original Equipment Manufacturer (OEM) and key suppliers; 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,
• 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,
• 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 SE Handbook emphasizes the use of "Failure Modes and Effects Criticality Analysis (glossary)" (FMECA) to understand the the root causes of product failures to 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 references 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 and Blanchard, Fabrycky 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 (glossary)" 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, Lewis 2003 Modernizing Legacy Systems, states the importance of documenting the existing architecture of a system, including the software architecture prior to making any changes.

Seacord, Plakosh, Lewis Chapter 5 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 depend 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 pg 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. Examples of these types of commercial systems are Consumer Electronics (e.g., 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 area. Modernization often require 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 Systems Engineering Guidebook for Intelligent Transportation Systems adds reverse engineering to the processes 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, physical requirements in the form of requirements, design and support specifications.

Application to Enterprises

The global positioning system (GPS) is an enterprise system implement by the 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. 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. The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. 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 UK Chapter Guidebook 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,

Other Topics

The Vee Model for Modifications

Figure below illustrates how the standard "Vee model (glossary)" 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, 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 (Nguyen, L. 2006). Modification introduced at points B or C in Figure 7-1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements.

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 with the customer and the other stakeholders.

Practical Considerations

As pointed out by the INCOSE UK Chapter Guidebook 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, providing increase functionality while shrinking in physical size. The other advantage for using COTS components is cost. . The risk associated with using COTS during system life management involves 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

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

Blanchard and Fabrycky. 2006. Systems Engineering and Analysis, 4th edition. Prentice Hall International Series.

INCOSE Systems Engineering Handbook v3.2. A Guide for System Life Cycle Processes and Activities. 2010. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2

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, p10, 13, 23.

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

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.

Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics. On-line policies, procedures, and planning references. http://www.acq.osd.mil/log/

Seacord, Plakosh, Lewis. 2003. Modernizing Legacy Systems, Addison Wesley, Pearson Education Inc.

Systems Engineering Guidebook for Intelligent Transportation Systems ver 1.1. 2005. California Department of Transportation Division of Research and Innovation

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

Blanchard and Fabrycky. 2006. Systems Engineering and Analysis, 4th edition. Prentice Hall International Series.

INCOSE Systems Engineering Handbook v3.2. A Guide for System Life Cycle Processes and Activities. 2010. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2

Jackson. 2007. A Multidisciplinary Framework for Resilience to Disasters and Disruptions. Journal of Integrated Design and Process Science Volume 11 (2), IOS Press

Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics. On-line policies, procedures, and planning references. http://www.acq.osd.mil/log/

Seacord, Plakosh, Lewis. 2003. Modernizing Legacy Systems, Addison Wesley, Pearson Education Inc.

Systems Engineering Guidebook for Intelligent Transportation Systems ver 1.1. 2005. California Department of Transportation Division of Research and Innovation

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

Blanchard, B. S., and W. J. Fabrycky. 2005. Systems engineering and analysis. Prentice-hall international series in industrial and systems engineering. 4th ed. Englwood Cliffs, NJ, USA: Prentice-Hall: p 541-565.

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: Kluwer Publishers Academic, Springer.

DAU. Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge. in Defense Acquisition University (DAU)/US Department of Defense (DoD) [database online]. Ft. Belvoir, VA, USA, 2010 Available from https://acc.dau.mil/ (accessed August 5, 2010).

Elliot, T., K. Chen, and R. C. Swanekamp. 1998. Standard handbook of powerplant engineering. New York, NY: McGraw Hill, section 6.5.

FAA. 2006. Section 4.1. In Systems engineering manual. Washington, D.C.: U.S. Federal Aviation Administration (FAA).

FCC. 2009. Radio and television broadcast rules. Washington, D.C.: U.S. Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: p 11299-11318.

Finlayson, B., and B. Herdlick. 2008. Systems engineering of deployed systems. Baltimore, MD, USA: Johns Hopkins University: p28.

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: 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: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332.

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

IEEE 2008. ISO/IEC/IEEE Systems and Software Engineering – System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization, ISO 15288.

IEEE 2005. IEEE Standard for Software Configuration Management Plans. New York, NY: 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, p10, 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): p91-108, 10.

———. 1997. Systems engineering for commercial aircraft. Surrey, UK: Ashgate Publishing Ltd.

Koopman, P. Life cycle considerations. in Carnegie-Mellon University (CMU) [database online]. Pittsburgh, PA, USA, 1999Available from http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html (accessed August 5, 2010).

Livingston, H. 2010. GEB1: Diminishing manufacturing sources and material shortages (DMSMS) management practices. McClellan, CA, USA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD).

Mays, L., ed. 2000. Water distribution systems handbook. New York, NY: McGraw-Hill Book Company: Chapter 3.

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: p38.

NAS. 2006. Natioanl airspace system (NAS) system engineering manual, version 3.1 (volumes 1-3). Washington, DC: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1.

NASA. December 2007. Systems engineering handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

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 hte systems engineering process. Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT).

SAE International. 2010. Standards: Automotive--maintenance and aftermarket. Warrendale, PA, USA: Society of Automotive Engineers (SAE) International.

SEI. Software engineering institute. in Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU) [database online]. Pittsburgh, PA, USA, 2010Available from http://www.sei.cmu.edu (accessed August 5, 2010).

Schafer, D.L. 2003. Keeping Pace With Technology Advances When Funding Resources Are Diminished. Paper presented at AUTOTESTCON 2003. IEEE Systems Readiness Technology Conference, Anaheim, CA :p 584.

SOLE. Applications divisons. in The International Society of Logistics (SOLE) [database online]. Hyattsville, MD, USA, 2009Available from http://www.sole.org/appdiv.asp (accessed August 5, 2010).

All additional references should be listed in alphabetical order.

---

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->