Model Assistant represents a fundamentally new capability in CORE as we begin to branch into truly assisted engineering. The intent is to better highlight the power and integration of a true model-based approach while reducing some of the framework details required to successfully implement model-based systems engineering (MBSE). The initial capability provides a powerful foundation that we expect to build upon going forward.
The individual model assistant rules are enabled or disabled per-user via the Model Assistant item in the project explorer tree. By default, all options are enabled.
Over the last 21 years, we have focused attention on an underlying integrated model represented through multiple specialty representations. While the connection between diagrams within a domain (behavioral or physical) has been clear, the connection between the state, functional, and physical aspects has not. Ideally, much as one can pick up a cube and twist it to look at any face, we would be able to “pick up” the system model and rotate it to see any perspective.
Reducing the learning curve while reinforcing the connected nature of the underlying model, users can now open logical views on physical objects. This includes both state and behavioral representations. If the physical object has a root state, the state views transparently open on that root state. If the physical object has a root function, the behavioral views transparently opens on that root function. The net result is simplicity of operation (individuals often think of a system in terms of its components) with clear indication that logical and physical representations are two perspectives of a single system model.
To see this capability in action, import the Geospatial Library example and click through the Component class. For components with root states, you can see the state transition diagram (if you have CORE Spectrum). For components with root functions, you can see the many logical views. For components without a root function / state, you will receive an appropriate message when attempting to access a logical view.
With this option enabled, CORE automatically checks the completeness of an element every time the element is modified. Given the efficiency of the embedded framework, this check is virtually unnoticeable. Running the checks automatically ensures the diagnostics are always up to date. If your machine is overloaded or if you choose not to use the embedded diagnostics, this capability can be disabled. Consistency checks can always be run manually.
One condition of completeness is that each leaf-level function be uniquely allocated to a single component. With this option enabled, CORE will prompt when you attempt to allocate a function to multiple components. You will have the option of completing the multiple allocation, replacing the existing allocation with the new component, or canceling the action. This streamlines the allocation process while helping to maintain model completeness.
Root functions are an essential connector between logical and physical aspects of the model. To those who understand the methodology, their role is clear. To those learning, they are odd artifacts of the approach that muddy the system definition effort.
CORE (optionally) auto-creates a root function when you create a component. The function is named “_Perform ABC Functions” where ABC is the name of the component. This root function houses behavior decomposition for the component. After creation, this root function can be manipulated as desired – renamed, related, or even deleted. However, the up-front automation reduces the learning curve, largely moving this 'perspiration' step behind the scenes.
As models are progressively expanded to a greater level of detail, flow-down of conditions from the parent level of the model are important. With this option enabled, CORE automatically allocates child functions when they are inserted in the decomposition. You can change this allocation, but it provides an initial flow-down from the parent allocation to serve as a guide.
After the integrated behavior is completed at a layer, the behavior is allocated to components where component logic is developed. Previously, the allocation and behavior were disjoint steps, subject to cross-check via consistency scripts but without automated support.
CORE (optionally) auto-inserts a function into the root function decomposition when you allocate that function to the component. This only occurs if neither the function nor one of its ancestors is already on the root function decomposition. Again, this automation helps reinforce the alignment, integration, and synchronization of the models. It does not create the behavior structure, but it does ensure all necessary functions are present and considered.
Root states are an essential connector between state and physical aspects of the model. To those who understand the methodology, their role is clear. To those learning, they are odd artifacts of the approach that muddy the system definition effort.
CORE (optionally) auto-creates a root state when you create a component. The function is named “_Exhibit ABC States” where ABC is the name of the component. This root state houses state definition for the component. After creation, this root state can be manipulated as desired – renamed, related, or even deleted. However, the up-front automation reduces the learning curve, largely moving this “perspiration” step behind the scenes.
As models are progressively expanded to a greater level of detail, flow-down of conditions from the parent level of the model are important. With this option enabled, CORE automatically sets the exhibited by relation for the child states when they are inserted in the decomposition. You can change this inclusion, but it provides an initial flow-down from the parent allocation to serve as a guide.
After the integrated state decomposition is completed at a layer, the decomposition is related to components where component logic is developed. Previously, the state decomposition and relationship back to the component were disjoint steps, subject to cross-check via consistency scripts but without automated support.
CORE (optionally) auto-inserts a state into the root state decomposition when you set the exhibited by relationship to the component. This only occurs if neither the state nor one of its ancestors is already on the root state decomposition. This helps reinforce the alignment, integration, and synchronization of the models. It does not create the structure, but it does ensure all necessary states are present and considered.
A standard naming convention for interfaces, links, needlines, and transitions (elements that serve to connect two elements) is "Element Name 1 / Element Name 2" to reflect the names of the two connected elements. With this option enabled, CORE auto-generates and maintains the names for these connector elements. If a default element name is used (for example, Link_002 for a Link), CORE will automatically rename the element when the connector connects to two elements. It will revert to a default element name when the connection is broken. If a custom element name has been assigned, CORE will not rename the connector element.