- The Model Based Systems Engineering (MBSE) is effectively applied to develop a naval gun system, actively controlled for the target tracking, and to control the effect of ship dynamics. A commitment, usually written by a Department of Defense, requires to include in the trade-off analysis the investigation of both the system configuration and dynamic behavior. The use of interoperated functional and physical models, based on the SysML language, allow the customer getting a realistic impression of the system geometry and of its controlled dynamics, when the MBSE heterogeneous simulation is performed. To enable that simulation, the geometrical and numerical models are built and linked to the functional models, even by resorting to the architecture frameworks, deeply detailed by the customer. A test case is herein proposed, to provide an example of full mechatronic system integration and simulation, through the creation of a virtual mock-up.
The development of a smart product as a weapon system
includes some crucial tasks, like the elicitation of
requirements, usually based on a very specific commitment of
a Department of Defense, expressing the customer needs; the
decomposition of the system complexity, motivated by a
number of subsystems, interfaces and components; the
prediction of system dysfunctions, and the related assessment
of system safety and reliability [
In case of naval constructions, for defense purpose, the commitment document is written by the Department of Defense, of a given country, often in tight collaboration with operative units, like the Navy [4]. The contents must be exhaustive, unambiguous and sufficiently clear to suitably drive the manufacturer through a trade–off of the system layout. This document is complete and precise, but a common language between customer and manufacturer is needed, as well as a clear pattern to be followed in the product development, to fit all the requirements of safety, performance, quality, cost and delivery (QCF) and those of some technical standards. Moreover, the customer wants to have a preliminary overview of the system capabilities, based Copyright © held by the author on a virtual representation of the system in operation, i.e. a virtual mock–up, and a heterogeneous simulation of its functions [5]. Therefore, a suitable integration between commitment, functional and physical models is strictly required [6].
That need is coped by the MBSE, and the SysML language [7] can be used to perform a preliminary assessment of requirements, and a trade–off of the system architecture. A numerical modeling is then linked to the functional models, as it is herein developed, through the SOLIDWORKS®, SIMSCAPE® and SIMULINK® tools. This activity leads to a preliminary impression of the overall system architecture, functions, and dynamic behavior, i.e. it provides the required virtual mock–up. An efficient interoperability of tools is required, to assure the effectiveness of the MBSE, expressively in this technical domain, where the verification of requirements is performed, upon the contents of the commitment document [8].
As the test case demonstrates, those needs are applied, in general, to many mechatronic systems. Therefore, the use of integrated geometrical, dynamic (both physical) and functional simulators for the heterogeneous simulation [9] is here proposed and discussed, for a wider application in systems dynamics and control. The focus of this paper is investigating the methodology applied to interoperate and using some useful tools, for the above mentioned design analysis. For this purpose, a real test case is analyzed, thanks to the collaboration with an industrial partner.
Some nondisclosure restrictions impose to limit the information herein shared, about some figures and parameters, although the main goal here is describing how the heterogeneuous simulation can be effectively used, to improve the design activity, more than emphasizing the performance of the specific commercial product.
The Naval Gun System, or NGS, as it shall be herein called, is a subsystem of a navy ship. It provides a weapon system against surface, land and air targets, being conceived to operate under all the operating environments and sea conditions, and to assure a high accuracy in training and elevation motion rates, as well as a rapid response to the operator command [4].
A main innovation target is currently to operate this system automatically and remotely, without a direct crew member interaction, with a very high reliability in terms of operation and lethality. The NGS control basically drives two motions, a yaw about the vertical axis through the so–called training motion, and the gun elevation about an horizontal axis (Fig.1). Usually the architecture includes a lower section, where the fixed part, constrained to the ship deck, and the ammunition system are located, and an upper section, where the carriage, including all the mechanical components of the gun, the shield, the training and elevating masses are installed, together with the crandle, for recoiling motion [4,5].
A FUNCTIONAL MODEL
A first novelty, recently introduced in this technical
domain, consists in applying the MBSE to the NGS
commitment. Usually, this document defines all the
requirements of the new system, through a written technical
specification. It takes time to be written, it does not allow a
real exploration of alternative solutions, since a given
architecture is assumed, to define the requirements.
Sometimes, it looks ambiguous, if it is based on a verbal
report, whose style depends quite a lot upon the
communication skills of the committing customer. Therefore,
the architecture frameworks, like the DoDAF (US Dept. of
Defense Architecture Framework) [
Those architecture frameworks are often applied to write directly the system requirements, despite the MBSE approach, which identifies the customer needs before the requirements, which are directly imported into the digital model of the system. The digital model allows allocating, verifying and validating the requirements, through an iterative refinement, until that a complete correspondence between the product and the customer needs is found (Fig.2).
Converting the commitment into a digital model assures a standard language, and is linked to the numerical models developed during the design activity, thus bringing the customer to provide a clear information about the needs, in tight collaboration with the manufacturer.
IV. REQUIREMENT ANALYSIS AND CUSTOMER NEEDS
According to the MBSE, the customer needs are preliminary detected, as a list of items, not yet written according to standards, like the MIL–STD 901. It is helpful distinguishing needs into four categories. Some are real exigencies of customer, others are constraints related either to the technical standards or typical of the technical domain, Sometimes they represent some exigencies related to the manufacturing practice. Finally, some are key issues to innovate the product (i.e. innovation targets) [5]. The priority of needs is perceived in different ways, depending on the category. It is higher for the customer needs and the technical standards, and strategic, but somehow negotiable, in case of the domain practices and the innovation targets.
Some main goals are even detected, as in the test case designing a lighter system, capable of assuring a target tracking despite the dynamic behavior of the ship, covered by a stealth shield, and equipped with a fast and reliable ammunition system. Among the domain constraints it is required to apply a proprietary technology, while having the ammunition system above the deck plane is an innovation target. It is worthy noticing that a representation of needs, as in Fig.3, allows realizing the balance between innovation and tradition, in the system development, simply by comparing the number of needs related to each category and the related source.
A key issue in the requirement analysis is the classification, defined by the manufacturer, according to the technical domain and practice. A preliminary classification includes functional, operational and physical (or structural) requirements [6]. In this case a further level of classification is required. A distinction is even made between functional and non–functional or “dysfunctional” requirements, i.e. between a nominal system configuration working in operation and a damaged configuration, in which some failures modes occurred. Some specific items are then considered, like operational, physical, safety, maintenance and performance requirements. Within those classes, some interfaces, environmental conditions and power supplies are considered. The caliber of the gun is even fixed, as well as the rates of training and elevation motion. A significant step consists in writing all the requirements through a manager tool, like the IBM DOORS®, to allow then an easy synchronization within the functional model developed by resorting to the IBM RHAPSODY®, which implements the SysML language. As a relevant result of this step the classification of requirements is assessed, as in Fig.4.
“Maintenance” defines the condition of out of service, under maintenance, while “isolated” describes the complete disconnection from the power supply and the direct control for extraordinary maintenance. Finally, the “shutdown” brings the system to be switched off. Some extensions are even defined, as the “change barrel” for a substitution of the gun, “dry” to remove the sea water from the gun, “turn around” to describe an imposed rotation, and “compensate displacement” to describe the specific action of feedback control applied to the NGS motion, to compensate for the deck motion.
A significant enhancement in the system development is given by the functional analysis, developed by means of the SysML [7]. Several diagrams are drawn to describe the behavior of the system first, and then some candidate architectures. A first step defines the stakeholders, here the commander (or COMANDO – COMmand unit AND ship Operations), the weather, the sea (since it drops water over the NGS), the radar unit, the operator at the NGS (or user), the operator for maintenance (or manual operator), the power supply, and the deck (i.e. a platform connected to the ship body). According to the architecture frameworks above cited, some operating conditions or ‘use cases’ are detected, as they appear in the Use Case Diagrams (UCD) of Fig.5. The use cases are very important to identify the role of each stakeholder and the activities, to create then a consistent numerical simulation of the system dynamics, as the physical modeling is performed. A number of use cases is defined by the manufacturer (Fig.5).
In the “wait” case the system is connected to a power supply, without operating (in maintenance), while during the “start-up” it is brought to the “stand by”, during which it can be fed by ammunition, but is unable to shoot. “Ready” means that it can be trained and elevated, without shooting, being the main action of the case “operating”. It is worthy noticing that some dysfunctional use cases are even foreseen, as the “misfire”, being the self–recovering status reached after a lack of shot, and the “fault”, corresponding to a stand–by after that a dysfunction is detected, apart from the misfire.
For each use case, some related activities are described through the Activity Diagrams (AD). They allow realizing the sequence of actions to be performed, the interfaces between system and stakeholders, the components and subsystems to be used, like actuators, sensors, power supplies and other ones. All activities are described step by step, through a waterfall of diagrams, for a complete prediction of the logical operation of system, as in Fig.6, where a detail of the start–up activity is depicted.
A preliminary system architecture is described through the Block Definition Diagrams (BDD), as in Fig.7, once that some AD and State Diagrams, describing the different states in which the system holds in each use case, were drawn.
The previous step is relevant for the allocation of requirements, which are imported from the IBM DOORS® into the IBM RHAPSODY® model, through the gateway provided by the software. Particularly, the user activates some connections, between each block and the related function foreseen, within an AD and simultaneously between a block and the allocated requirement to define a satisfaction (for a given function there is a part satisfying the need), or either a trace dependency or a refinement between requirements, being related each other. This action allows importing the requirements inside the digital model of system, by connecting them to functions and blocks.
Moreover, the actual allocation of requirements is verified and the so–called coverage of requirements is automatically checked, to assure a full satisfaction, i.e. each requirement motivates the presence of a corresponding component. After the synchronization of requirements, a full representation of blocks, functions and requirements can be done as in Fig.8, and an immediate impression of the system traceability is provided. This step makes usually easier a complete allocation to the elements of some numerical models, which are exploited to predict the system dynamic behavior.
After the functional view, including only functions, and
the logical view of system operation, describing some blocks,
not yet associated to physical components, a physical view,
aimed at defining the commercial components to be
assembled is drawn. In this case, it is stated that two
modeling activities are required. An impression of the system
configuration, revealing the mass, volume and shape is
needed to check the requirements related to the compatibility
with the ship body and systems, respectively. A dynamic
model has to be numerically solved, to predict the system
response to the deck motion, under the active control
command. Unfortunately, connecting immediately the
functional model, developed in the IBM RHAPSODY®, to
the SIMULINK® through the standard FMI as in [
The link between IBM RHAPSODY®, the SOLIDWORKS® and the SIMULINK® allows tracing and allocating the requirements to functions, and to the system components, described by a Part Number, and schematically sketched. The geometric model, built up in the SOLIDWORKS® environment, is then imported into the SIMULINK®, by means of the new tool SIMSCAPE®. It assures the importation of the system capabilities, by keeping the geometry, degrees of freedom, inertia and reference frames of the geometrical model. The SIMSCAPE® automatically decomposes the system into some SIMECHANICS® items, to be used for the dynamic simulation, as in Figs. 9 and 10. The SIMSCAPE® model can be directly connected to the SIMULINK® environment, thus allowing a preliminary selection of some typical design parameters of the whole system. Therefore, some assumptions in terms of material, geometry and characteristics of the joints between gun and tower, for instance, can be made, since the beginning, whilst the geometric model is drawn, or even associated to the parts, by forcing a simple attribution of numerical values to few design parameters, to assess then the best combination to be used for a detail design of components. profile of roll motion of the frigate ship, imposed to the deck as a dynamic input (Fig.11). In this case, the system is modeled as an assembly of rigid bodies, and only two degrees of freedom are considered, i.e. the train and the elevation angles. A feedback PID control is applied to the
motors, governing the two motions, to constantly point the target.
This
strategy
measures the error between the target point and the gun
alignment. The Ziegler–Nichols approach [
The PID control gain is defined, as usual, as [
10
TIME [s] 2 4 6 8 12 14 16 18 20 146 W, respectively. Those numerical results depend on how early the parasitic ship motion is detected. Nevertheless, this is linked to the specific system layout, i.e. on the location of the overall center of mass. To assure the system motion and target pointing, an AC Brushless motor fed by 760V/50Hz could be applied.
Other activities might be similarly performed to test some new layouts proposed for the ammunition system, but this part of the study is covered by the nondisclosure agreement. Nevertheless, the process applied looks similar to that previously described to refine the layout of the training and elevation systems.
As the example shows, the virtual mock–up implements the typical functional simulation performed within the MBSE to show the customer the qualitative performance of the system, but in this case the detail of the graphical 200° 150° E100° L G50° AN 0° IN-50° A -R100° T -150° -200°0 100° LE80° GN60° A40° INO20° TA 0° V LE-20° E -40°0 5 5 10 10
15 TIME [s] 20 25 30
The process above implemented greatly helps in applying a new strategy for the analysis of the system safety and reliability. The practice of this technical domain suggests a Safety Assessment Process based on a Failure Hazard Analysis (FHA) and a System Safety Assessment (SSA), by resorting to the Failure Tree Analysis (FTA) and the Failure Mode and Effect Analysis (FMEA). This approach is applied to refine the requirements concerning reliability, availability, maintenance and safety (RAMS). In principle, the trade-off of the system configuration is an input for the following analyses, concerning the RAMS. Therefore, they are performed a posteriori, through the identification of several failure modes. This means that any eventual problem related to the RAMS analysis leads to a re–engineering operation.
The integrated heterogeneous simulation herein described
adds another relevant benefit. It allows deploying the
analysis of system functions and dysfunctions
simultaneously, as the trade-off is performed. Particularly, it
might be preliminarily realized that the RAMS analysis is
definitely similar to the functional analysis. As it was
described in [
This process is greatly improved by resorting to the AD, since they help in detecting the failure conditions applied to each function. It is simply required to negate each activity and to find the related effects, by following the links to the other activities, as it could be done in Fig.6.
In the test case a dysfunctional analysis is even driven by
selected use cases like “misfire” and “fault”. They suggest
the contents of the activities described in Fig.14, for the
aircraft design [
Moreover, the failure conditions can be introduced as
additional blocks in the virtual mock–up, based on the
SIMULINK® model. Particularly, for each block the
nominal behavior is described by the related equations,
including some design parameters. An additional block,
representing the failure modes and the related probability of
occurrence, can be applied to the output of each block
corresponding to a system component. Therefore, during the
simulation, either the user or a probability function can
activate a failure mode, to test its effects directly on the
dynamic response of the NGS, as is currently done in other
technical domains, like in aerospace engineering [
Functional Analysis Logical Analysis Physical Analysis
Functions
Logical Architecture
Physical Architecture
Failure Conditions Reliability Target Reliability Prediction
Functional
Hazard Analysis Reliability Allocation Reliability Prediction
This approach is aligned with some contributions recently
proposed and still under development, which formalize the
definition of the tool chain applied to the so-called
dependability assessment [
The benefits of creating a virtual mock–up to be simulated through the MBSE heterogeneous simulation is here investigated. Particularly, the test case of a naval gun system simultaneously represents an example of full mechatronic system and of product developed on the basis of architecture frameworks, and described by a technical commitment document. Two needs characterize the technical domain involved. Performing the trade-off activity by exploiting a clear prediction of the system dynamics as well as a precise impression of the system layout is required. Anticipating to the trade-off activity the RAMS analysis, to select the most reliable commercial products, to assembly the system is equally welcome.
The paper demonstrates that resorting to a digital model, including the system requirements, functions, and architecture, makes the communication between customer and designer clearer, faster and more effective, than a simple transmission of a verbal commitment document. The traceability and the allocation of requirements are better assured through the MBSE tools, provided that a suitable interoperability of tools is deployed.
An example of virtual mock–up making is provided. The requirement manager IBM DOORS® is easily linked to the functional model developed in the IBM RHAPSODY®, and then connected to the SIMULINK® model, once that a preliminary system drawing is done in the SOLIDWORKS® tool, through the SIMSCAPE® capabilities and dropped into the dynamic simulator. This approach allows a complete definition of the tool chain. A further development includes some additional blocks to integrate the failure conditions inside the dynamic simulator, for a faster RAMS analysis.
The originality of the proposed approach consists in
providing a visual representation of the product under
development, that the customer can evaluate in terms of
volume, geometry, and layout, associated to a preliminary
dynamic simulation, aimed to check the system behavior, its
performance and even its failure conditions, when some
additional blocks are included to predict the system
reliability. This approach can be easily extended to other
mechatronic systems, characterized by a controlled
dynamics. A further development shall extend this strategy of
virtual mock–up for the heterogeneous simulation even to
some tools conceived for the multibody dynamic analysis, to
predict the overall behavior of even more complex systems,
as some smart manufacturing systems, applied in other
technical domains [