Systems Engineering for Naval Ship Design Evolution

Abstract

The intensive integration of technology and the demand for high-level performance are specific features of warships, which are at present one of the most complex systems. An appropriate design process, able to foresee in a life cycle perspective, is necessary to properly implement the emergent properties and the capabilities required for the warship in the different operational profiles. This paper will delve into the integration of the Systems Engineering (SE) approach into the realm of naval ship design, fostering an innovative perspective. An integration of the design spiral method with the SE approach will be described, making possible the definition of a hinge between the two realms and depicting a novel comprehensive approach where the ship platform and the so-called payload are finally interconnected with each other.

1. Introduction: The Complexity of Warship Design

The design process of a warship often requires a superior effort and resources when compared to merchant vessels: more and diverse stakeholders are involved and the ship’s technical specifications are identified starting from mission and capabilities requirements with a dedicated process. Platform systems such as the energy system and its distribution grid, sensors, weapons, and communication systems need to work as a whole, under the control and management of personnel onboard.

This array of systems reflects the multiplicity of a warship’s functions, as opposed to the single/few functionality/ies (typically goods transportation) of many merchant vessels. For example, a commercial ship needs a radar system only for navigation; a warship, on the other hand, requires such a system not only for navigation but also for detecting threats and engaging them.

The idea of the naval ship as a complex system is recognized by many authors, for example, D. Andrews, who defines the warship as a physically large and complex (PL&C) system [1]. In this perspective, he stated that ship design is a “wicked problem”, i.e., the problem is not understood until the formulation of a solution and for that reason determining the actual requirements is really challenging. Moreover, for complex systems, it is not possible to directly identify a unique possible solution to the problem. The characteristics of a “complex system” are defined by M. Clemens of the New England Complex Systems Institute [2] as a gathering and integration of diverse entities, each with specific attributes and fundamental behaviors, but more importantly, they interact with each other and with the surrounding environment and contextual factors. In naval vessels, platform and combat systems act as a whole in the operational environment, to meet mission requirements established by stakeholders. As a result of successful integration, the entire ship system exhibits qualities that do not exist in any of its individual components, giving rise to emergent properties at various scales.

The idea of the ship as a complex system was also the basis of the project HOLOSHIP [3], where a systemic approach was defined to describe the ship as the sum of various subsystems and components. This approach deals with the complexity of a surface unit by employing a holistic vision. The project specifically refers to cargo ships, describing subsystems such as cargo storage, energy/power generation, propulsion, crew/passenger accommodation, and navigation. Furthermore, the HOLOSHIP project highlights certain limitations of the Design Spiral and emphasizes the need to transition towards a more modern and comprehensive life cycle perspective.

Modern ship design approaches also embrace a systemic perspective by treating the ship as an assembly of modular components. These modules can be replaced throughout the ship’s life cycle to adapt to different transport and operational scenarios. This approach, known as “Modular-based Ship Design” or “Set-based Ship Design” [4,5] allows for flexibility and facilitates retrofitting to enhance transport services in terms of efficiency and safety. This modular methodology has found broader application in naval and multi-purpose ship design, and it could potentially be an ambitious feature to be integrated into the authors’ proposed theoretical approach in future developments.

The integration of the design spiral in the framework of the se approach, described in the paper, is meant to provide a systemic vision to put the theoretical foundation to deal with the described problem and lead the whole system toward a specific solution. As highlighted in the following sections, an update to the overall method of designing naval ships must include the identification and definition of specific metrics. Therefore, future advancements in the proposed approach will involve the incorporation of innovative computational tools, such as CAD [6], PLM [7] and operational simulations [8], which will provide reliable prediction of ship performance, particularly within a life cycle perspective.

2. The Design Spiral: Points of Strength and Weakness

Traditionally the design of a ship is performed by making use of the well-known “Design Spiral”, which was originally introduced by J. H. Evans in 1959 [9]. Evans intended to develop a rational comprehensive design procedure for a surface cargo ship, enabling the trade-off process and the convergence toward solution efficiently and possibly taking advantage of automatic tools.

A design spiral specifically elaborated for naval ship design was published by Watson in 1998 [10] and it is shown in the right part of Figure 1.

Figure 1. The Design Spiral for merchant ships and warships by Watson [10].

The spiral illustrates how several ship properties are assessed with proper sequencing in a linear iterative process, on the basis of previous steps, which in turn are established with assumptions on the following ones, still unknown. Figure 1 displays two tailored design spirals, for merchant vessels and warships, showcasing their similarities and differences, in particular for what concerns the input requirements for the procedure. However, the resemblances are more prevalent.

Over the decades, several attempts have been made to improve the original spiral in terms of model representation and inclusion of aspects not considered previously. The efforts to modernize the original design spiral model and the evolution of the design techniques emphasized that the spiral approach cannot well represent the entire life-cycle process of the ship, requiring a wider vision.

One of the most discussed weak points of the design spiral is the lack of a proper approach to define the ship requirements and well explore the problem domain before formulating trade-off analysis of possible solutions. This is because the traditional design spiral starts its process when requirements have been already defined in agreement with the client and use them as input to develop a balanced solution.

Thus, some researchers started to find a way to integrate the elucidation of requirements into the ship design spiral process, for example, Levander [11] and Papanikolaou [12] tried to merge the ship requirements definition in the spiral process.

The flaws of the design spiral are described by Andrews who dedicated a lot of his work [13,14,15] to analyzing warship design methodologies and in particular the validity of the design spiral approach. He identifies two aspects of ship design, iterative and interactive, stating that only the iterative aspect is well captured by the Design Spiral, and even then, only in the specific steps represented.

As Papanikolaou, Andrews underlines how Early Stage Ship Design (ESSD) is a peculiar process, which must be treated with a different approach than the design spiral [16]. Indeed, its purpose is the exploration of different possible architectures to identify the requirements needed to properly make use of the design spiral, rather than the design of the vessel itself.

Many other authors found flaws in the design spiral method and felt the necessity to discuss a novel approach. Brown for example stated [17] that the concept design phase is a delicate process, which is not well represented by the design spiral. In his opinion, naval ship concept design relies heavily on an ad hoc approach, where design concepts are chosen based on experience, design lanes, rules of thumb, personal preferences, and imagination.

Bruinessen et al. point out some limits of the design spiral [18], stating that the model effectively represents the progressive refinement of design details, but it lacks flexibility in adapting to evolving system choices, solutions, or requirements. The main flaws attributed to the design spiral traditional approach can therefore be resumed as follows:

• Close process: the interactions with all the stakeholders involved in the design process are not rationally described in the Design Spiral stages and it is not clear when and how their feedback is needed to assess the solution.
• Inappropriate Early Stage Ship Design: the decisional process in the early phases of the ship design is crucial to well define the problem and identify the requirements needed. The requirements identification is taken for granted and it is completely left out of the design process, which uses them as input.
• Lack of a Life-Cycle vision: it considers only the design stage of the ship’s entire life, excluding from the design process the influences of significant phases like overarching architectures, operational life, maintenance, and retirement.
• Linear approach: the naval architectural aspects of the design cannot be adequately structured and represented by flow diagrams like the design spiral. This is due to the process involving closed loops and intuitive leaps, while performance functions are nonlinear and often discontinuous. In addition, inequalities are more common than equations in this context. The looping, nonlinear, and discontinuous nature of the design process creates challenges not only for representing it using the design spiral but also for computer-based systems widely used for achieving balanced solutions through rapid iterations [19].

The Design Spiral seems to work well in a further phase of the design process once the requirements have been defined and they need to be put together in a final balance solution. The definition of requirements in the early design stages is often executed using the ‘experts’ perspective and rule of thumb, constraining the design by previously known and workable technical solutions.

Moreover, the time-consuming efforts for the several iterations necessary to achieve the final result usually favor the adoption of a past and already consolidated reference model, limiting the project merely to a tuning and customization process that can certainly meet the operational requirements, but which is not necessarily the best possible solution. Thus, the spiral process addresses mainly the engineering of the vessel once the main requirements and functions have been made.

From all the above discussions it derives how the design spiral method needs to evolve to keep pace with modern systems and industry needs. The lack of a mode in the design spiral process to assess the solution’s effectiveness demands a quantitative methodology to assist the designers and the customers in the decisional process, which is the foundation to identify and design the needed ship solution. Thus, to upgrade the traditional warship design methodology and apply a whole system vision, the Systems Engineering (SE) approach is a sound resource, that applies the systems approach to observe large and complex systems design exploration, development, and problem-solving through systematic and systematic processes.

3. Overview of Systems Engineering Approach

In this section, a brief introduction to SE main features will be given, keeping in mind the level of complexity of a naval ship and the point of weakness (and strength) put in evidence for the linear iterative model of the ship design process represented by means of the design spiral.

Systems engineering is commonly recognized as a powerful approach to enable the realization of complex systems also in a life-cycle perspective. Considering in particular the design phase, it aims to focus on effectively defining stakeholder’s needs and requirements in the early design process, translating them into a technically feasible solution. It encompasses a wide range of activities to ensure that the final product fulfills its intended purpose, both from a technical and economic point of view. It is based on activities such as trade-off analysis and optimization procedures, aimed to provide successful integration among different technical engineering knowledge and systems [20].

One of the most important features of SE is that it enables the grasp and modeling of a complex system as a whole besides the visualization of the different parts in interaction and it permits the implementation of socio-technical aspects into the process [21]. From what above, Systems Engineering can be briefly defined as a systemic and systematic approach with the aim of identifying the best possible solution that fulfills the stakeholder’s needs and translates them into technical requirements [22]. It is a systematic approach because it refers to taking a structured, orderly methodology to solve the problem and to implement the system; it can also be defined as a systemic approach because it refers to the holistic appreciation of the system of interest, considering its context, stakeholders, and the interrelationships and interconnections.

In past years, several models have been developed to graphically represent the SE processes throughout the main life stages of a system. These can be classified into three major categories: iteration and recursion methods, sequential methods, and incremental and iterative methods [20].

There a “perfect model” does not exist among the three presented above, but it depends on the organization that will produce the system and on the nature of the system to be designed. However, the most widespread model used to represent SE approach is the V-model. Several representations of the V-model can be found in the literature, but one of the most comprehensive in the transportation field has been developed by the Federal Highway Administration of the U.S. Department of Transportation [23].

Figure 2 represents a model developed by the authors and adapted from the previously mentioned one [23] to better depict the warship’s main design steps. The model illustrates SE activities throughout the life cycle stages, with time and system maturity progressing from left to right. The blue color of the processes intensifies as it descends along the legs, representing an increasing level of detail. The “wings” have been added recently to the modern V-models to include the entire project life cycle.

Figure 2. The Systems Engineering V-Model.

This model represents how SE is the fusion of two different design approaches: the top-down and the bottom-up processes. On the left leg, there is the top-down process (Decomposition and Definition), where the system definition evolves from an initial high-level user perspective to a detailed specification of the system design. The System of Interest (SOI) is broken down into subsystems and further into components, allowing for a hierarchical organization of large systems, which are divided into smaller pieces through multiple layers of decomposition. Simultaneously, the requirements are also broken down into more specific ones, which are then allocated to the corresponding system components. The top-down process guarantees that the starting requirements are met but cannot ensure the physical feasibility of the product.

The practical realization of the asset takes place at the bottom of the “V” model, while on the right leg the bottom-up process takes place (integration and recomposition), where integration and verification of the components and system take place. Ultimately, the completed system is subjected to validation to assess how effectively it meets the user’s needs. The right leg bottom-up process guarantees that the product is physically feasible and jointly with the top-down process on the left leg ensures that the final product fulfills the starting requirements.

The V-model certainly reduces project risks by:

• Improving the quality of the design.
• Controlling costs throughout the entire life cycle framework.
• Enhancing interaction among stakeholders.

However, it does not inherently address time management in the planning and realization of the project.

The key to the V-model is the V representation itself. The two legs are not sequential to each other, but they coexist from the very beginning representing the strength of the SE. Indeed, the top-down and bottom-up processes are kept together by the core of the model, which metaphorically also represents the core of the entire SE methodology. The symmetric structure of the V-model highlights the interrelation between the left and right sides of the model, demonstrating the correlation between the activities performed on the left side and their corresponding verifications on the right side. The system definition established on the left serves as the basis for validating the system on the right.

Thus, at each level, there exists a deliberate and direct correspondence between the activities on the left and right sides. This approach ensures that the verification method is determined and defined as the requirements are developed and documented at each level. Even at the initial and highest level, when user requirements are translated into system requirements, the system verification approach must be established to ensure that the system fulfills its intended purpose. The verification process can significantly impact cost and schedule and may serve as a differentiating factor between alternative concepts.

Verification and Validation are then the core of the V-model and it is important to note the clear distinction between verification and validation. Verification focuses on proving that each product meets its specified requirements (answering the question: “Have we built the system right?”). On the other hand, validation aims to demonstrate that the product satisfies the user’s needs, irrespective of what the system specification demands (answering the question: “Have we built the right system?”).

Metrics are a crucial part of the Systems Engineering processes, allowing quantitative and objective measures to evaluate the goodness of the system under analysis. The purpose of metrics is to gauge progress toward a goal or continuous product improvement. Achieving a goal or improvement requires action, which should be based on the data collected from the metrics and their interpretation. Below are described different categories of technical measures commonly used to obtain detailed information on solution performance during development. It is crucial to recognize that within KPIs (Key Performance Parameters), a hierarchical order is necessary to manage the process systematically and systemically, especially for complex systems with numerous parameters at play. The definitions provided are derived from INCOSE [20,24], which shows that technical measures can be divided into the following four groups:

• Measures of Effectiveness (MOEs)
  “The “operational” measures of success that are closely related to the achievement of the mission or operational objective being evaluated, in the intended operational environment under a specified set of conditions; i.e., how well the solution achieves the intended purpose.” INCOSE

• Measures of Performance (MOPs)
  “The measures that characterize physical or functional attributes relating to the system operation, measured or estimated under specified testing and/or operational environment conditions.” INCOSE

• Technical Performance Measures (TPMs)
  “TPMs measure attributes of a system element to determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.” INCOSE

• Key Performance Parameters (KPPs)
  “A critical subset of the performance parameters representing those capabilities and characteristics so significant that failure to meet the threshold value of performance can cause for the concept or system selected to be reevaluated or the project to be reassessed or terminated.” INCOSE

The distinction between ‘effectiveness’ and ‘performance’ highlights that Measures of Effectiveness (MOEs) and Measures of Performance (MOPs) are formulated from distinct perspectives. An MOE relates to the effectiveness of a solution and is not tied to any specific solution; in contrast, an MOP pertains to the actual performance of a chosen entity or solution. The MOE reflects the intentions of stakeholders, whereas the MOP focuses on the tangible performance of the supplier’s solution, which may deviate from stakeholders’ intentions. Moreover, a MOE identifies a property that a potential solution must possess to fulfill a need, while a MOP reveals the capabilities of something, even if it’s not necessarily what stakeholders desire it to do.

It is possible to see where the described measures have a crucial role in the “V” model processes. At the highest level, MOEs come into play and are essential for the Validation Process, by centering on meeting acquirer needs. They serve to quantify value, aiding in the justification of procurement decisions and, at the project’s conclusion, in quantifying system validation.

Developers utilize KPPs to define the essential requirements needed to attain the MOEs. KPPs, in turn, guide the establishment of MOPs, which are assessed as early as possible and repeatedly throughout the development, testing, and evaluation phases. MOPs play an essential role in the verification process, verifying that the system adheres to the system’s technical requirements, and facilitating the validation of these requirements to align with mission objectives and acquirer needs.

TPMs offer a more detailed breakdown of MOPs, often driven by identified risks, with the goal of providing measurable and continuous insights into technical progress. These measures are assessed through various means, including analysis, modeling, simulation, and appropriate verification methods such as testing. As development progresses, periodic estimations of MOEs are derived using MOP and TPM values to ensure the likelihood of meeting MOEs.

It seems clear how SE is a powerful tool to manage the design of complex systems, such as naval ships, being able potentially to overcome the traditional design spiral flaws, described in Section 2, and supply warship design with a wider and modern vision. Many international figures tried in the past years to apply SE concepts to naval ship design: Andrews [25] developed a new methodology to face the peculiarity of early stage design, which makes use of SE approach. Decomposition is largely used to approach the complexity of warship design, by Gaspar et al. [26], to separate the whole system into separated basic elements and subsystems, making it more comprehensible. Brown [27,28] also makes use of capability-based approaches to decompose the ship’s complex system and he largely makes use of SE metrics. The necessity to use metrics to evaluate the adequacy of the solution under design has been also underlined in the already mentioned project HOLISHIP [3], where “measures of merit” have been defined to properly instruct the design optimization procedures.

However, there is still the necessity for a commonly recognized methodology that exploits the strength of both the design spiral and the systems engineering approach, encouraging the designer, right from the initial design stage, to prioritize the functions of a naval ship rather than the individual components that constitute it. This shift in perspective is demanded to grasp “what” is necessary to meet the customer’s requirements before delving into the technical aspects of “how” to achieve those objectives.

The forthcoming chapter will delve into the integration of the Systems Engineering (SE) approach into the realm of naval ship design, fostering an innovative perspective.

4. A Proposal for the Integration of the V-Model and the Design Spiral

As stated in the previous sections, the design spiral and the V-Model merging is assumed to be an interesting activity to empower naval ship design. In this perspective, it is necessary to define how the two methodologies could interact with each other and when during the design process [29].

Figure 3 points out an aspect that is not often represented: indeed, the V-Model is usually depicted in a 2-D mode, implying that processes evolve only from the left to the right (see Figure 2 in the previous section). However, this is only an interpretation of the original model, initially developed by Forsberg [30] in 1991 and intended as a 3-D model. The 3D representation implies that, at each step of the V-Model, parallel activities are going on at the same time. It also represents the level of detail, which increases while descending the model, where the attention goes from the general system to its components.

Figure 3. The different domains of the V-Model.

To better discuss the processes the following actions are needed:

-

Definition of technical features starting from needs (problem domain)

-

Subsequent development of details for the system identified as a solution (solution domain)

A double cone figure, possibly resembling an hourglass, can be used on the left leg of the V-Model, as the one shown in red in Figure 3. The upper cone (Problem Domain) identified as P-Cone depicts the stage where a problem is identified and understood, concentrating on understanding the needs in order to formulate requirements, answering the questions “what is the right asset I need and why?” [31]. For instance, this involves gathering information, defining goals and objectives, and exploring the factors contributing to the problem with the aim of being ready for product functionalities identification.

The large base of the P-Cone implies that the discussion about requirements identification is very open. Convergence in the process is provided by solving possible conflicts among requirements and by selecting the most significant requirements in terms of priority. At the end of the problem domain, represented by the upper cone’s apex, the technical specifications of the solution to fulfill the stakeholder’s needs, have been selected. During the P-Cone processes, computational tools, such as operational simulations, can be applied to support the designers’ decisional process.

The lower cone (solution domain) identified as S-Cone pertains to the space where potential solutions are assessed in terms of compliance with the issues identified in the problem domain. In this phase, the question is: “how do we build the identified right design?” [31]. The focus shifts therefore from understanding the problem to crafting the solution. In S-Cone the increasing diameter is meant to represent the increasing level of knowledge about details. Indeed, the solution implementation starts from the general system, which is represented by the S-Cone’s apex, and proceeds to define the subsystems and components in the lower processes of the left leg.

The development along the design spiral of the ship design steps (from feasibility study to detailed design) [32] perfectly fits with the lower part of the left leg and the S-Cone (see Figure 4): once the system specifications have been defined, they are attentively addressed along the traditional ship design processes to produce the final ship configuration. Indeed, the design spiral is a powerful tool to synthesize the selected requirements and functionalities into a final feasible technical solution.

Figure 4. The relationship between the design spiral and the V-model.

It is necessary to clarify that traditionally the ship design spiral models make use of a convergent spiral representation of the design process, ending with the ship to be built. However, some researchers developed divergent spiral models, such as the one developed by Rawson [33], which differs from the typical inward-spiraling approach and prefers an outward spiral, proposing a different perspective of the solution domain. The convergent representation, in fact, means that the final solution is reached after several iterative loops; while the divergent representation suggests an increase in complexity and details as the solution evolves, but still the solution converges in the final feasible product.

For all the ship’s typology, during the design spiral development, the payload integration is assessed in terms of space (volume and area), weight, electrical balance, local structural strength, and stability. However, for naval ships some other important integration issues are to be considered to overcome the dichotomy, very evident between the so-called platform and payload:

• Platform: it refers to the ship itself, including its hull, superstructure, propulsion systems, sensors, and other fundamental components. It is the physical vessel that serves as a foundation for carrying and deploying various types of payloads.
• Payload: it refers to the specific equipment, weaponry, sensors, and systems that are installed onboard the ship to carry out its mission operational objectives. For instance, they can be weapons like missiles, guns, torpedoes, or sensors like radar, sonar, or communication systems.

To this purpose starting from the Design Spiral defined by Watson in [10] (see also Figure 1), a new version is proposed in Figure 5 taking into account other integration issues such as:

Figure 5. Integration of payload aspects in the design spiral.

• Equipment selection: The selection of the systems/equipment that are necessary for the naval ship mission.
• Topside: This is where many key components are located along the ship length and it plays a crucial role in the ship’s functionality and combat capabilities. It involves the correct positioning of the payload systems with respect to each other, considering possible interferences between systems.
• EME: Electromagnetic Environment Effects refers to the impact of electromagnetic radiation, including radiofrequency emissions and other forms of electromagnetic energy, on the operation and performance of electronic systems and equipment on board a warship. Considerations on EME are critical to ensure the proper functioning and protection of electronic systems and equipment on board and to maintain operational effectiveness in a potentially hostile electronic warfare environment
• Equipment thermal dissipation: This refers to the management and control of heat generated by the various electronic and electrical equipment on board the warship, which is essential to effectively dissipate to ensure the reliable and safe functioning of these systems.
• Blast and FOD: Blast refers to the shock wave and pressure generated by the detonation of explosive devices. It is a significant concern in naval warfare, as blast effects can cause severe damage to the ship and its crew. Thus, warships are designed and equipped to withstand or mitigate the effects of blasts making use of reinforced hulls, blast-resistant compartments, and other protective measures. FOD (Foreign Object Debris or Foreign Object Damage) refers to any foreign object, substance, or debris that can enter or damage a warship’s systems, equipment, or machinery, potentially leading to equipment malfunction or damage. FOD considerations are crucial for maintenance and operation activities.
• CS LAN/NAV LAN: Combat System LAN (CS LAN) is a network dedicated to supporting the ship’s combat and weapons systems, which is used for coordinating and controlling the ship’s offensive and defensive capabilities, such as missile launch systems, gun mounts, radar, and other combat-related sensors and systems. Navigation LAN (NAV LAN) is a network established for the ship’s navigation and general ship management purposes. It typically includes navigation sensors, charts and mapping systems, GPS equipment, and communication systems necessary for the ship’s navigation and coordination with other vessels. These LANs are separate and distinct to ensure that combat systems and navigation functions are segregated for security and operational reasons, so it is necessary to well define the cable passage and positioning.

The above topics have been added as new rays (depicted in red in Figure 5) to the traditional design spiral for warships and they have been placed according to the necessary knowledge to be addressed in the design process. It is pointed out that they are not usually all involved during the first loops of the design spiral, but they are certainly taken into account when the knowledge level about details is appropriate in the further loops to properly merge the platform and the payload in a final feasible warship.

As stated above, the design spiral perfectly fits in the lower part of the V-Model left leg once the ship specifications have been defined. The proposed new version of the design spiral model is meant to better fit in the case of warship design and production.

Nevertheless, a robust procedure that creates an objective link between the needs and the ship requirements (input for the design spiral) is necessary. Moreover, a sound metric (MOE) that enables the mirroring of the ship’s performance and the fulfillment of the needs is of outstanding importance. In this paper, a capability-based approach is proposed in order to rationally guide the selection of the necessary requirements to define specifications and subsequently better instruct the design spiral method.

An example is the selection of the speed(s) requirement, which is usually already established when approaching the first Design Spiral steps. The selected speed(s), also in relation to the size of the ship, has a significant impact on the installed power and acquisition (CAPEX) and maintenance/operational (OPEX) costs. In this example, the proposed approach essentially facilitates an objective discussion about the required speed(s) for mission compliance and ensures a tangible connection between the chosen speed value and the underlying reasons for its selection.

To this aim, a decomposition of the capabilities is going to be postulated. The necessary level is the one that enables the definition of MOP.

Capability-based approaches are often used to manage the design of complex systems [32], being able to decompose and represent the whole system through its main functions and shifting the focus from the solution domain to the problem domain. This kind of approach enables the trade-off of different solutions early in the design process, allowing the selection of the right design with quantitative and objective evaluations.

Figure 6 shows a possible hierarchical model [34] to decompose the capabilities involved in the naval ship design process in the upper part of the V-Model left leg. The first set of capabilities (defense role, military mission, and operational) is strictly related to high-level evaluations of political strategies and the identifications of the military missions and operational capabilities needed to perform specific naval tasks required by the navy or the government. Those capabilities allow us to ultimately select the ship capabilities required to fulfill the operational requirements identified. Thus, it is in this phase that MOEs are selected to analyze the trade-off of different possible architectures and validate them to select the right ensemble of capabilities that the final solution should embed.

Figure 6. Capability Decomposition for the P-Cone.

Hereafter an approach is proposed to manage the last groups of capabilities (ship capabilities and elemental capabilities), which are necessary to well describe what the ship should be, in order to define the specifications that will lead to the design spiral and the physical realization of the ship. Those particular capabilities represent the connection between the problem domain and the solution domain, where the two cones’ vertices meet. At this point, it is necessary to select the functions required for each capability to subsequently select appropriate high-level MOPs, which will be then used to verify that the selected capabilities are appropriately integrated during the first loop of the design spiral.

Referring to Figure 6, the main ship capabilities (Table 1), are divided into elemental capabilities, following the decomposition proposed by L. Tirone [35] and Guglielmi [36].

Table 1. Main naval ship capabilities.

Ship Domain	Ship Capability
Platform	Buoyancy
	Stability
	Structural Strength
	Power Generation
	Controllability
	Communications (internal)
Payload	Navigation
	Command and Control
	Communications (external)
	Surveillance
	Combat

Those elemental capabilities represent the lower possible level of decomposition to describe a warship. Table A1 (Appendix A) reports the platform elemental capabilities, with their naval intent, here introduced to describe in detail the functions enabled by each capability, and the satisfaction level. The same for the payload elemental capabilities in Table A2 (Appendix A). The satisfaction level must be selected from the proposed ones in order to appropriately select the functions that are required to accomplish the operational capabilities derived by the previous political and strategic studies.

When the satisfaction level and the required functions have been identified, it would be possible to in turn appropriately define high-level MOPs. These KPIs will be used in the next design stages to assess the integration of the platform and payload capabilities in the naval ship under design. Moreover, the selected MOPs will enable tracking the impact of both payload and platform on specific topics of the Design Spiral, making it possible to define a hinge between the two realms and put the basis for a novel comprehensive approach where they are finally interconnected with each other.

The proposed approach aims to establish a solid theoretical foundation. However, for efficient implementation in the design process, future developments will require the application of a modeling tool, utilizing powerful instruments like Model-Based Systems Engineering (MBSE) softwares. Simultaneously, within the context of evaluating the ship’s performance at both MOPs and MOEs levels, it is crucial to emphasize the significance of numerical applications. These applications, such as CAD/FEM/CFD, are already state-of-the-art in handling crucial design spiral steps, and their efficient integration into the proposed approach is also desirable.

5. Conclusions

The shortcomings of the traditional but still fundamental design spiral together with the evident complexity of a warship emphasize the need for an evolution of the naval ship design process with a wider vision: from the requirements definition to the delivery of the final product.

An integration of the traditional design spiral linear iterative model and the SE V-model has been described, supported by the discussion of an integration methodology based on a capability-based approach. The capabilities decomposition permits to well describe the functionalities that the desired naval ship should embody, both in terms of Platform and Payload.

The important outcome is the possibility to define, starting from the selected levels of satisfaction, metrics (MOPs) that allow the assessment of ship/systems performance in the key SE process of verification. MOEs for the validation processes should be defined on a higher level according to the definition of the strategic and mission capabilities.

An extended ship design spiral has been proposed, with the integration of new rays relevant to the payload performance when acting onboard. Those rays represent important gates, which take place at their intersection with the spiral loops, where the MOPs can be used for the capabilities assessment.

The proposed approach aims to define the first theoretical steps in the process to define a novel approach exploiting the design spiral and systems engineering, starting with the identification of the ship’s platform and payload capabilities. The methodology appears a good support for bridging the two different domains, a traditional still unsolved challenge in naval ship design.

The proposed approach will be applied to a selected case study to assess the satisfaction level for each capability required for a Maritime Interdiction Operation (MIO) naval task. Identifying the necessary level for each elemental capability will then facilitate the selection of the relevant MOPs and their target values. This step is crucial for establishing the technical requirements at the intersection of the two cones.

Nevertheless, there appears a need to further develop the methodology by means of the selection of a modeling tool, which could enable a more agile structuring process and a more effective benefit acquisition for a more usable and practical application.