SUBMARINES, NAVAL ARCHITECTS & SYSTEMS ENGINEERING
4. THE SYSTEMS ENGINEERING PROCESS Systems Engineering has embraced a number of standard
approaches to development. Almost all of these approaches are consistent with the the “vee diagram” as the representation of the structured development process
that proceeds from concept to production to operation and, in some cases, through to termination and disposal.
The process flows from the definition of the problem through the Investigation of alternatives, Modeling of the system, identification of the component sub systems, Integration and development of the candidate system solution, Assessment of performance, and acceptance into service. It is important to note however that the systems engineering process is not sequential waterfall or cascade activity, : many tasks are performed concurrently and in an iterative manner.
With respect to a typical acquisition program this can be articulated in project phases as follows.
The standard V-model (Figure 3) can be modified to progress the activities from the development phase into the production phase.
4.1 NEEDS ASSESSMENT, CONCEPT EXPLORATION, AND BENEFITS ANALYSIS
Concept Exploration is used to perform an initial feasibility & benefits analysis and needs assessment for the project. A business case is developed and specific cost benefit analyses presented for alternative project concepts. The output of this stage is a definition of the problem space, key technical metrics, and refinements to the needs, goals and objectives. This stage identifies the highest cost/benefit concept project to move forward into development.
4.2 SYSTEMS ENGINEERING PLANNING The concept that moves forward for further development as the genisis of a procurement project must be planned with schedules that identifies the key systems engineering milestones and activities throughout the follow on phases.
Figure 3 - System Lifecycle
Warship 2008: Naval Submarines 9, Glasgow, UK
©2008: The Royal Institution of Naval Architects
These plans, once approved by the system’s owner, become the control documents for completion of the development and implementation of the project.
4.3 CONCEPT OF OPERATIONS
The Concept of Operations is the initial definition of the system. At this stage, the project documents the way the envisioned system is to operate and how the envisioned system will meet the needs and expectations of the stakeholders. The operation is defined from multiple viewpoints consisting of operators, technical specialists and maintainers. The focus is on how the system will be validated (the Test Concept Document) to prove that it satisfies the intended capability. The problem space, definition, needs, goals, expectations, stakeholder lists, and project constraints is captured in the concept of operations document. This document contains the updated, refined summary of work done at the Concept Exploration phase.
4.4 SYSTEM LEVEL REQUIREMENTS
The system level is the highest level of abstraction of the ie the Submarine Capability which incorporates its associated FIC elements. Requirements are developed for the system. At the system level; the definitions of what the system is to do, how well it is to do it, and under what conditions are documented. System requirements are based on the user needs from the Concept of Operations.
Requirements do not state how the system will be implemented unless it is intended to constrain the development team to a specific solution.
4.5 HIGH LEVEL DESIGN AND SUB-SYSTEM REQUIREMENTS
The High Level Design stage takes the top level system requirements established in the previous phase and translates them into subsystem requirements at the FIC level which will define the functions the capability is to deliver.
These requirements normaly generate a few alternate system configurations/ designs that can deliver the desired capability. Each requirement is periodically examined for validity, consistency, desirability and attainability, through this examination/evaluation process a decision can be made on the preferred system design.
With the chosen design a requirements analysis will be performed and a functional design can be made. This functional design is a description of the product in the form of a model: the functional architecture. This model describes what the system does and of which items it consists of (allocation and synthesis). Thereafter, the product can actually be developed, integrated and implemented in the user environment.
The System level requirements are further refined and allocated [assigned] to the sub-systems considering the
constituent elements of hardware, software, databases, people etc. Requirements for each sub-system element are documented the same way as the system level requirements. This process is repeated until the system is fully defined and decomposed to component level. Each layer will have its own set of interfaces defined. Each layer will require an integration step that is needed when the sub-system is developed. The control gate that is used for this final review called the Preliminary Design Review [PDR].
Figure 4 - The System Design Process
4.6 COMPONENT LEVEL DETAILED DESIGN At the Component Level Detailed Design step the development team defines how the system will be built.
Each sub-system has been decomposed into components of hardware, software, personnel etc. For these components, Detailed Design specialists in the respective fields create the “build-to” specifications which will be used to build or procure the individual components. A final check is done on the “build–to” specifications before the design moves forward to the actual hardware fabrication which does not commence until a review is completed and approved by the system’s owner and stakeholders. The control gate used for this final design review is called the Critical Design Review [CDR].
4.7 FABRICATION
The program then progresses to the procurement of equipment and fabrication phase. This stage is primarily the work of the prime contractor. The system’s owner and stakeholders monitor this process with planned periodic reviews, ie. technical review meetings.
Warship 2008: Naval Submarines 9, Glasgow, UK
©2008: The Royal Institution of Naval Architects Concurrent with this effort, unit test procedures are
developed that will be used to demonstrate how the products will meet the detailed design. At the completion of this stage, the developed products are ready for unit test.
Figure 5 - System Analysis
4.8 UNIT TESTING
The components consisting of the hardware and software are verified in accordance with the unit Verification Plan.
The purpose of unit testing is to verify that the delivered components match the documented Component Level Detailed Design. This is done by the prime contractor in preparation for the next level of integration. It is also a good review point for the system’s owner and stakeholders.
4.9 SUB-SYSTEM INTEGRATION AND VERIFICATION
At this step, the components are integrated and verified at the lowest level of the sub-systems. The first level of verification is done in accordance with the Verification Plan and is carried out in accordance with the Verification Procedures developed in this stage. Prior to the actual verification, a Test Readiness Review is held to determine the readiness of the sub-systems for verification. When it has been determined that verification can proceed, the sub-systems are then verified. When the integration and verification are completed, the next level of sub-system is integrated and verified in the same manner. This process continues until all sub-systems are integrated and verified.
4.10 SYSTEM VERIFICATION
System verification is done in two parts. The first part is done under a controlled environment ie “factory acceptance test”. The second part is done within the environment that the system is intended to operate called
“harbour acceptance trials” after initial system deployment. At this stage, the system is verified in accordance with the Verification Plan developed as part
of the system level requirements performed early in the development. The system acceptance will continue through the next stage, Initial System Deployment. The final part of system verification is then completed. A control gate is used for this conditional system acceptance.
4.11 INITIAL SYSTEM DEPLOYMENT
At Initial System Deployment, the system is finally integrated into its intended operational environment through thre conduct of sea trials. This step may take several weeks to complete to ensure that the system operates satisfactorily in the long term. This is sometimes called a “shake down”. Many system issues surface when the system is operating in the real world environment for an extended period of time. This is due to the complexity of the system and the diversity of operational conditions that may only occur under specific and infrequent conditions. Once the system verification is completed, the system is accepted by the system’s owner and stakeholders and then moves into the system validation and operations & maintenance phases.
4.12 SYSTEM VALIDATION
Validating the system is a key activity of the system’s owner and stakeholders. It is here that they will assess the system’s performance against the intended needs, goals, and expectations documented in the Concept of Operations and the Validation Plan. This represents a series of operational trials known as “System Qualification and Acceptance Trials” conducted by the fleet test specialists which completes with the milestone of “Accepatnce Into Naval Service”. It is important that this validation takes place as early as possible [after the acceptance of the system] in order to assess its strengths, weaknesses, and new opportunities. This activity does not check on the work of the system integrator or the component supplier [that is the role of System Verification]. It is performed after the system has been accepted and paid for. As a result of validation, new needs and requirements may be identified. This evaluation sets the stage for the next evolution of the system.
4.13 OPERATIONS & MAINTENANCE
After the initial deployment and system acceptance, the system moves into the Operations & Maintenance phase.
In this phase the system will carry out the intended operations for which it was designed. During this phase routine maintenance is performed as well as staff training. This phase is the longest phase, extending through the evolution of the system and ends when the system is retired or replaced. In the case of a submarine this phase will continue for decades. It is important that there are adequate resources to carry out the needed Operations & Maintenance activities; otherwise, the life
Warship 2008: Naval Submarines 9, Glasgow, UK
©2008: The Royal Institution of Naval Architects
of the system could be significantly shortened due to neglect.
4.14 CHANGES & UPGRADES
Changes & upgrades should be implemented in accordance with the Vee technical process described previously. Using the Vee process for changes &
upgrades will help maintain system integrity including configuration control between the system components and supporting documentation.
4.15 RETIREMENT/REPLACEMENT
Eventually, every system will be retired or replaced for one of the following reasons:
x No longer able to ensure materiel/technical integrity;
x Capability no loger relevant or viable;
x The system may no longer be needed;
x It may not be cost effective to operate; or
x It may no longer be maintainable due to obsolescence of key system elements.
This phase looks at how to monitor, assess needed changes, and make change/upgrade decisions.