About Multi-Models

A session in which several root products can be realized by several root items is known as a Multi-Model session. In Process Planning, a single system can have scope links to one or more root items. Hence, a single system can be used to realize several different products.

This page discusses:

See Also
Activating Root Items
Managing Scopes with Multi-Models
Workload Balancing Using Multi-Models

Root Item Activation/De-activation

The Multi-Model concept means that several root products can be realized through several root items.

For example, the following tree is possible in a session:

Several root products are owned by the PPR in session and several root items can be owned, each one corresponding to a root product.

In the figure below, three products (Triangle, Cylinder, and Square) are associated with three root product contexts.

Each root product context is associated through an Item-Product scope with a root item (Root A, Root B, or Root C).

Each root item is associated through a System-Item scope with a system under a root system (System 1, System 2, or System 3).

The Cylinder product is associated with the Root B item and the Root B item is associated with System 2 as indicated by the scope icon on the tile.

Session States

The two possible states of a session with several root items loaded are as follows:

  • All root items are activated. In this case, when an operation implements items from these roots, the parts implemented by all the items are displayed in the System Editor and the buildup.
  • Only one root item is activated and other root items are deactivated. In this case, only the parts implemented by to that root's items are displayed in the System Editor and the buildup.

It is impossible to have two activated root items and a deactivated root item.

Root Item Activation

In Process Planning, when a root item is activated:

  • Parts implemented by its items are shown in the System Editor and the buildup.
  • Parts implemented by its items are listed in F5 list.

Root Item De-Activation

In Process Planning, when a root item is deactivated:

  • Parts implemented by its items are not shown in the System Editor and the buildup.
  • Parts implemented by its items are not listed in F5 list.

Visibility in System-Item Scope Links

When a scope is defined on a system, it gives the visibility of the item corresponding exclusively.

If other root items are to be visible for the system, it is required to add a scope to a convenient item.

For example, in the figure below, "Root Process B" is not visible from "System 2" since "Scope A2" excludes "Root B" from visibility.

If "System 2" is to be used for an item belonging to "Root Process B," another scope must be defined on "System 2."

In the figure, the scope would have to link "System 2" and "Assemble BB" since the scope to be created cannot cross "Scope B1."

It is not recommended to have such unbalanced scopes construction for this visibility reason, which could be difficult to manage.

It is recommended that a system has as many scopes as there are available root items.

It is also recommended to use one of the following strategies for creating scopes and assignments:

  • Define all scopes on all root items and then perform the assignments.
  • Define scopes and perform assignments root item by root item.

Concurrent Systems

Two systems are concurrent when they hold a scope relative to a same item.

In this case, both systems are able to realize the same items independently.

This means that an item already assigned by a system is seen as assignable for the concurrent system.

So if assignment of an item is performed on each concurrent system, it leads to a Multi-Model item.

In the figure below, "System 1" and "System 2" are concurrent: "Provide A" is assignable to both "Loading 1" and "Loading 2." The assignment on both operations leads to a Multi-Assigned "Provide A."