Classes
The template for CR concerning Classes (Classification Classes, Aspects and Blocks)
NEW CC
NEW CC = A new CC shall be created.
Mandatory fields:
| CR type | NEW CC |
| id_class_non_existing | If creating a new CC, insert a unique ID, e.g. YOURNAME_NEW_CC_01 |
| class coded name | 8-digit ECLASS identifier |
| preferred name EN | Name of the new Class (See naming rules) |
| definition EN | Definition of the new Class (See naming rules) |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
NEW BL
NEW BL = A new BL shall be created.
Mandatory fields:
| CR type | NEW BL |
| id_class_non_existing | If creating a new BL, insert a unique ID, e.g. CR_NEW_BL_01 |
| class coded name | 8-digit ECLASS identifier |
| preferred name EN | Name of the new Class (See naming rules) |
| definition EN | Definition of the new Class (See naming rules) |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
NEW AS
NEW AS = A new AS shall be created.
Mandatory fields:
| CR type | NEW AS |
| id_class_non_existing | If creating a new AS, insert a unique ID, e.g. CR_NEW_AS_01 |
| class coded name | 8-digit ECLASS identifier |
| aspect type | aspect type of the new AS: SGT001 = identification (identification specific Aspect) SGT002 = submodel (AAS specific aspect for Application Class Asset) SGT003 = commercial (commercial specific Aspect) SGT004 = engineering (engineering specific Aspect) SGT005 = operating (operating specific Aspect) SGT006 = environmental (environmental specific Aspect) SGT007 = segment specific (segment specific Aspect) SGT008 = default (all other Aspect types do not fit) |
| preferred name EN | Name of the new AS (See naming rules) |
| definition EN | Definition of the new AS (See naming rules) |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
Note: If the segments SGT001 to SGT007 do not fit, please select SGT008.
EDIT CC
EDIT CC = changing an existing CC
To change the preferred name proceed as follows:
Fill in the field "preferred name EN" with the old preferred name you want to change. Then fill in the field "preferred name new EN" with your proposed change.
Mandatory fields:
| CR type | EDIT CC |
| id_class_existing | the 6-digit identifier of the existing CC |
| class coded name | 8-digit ECLASS identifier |
| preferred name EN | Current name of the CC |
| definition EN | Current Definition of the CC |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
EDIT BL / EDIT AS
EDIT BL or EDIT AS = changing an existing BL/AS
To change the preferred name proceed as follows:
Fill in the field "preferred name EN" with the old preferred name you want to change. Then fill in the field "preferred name new EN" with your proposed change.
Mandatory fields:
| CR type | EDIT CC |
| id_class_existing | the 6-digit identifier of the existing CC |
| preferred name EN | Current name of the CC |
| definition EN | Current Definition of the CC |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
MOVE CC
(only permitted before ALPHA phase!)
MOVE CC = A CC shall be moved, i.e. will get a new Class Coded Name
Mandatory fields:
| CR type | MOVE CC |
| id_class_existing | the 6-digit identifier of the existing CC |
| id_cc_target_non-existing | the CR ID or the id_class_non-existing with your proposed target CC |
| id_cc_target_existing | the 6-digit identifier of the target CC |
| previous coded name | the existing 8-digit ECLASS identifier |
| class coded name | your proposed new Class Coded Name (future release) |
| previous preferred name EN | Current name of the CC |
| preferred name EN | Your proposed new name of the CC |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
NOTE: This structural change is only allowed on the 4th level, i.e. only a Class on the 4th level can be moved to a different spot in the hierarchy on the 4th level. Thereby a predecessor-successor-relation is documented for product Classes (4th level). In case of a CC on the 2nd or 3rd level, the old CC has to be deleted (see DELETE CC) and a new CC has to be created (see NEW CC). The DELETE CC of a CC on 3rd or 2nd level is only possible, if all its subordinate (child-) CCs on the 4th level have been moved/joined/split and a successor-CC is thereby documented. NOTE: This requests changes only the CC’s coded name. The id_class_existing, the preferred name, definition and all its relations to Keywords and Properties stay the same. In case a CC is moved into another segment, the Aspect (segment-specific basic Properties) of the source segment will be replaced by the Aspect of the target segment.
SPLIT CC
(only permitted before ALPHA phase)
SPLIT CC = A CC shall be split into at least two Classes (existing or new Classes)
Mandatory fields:
| CR type | SPLIT CC |
| id_class_existing | the 6-digit identifier of the existing CC (to be split, source) |
| id_cc_target_non-existing | the CR ID or the id_class_non-existing with your proposed target CC |
| id_cc_target_existing | the 6-digit identifier of the target CC |
| previous coded name | the existing 8-digit ECLASS identifier |
| class coded name | your proposed new Class Coded Name (future release) |
| previous preferred name EN | Current name of the CC (to be split, source) |
| preferred name EN | Your proposed new name of the CC |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
NOTE: SPLIT CC does always have to include more than one line, i.e. there have to be at least two lines with the same previous coded name and two different (new) Class Coded Names. The original Class will be automatically deleted, as the content is represented in at least two other Classes. No separate CR DELETE CC has to be created by the requestor. NOTE: This structural change is only allowed for Source Classes and Target Classes on the 4th level, i.e. only a Class on the 4th level can be split only into Classes on the 4th level. Thereby a predecessor-successor-relation is documented for product Classes (4th level). NOTE: If a SPLIT CC is combined with NEW CC-changes, additional lines have to be filled out to create the new Classes in which the old Class will be split into.
Example screenshot:
The existing class AEI956 is splitted into the non-existing Classes CR_NEW_CC_001 (from import sheet) and 32129525 (CR ID from the CDP).
JOIN CC
(only valid for major release!)
JOIN CC = More than one existing CC shall be joined/merged in one new or existing CC
Mandatory fields:
| CR type | JOIN CC |
| id_class_existing | the 6-digit identifier of the existing CC (to be joined in the target) |
| id_cc_target_non-existing | the CR ID or the id_class_non-existing with your proposed target CC |
| id_cc_target_existing | the 6-digit identifier of the target CC |
| previous coded name | the existing 8-digit ECLASS identifier (to be joined, source) |
| class coded name | your proposed new Class Coded Name (future release) |
| previous preferred name EN | Current name of the CC |
| preferred name EN | Your proposed new name of the CC |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
NOTE: JOIN CC can be done into an existing CC or a new CC (as target class), in which at least one other CC is joined (Source Class). The Source Class(es) will be automatically deleted. NOTE: This structural change is only allowed for Source Classes and Target Classes on the 4th level, i.e. only Classes on the 4th level can be joined only on the 4th level. Thereby a predecessor-successor-relation is documented for product Classes (4th level). NOTE: A JOIN CC can be combined with a NEW CC-change as Target Class. I.e. in case of creating a new Class an additional line has to be filled out to create the new Class in which the existing Source Classes will be joined into.
Example screenshot: 19010201 shall be joined in new Class 19010204. Two lines have to be filled out: NEW CC 19010204 and JOIN CC 19010201 in 19010204. The CR for DELETE CC 19010201 will be done automatically in the name of the same requestor.
DELETE CC
(only valid for major release!)
DELETE CC = An existing CC shall be removed from the ECLASS Standard
Mandatory fields:
| CR type | DELETE CC |
| id_class_existing | the 6-digit identifier of the existing CC (to be deleted) |
| class coded name | 8-digit ECLASS identifier |
| preferred name EN | Name of the Class (to be deleted) |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |
NOTE: DELETE CC is only possible for CCs on 2nd and 3rd levels: if all subordinate (child-) CCs on 4th level have a successor by move/split/join and the Üarent Classes to be deleted are empty o For CCs on 4th level: in case of SPLIT CC or JOIN CC, the source CCs are automatically deleted. Thereby a predecessor-successor-relation is documented for Product Classes (4th level), the DELETE CC line does not have to be filled out, it would be a duplicate.
DELETE AS / DELETE BL
(only permitted before ALPHA release!)
DELETE CC = An existing AS or BL shall be removed from the ECLASS Standard
Mandatory fields:
| CR type | DELETE AS / DELETE BL |
| id_class_existing | the 6-digit identifier of the existing AS/BL (to be deleted) |
| preferred name EN | Name of the AS/BL (to be deleted) |
| CR Proposer | CDP user name |
| Reason for request | Your reason for the change |