Relatie met NBility en registers

[TjeerdSNL]

Graag toelichten hoe je CIM positioneert tov Nbility. Mn:

• De bedrijfsobjecten uit het BOM, hoe relateren die aan de klassen/profielen?
• Aanvullend op NBility onderkennen we registers. Dit zijn (in DDD termen) domeinen. Hoe gaan we daarmee om in CIM gebaseerde profielen.
• De koppelingen (die de profielen implementeren) zijn onder verantwoordelijkheid van een business solution of waardestroom. Wat doet dit met de svope van een profiel?

[ritger-alliander]

1. Uitleg toegevoegd voor semantische interoperabiliteit onder hoofdstuk "Opzet"
2. Voor de CIM profielen worden CGMES en LTDS als basis genomen. Dit is een eigen indeling zoals door de Europese TSOs en Britse DSOs wordt gehanteerd. Vanuit het vastleggen van de profielen wordt via broader/narrow mapping een koppeling gemaakt met andere ontologiën
3. Het ontwerp doet (impliciet) de aanname dat één profiel één dataproduct wordt. Of dit zo ook geïmplementeerd wordt is een leertraject. Verwachting is dat de mensen die een koppeling bouwen zelf een kleiner technisch model zullen bouwen dan in een profiel op logisch niveau beschreven wordt. Concreet: een lijst van onderstations gebruikt de klasse cim:Substation en cim:VoltageLevel, maar niet de andere klassen uit het _Equipment_profiel. Eventueel kan er een apart datamodel gemaakt worden voor een dataproduct, gebaseerd op een profiel, maar dit is iets wat we tijdens de implementatie moeten leren. Voornamelijk om de administratieve overhead van informatiemodellering te beperken.