In the past, it was common to use parent-child structures. However, from today's perspective, most of these applications are no longer relevant. Due to developments in filtering, e.g. the ability to combine data based on k-fields etc., almost all previous use cases for parent-child structures - and their problems - have become obsolete. Using parent-child structures to map some sort of "test plan structure", as in Windows Explorer, is also considered bad form. This can all be done with queries and k-fields without using parent-child structures.
There is only one remaining use case for these structures:
Passing k-field information from a superordinate test plan (parent) to all subordinate test plans (children).
| Subordinate Test Plans (Parent-Child Structures) This document explains the purpose and use of parent-child structures. |
English:PDF | German:PDF |
Table of Contents
- 1 Applications for test plans with parent-child structures
1 Applications for test plans with parent-child structures
In the past, it was common to use parent-child structures. But from today's point of view, most of the applications are no longer relevant. Due to advances in filtering, e.g. the ability to combine data on the basis of K fields etc., almost all previous applications for parent-child structures and therefore their problems have become obsolete. Its also considered bad form to use parent-child structures to map some kind of "test plan structure" akin to Windows Explorer. This can all be done with queries and K fields, without resorting to parent-child structures.
But there is one remaining use for these structures:
Passing on K field information from a superordinate test plan to all subordinate test plans.
Heres an application scenario:
A test plan exists in the database.
It has 15 characteristics. However, the part is produced on 3 parallel lines and is also measured in parallel. If the first station has opened the test plan, each additional location can only load it in "read-only mode" and therefore cannot record any new measured values.
Therefore, a copy of the test plan is required for each line.
In principle, this can involve normal copies of the test plan, and
This would also be the preferred procedure.
However, if changes are to be made to the test plans in the foreseeable future, all the changes would have to be made separately for each test plan (new characteristics / adjustment of specification limits, etc.). This would be a reason to start a parent-child structure.
1.1 Creating subordinate test plans
When creating subordinate test plans, all the K fields included in the "Read from database" dialogue are displayed and can be modified. Therefore, it is advisable to display the later K fields, which are required for separation, directly.
If all subordinate test plans are identical copies of the superordinate test plan, the number of copies required can be selected directly. With the option "Copy all characteristics", each test plan becomes a copy (except for the changed K field):
However, another option would be to give each subordinate test plan certain characteristics only (e.g., where the identical part is measured at different stations). In this case, one subordinate test plan would have to be created at a time. With the option "Copy all characteristics" deselected, a dialogue appears for the selection of characteristics.
This would have to be done separately for each subordinate test plan to be created.
Warning: This procedure is not recommended. The last few remaining advantages of parent-child structures as described in the introduction would be lost here. If individual test plans have different characteristics, these should be created as "normal" test plans which can later be displayed and evaluated together using the option "group parts". Parent-child structures would offer no particular advantage here.
1.2 Allocating subordinate test plans
The options for allocating subordinate test plans will only be referred to briefly. They are described in detail in separate documentation.
Data recording stations that are to receive one of the subordinate test plans can work with preliminary filters in the "Read from database" dialogue:
Or with preliminary filters in the Part selection database dialogue:
In SPC test planning, test plans can be assigned to computers:
1.3 Changes to the main test plan and their inheritance
The main reason for using parent-child structures is the inheritance of changes.
The superordinate test plan is loaded using the specification limits of the first characteristic as an example. The specification limits 173.1 to 201.9 are changed to 172.5 to 202.8.
After saving and loading all subordinate test plans (reduced to this characteristic), it can be seen from the characteristics table that all K fields have been transferred.
1.3.1 Changes to fields in subordinate test plans
As an example, a specification limit was changed in the line 2 test plan:
Changes made to subordinate test plans are NOT transferred to the superordinate test plan and remain confined to the subordinate test plan.
If a change is subsequently made to the superordinate test plan,
the change made manually to the subordinate test plan is overwritten again!
The following general rule applies: When the main test plan is saved, all information is passed on to the "children".
1.3.1.1 K fields that are NOT inherited
Some K fields are excluded from this rule.
Examples:
The type of recording
Decimal places
Such fields are mostly test-plan-specific and must remain in place in each subordinate test plan.
1.3.2 Creating new characteristics in the superordinate test plan
In database options under File | Configuration | Databases | Options | Administration | Interactive saving, the following option is active by default:
If a new characteristic is added to the superordinate test plan,
It is also generated in all subordinate test plans.
1.4 Loading the structure for evaluation
Two options in the "Read from database" dialogue configuration have an impact on parent-child‑structures. File | Configuration | Databases | Options | User options | Load
If the filters would only find subordinate test plans, this option allows the superordinate test plan to be displayed as well:
In order to evaluate all the subordinate test plans together, the following option can be enabled in a test plan:
To illustrate this in more detail, the behaviour when reading from the database is shown, first without this option and then with this option enabled.
Without the option set
If a superordinate test plan is selected, only this plan is selected (and loaded as such).
If the superordinate test plan is selected again, all subordinate test plans are highlighted.
They are loaded separately:
With the option set:
All subordinate test plans are automatically highlighted. If the data is loaded in "read-only mode", this is also shown directly.
When loading, all the values of the subordinate test plans are combined into a single test plan.
Any measured values in the superordinate test plan are ignored!
1.5 Creating the structure manually
Its not usually necessary to create the structure manually when using a database. Sometimes, however, the customer "changes" databases. For example, a parent-child structure was created in a test phase using an Access database. The database is then changed to MS SQL. In the process, the test plans are saved as DFQ file (from the Access database) and manually saved to the SQL database.
Parent-child structures, however, exist solely at the database level. The information is therefore not transferred to the DFQ‑files.
This means that after the files have been saved to the new database, there is no longer a parent-child structure.
To re-create the structure, the following option can be used. The required superordinate test plan must be selected.
The following option can be selected with a right mouse click:
In the dialogue that appears, the number of K fields that are the same in all test plans (superordinate and subordinate) can be defined (if necessary).
The command is executed after the required subordinate test plans have been selected.
The structure is created after the dialogue is closed.
1.6 Copying parent-child structures
When a superordinate test plan is copied to the database, the option "also copy subordinate test plan" can be set:
The default change fields are only those of the superordinate test plan.
After copying, all test plans have the fields that have been changed. The fields with the different information in the subordinate test plans are also contained in the copies.
