Final Issue: Model-based Development Requires the Ability to Expand, Shrink, and Share the Model
This series discusses JMAG's contributions to model-based development.
Issue 1 talks about the motivation behind developing "JMAG-RT" for control simulations, which have become a typical solution in model based development.
In issue 2, I explained how we are approaching the model based development that we have in mind for JMAG by presenting the new functions involved with JMAG's model base, which was released last summer.
Finally, in issue 3, I confirmed that multiphysics is also a solution for model based development and showed that improving the ability to share and distribute information is a necessary condition for CAE to participate in model based development.
This series has examined explanations of conventional model bases while also delving into what exactly model-based development is and what CAE technicians' tasks are. While at first I believed that I had a good understanding of MBD, over the course of this series I soon came to realize that I have much to learn. Though this means that I may have inconvenienced my readers, it provided me with a good chance to rethink model-based development. To finish this series, I would like to study model-based development by focusing on the keywords "zoom-in/zoom-out" and "circulation."
The model's role in a V-model development cycle V-model development cycle
People often pattern their development process after the V-model, using it when explaining model based development, in particular. It conveniently links each step of the development process ("Specification and requirement", "System design", "Subsystem design", "Part design ", "Prototype creation", "Unit evaluation", "Combined evaluation", "System evaluation", and "Comprehensive evaluation") in a workflow, expressing it in an easily understood manner by presenting the study and evaluation progress in a V shape.
The V-model starts with the part specifications and gets more and more detailed as the process moves along. First the prototype becomes more concrete as its trial parts and software become clearer, then it approaches completion thanks to evaluations and revisions, and finally the product comes to fruition when the scope of the evaluations broadens (fig.1).
Fig. 1 V-model development workflow
Divergence and convergence
Recently, however, I have begun to feel uncomfortable about this V-model development cycle. After giving it much thought, I have finally reached a conclusion as to the cause of this discomfort, and therefore would like to give a brief explanation. To put it simply, this V-model development cycle is drawn as a single line, while an actual system is composed of multiple subsystems, and each subsystem is an assemblage of a number of components, sub-assemblies, software, and controllers. The configuration starts from the system design and ends with the complete product, but it is not a single line. Instead, it begins to diverge from the first step, splitting into its greatest number of branches when creating a prototype, and beginning to converge up the ladder when evaluations start. I had thought that the old method was strange because no one had ever explained this to me (figures 2 and 3).
next
