About System-Process Scope

Manufacturing System Definition is used to define the system structure that realizes the product transformation or "process" defined in Process Definition. In that context, System-Process scope creation and assignment is necessary for system planning.

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

A system holds a set of operations and sub-systems that correspond to the steps necessary to realize completely the process structure that is delimited by the scope.

Each operation contributes to the realization of one or more child processes related to the process dedicated to the system.

Note: A "child" process is also the "predecessor" process of its father.

As a first step, scopes can be created by a system planning team leader.

Then, the scopes can be assigned to system planners to help delimit their activity. Each system planner then creates the work plan associated to system. The work plan is made of a set of operations that realize the processes visible in the scope of the system.

A System-Process scope is defined by an implement link between a system and an Assemble process.

The scope of the system groups all child/predecessor processes held by the Assemble process until a child Assemble process is found which defines another scope for another system.

This mechanism is repeated for all branches of the process structure held by the Assemble process implemented by the system.

When a System-Process scope is defined, the 3D representation of the process is displayed in transparency on the system tile.

When a System-Process scope is created and if the "scoped" process has a 3D representation, the 3D representation is displayed on the "scoped" system tile in the Live System Editor. The 3D representation is displayed in transparent mode.

If a sub-process is dragged and dropped onto a sub-system (to create operations, for example), the corresponding 3D representation of the sub-process is no longer displayed in transparent mode on the "scoped" system tile.

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

A scope defined on a father 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 Assemble A+B+C+D+E+F process 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 processes included in System-Process scope.1 could be assigned on operations of System.1 or on operations of System.2.

When a System-Process scope links a system and process, two distinct domains of visibility are determined: one is inside the scope, the other is outside the scope.

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

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

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

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

The figure below represents the "outside" Scope F viewpoint.

Outside the scope F, Assemble F is seen as an output process: its inner processes cannot be assigned from outside.

System J sees Assemble F as an output process.

A dedicated attribute on an Assemble process allows a System-Process scope to be defined between the process and a system that is not yet present in the session. A Loading operation is created in this case (the process is consumed). Later, if the process is to be realized, a real scope can be created and a General operation will be created.

An attribute Detailed by a dedicated system is available in the Properties dialog box of an Assemble process to allow the user to simulate the System-Process scope for this process.

If the attribute on the Assemble process is set to YES, this process has (or will have) a scope with a system which is not in the session. This means that this process can only be consumed (a Loading operation is created).

If the user really wants to realize the process (create the General operation), the user will have to really create the scope with the system in the normal way.

If the user creates a real scope between a process and a real system and the attribute is set to YES, the attribute is not taken in account (the real scope has priority over the attribute).

It is recommended that there is at least one real scope between an ancestor process with a real system before using the Detailed by a dedicated system attribute on a child process.