The concept of electromagnetic railguns has fascinated researchers in fields from defense weaponry to space launch. It also provides an interesting demonstration of the power of Model-Based Systems Engineering (MBSE). In Part 1 of this blog series, we described the basic physics of such a system and used SysML to model the overall concept of operations, including the larger domain in which the railgun operates, necessary inputs and outputs, and scenarios of operation. In this section, we will focus on modeling the railgun itself, using the Intercax MBSE interoperability platform, Syndeia, to build a distributed digital system model using SysML, CAD, and requirements tools.
Modeling the RailGun
Figure 1 Simplified physics of electromagnetic railgun
The design of a complex system is typically an iterative process connecting architecture, requirements, hardware and software. An effective MBSE approach recognizes and facilitates the interconnectedness of the process. In our example, we will use Syndeia to build and utilize a network of connections between our SysML model (in MagicDraw or Rhapsody), a requirements repository (Jama) and a CAD model (NX) to demonstrate the approach.
Figure 2 Jama requirements and SysML constraint blocks. Red lines represent Syndeia reference connections
We create and manage our master requirements list in Jama, but we want to link this with the other system design and analysis models that will be needed to verify the requirements. While there are a number of ways to accomplish this, we have chosen to construct constraint blocks in SysML that provide direct mathematical tests of some of the performance requirements and create Syndeia reference connections to the requirements in Jama (Figure 2). We will use these constraint blocks in the final section to build requirement verification into the parametric analysis.
For example, the Jama requirement “The projectile energy shall be greater than or equal to 5 MJ” in Figure 2 is connected to the SysML conditional constraint, “verdict = if(actual < 5, 0,1)”, which returns a binary result for verdict, 0 or fail if the actual energy is < 5 MJ, 1 or pass otherwise. The exit velocity requirement has a slightly more complex test, the conditional requiring that velocity 3 km/sec and mass = 1 kg.
A reference connection in Syndeia does not share or duplicate data between the two model elements. Even if it did, the ability to parse a text requirement in terms of its parametric constraints and parameters is not standardized in SysML. However, when the requirement repository is version-managed, as in Jama or DOORS NG, Syndeia can detect a new version across the reference connection, enabling the SysML modeler to find changes, access the new version and manually update the constraint.
Figure 3 RailGun decomposition, SysML block definition diagram
As requirements are developed, we can begin to build the railgun system architecture in SysML. In Figure 3, we have decomposed the railgun into electrical power, rail and projectile subsystems.
The power subsystem is further decomposed into the
- AC_DC_Converter, which converts the continuous AC input into DC to charge the
- Capacitor, which stores the energy until discharged into the rail system through the
RailSystem at this stage consists only of the two rails and the armature. We have used a reference property for the armature, which is also part of the projectile subsystem.
In future parts of this blog series, we will complete architectural modeling and carry out analysis of the RailGun system. We will examine both intrinsic (constraints inside the SysML model) and extrinsic (external to the SysML model) modes of analysis and the use of external solvers, Mathematica and Simulink, to execute the analyses. The combination of these tools with system requirements from Jama and geometric dimensions from NX demonstrate the power of distributed digital total system model managed by Syndeia.