Intercax - Blog

MBSE for Railgun Design | Part 1

Written by Dirk Zwemer | Jul 19, 2018

Introduction

The promise of Model-Based Systems Engineering (MBSE) is that we can capture all aspects of a system, including architecture, design, analysis and operations, in a single unified digital model. The challenge is that the development of complex systems requires the use of many different software tools and databases. The objective of this TechNote is to illustrate how a combination of tools can work together on the design of a new weapons system, an electromagnetic railgun. We will use SysML architectural modeling (MagicDraw or Rhapsody), physics-based analysis (Mathematica and Simulink), mechanical CAD (NX) and requirements management (Jama), connected by two Intercax tools, the MBSE platform Syndeia and the parametric solvers ParaMagic (for MagicDraw) and Melody (for Rhapsody).

Figure 1 Simplified physics of electromagnetic railgun

Railguns represent an elegant (if challenging in practice) solution to the problem of putting energy on target. In its most basic form (Figure 1), DC electrical current is pulsed through a single loop consisting of two long conductive Rails and a movable Armature that bridges them. The interaction of the magnetic field B generated by the current through the Rails with that same current I flowing through the Armature produces a lateral force F on the Armature. If the Armature is allowed to slide down the length of the Rails, it can carry the Projectile and launch it from the end of the Rails towards a target. The exit velocity (km/sec) and kinetic energy (MJ) imparted to the projectile can meet or exceed that of conventional artillery without the cost and handling hazards of conventional explosive propellants. Experimental systems have been reported with exit velocities >3 km/sec and energies >30 MJ. However, many practical problems stand in the way of widespread deployment, including the destructive thermal and mechanical stresses applied to the rails in each shot.

Note: the author of this TechNote has no special expertise or confidential knowledge of railgun design and has relied on public sources (e.g., Wikipedia, Popular Mechanics) for basic principles and parametrics. The objective of this example is not to design a practical weapons system, but to show how MBSE might be applied to the problem.

Modeling the RailGun Domain

The Concept of Operations phase of system development requires us to answer several questions:

  • What is the domain or System-of-Systems (SOS) in which the System-of-Interest (SOI), the railgun, operates?
  • How do we expect the users to interact with the SOI? What are the scenarios of operation?
  • What inputs, in terms of material, energy and information, does the SOI require to serve its purposes?

We will use SysML to hold this information. Its advantage relative to PowerPoint or Vizio is that the model we create becomes a solid foundation for the modeling of the SOI. Architectural frameworks such as UPDM or UAF would work equally well for this phase.

Figure 2 Railgun domain, MagicDraw block definition diagram

Figure 2 shows the composition of our railgun domain. It includes

  • Platform, the SoS that holds the railgun. It may be vehicle-, land- or ship-mounted, represented by specializations BattleTank, LandMount and Ship, and includes parts of type ControlStation, ProjectileStorage and AC_PowerSource (one prerequisite for railguns is a large electrical power source, especially if they are to fire at rapid intervals).
  • Railgun, the SOI. We will start modeling the internal structure of the SOI later, in Part 2.
  • Users, at minimum the Operator of the Railgun and the Platform Commander who directs its use. Note that the Operator’s use case is primarily concerned with firing the weapon at the target, the Platform Commander with maintaining and protecting the viability of the Platform.

Figure 3 Sequence diagram, Railgun Domain

We can use the behavior modeling capabilities of SysML to capture scenarios of operation. Figure 3 is a sequence diagram describing the firing operation as a series of transactions between the control station, the railgun and the projectile storage facility, all parts of the domain in Figure 2. One characteristic of railguns is that they require massive current (mega-amperes) for very short periods (milliseconds), which is supplied from an energy storage device such as a capacitor that is charged slowly from a continuous power source and discharged rapidly during firing. This charging-firing cycle must be accommodated in the scenario of operation.

Figure 4 State machine, Railgun

This same cycle is captured in a state machine diagram in Figure 4 for the Railgun block, including a Discharging state before the system can be shut down. Note that Figure 4 is a behavior of the SOI, while Figure 3 is a behavior of the domain. However, they are linked by the state invariant symbols on the Railgun lifeline in Figure 3, which show the Railgun state at different stages of the scenario of operation.

Figure 5 Railgun inputs, MagicDraw internal block diagram

Finally, we need to consider the inputs required by the Railgun. The SysML IBD (internal block diagram) in Figure 5 summarizes these at a very abstract level. The Railgun requires from its Platform:

  • Electrical Power (AC in our example)
  • Operating Commands (see the messages in Figure 3)
  • Guidance Information (the railgun may direct the projectile either by aiming a steerable rail mount or by guidance-in-flight by the projectile)
  • Projectile reloads.

Next Steps

In the second part of this blog series, we begin modeling the RailGun system itself. We start by building a system architecture in SysML, then use Syndeia to bring in model elements from external tools, including system requirements from Jama and geometric dimensions from NX for analysis and requirements verification, the topic of the final part of the series.

Related posts:
View full post