About System-Item Scope

Process Planning is used for defining the system structure that realizes the scoped item. In that context, System-Item scope definition and assignment are required for system planning.

A System-Item scope can be defined for each system. It delimits a subset of the Manufacturing Assembly structure that can be accessed by the system.

A system comprises the operations and subsystems that correspond to the steps required to realize completely the assembly structure that is delimited by the scope.

Each operation contributes to the realization of one or more child items related to the item dedicated to the system.

In a first step, scopes can be defined by a system planning team-leader.

Then, the scopes can be assigned to system planners to help delimit their activity.

System-Item Scopes are managed in the Manage Scopes panel that lets you define, delete and reconnect scopes.

Scope status in indicated as follows in the panel:

• : the scope is OK.
• : the target of the scope is not loaded in the session.
• : the scope link is broken.

System-Item scope defines the set of items allowed to be assigned to operations of the system. Rule is as follow for an operation:

• It retrieves its first upper parent system holding a scope to an item.
• If this item is of every type but Installation and Transform:
  • All predecessors of this item are assignable to the operation, until a predecessor is scoped by another system or its attribute Planning Required=True.
    Note: This predecessor item is included in the list of items assignable to the operation.
• If this item is an Installation or a Transform:
  • It retrieves its first upper parent system holding a scope to an item, and also considers item of the Installation or Transform.
  • This input item and its predecessors are assignable to the operation until a sub-scope or the attribute Planning Required=True are found.
    Note: The input or predecessor item valid for the above condition is excluded from the list of items assignable to this operation.

This rule applies for the different ways to create assignments, that are Drag and Drop, Assignment Manager, and System Assignment Assistant.

When a System-Item scope is defined, a scope symbol appears on the system.

• When a System-Item scope is defined, a blue circle appears on the system node in the tree.
• If the scoped item is not loaded in the session, a blue semi-circle appears on the system node in the tree.

There is implicit propagation of System-Item scope on the child systems.

A scope defined on a parent system is implicitly applied to all its child systems as long as those systems do not own an explicitly defined scope.

In the example below, System.2 is a child system of System.1 where a scope on the Assemble A+B+C+D+E+F item was defined.

System.1 shares its scope with its child System.2 as long as no scope is defined for System.2. This means that the items included in System-Item scope could be assigned on operations of System.1 or on operations of System.2.

When a System-Item scope links a system and item, two distinct domains of visibility are determined. One domain is inside the scope, while the other is outside the scope.

In the figure below, a System-Item scope links the system System F to the item Assemble F. Two distinct domains of visibility are determined, which are delimited by System F and Assemble F.

The figure below represents the viewpoint from inside Scope F. Each inner item of Assemble F is seen by the child systems of System F.

For example, System G sees the items Assemble F, Assemble G and Provide G1.

However, item Assemble H cannot be seen by System F: it is outside the scope.

The figure below represents the viewpoint from outside Scope F.

Item Assemble F is seen as an output item: its inner items cannot be assigned from outside.

System J sees item Assemble F as an output item.

A consistency check is run to prevent you creating crossed scopes between systems and items. Sometimes a scoped item is not loaded in session (the status of the scope is Broken in the Manage Scopes panel). As a result, you are not allowed to create an additional scope with another item. You are unable to do the security check to ensure that the scopes are not crossing one another. To create this additional scope, you need to load the unloaded scoped item in the session.

A dedicated attribute on a Service Assembly allows a System-Service Item scope to be defined between the service item and a system that is not yet present in the session. In this case, a Loading operation is created and the service item is consumed. Later, if the service item is to be realized by a system, a real scope can be created and a General operation is created.

The Planning Required attribute in the Properties dialog box of a Service Assembly enables you to simulate the System-Service Item scope for this service item.

If the attribute on the Service Assembly is set to YES, this service item has, or will have, a scope with a system that is not in the session. This means that this service item can only be consumed and a Loading operation is created. If you want to realize the service item and create the General operation, you must create the scope with the system in the normal way.

If you create a scope between a service item and a system while the attribute is still set to YES, the attribute is ignored: the scope has priority over the attribute.

It is recommended that there is at least one scope between an ancestor service item and a system in some cases. Particularly, create a scope before using the Planning Required attribute on a child service item.

When a reference-reference System-Item scope exists, you can add a "contextual" scope to specify which system instance will realize a particular item instance.

A typical scenario of use: if there is a subassembly that is to be used multiple times in a car and reused in the corresponding item at different stations of a production line.

The contextual scope is an implement link from a system instance to an instance of the scoped reference item. Upper and lower scope links must exist, before creating a contextual scope.

Contextual scopes are created, reconnected, or deleted in the Manage Scopes panel.