=Paper=
{{Paper
|id=Vol-2248/paper5
|storemode=property
|title=Virtual Engineering of a Naval Weapon System based on the Heterogeneuous Simulation Implemented through the MBSE
|pdfUrl=https://ceur-ws.org/Vol-2248/paper5.pdf
|volume=Vol-2248
|authors=Eugenio Brusa,Davide Ferretto,Jean Michel Cervasel
|dblpUrl=https://dblp.org/rec/conf/ciise/BrusaFC18
}}
==Virtual Engineering of a Naval Weapon System based on the Heterogeneuous Simulation Implemented through the MBSE==
https://ceur-ws.org/Vol-2248/paper5.pdf
Virtual engineering of a naval weapon system
based on the heterogeneous simulation implemented
through the MBSE
Eugenio Brusa Davide Ferretto Jean Michel Cervasel
Dept. of Mechanical and Aerospace Dept. of Mechanical and Aerospace Dept. of Mechanical and Aerospace
Engineering Engineering Engineering
Politecnico di Torino Politecnico di Torino Politecnico di Torino
Torino, Italy Torino, Italy Torino, Italy
eugenio.brusa@polito.it davide.ferretto@polito.it
Abstract— The Model Based Systems Engineering (MBSE) on a virtual representation of the system in operation, i.e. a
is effectively applied to develop a naval gun system, actively virtual mock–up, and a heterogeneous simulation of its
controlled for the target tracking, and to control the effect of functions [5]. Therefore, a suitable integration between
ship dynamics. A commitment, usually written by a commitment, functional and physical models is strictly
Department of Defense, requires to include in the trade-off required [6].
analysis the investigation of both the system configuration and
dynamic behavior. The use of interoperated functional and That need is coped by the MBSE, and the SysML
physical models, based on the SysML language, allow the language [7] can be used to perform a preliminary assessment
customer getting a realistic impression of the system geometry of requirements, and a trade–off of the system architecture. A
and of its controlled dynamics, when the MBSE heterogeneous numerical modeling is then linked to the functional models,
simulation is performed. To enable that simulation, the as it is herein developed, through the SOLIDWORKS®,
geometrical and numerical models are built and linked to the SIMSCAPE® and SIMULINK® tools. This activity leads to
functional models, even by resorting to the architecture a preliminary impression of the overall system architecture,
frameworks, deeply detailed by the customer. A test case is functions, and dynamic behavior, i.e. it provides the required
herein proposed, to provide an example of full mechatronic virtual mock–up. An efficient interoperability of tools is
system integration and simulation, through the creation of a required, to assure the effectiveness of the MBSE,
virtual mock–up.
expressively in this technical domain, where the verification
Keywords—Structural mechatronics, Virtual engineering,
of requirements is performed, upon the contents of the
MBSE, Interoperability, Dynamic simulation, Heterogeneous commitment document [8].
simulation. As the test case demonstrates, those needs are applied, in
general, to many mechatronic systems. Therefore, the use of
I. INTRODUCTION integrated geometrical, dynamic (both physical) and
functional simulators for the heterogeneous simulation [9] is
The development of a smart product as a weapon system
here proposed and discussed, for a wider application in
includes some crucial tasks, like the elicitation of
systems dynamics and control. The focus of this paper is
requirements, usually based on a very specific commitment of
investigating the methodology applied to interoperate and
a Department of Defense, expressing the customer needs; the
using some useful tools, for the above mentioned design
decomposition of the system complexity, motivated by a
analysis. For this purpose, a real test case is analyzed, thanks
number of subsystems, interfaces and components; the
to the collaboration with an industrial partner.
prediction of system dysfunctions, and the related assessment
of system safety and reliability [1]. Those exigencies drive
the industry to implement the Model Based Systems II. THE NAVAL WEAPON SYSTEM
Engineering (MBSE) to link requirements, functional and The system is a naval gun for cruisers, destroyers and
numerical analyses of the system, to be designed and frigates ships, similar to the Mk45 [10], although this is just
manufactured [2]. This approach allows the allocation of another product available on the market.
requirements to functions, then of functions to the system
components and to trace completely the whole product life
cycle development [3]. Train motion
Shield
In case of naval constructions, for defense purpose, the Elevation UPPER
commitment document is written by the Department of SECTION
Defense, of a given country, often in tight collaboration with
operative units, like the Navy [4]. The contents must be Gun
Deck
exhaustive, unambiguous and sufficiently clear to suitably
drive the manufacturer through a trade–off of the system Fixed stand
layout. This document is complete and precise, but a common
language between customer and manufacturer is needed, as Ammunition LOWER
well as a clear pattern to be followed in the product SECTION
system
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 Fig. 1. Example of impression of a typical naval gun architecture.
have a preliminary overview of the system capabilities, based
Copyright © held by the author
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
Some nondisclosure restrictions impose to limit the refinement, until that a complete correspondence between
information herein shared, about some figures and the product and the customer needs is found (Fig.2).
parameters, although the main goal here is describing how the
heterogeneuous simulation can be effectively used, to Converting the commitment into a digital model assures a
improve the design activity, more than emphasizing the standard language, and is linked to the numerical models
performance of the specific commercial product. developed during the design activity, thus bringing the
customer to provide a clear information about the needs, in
The Naval Gun System, or NGS, as it shall be herein tight collaboration with the manufacturer.
called, is a subsystem of a navy ship. It provides a weapon
system against surface, land and air targets, being conceived IV. REQUIREMENT ANALYSIS AND CUSTOMER NEEDS
to operate under all the operating environments and sea
conditions, and to assure a high accuracy in training and A. Customer needs and committment
elevation motion rates, as well as a rapid response to the
operator command [4]. According to the MBSE, the customer needs are
preliminary detected, as a list of items, not yet written
A main innovation target is currently to operate this according to standards, like the MIL–STD 901. It is helpful
system automatically and remotely, without a direct crew distinguishing needs into four categories. Some are real
member interaction, with a very high reliability in terms of exigencies of customer, others are constraints related either
operation and lethality. The NGS control basically drives two to the technical standards or typical of the technical domain,
motions, a yaw about the vertical axis through the so–called Sometimes they represent some exigencies related to the
training motion, and the gun elevation about an horizontal manufacturing practice. Finally, some are key issues to
axis (Fig.1). Usually the architecture includes a lower section, innovate the product (i.e. innovation targets) [5]. The priority
where the fixed part, constrained to the ship deck, and the of needs is perceived in different ways, depending on the
ammunition system are located, and an upper section, where category. It is higher for the customer needs and the technical
the carriage, including all the mechanical components of the standards, and strategic, but somehow negotiable, in case of
gun, the shield, the training and elevating masses are the domain practices and the innovation targets.
installed, together with the crandle, for recoiling motion [4,5].
Some main goals are even detected, as in the test case
designing a lighter system, capable of assuring a target
III. THE COMMITMENT CONVERTED INTO tracking despite the dynamic behavior of the ship, covered by
A FUNCTIONAL MODEL a stealth shield, and equipped with a fast and reliable
A first novelty, recently introduced in this technical ammunition system. Among the domain constraints it is
domain, consists in applying the MBSE to the NGS required to apply a proprietary technology, while having the
commitment. Usually, this document defines all the ammunition system above the deck plane is an innovation
requirements of the new system, through a written technical target. It is worthy noticing that a representation of needs, as
specification. It takes time to be written, it does not allow a in Fig.3, allows realizing the balance between innovation and
real exploration of alternative solutions, since a given tradition, in the system development, simply by comparing
architecture is assumed, to define the requirements. the number of needs related to each category and the related
Sometimes, it looks ambiguous, if it is based on a verbal source.
report, whose style depends quite a lot upon the
Innovation
communication skills of the committing customer. Therefore,
Target
the architecture frameworks, like the DoDAF (US Dept. of 12
Defense Architecture Framework) [11], MODAF (UK) [12] 10
8
and NAF (NATO) [13] suggest a set of standard views (for 6
instance, strategic, system, operational, technical and 4
acquisition views), to define the mission, scenarios and STD
2
Customer
0
capabilities of the committed system. Technical Needs
Constraints
Fig. 3. Analysis of needs and related sources, for the detection of the level
of innovation applied, in test case.
B. Requirements
A key issue in the requirement analysis is the
classification, defined by the manufacturer, according to the
technical domain and practice. A preliminary classification
Fig. 2. Product life cycle development performed through the MBSE. includes functional, operational and physical (or structural)
requirements [6]. In this case a further level of classification
Those architecture frameworks are often applied to write is required. A distinction is even made between functional
directly the system requirements, despite the MBSE and non–functional or “dysfunctional” requirements, i.e.
approach, which identifies the customer needs before the between a nominal system configuration working in operation
requirements, which are directly imported into the digital and a damaged configuration, in which some failures modes
model of the system. The digital model allows allocating, occurred. Some specific items are then considered, like
verifying and validating the requirements, through an iterative operational, physical, safety, maintenance and performance
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
requirements. Within those classes, some interfaces, “Maintenance” defines the condition of out of service,
environmental conditions and power supplies are considered. under maintenance, while “isolated” describes the complete
The caliber of the gun is even fixed, as well as the rates of disconnection from the power supply and the direct control
training and elevation motion. A significant step consists in for extraordinary maintenance. Finally, the “shutdown”
writing all the requirements through a manager tool, like the brings the system to be switched off. Some extensions are
IBM DOORS®, to allow then an easy synchronization within even defined, as the “change barrel” for a substitution of the
the functional model developed by resorting to the IBM gun, “dry” to remove the sea water from the gun, “turn
RHAPSODY®, which implements the SysML language. As around” to describe an imposed rotation, and “compensate
a relevant result of this step the classification of requirements displacement” to describe the specific action of feedback
is assessed, as in Fig.4. control applied to the NGS motion, to compensate for the
deck motion.
Fig. 5. The NGS use cases interactions as they appear in the IBM
RHAPSODY® tool.
B. Activities and States
Fig. 4. Structure of requirements imported into the IBM DOORS® tool. For each use case, some related activities are described
through the Activity Diagrams (AD). They allow realizing the
V. FUNCTIONAL ANALYSIS sequence of actions to be performed, the interfaces between
system and stakeholders, the components and subsystems to
A. Stakeholders and use cases be used, like actuators, sensors, power supplies and other
ones. All activities are described step by step, through a
A significant enhancement in the system development is waterfall of diagrams, for a complete prediction of the logical
given by the functional analysis, developed by means of the operation of system, as in Fig.6, where a detail of the start–up
SysML [7]. Several diagrams are drawn to describe the activity is depicted.
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).
Fig. 6. Example of Activity Diagram drawn in the IBM RHAPSODY®
In the “wait” case the system is connected to a power tool for the “Start-up” of the NGS.
supply, without operating (in maintenance), while during the
“start-up” it is brought to the “stand by”, during which it can A preliminary system architecture is described through
be fed by ammunition, but is unable to shoot. “Ready” means the Block Definition Diagrams (BDD), as in Fig.7, once that
that it can be trained and elevated, without shooting, being the some AD and State Diagrams, describing the different states
main action of the case “operating”. It is worthy noticing that in which the system holds in each use case, were drawn.
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.
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
Fig. 7. Synthesis of the Blocks Definition Diagrams defined for the test case and example of the real implementatioon within the IBM RHAPSODY®
(zoom).
C. Requirements allocation VI. NUMERICAL MOCK–UP AND SIMULATION
The previous step is relevant for the allocation of
requirements, which are imported from the IBM DOORS® A. Numerical modeling
into the IBM RHAPSODY® model, through the gateway After the functional view, including only functions, and
provided by the software. Particularly, the user activates the logical view of system operation, describing some blocks,
some connections, between each block and the related not yet associated to physical components, a physical view,
function foreseen, within an AD and simultaneously between aimed at defining the commercial components to be
a block and the allocated requirement to define a satisfaction assembled is drawn. In this case, it is stated that two
(for a given function there is a part satisfying the need), or modeling activities are required. An impression of the system
either a trace dependency or a refinement between configuration, revealing the mass, volume and shape is
requirements, being related each other. This action allows needed to check the requirements related to the compatibility
importing the requirements inside the digital model of with the ship body and systems, respectively. A dynamic
system, by connecting them to functions and blocks. 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 [14] is
impossible. A first allocation of blocks described by the BDD
has to be performed, by drawing, for instance through the
SOLIDWORKS® tool, each physical component, as in Fig.9.
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
Fig. 8. Example of allocation of the requirements to blocks. SIMECHANICS® items, to be used for the dynamic
simulation, as in Figs. 9 and 10. The SIMSCAPE® model can
Moreover, the actual allocation of requirements is verified be directly connected to the SIMULINK® environment, thus
and the so–called coverage of requirements is automatically allowing a preliminary selection of some typical design
checked, to assure a full satisfaction, i.e. each requirement parameters of the whole system. Therefore, some
motivates the presence of a corresponding component. After assumptions in terms of material, geometry and
the synchronization of requirements, a full representation of characteristics of the joints between gun and tower, for
blocks, functions and requirements can be done as in Fig.8, instance, can be made, since the beginning, whilst the
and an immediate impression of the system traceability is geometric model is drawn, or even associated to the parts, by
provided. This step makes usually easier a complete forcing a simple attribution of numerical values to few design
allocation to the elements of some numerical models, which parameters, to assess then the best combination to be used for
are exploited to predict the system dynamic behavior. a detail design of components.
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
Fig. 9. The Simscape® (left side) and Simulink® (right side) models of the whole NGS system.
35°
30°
25°
YAW ANGLE
20°
15°
10°
5°
0
-5°
0 2 4 6 8 10 12 14 16 18 20
TIME [s]
Fig. 11. Example of roll maneuvre imposed to the ship deck to test the
dynamic response of the controlled NGS.
Fig. 10. Example of allocation of blocks to material and numbered parts.
B. Numerical simulation and design synthesis 1 𝑁𝑁
𝐺𝐺(𝑠𝑠) = 𝑃𝑃 + 𝐼𝐼 + 𝐷𝐷
𝑠𝑠 1 (1)
The virtual mock–up of the NGS can be tested, through a 1 + 𝑁𝑁 𝑠𝑠
numerical prediction of the controlled dynamic behavior, in where P, I and D are the proportional, integral and derivative
the SIMULINK®. Some typical maneuvers, foreseen by the contributions, while s is the Laplace coordinate, and N the
MIL–STD Standards, for each use case, can be performed. control tuning parameter.
A main test concerns the dynamic response to a given The electric motors to be applied to the two above
profile of roll motion of the frigate ship, imposed to the deck mentioned motions are simultaneously selected among those
as a dynamic input (Fig.11). In this case, the system is commercially available and compatible with the installation
modeled as an assembly of rigid bodies, and only two on the frigate ship. To avoid the parasitic effect of the ship
degrees of freedom are considered, i.e. the train and the roll motion on the NGS maneuvers, the values of peak
elevation angles. A feedback PID control is applied to the control torques found, by calculation, are 547 Nm for the
NGS, to operate the electric motors, governing the two training motion and 126 Nm for the elevation motion. They
motions, to constantly point the target. This strategy correspond to a request of additional power of 1231 W and
measures the error between the target point and the gun 146 W, respectively. Those numerical results depend on how
alignment. The Ziegler–Nichols approach [15] is applied to early the parasitic ship motion is detected. Nevertheless, this
tune the PID parameters. For an inertia of 3000 and 3500 is linked to the specific system layout, i.e. on the location of
kgm2 of the whole system, about the yaw and elevation axis, the overall center of mass. To assure the system motion and
respectively, the related stiffness can be tentatively set at 180 target pointing, an AC Brushless motor fed by 760V/50Hz
and 90 MNm/rad, respectively [4]. The saturation angle for could be applied.
the training motion is fixed at –175° to +175°, while for the
elevation motion spans from –27° to +88°. Some additional Other activities might be similarly performed to test some
limitations are even applied to the train and elevation rates, new layouts proposed for the ammunition system, but this
although they are covered by the nondisclosure agreement. part of the study is covered by the nondisclosure agreement.
Nevertheless, the process applied looks similar to that
The PID control gain is defined, as usual, as [15]: 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
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
representation and the simplified physical modeling of the drive the design to select the most suitable physical
system provide a quantitative impression of the system products. Finally, as the physical architecture is composed by
geometry and dynamics. This preliminary design shall be selecting commercial components and subsystems, the
surely refined and assessed. Nevertheless, it helps the reliability prediction of the system in service can be
customer either to accept or to reject the proposed layout. In performed, by resorting to the reliability of commercial
the meanwhile, this judgement is reached with a complete products declared and eventually tested.
awareness about the implications in terms of requirements
coverage concerning each relevant detail of the tested This process is greatly improved by resorting to the AD,
system. since they help in detecting the failure conditions applied to
each function. It is simply required to negate each activity
200°
and to find the related effects, by following the links to the
150° other activities, as it could be done in Fig.6.
100°
TRAIN ANGLE
50° In the test case a dysfunctional analysis is even driven by
0° selected use cases like “misfire” and “fault”. They suggest
-50°
-100°
the contents of the activities described in Fig.14, for the
-150° aircraft design [17], as in the tradition of this technical
-200°
0 5 10 15 20 25 30 domain they lead to an easier definition of the FTA and
TIME [s] FMEA.
Fig. 12. Numerical prediction of training motion angular position. Moreover, the failure conditions can be introduced as
additional blocks in the virtual mock–up, based on the
100° SIMULINK® model. Particularly, for each block the
ELEVATION ANGLE
80° nominal behavior is described by the related equations,
60°
including some design parameters. An additional block,
40°
20°
representing the failure modes and the related probability of
0°
occurrence, can be applied to the output of each block
-20°
corresponding to a system component. Therefore, during the
-40° simulation, either the user or a probability function can
0 5 10 15 20 25 30
TIME [s] activate a failure mode, to test its effects directly on the
dynamic response of the NGS, as is currently done in other
Fig. 13. Numerical prediction of elevation motion angular position. technical domains, like in aerospace engineering [17].
Failure
Functions Conditions Functional
VII. SAFETY AND RELIABILITY Functional
Hazard
Analysis
The process above implemented greatly helps in applying Analysis
Logical Reliability
a new strategy for the analysis of the system safety and Architecture Target
Logical Reliability
reliability. The practice of this technical domain suggests a Analysis Allocation
Safety Assessment Process based on a Failure Hazard Physical Reliability
Analysis (FHA) and a System Safety Assessment (SSA), by Physical
Architecture Prediction
Reliability
resorting to the Failure Tree Analysis (FTA) and the Failure Analysis Prediction
Mode and Effect Analysis (FMEA). This approach is applied
to refine the requirements concerning reliability, availability, Fig. 14. Comparison and similitude between functional and RAMS analyses
maintenance and safety (RAMS). In principle, the trade-off performed within the frame of the MBSE.
of the system configuration is an input for the following
analyses, concerning the RAMS. Therefore, they are This approach is aligned with some contributions recently
performed a posteriori, through the identification of several proposed and still under development, which formalize the
failure modes. This means that any eventual problem related definition of the tool chain applied to the so-called
to the RAMS analysis leads to a re–engineering operation. dependability assessment [18], through an integrated
dysfunctional and numerical analysis [19], aimed at verifying
The integrated heterogeneous simulation herein described
the system requirements [20], even in case of systems of
adds another relevant benefit. It allows deploying the
systems [21].
analysis of system functions and dysfunctions
simultaneously, as the trade-off is performed. Particularly, it
might be preliminarily realized that the RAMS analysis is VIII. CONCLUSION
definitely similar to the functional analysis. As it was The benefits of creating a virtual mock–up to be
described in [16] a perfect analogy can be found between the simulated through the MBSE heterogeneous simulation is
typical steps of the MBSE applied to the product here investigated. Particularly, the test case of a naval gun
development and those of a RAMS analysis, in terms of system simultaneously represents an example of full
activities, products and tools involved. As Fig.14 describes, mechatronic system and of product developed on the basis of
the dysfunctional analysis can be accomplished into three architecture frameworks, and described by a technical
steps in sequence. The Functional Hazard Analysis (FHA) commitment document. Two needs characterize the technical
can detect the typical failure conditions of the operating domain involved. Performing the trade-off activity by
system, exactly like the functional analysis defines its exploiting a clear prediction of the system dynamics as well
functions. Once that the failure modes are known, a first as a precise impression of the system layout is required.
reliability allocation on the logical elements of the system Anticipating to the trade-off activity the RAMS analysis, to
architecture helps to define the reliability targets, which
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
select the most reliable commercial products, to assembly the [6] E. Brusa, A. Calà, and D. Ferretto, Systems Engineering and Its
system is equally welcome. Application to Industrial Product Development. Cham, Switzerland:
Springer, 2018.
The paper demonstrates that resorting to a digital model, [7] L. Delligatti, SysML Distilled: A Brief Guide to the Systems
including the system requirements, functions, and Modeling Language, Addison-Wesley Professional, 2013.
architecture, makes the communication between customer [8] E. Brusa, A. Calà, S. Chiesa, F. De Vita, D. Ferretto, “Towards an
and designer clearer, faster and more effective, than a simple effective interoperability of models within the 'Systems Engineering'
applied to aeronautics”. Proc. INCOSE Conf. on Systems Engineering
transmission of a verbal commitment document. The (CIISE 2014), Rome, Italy, November 24-25, 2014, pp.38–47.
traceability and the allocation of requirements are better [9] A. Mitschke, E. Brusa, A. Calà, D. Ferretto, C. Pessa, G. Bachelor,
assured through the MBSE tools, provided that a suitable “Heterogeneous simulation based on standards: deepening
interoperability of tools is deployed. interoperability in trade-off analysis approach for aeronautical
application”. Proc. 23rd Conf. Italian Ass. of Aeronautics and
An example of virtual mock–up making is provided. The Astronautics, AIDAA 2015, 17-19 November 2015, Torino.
requirement manager IBM DOORS® is easily linked to the [10] Mk 45 Naval Gun System. BAE System: www.baesystems.com
functional model developed in the IBM RHAPSODY®, and [11] D.E. Wisnosky, J. Vogel, Dodaf Wizdom: a Practical Guide to
then connected to the SIMULINK® model, once that a Planning, Managing and Executing Projects to Build Enterprise
preliminary system drawing is done in the SOLIDWORKS® Architectures using the Department of Defense Architecture
tool, through the SIMSCAPE® capabilities and dropped into Framework. Wizdom Systems, Inc., 2004.
the dynamic simulator. This approach allows a complete [12] MODAF, Guidance MOD Architecture Framework,
https://www.gov.uk/guidance/mod-architecture-framework, 2012.
definition of the tool chain. A further development includes
some additional blocks to integrate the failure conditions [13] NAF, NATO Architecture framework, http://nafdocs.org/introduction/
inside the dynamic simulator, for a faster RAMS analysis. [14] E. Brusa, D. Ferretto, “Impact of the Model Based Systems
Engineering on the design of a mechatronic flywheel–based energy
The originality of the proposed approach consists in storage system”, Proc. IEEE ISSE 2016, Edinburgh, October 4–5,
2016, pp.171–178.
providing a visual representation of the product under
development, that the customer can evaluate in terms of [15] G.F. Franklin, J. Powell, A. Emami-Naeini, Feedback Control of
Dynamic Systems, Pearson, 2014.
volume, geometry, and layout, associated to a preliminary
[16] I. Vagliano, D. Ferretto, E. Brusa, M. Morisio, “OLSC based tool
dynamic simulation, aimed to check the system behavior, its integration in the aerospace domain: an industrial case”, Proc. IEEE
performance and even its failure conditions, when some COMPSAC 2017, Turin (Italy), 4-8 July, 2017.
additional blocks are included to predict the system [17] C. Pessa, M. Cifaldi, E. Brusa, D. Ferretto, K. Malgieri, N. Viola,
reliability. This approach can be easily extended to other “Integration of different MBSE approaches within the design of a
mechatronic systems, characterized by a controlled control maintenance system applied to the aircraft fuel system”, Proc.
dynamics. A further development shall extend this strategy of IEEE ISSE 2016, Edinburgh, October 4–5, 2016, pp.120–127.
virtual mock–up for the heterogeneous simulation even to [18] A. Tundis, M. Mühlhäuser, A. Garro, E. Brusa, D. Ferretto,
“Dependability Assessment of a Deicing System through the
some tools conceived for the multibody dynamic analysis, to RAMSAS method”, Proc. IEEE Int. Symp. on Syst. Eng. ISSE 2017,
predict the overall behavior of even more complex systems, Vienna, Austria, October11-13, 2017.
as some smart manufacturing systems, applied in other [19] A. Garro, J. Groß, M. Riestenpatt Gen. Richter, and A. Tundis,
technical domains [22]. “Reliability Analysis of an Attitude Determination and Control
System (ADCS) through the RAMSAS method”, J. Computational
Science, 5(3):439-449, 2014.
REFERENCES
[20] F. Aiello, A. Garro, Y. Lemmens, S. Dutré, “Simulation-based
[1] E. Crawley, B. Cameron, D. Selva. System Architecture: Strategy and verification of system requirements: an integrated solution”, Proc.
Product Development for Complex Systems, Pearson, 2015. 2017 IEEE 14th Int. Conf. on Networking, Sensing and Control
[2] D.D. Walden, G.J. Roedler, K. J. Forsberg, R. D. Hamelin, T.M. (ICNSC 2017), Calabria, Italy, May 16-18, 2017.
Shortell, The INCOSE Systems Engineering Handbook. Wiley, 4 ed., [21] A. Garro, A. Tundis. On the Reliability Analysis of Systems and
2015. Systems of Systems: the RAMSAS method and related extensions,
[3] A. Kossiakoff, W.N. Sweet, S.J. Seymour, S.M. Biemer, Systems IEEE Systems Journal, 9(1):232-241, 2015.
Engineering Principles and Practice. Wiley-Interscience; 2 ed., 2011. [22] E. Brusa, S. Morsut, “Design and optimization of the Electric Arc
[4] C.P. Chiarelli, Nozioni sui sistemi d’arma di artiglieria e missilistici, Furnace structures through a mechatronic integrated modeling
A.N. 2-35. Accademia Navale, 1994. activity”. IEEE - ASME Trans. Mechatronics, 20(3), June 2015,
[5] E. Brusa, D. Ferretto, A. Calà, “Integration of heterogeneous pp.1099–1107.
functional-vs-physical simulation within the industrial system design
activity”, Proc. IEEE ISSE 2015 Int. Symposium on Systems
Engineering, Rome, September 29–30, 2015, pp.303-310.
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE