Intercax
IntercaxIntroduction
In this series we have sought to demonstrate how Model-Based Systems Engineering (MBSE) could be applied to designing a railgun (Figure 1) which uses electromagnetic fields to accelerate and launch a projectile at very high velocities. In previous sections, we have described the fundamental physics, then applied the SysML modeling language and Intercax SysML-compatible software tools to
- Model the Concept of Operation
- Describe the architecture of the railgun and its larger domain
- Connect the architecture model to requirements repositories and CAD geometry, and
- Use SysML parametrics to build a mathematical model of the railgun.
Figure 1 Simplified physics of electromagnetic railgun
In this final section, we will execute the parametric analysis and examine an alternative approach to system analysis, using a specialized simulation tool linked to the architecture model through the Syndeia MBSE platform.
Executing the Railgun Analysis
Once the SysML parametric model is complete, we can create one or more instances of it and solve them using the Intercax parametric solver plug-ins, ParaMagic for MagicDraw and Melody for IBM Rational Rhapsody, with Mathematica or Player Pro as the math engine.
Figure 2 ParaMagic results, SysML Railgun parametric model
An example of one solution set is shown in Figure 2 in the ParaMagic “object-oriented” browser. At the top level, we have the three requirements verdicts, all of which are 0 (fail). Drilling down, we can see why:
- rechargeTime – 116.5 sec, which exceeds the 60 sec requirement
- projectileEnergy = 2.7 MJ, which is below the 5 MJ threshold, and
- exitVelocity = 2.3 km/sec, which is below the 3 km/sec threshold for a 1 kg projectile.
ParaMagic and Melody allow the system engineer to set up multi-variable trade studies to explore the design space. In Table 1, we vary two inputs, Beam Length and AC Power, and examine the effect on the performance vs. requirements. The ParaMagic and Melody tools read the inputs from the Excel spreadsheet and write back the results after solving. Beside each numerical result, there is a second column containing a 1 or 0 for the requirement verification, also written by the parametric solver, with Excel providing the red (fail) or white (pass) background using conditional formatting. As can be seen easily, only the last row meets all three requirements.
The extrinsic approach assumes that the analysis model is created and executed in an external tool such as Simulink or Modelica, but with the ability to ensure that the simulation model reflects accurately the system architecture model. This requires not only traceability between the models, or even the initial generation of the simulation model from the architecture model; it requires a mechanism that allows comparison and updating of the two models as the project moves forward.
Figure 3 Simulink model of ControlPoint_3Way
Figure 3 illustrates the initial generation of Simulink and Stateflow models from the sections of the SysML model shown in Part 3, Figure 2 and Part 1, Figure 4, respectively, using Syndeia. With respect to Simulink and the SysML internal block diagram, the common elements between models are blocks, ports and connectors. Syndeia is available to compare and update these model elements after the initial model transform connections. For Stateflow and SysML state machines, the common elements include states, transitions, and some behavior, event and pseudostate elements.
The common workflow is that the Simulink/Stateflow model “Skeleton” is generated from the SysML model by Syndeia, then the simulation specialist builds out the model with specialized code and model elements to carry out the desired simulation. Periodically, the SysML and simulation model structures are compared using Syndeia and updated, either by Syndeia or manually, to resolve any critical differences.
It is possible to use intrinsic and extrinsic analysis in a complementary fashion. As sophisticated extrinsic analysis models are created, they may be called from parametric constraints like those in Part 4, Figures 3 and 4, with the ParaMagic or Melody parametric plugin allocating both simple equations and function calls to the appropriate solver to complete the overall calculation.
Next Steps
We offer this example primarily to inspire ideas in systems engineers in weapons development and other defense domains looking to apply the principles of MBSE to their work. The combination of high-level architectural modeling in SysML with a variety of connections into the larger engineering model domain is a powerful combination for developing better systems faster, while maintaining traceability and accurate documentation.
Related posts:
- MBSE for Railgun Design | Part 1
- MBSE for Railgun Design | Part 2
- MBSE for Railgun Design | Part 3
- MBSE for Railgun Design | Part 4
- MBSE for Railgun Design | Part 5 (this post)
About Author
