Simulation Testing of Maritime Cyber-Physical Systems : Application of Model-View-ViewModel

. From the perspective of the system of systems development, system-level functional testing is required for designing subsystems. This study utilizes modeling and simulation techniques to analyze the operational behaviors of the subsystems and conﬁrm data communication between them. The targeted system in the study is a naval combat system (NCS), which is a typical type of defense cyber-physical system (CPS). Three types of models were designed for the simulation testing of the NCS: a combat-management model for simulating the overall computational activities, physical models to conﬁrm the intrasubsystem behaviors, and data integration models to test the intersubsystem communications. These models are realized with the Model-View-ViewModel design pattern, which strongly facilitates graphical user interfaces being decoupled from model logic and data. We consider underwater combat scenarios as an application. Six signiﬁcant physical subsystems within the NCS are simulated and tested: a ship-steering system, an inertial navigation system, a global navigation satellite system, a periscope, sonar systems, and a plotting board. We expect that the proposed work will play a principal role when analyzing the behaviors and communications of defense CPSs and providing an environment for functional testing as a digital twin.


Introduction
A military combat system is a type of maritime cyberphysical system (CPS) [1][2][3] that collects physical data through sensor subsystems [4]. In turn, it makes real-time decisions by feeding the data into computing subsystems [5]. As a naval combat system (NCS) for a surface ship or underwater vessel is highly complex, its functionalities regarding sensors, computers, and communications should be tested individually in system of systems engineering [6,7].
For the functional testing of an NCS, the following realworld requirements at the subsystem level must be considered. Firstly, most physical subsystems of an NCS are highly distributed [8]. As the subsystems operate separately, they have multiple console panels to identify and control their operations. Next, the subsystems usually have different data formats and communication protocols [9]. To communicate between the Various M&S methods for defense CPSs have been used over the last decade. Some researchers have proposed classification methods for CPS models [16][17][18][19], and others have developed simulation systems with diverse modeling languages [20][21][22]. e collective contribution of these studies has been to suggest meaningful modeling methods and simulation software for defense CPSs. Despite this contribution, the methods still warrant some improvements. For example, some CPS models lack a realistic configuration of their target systems. ey focus on evaluating a CPS's integrated performance as a whole rather than analyzing the operational behaviors of subsystems. In addition, some researchers developed simulation systems with a centralized approach so that the communications between the subsystems could not be simulated or expanded.
us, the previous techniques were not suitable for subsystem-level simulation testing.
is study presents a practical simulation approach to testing defense CPSs, specifically an NCS, at the subsystem level. We functionally classify CPS models that closely resemble the components of the real NCS. en, we develop a distributed simulation system to help with analyzing intrasubsystem behaviors and confirm the conversion of intersubsystem data. e designed models were implemented using the Model-View-ViewModel (MVVM) design pattern [23] in Windows Presentation Foundation (WPF). e main advantage of the MVVM pattern is to decouple the graphical user interface (GUI) significantly from the model logic and data [24]. We created GUIs for the subsystems' console panels with extensible application markup language [25]. e logical parts of the models-e.g., the decisions, dynamics, and data conversions-are implemented in the models of the MVVM pattern. is separation between data and logic increases the transparency, modularity, and flexibility of the overall modeling, i.e., the external graphical interfaces and the internal model logic. For this reason, the MVVM design pattern has been used widely to develop software for human-computer interaction (HCI) in many industrial fields [26,27]. To the best of our knowledge, this study is the first attempt to develop a practical implementation of the MVVM design pattern for simulating a naval CPS.
As a practical case study, we simulated underwater combat operations. e physical subsystems to be modeled in this simulation included a ship-steering system, an inertial navigation system (INS), a global positioning system (GPS), a periscope, sonar systems, and a plotting board. A DIS model was developed to convert simulated data from the INS model into real-system data comprising hexadecimal values with a predefined header. e empirical results show how the physical models behaved during the simulation and how the DIS model transformed the collected data into compatible information for system scalability. With several discussions, we expect that the developed simulation system can be utilized to test an NCS at the subsystem level successfully. e study is organized as follows: Section 2 describes the NCS briefly to provide the background, and Section 3 analyzes previous works. Section 4 proposes the overall simulation architecture and the realization of the three model types based on the MVVM pattern. Section 5 explains and discusses an application for naval combat simulation. Finally, Section 6 presents our conclusions.

Background
An NCS, as a defense CPS, evaluates real-time threat situations and assigns appropriate weapons based on complex computations. Figure 1 shows a simplified configuration of an NCS. It comprises the multiple families of physical subsystems that perform similar functions (the red part in Figure 1). For example, the navigation sensor systems containing a GPS and an INS calculate the position, orientation, and velocity of their vessel. Underwater sensor systems, as typified by sonar systems, mainly detect objects in the water, and surface sensor systems, such as radar or periscope systems, perceive objects on the water's surface [28]. e underwater and surface sensor systems must be integrated with the navigation sensors because the accuracy of target detection requires precise self-localization. Weapon systems, e.g., missiles or torpedoes, contain independent objects launched from the vessel against offensive and defensive tactics.
As a computational part of the CPS, a combat management system (CMS) utilizes all information gathered from sensor and weapon systems [29]. It continuously performs the information-processing stages in the computational domain. For example, the CMS perceives the surroundings of its vessel and identifies approaching threats. After tracking them, it launches appropriate weapons and controls them, if necessary [30]. e CMS also contains several subsystems. As shown in the green part of Figure 1, it has multifunction consoles for HCI. e multifunction consoles display the overall tactical situation upon awareness by data integration from signal-processing units. ey assist vessel operators with understanding the situation and commanding their decision-making.
An NCS configures a combat system data bus (CSDB) and a central bus network to connect all the physical and computational subsystems. Note that the physical subsystems do not plug into the CSDB directly. e subsystems within the same group link to a data-integration system (DIS), which is interconnected across the CSDB sequentially [31]. In this case, the DIS (the blue part in Figure 1) performs essential roles as a gateway [32]. As each subsystem has a different data format and communication type, the DIS converts its I/O data to compatible forms with the CSDB. It also allows new subsystems to be added to the same system group without directly affecting the CSDB. erefore, the physical subsystems are connected through interoperability arrangements, which guarantees that they do not require strong coupling or tight integrations [33].
To summarize, the NCS is a defense CPS that has physical and computational subsystems connected via a centralized network [34]. For data conversion and system scalability, NCS also contains several DISs according to the subsystem types. In this regard, we developed three models for simulation testing: combat management (CM), physical, and DIS models.

Literature Review
Simulation testing utilizes the computerized models of a real system to evaluate the corresponding system's functionality under a given set of conditions [35]. Over the last decade, various studies have been conducted to provide indications for the simulation testing of defense CPSs. In this section, we categorize them by aspects of their modeling and simulation, as summarized in Table 1.
From a modeling perspective, several classification methods have been proposed for defense CPS models. For example, Sung and Kim [16] developed a collaborative modeling methodology for a domain-specific discrete eventsimulation system, which categorizes models as discrete event-level models or behavioral-level models. Li et al. [17] similarly explained two-level modeling (physical and decision modeling) for defense CPSs. ey focused on decision modeling rather than physical modeling because combat effectiveness is closely related to the tactics of the defense CPS under certain conditions. Zhu et al. [18] introduced domain-specific metamodeling with two orthogonal dimensions. Ontological modeling locates a model element from a domain-definition perspective, and linguistic modeling is concerned with modeling language definition. Park et al. [19] split a defense system into two parts for CPS modeling: core parts representing the system's physical and performance characteristics and shell parts for its operational attributes.
Although the above modeling methods provide transparent classification systems, they focused more on analyzing the integrated functionalities of the target systems. ey tend to explain a holistic view of their modeling rather than the modeling itself. us, they have a weakness when evaluating the functionalities of subsystems, such as navigation, radar, and sonar systems. In addition, as the methods were developed to enhance general modeling indices, e.g., model composability and reusability, the authors were not interested in basing the model components on a realistic system configuration.
Simulation studies have been conducted to represent defense CPS models graphically and analyze them. Squarcia et al. [20] developed a numerical simulation tool named Integrated Combat Systems Simulation (ICS-Sim), which allows the integration of simulation models to analyze and evaluate systems' performance for studying innovative algorithms. As these studies were fundamentally developed with a centralized simulation environment, it is difficult to apply them to geographically dispersed simulation systems with a common simulation platform.
Similar to our simulation approach, some researchers focused on distributed simulation with realistic components of defense CPSs. For example, Xu et al. [21] federated one computational simulation system at the engagement level and three physical simulation systems at the engineering level. Cheng et al. [22] also developed a distributed simulation system containing a general simulation platform, several observation systems, and a navigation system. ey focused on how to construct interoperable simulations with legacy systems and achieve data flows according to real-time constraints. Despite their contributions, however, these works do not provide behaviors or communication data at the subsystem level.
In  conducted the requirement analyses of next-generation systems [36] and created several modeling methods for CPSs, such as conceptual modeling [37], discrete event modeling [38], multifidelity modeling [39], and distributed simulation for heterogeneous systems [40]. Based on this methodological background, this study develops a practical simulation system with CPS models that are more realistic. e critical points for this study are (1) how to evaluate behaviors of subsystem models graphically for performance analysis and (2) how to convert their communication data for system scalability.

Proposed Work
is section, firstly, proposes the overall simulation architecture for testing the naval CPSs. en, we explain the three main components: the CM, physical, and DIS simulators.

Overall System Architecture.
Simulation testing is the process of designing and creating a computerized model of an engineered system for conducting tests to evaluate the behavior of the corresponding real system under a given set of conditions [35]. e proposed CPS simulation confirms intrasystem behavior and intersystem communication, which is required for simulation testing. To this end, the simulation architecture in Figure 2 utilizes three types of simulators: a CM simulator for overall simulation activities and physical and DIS simulators to achieve the above-stated requirements.
e CM simulator supports the continuous execution of the information-processing stages in the tactical domain and builds a situational picture of the ship's surroundings [29]. To simulate the overall actions of all the combat entities, it contains simulation engines and model constructions, which will be explained in the following subsection. After simulating the main activities, the simulator sends the simulated data to the relevant physical simulators.
e physical simulators realize their dynamics and behaviors by imitating the console panels of the corresponding system. As the real NCS has various types of physical subsystems, we selected several subsystems developed in this study, as shown in Table 2. e vessels usually use multiple navigation systems, which provides greater accuracy than possible when using any single system. For example, physical simulators control the propulsion, check their own behaviors with navigation simulators, detect threats with sonar and periscope simulators, and check the surroundings with a plotting board simulator. In this study, a periscope simulator was developed for virtual-constructive simulation, which will be explained in the discussion section.
Finally, the DIS simulator performs a gateway role. It links the existing physical simulators to external CPSs or their simulators by generating compatible I/O data on both sides. In other words, it stores received simulation data, converts them to real-world data, and sends the converted data externally. Figure 3 shows the configuration of the CM simulator. It consists of simulation engines and a simulation model, which means that models can be developed independently of a simulation engine and interfaced with the simulator using an API. e simulator layer contains platform-level models. e submarine model has various submodels, as well as submarine and target models. e combat-management simulator enables the users to interact with and control the physical systems for the large-scale systems [42]. In the model layer, the space module simulates the physical signals to be transferred within the environment. e acoustic Table 1: Related works for modeling and simulation studies of defense cyber-physical systems.

Previous work Motivation Method
Sung and Kim [14][15][16] A collaborative modeling process was proposed. It formally defines the roles and responsibilities of domain engineers, M&S engineers, and platform engineers. e models can be switched at the run-time or the load-time of a simulation run by the dynamically linked library technology. Li et al. [15][16][17] Domain-specific modeling containing physical and intelligent aspects was developed.
Code generation mechanisms transform domain-specific decision models to python code.
Zhu et al. [16][17][18] e proposed two-level metamodeling was based on petri nets to support continuous state transitions and event triggering.
MetaDepth was used for supporting the two-level textual modeling and implementing the deep semantics.
Park et al. [17][18][19] A defense CPS model is classified into core and shell parts. e two parts are specified with the DEVS (discrete event systems specification) formalism.
e Delta3D engine was used to represent combat entities graphically within a centralized simulation environment.
Squarcia et al. [18][19][20] A multiscale method was applied for modeling and simulation of systems/subsystems with a different degree of detail and accuracy.
An integrated simulation environment was developed for the performance evaluation of entire naval CPSs.
Xu et al. [19][20][21] e proposed warship model contains one computational model for overall tactical behaviors and three engineering models regarding weapons.
A specific software-hardware environment was required to interconnect legacy systems.
ree key technologies are resolved in their simulation system: general simulation platform, distributed simulation, and data exchange.
4 Complexity module simulates the acoustic signals generated from the engines and propellers of the combat entities. It is a closed-loop system that repeatedly performs object detection and data processing, makes command decisions, and determines how to respond to actions by appropriately using composite equipment over the course of a war. Each submodel is designed by the system taxonomy. In this study, we used a discrete event system and a discrete time system. For example, the data from the sensor and weapon models are fed into a control system simulation that models the sequence of events, from detection of the threat by various sensors to its engagement by different weapons. Figure 4 shows the class diagram for the combatmanagement simulator to implement the concept of Figure 3. To resolve this issue from the software side, we use the MVVM design pattern in the WPF framework. We divide the class diagram into View, ViewModel, and Model horizontally according to the MVVM pattern.
In Model, the combat-management simulator conducts a simulation algorithm and model logic. In View, the user can configure the scenario. e battlefield simulator helps the user to configure new scenarios. In the scenario, the user sets the model structure and values of the model's attributes, observes the simulation's trajectories, and monitors the specified attributes. e user handles the simulation object's spatial information, such as its position and speed. Mutual influences among the subsystems and the nonindependent behavior of the subsystems are evaluated from the battlefield simulator.
e combat-management simulator has references for specific scenarios. It only uses interface classes.
us, it is not affected by changes to the scenario. e modeler specifies which model attributes can be changed in

Physical Simulators Development.
e physical simulators provide physical subsystem aids and data and meteorological information for physical stabilization. Figure 5 shows the underwater sensor simulator in Table 2. Figure 5(a) shows that, firstly, the targets generate noise, and the noise radiates in all directions. e radiated noise propagates far away, undergoing the loss of acoustic energy and addition to background noise. Once the radiated noise arrives at sonars, the sonars analyze the radiated noise. Finally, sonar operators determine whether the noise represents targets ( Figure 5(b)). e sonar equation systematically estimates the expected signal-to-noise ratios for sonar systems. e signal-to-noise ratio determines whether a sonar will detect a signal in the presence of background noise in the ocean. It considers the source level, sound spreading, sound absorption, reflection losses, ambient noise, and receiver characteristics. Such signal-to-noise can be expressed as a passive sonar equation.
(1) e first term, source level (SL), is the magnitude of the radiated noise, whose major sources are engines and propellers. e characteristics of the radiated noise vary, depending on the type and operational conditions of the naval ship, which becomes the clue for the classification of targets. Propagation loss (PL) refers to the loss of acoustic energy that the radiated noise undergoes when propagating. Noise level (NL) is the magnitude of the background noise. Bandwidth (BW) and array gain (AG) are related to signal processing. Sonars analyze the radiated noise by signal processing, and the results of the signal processing are the magnitudes of the radiated noise according to bearings and frequencies. Finally, detection threshold (DT) is the standard for determining whether there are targets.

DIS Simulators Development.
e combat system links together various network topologies, treated as subnetworks, in a larger topology. In this case, the DIS is designed to act as a proxy for combat systems residing on the central data bus, which enhances interface compatibility. e DIS simulator verifies that the realized simulated model accurately reflects the authentic behavior of the real system to be tested. e primary role of the DIS simulator is to convert simulation data into a middleware data format.

Application: Naval Combat Simulation
is section introduces a practical application to maritime warfare. e developed simulation system was used to test the behaviors of the NCS's subsystems and verify data conversion in a specific subsystem.

Simulation Scenario.
Modern warfare has two conflicting goals, depending on the side: (1) how the attacker can hit targets accurately, and (2) how the defenders can incapacitate the attackers effectively [36]. For example, during a maritime engagement between a submarine and a surface ship, the submarine fires a torpedo, which sends out sounds and seeks the surface target with echoes. In contrast, the surface ship employs countermeasures to deceive the threat, i.e., the torpedo, and implements evasive maneuvering [36].
We assumed underwater warfare in this application: a friendly submarine attacks a hostile surface ship with a torpedo. Simulation models for the submarine were built based on the proposed CPS modeling. e CPS models specify when the submarine would launch a torpedo and how it would control the torpedo to hit the target. e simulation models for the surface ship also contained when and how to launch various types of countermeasures according to the defensive tactics used. e simulation would terminate when the surface ship has gone down or when the torpedo is discharged.

Simulation Environment.
We developed three types of CPS simulators for the submarine. Five physical simulators, as shown in Figure 6, were distributed across four desktops. e CM and DIS simulators were set up on the same desktop as that of the plotting board simulator. ey interacted with the developed physical simulators. For example, the CM simulator computed the overall actions of all of the combat objects. e submarine's actions were decided based on the sonar, GPS, INS, ship steering, and plotting board simulators. e DIS simulator transformed simulation data from the INS simulator into real-world data. e simulators were developed in .NET framework 4.7 using the language C#. We utilized WCF to realize serviceoriented communications between them. As a real INS has a serial interface to connect to external systems, the INS and DIS simulators were connected based on RS-232 serial communications. To retain the consistency of the GUI with the MVVM design pattern, we used DevExpress, which provides best-in-class user-interface controls for WinForms, ASP.NET, and WPF [43]. Figures 7-10 show the GUI results of the simulators developed in this application. Figure 7(a) shows a screenshot of the CM simulator, which comprises of five submenus. e main menu (Part I in Figure 7(a)) helps the user to control the overall simulation settings. A user can manage the simulation scenarios, such as by creating, saving, and opening them. When a simulation scenario is chosen, the user constructs the simulation models and configures their variables and parameters via Parts II and III. After completing the configuration, the user can start the simulation and pause, resume, and stop it, if necessary.

Simulation Execution.
Part IV is the main screen to visualize the current simulation situation. It provides all of the trajectories of the combat objects, which are represented with North Atlantic Treaty Organization joint military symbols. In this Complexity Complexity screenshot, a friendly submarine fires a torpedo at multiple threats. e sensing ranges of the submarine and the torpedo are displayed as purple and yellow fan-shaped sectors, respectively. Part V shows specific events during the simulation, e.g., threat detection, target evaluation, weapon assignment, and weapon launch. As the combat-management simulator provides an integrated situation, the individual behaviors are verified by the physical simulators. Figure 7(b) is a screenshot of the ship-steering simulator, which shows the six degrees of freedom for the vessel, i.e., latitude, longitude, depth, heading, pitch, and roll. e simulator was developed with autopilot and manual operation modes. e user can select the mode from part I, and the selected mode is displayed and managed via parts II and III. For example, in the manual mode, the user can control a pair of hydroplanes at the forward and afterward sides to change the vessel's horizontal direction and two rudders mounted in the vertical plane to change the lateral movement.
e current positional and attitude information is displayed in part IV. All of the views in this simulator are displayed as bar charts. Figure 8 shows the results from the two navigation sensor simulators. e GPS simulator in Figure 8(a) provides positional data based on satellite information. Part I displays the current latitude, longitude, altitude, and speed with text, and part II illustrates the number of satellites needed to calculate the position. In this application, the navigation data are processed with the global marine navigation protocol, which is a combined electrical and data specification for communication between marine navigation equipment [44].
When the vessel is operated underwater, it cannot receive a GPS signal; therefore, the INS mainly is activated, instead of the GPS simulator. In contrast to the GPS simulator, the INS simulator in Figure 8(b) provides textual and graphical information for the vessel's position and altitude (Parts II and III). e INS simulator uses the GPS signal to calibrate navigation inaccuracies when the GPS signal is available. us, through Part I, the user can choose whether to use the GPS signal while checking the current simulation time. Figure 9 provides the screenshots of the sonar simulator, which displays all of the undersea-detection information as broadband and narrowband views. e broadband view in Figure 9(a) contains thee subviews: the bearing diagram, plan-position indicator, and bearing time history. Firstly, the bearing diagram displays the amplitude envelope curve of the signal according to the directed sensors. If a target is detected in a specific sensor, the target is displayed as a raised section and assigned a specific number. Next, the planposition indicator view (part II) is a type of radar display using a polar coordinate system. In this view, our vessel is in the center, and the detected targets are marked as red points. e view displays the targets' sound levels with a crushed blue circle. In parts I and II of Figure 9(a), three targets-numbered 1, 2, and 3-were detected at about 100°, 310°, and 330°angles, respectively, with the 310°target having the highest sound level. Finally, the bearing time history (part III), referred to as a waterfall diagram, displays the output of the beamforming processor by time. e newest information is at the top of part III, which is matched with the bearing diagram.
Although the broadband view finds the targets' bearings and sound levels, it does not indicate which types of targets have been detected. e target type is specified by the sounds emitted and can be identified from the narrowband view. Figure 9(b) shows two narrowband views for the frequency analysis (II) and gram (III). e frequency analysis, which contains bearing-intensity and bearing-frequency graphs, provides all of the targets' detected sound frequencies. e frequency signals represent vital information about the targets' outward shapes and operations. Similar to the bearing time history in the broadband view, the gram (part III) in the narrowband view displays several sound beams simultaneously for time-series analysis. As shown in  Figure 9(b), twelve beam arrays for three targets were detected and temporarily faded away. In Figure 10(a), the plotting-board simulator displays various types of information from the platforms currently in operation. e main view shows the overall trajectories of the submarine, surface ship, and torpedoes with differentcolored lines. e right part of the main view offers two types of information: (1) numerical values such as latitude, longitude, heading, and speed and (2) status information containing the targets' categories and identification. Finally, Figure 10(b) is a screenshot of the DIS simulator, which provides the real-world data to be converted from simulation data. us, it provides increased transparency for the data set, to both the existing and connected systems.

Discussion.
e simulation experiments show functional testing results at the subsystem level. e CM simulator simulates real-world combat scenarios, computes overall activity, and sends simulated data to the relevant physical simulators. e five physical simulators display specific behaviors via the user interface, and the DIS simulator shows the data communication between the simulators.
Here, we discuss two further applications for the developed simulators. First, the simulators were utilized to analyze effectiveness and performance. e ultimate goal of NCS is to maximize fighting and defensive strengths based on optimal control of sensor and weapon systems. e NCS should be optimized, and performance should be evaluated before a real war is conducted, to measure the system's reliability [42]. Such early feedback during the system-design phase improves to the product's quality by allowing a new understanding of emergent behavior. e proposed simulation can reduce the time it takes to introduce new products, as has been very effectively demonstrated in the automotive industry [41].
Next, the present study supports a testing environment for other studies. It is common practice in military simulations to federate systems at different levels so that they can interoperate to provide their functionalities in a new context. MBSE, a paradigm in which the model becomes the actual software, provides not only a safe and efficient testbed but also provides an immersive environment in which CPSs can learn to adapt and optimize their behavior [45][46][47]. A buildand-test approach is insufficient because the complexity, cost, and design times become more challenging [48]. Figure 11 shows virtual and constructive simulations, a further application for the developed system [49,50]. We developed a periscope simulator with HCI interaction. e operator, in turn, interacts with the system or performs these activities, linked with the help of specific HCI panels. e DIS simulator in this advanced simulation produces new real-system data from received simulation data, which extends to live-virtual-constructive simulation.

Conclusion
In this study, we propose a layered simulation architecture for functional testing that differentiates intrasubsystem behaviors and intersubsystem communications. We designed and modularized three types of simulators. e CM simulator simulates real-world combat scenarios and sends simulated data to the relevant physical simulators. With the simulated data, each physical simulator realizes its dynamics and behaviors by imitating the console panels of its corresponding system. Finally, the DIS simulator performs a gateway role. It links the existing physical models to external CPSs or their models by generating compatible I/O data on both sides. e proposed s increases the automation's transparency, both to the designer and to the user, by separating the domain processing needed to build the system view from the processing. e developed software provides parallel management of the external interfaces to the combat system and internal interfaces between subsystems within the combat system for simulation testing.
Specifically, we discussed several findings, including the balancing of physical and computational abilities as well as the importance of information technology and the statistical trends between the models' inputs and outputs. Models enable simulation and analysis, which can result in earlier identification of design defects than prototyping can. MBSE is now a critical enabler for managing the complexity when developing complex modern systems like CPSs. We believe that the proposed systems also will allow developers and the research community, in general, to better understand open problems and their impact on the broad applicability of model-based design technologies.

Conflicts of Interest
e authors declare that they have no conflicts of interest.