Are these duplicate classees a problem?

[bartkl]

select
    C.Object_ID as ClassID,
    C.Name as ClassName,
    C.Package_ID as PackageID,
    P.Name as PackageName
from t_object as C

inner join t_package as P
on C.Package_ID = P.Package_ID

where Object_Type = "Class"
and Object_ID in <OBJECT_IDS> -- list of object IDs

Results

IEC61968CIMVersion

Object IDs 1683, 1760, 2188

ClassID	ClassName	PackageID	PackageName
1683	IEC61968CIMVersion	100	DocIEC61968
1760	IEC61968CIMVersion	100	DocIEC61968
2188	IEC61968CIMVersion	127	IEC61968

Profile

Object IDs 846, 2856

ClassID	ClassName	PackageID	PackageName
846	Profile	54	GenericDataSet
2856	Profile	149	ExternalInputs

ResourceCertification

Object IDs 2645, 2797

ClassID	ClassName	PackageID	PackageName
2645	ResourceCertification	139	InfMarketOperations
2797	ResourceCertification	161	ReferenceData

TroubleReportingKind

Object IDs 1834, 2100

ClassID	ClassName	PackageID	PackageName
1834	TroubleReportingKind	87	Customers
2100	TroubleReportingKind	87	Customers

[tviegut]

@bartkl : can you provide the version of the CIM model you’re using? The name of the EA project file should be sufficient. That will help me evaluate what we are seeing.

[bartkl]

Hi Todd,

I've used this QEA project file: iec61970cim17v40_iec61968cim13v13b_iec62325cim03v17b_CIM100.1.1.1.qea

[admin-cimug]

@bartkl , below is the eval:

IEC61968CIMVersion

ClassID	ClassName	PackageID	PackageName	Comments
1683	IEC61968CIMVersion	100	DocIEC61968	Duplicate...the diagram should be referencing the one in the IEC61968 package. This shouldn't have been included in the release. The 61968 CIM MM should have caught this.
1760	IEC61968CIMVersion	100	DocIEC61968	Duplicate...I believe this is unused. This shouldn't have been included in the release. The 61968 CIM MM should have caught this.
2188	IEC61968CIMVersion	127	IEC61968	This one's legit.

A possible solution to the above is to exclude any/all `Doc` packages from the model. This are only utilized anyway for the purposes of generated the IEC 61968-11 (and potentially the IEC 61968-13) publication(s).*

Profile

ClassID	ClassName	PackageID	PackageName	Comments
846	Profile	54	GenericDataSet	The GenericDataSet package is in an Inf* package which is not normative CIM. These packages are 'working/sandbox copies'. Generally I would suggest excluding them from all vocabularies, etc. at this stage if we are planning to deal with normative CIM (which is my suggestion).
2856	Profile	149	ExternalInputs	This actually is normative CIM in the IEC62325(i.e. Markets) package. So it is currently the single "legally" named class. Profile is a very general term and if the one in the Inf* package were to be approved for normative inclusion in it would need to be evaluate and some type of agreement made on renaming it to eliminate duplication in alignment with Rule040 (or the other way around).

A possible solution to the above is to exclude any/all `Inf` packages from the model.*

ResourceCertification

ClassID	ClassName	PackageID	PackageName	Comments
2645	ResourceCertification	139	InfMarketOperations	Again this is in an Inf* package and therefore should be ignored as non-normative. The IEC 62365 CIM MM should be aware that the class is a duplicate and should be renamed if it becomes normative. In reviewing this it looks it is semantically overloaded and more work should be done on that side of things by the CIM MM for IEC 62365. It needs a unique name assigned to it.
2797	ResourceCertification	161	ReferenceData	This is a currently normative MarketOperations class.

TroubleReportingKind

Note below that the ClassID is not visible in EA from what I can tell. The EAID_* or GUID might be easier to identify the particular class. Thus, I can't tell which of the two is the duplicate without querying the DB for more info...

ClassID	ClassName	PackageID	PackageName	Comments
1834	TroubleReportingKind	87	Customers	This exists in the IEC61968 package but upon reviewing looks like it interestingly got duplicated and inlined in the definition of the Tariff class image below). Hmmm....
2100	TroubleReportingKind	87	Customers	Normative

[bartkl]

Thanks for the analysis and suggestions!

With regards to the TroubleReportKind duplicates, here's the full * selection from the t_object table:

Object_ID	Object_Type	Diagram_ID	Name	Alias	Author	Version	Note	Package_ID	Stereotype	NType	Complexity	Effort	Style	Backcolor	BorderStyle	BorderWidth	Fontcolor	Bordercolor	CreatedDate	ModifiedDate	Status	Abstract	Tagged	PDATA1	PDATA2	PDATA3	PDATA4	PDATA5	Concurrency	Visibility	Persistence	Cardinality	GenType	GenFile	Header1	Header2	Phase	Scope	GenOption	GenLinks	Classifier	ea_guid	ParentID	RunState	Classifier_guid	TPos	IsRoot	IsLeaf	IsSpec	IsActive	StateFlags	PackageFlags	Multiplicity	StyleEx	ActionFlags	EventFlags
1834	Class	0	TroubleReportingKind		T. Kostic	1.0	Kind of trouble reporting.	87	enumeration	0	1	0		-1	0	-1	-1	-1	2008-09-08 13:24:17	2022-04-24 12:59:37	Proposed	0	0		Java		0						Java				1.0	Public			0	{69FC5C51-2840-4e50-A456-690D9026C079}	1521			14	0	0	0	0
2100	Class	0	TroubleReportingKind		T. Kostic	1.0	Kind of trouble reporting.	87	enumeration	0	1	0		-1	0	-1	-1	-1	2022-05-14 17:56:44	2022-05-14 17:57:34	Proposed	0	0		Java		0						Java				1.0	Public			0	{CBCADF0E-A59B-4a75-B085-16E23F8D0229}	0			14	0	0	0	0

Note that the one with ID 1834 has a parent ID of 1521. Here's a dump of that object, which turns out to be the Tariff class.

Object_ID	Object_Type	Diagram_ID	Name	Alias	Author	Version	Note	Package_ID	Stereotype	NType	Complexity	Effort	Style	Backcolor	BorderStyle	BorderWidth	Fontcolor	Bordercolor	CreatedDate	ModifiedDate	Status	Abstract	Tagged	PDATA1	PDATA2	PDATA3	PDATA4	PDATA5	Concurrency	Visibility	Persistence	Cardinality	GenType	GenFile	Header1	Header2	Phase	Scope	GenOption	GenLinks	Classifier	ea_guid	ParentID	RunState	Classifier_guid	TPos	IsRoot	IsLeaf	IsSpec	IsActive	StateFlags	PackageFlags	Multiplicity	StyleEx	ActionFlags	EventFlags
1521	Class	0	Tariff			1.0	Document, approved by the responsible regulatory agency, listing the terms and conditions, including a schedule of prices, under which utility services will be provided. It has a unique number within the state or province. For rate schedules it is frequently allocated by the affiliated Public utilities commission (PUC).	87		0	1	0		-1	0	-1	-1	-1	2008-05-22 00:21:45	2020-03-05 13:58:23	Proposed	0	0				0											Public			0	{0BE74F01-4122-4e79-A801-A70BCEAE82B2}	0			13	0	0	0	0

[tviegut]

@bartkl , thanks for narrowing that down. I caught this exact type of scenario in the past that occurred by accident when a class was accidentally "dragged" into another class (but that wasn't caught at first). In those situations my guess is that the CIM MM didn't realize it happened or thought it got deleted and ended up creating a second instance - resulting in what we're seeing. Ironically, EA allows that to occur but I'm not exactly sure why. I know the EA has a heavy Model Driven Development philosophy in its approach. Perhaps from that standpoint EA would generate code (e.g. Java, C#, etc.) from the UML that would reflect such an embedded class or enumeration as an "inner class".

[bartkl]

Maybe interesting to try out that code generation and see what happens! Thanks for the elaboration.