As described in the Concept, CIMverter utilizes CIM++ for deserialization of the CIM topology documents (e. g. power grids) for the generation of full system models based on the chosen Modelica library (e. g. ModPowerSystems). C++ was selected as programming language because of the CIM++ Deserializer, with its including CIM C++ codebase, as well as CTemplate, both written in C++. As a static, strong type-checking language with less Runtime Type Information (RTTI) capabilities than a dynamic language such as e. g. Python, speculative dynamic typecasts are used for a return of the correct CIM C++ class object. Anyway, the times for the conversion of CIM to Modelica models in comparison to the compile time of the generated Modelica models is negligible. The usage of C++ also allows to look up CIM details in the Doxygen documentation generated from the adapted CIM C++ codebase of CIM++.
CIMverter has a Command Line Interface (CLI) and follows the UNIX philosophy of writing one program for one task (McIlroy et al. 1978; Raymond 2003). Therefore, it can be simply integrated into a chain of tasks which need to be performed between the creation of a CIM topology and the simulations by a Modelica environment as realized in the SINERGIEN Co-Simulation project (Mirz et al. 2018).
A configuration file is handled with the aid of the libconfig++ library, where i. a. the default graphical extent of each Modelica component can be adjusted. It also allows the definition of default CIM datatype multipliers (e. g. M for MW in case of IEC61970::Base::Domain::ActivePower) which are not defined in some CIM RDF/XML documents such as the ones from NEPLAN based on the ENTSO-E profile, specified by (ENTSO-E 2018). After these implementation details, in following subsections the main aspects of the overall implementation are presented.
Mapping from CIM to Modelica
The mapping from CIM documents to Modelica system models can be divided in three levels of consideration as in (Cao et al. 2015).
At first level, there are the library mappings. The relevant data from CIM C++ objects, as deserialized by CIM++, is first stored in an intermediate object representation (i. e. in the Modelica Workshop) with a class structure similar to the one of the Modelica library. Hence, for each Modelica library there can be a set of appropriate C++ class definitions in the Modelica Workshop.
Object mappings are part of the second level. There are not just one-to-one mappings, es illustrated in Fig. 4. Sometimes, several CIM objects are mapped to one Modelica object resp. component, such as the IEC61970::Base::Wires::PowerTransformer. There are also CIM objects like IEC61970::Base::Core::Terminal (electrical connection points, linked to other CIM objects) which are not mapped to any Modelica component models.
Parameters and unit conversions are performed at the third level between the CIM C++ objects and the Modelica Workshop objects. Examples are voltages, coordinates, and so forth. The next section faces the second and third level mappings as part of the Modelica Workshop but before, the CIM object handling is explained.
CIM Object Handler
The CIMObjectHandler is in charge of the CIM objects handling. Figure 5 Listing 2 shows a part of its main routine ModelicaCodeGenerator. Topological nodes have a central role in CIM topologies of power grids. Therefore, finding a TopologicalNode (saved as tp_node), a busbar object of the Modelica Workshop class BusBar is initialized with it. busbar is needed later on, for the connections of all kind of conducting equipment (i. e. power grid components) that is connected to it.
Then, the inner loop iterates over all terminals of the found tp_node and checks which kind of ConductingEquipment is connected by the respective terminal to the tp_node. In case of a PowerTransformer, a trafo object of the Modelica Workshop class Transformer is initialized with the data from the PowerTransformerHandler. Furthermore, a new connection between the previously created busbar and the trafo is constructed and pushed on a queue of all connections. These steps are performed for all other kinds of components, which is why the ModelicaCodeGenerator calls handlers for all of them.
The tp_node with the terminal connected to the regarding component (here: trafo) are passed to the appropriate component handler (here: PowerTransformerHandler). Besides, the handler also gets the main template directory dict, called “MODELICA”. Within a handler, the conversions from the required CIM C++ object(s) to the Modelica Workshop object trafo are performed. Furthermore, a subdirectory (here called “TRANSFORMER” used for the Transformer subtemplate, see e. g. Fig. 8 Listing 4) is created and linked to the given main template directory (see Fig. 7 Listing 3).
Some conversions are related to the graphical representation of the CIM objects. This is because a graphical power grid editor, which can export CIM documents, can link a IEC61970::Base::DiagramLayout::DiagramObject to each component, with information about the position of this component, i. e. (x,y)-coordinates, in the coordinate system of the graphical editor. Since the coordinate system of the CIM exporting editor (e. g. NEPLAN) can differ from the one of the Modelica editor (e. g. OMEdit), the coordinates are converted by following code lines:
For reasons of flexibility, the four parameters trans_para can be set in the configuration file and in case of NEPLAN and OMEdit are defined by |1,0,-1,0|. Furthermore, the NEPLAN generated CIM documents have several DiagramObject instances linked to one component. To avoid multiple occurrences of the same component in the Modelica connections diagram, the middle point of these DiagramObject coordinates is calculated. This middle point then defines the component’s position in the Modelica connections diagram.
Another conversion must be performed for the instance names of Modelica classes which are derived from the name attribute of the CIM object and may not begin or contain certain characters. Each such object derives its name attribute from the elementary IEC61970::Base::Core::IdentifiedObject superclass. More on the electrics related conversion details will be given in the next section.