Initialization of Modelspace

Initialization of Modelspace is the first step of the model build life cycle. It is assumed that the model is presently maintained in a foreign system, such as EMS. This step is used to initialize the Modelspace by importing a full model in CIM/XML exported from the system where the model is currently maintained.

What is a Modelspace?

A Modelspace is a self-contained data store residing in a relational database. It contains all the information related to an independent power system model, including base model, pending/submitted model changes, and model management information such as versions and their dependencies.

Four families of database tables together make a Modelspace. Each family has its unique prefix to differentiate it from other table families.

• Model management tables (prefixed with MM) are used to manage the evolution of models, such as Version table and ModelingSpace table.
• Base model tables (prefixed with FM) are used to store the full base model.
• Incremental model tables (prefixed with IM) are the storage places for submitted model changes.
• Pending change tables (prefixed with PC) are used to store pending model changes.

User can overwrite the default prefixes by making changes in data source configuration.

Auto-generated Table Schema

Modelspace schema is auto generated from the model governing profile, supporting any version of CIM, standard or extended. In most cases, a CIM class defined in the profile corresponds to a database table within one table family. The properties of the class define the table columns.

For example, a standard CIM class of “ACLineSegment” in profile auto generates schema for three tables, each for one table family:

Table names and column names follow naming conventions, with a prefix to CIM class name as table name, and attribute name as column name.

The imported CIM could be in any supported versions. The Tool will detect the governing profile and auto-generate the database schema during the Modelspace initialization. However if the imported model contains the CIM extensions, you must extend the governing profile by adding the corresponding extended classes or properties. Otherwise such information will be lost during the Modelspace initialization. The bottom line is any extended modeling entities must be explicitly specified in order to be editable and storable.

For extended CIM, namespace will be included in table name and column name.

Adding Alias to Resolve the Database Naming Restrictions

The Tool supports various relational databases, including Oracle, MSSQL, and MYSQL. Each database has its own naming restrictions as listed in the table below.

	MSSQL	MYSQL	Oracle
Maximum length of name	128 character	60 character	30 character
Common Keywords to avoid	Index, open	Index, maxvalue, minvalue	Mode, index, date

The auto-generated schema has to follow the naming restrictions, i.e. the table name and column name cannot exceed maximum length and names cannot be any of the database keywords.

Sometimes, CIM class and property do have long names. The table name or column name directly generated from the long name with added prefix and name space (in case of extended CIM) could easily exceed the maximum length limit. This happens mostly in Oracle, since Oracle has the smallest size limit. In that case, a popup message will be issued to report the problem. Similar popup will be displayed if keyword violation is detected.

Aliases were added to the profiles in the Tool as needed. Normally, users don’t need do this step. But if extended modeling entities are added and the names of the extended modeling entities violate the naming restrictions of the database, users need add the aliases to resolve the issues, as instructed below.

To resolve the naming restrictions, an alias must be added to the CIM class and property in the model governing profile.

• Add an alias at table level
• In model governing profile, locate the CIM class that violates name restriction.
• Add an annotation tag if it does not previously exist.
• Add an appinfo tag inside annotation. It should contain the following information:
• Source = “TableName”: this is a table name alias.
• dsmr:appliedTo=”ORACLE”: the alias is only applicable to Oracle database. Use “MYSQL” or “MSSQL” otherwise. If the alias should be applied to all RDBMS, there is no need to add this term.
• actual alias

With the added alias, the Tool translates CIM class “LoadResponsCharacteristic” to table names “FM_LoadResponseCharact”, “IM_LoadResponseCharact”, and “PC_LoadResponseCharact”.

• Add an alias at column level
• In model governing profile, locate the CIM class and property that violate name restriction.
• Add an annotation tag if it does not previously exist.
• Add an appinfo tag inside annotation. It should contain the following information:
• Source = “ColumnName”: this is a column name alias.
• dsmr:appliedTo=”ORACLE”: the alias is only applicable to Oracle database. Use “MYSQL” or “MSSQL” otherwise. If the alias should be applied to all RDBMS, there is no need to add this term.
• actual alias

With the added alias, the Tool translates the property “maximumAllowableSpinningReserve” of “GeneratingUnit” class to a column name “maxSpinningReserve” in “FM_GeneratingUnit”, “IM_GeneratingUnit” and “PC_Generating” tables.

Preparing for Modelspace Initialization

Modelspace resides in RDBMS. An empty database must be created to be the Model Database. This is usually done by the database administrator. After that, the data source configuration should be set up, most importantly, with the correct connection string to the Model Database. The “seed” base model must be loaded into the Tool and validated.

Initializing a Modelspace

Modelspace is typically initialized from a loaded and validated CIM/XML file. The behind-the-scene work involves database table clean up, auto-generate database schema, create database tables, and insert records into tables.

For user, it is a few simple mouse clicks.

1. Right-mouse click the tree item associated with the “seed” model that will be used to initialize Modelspace. Select Database->Initialize Database from the context menu.
2. A popup message will be displayed to remind user that any existing model in the database will be removed if choose to proceed. Select “OK” to continue database initialization, or “Cancel” to cancel the action.
3. Depending on data connection set up in configuration file, if more than one database connections are defined, user can choose from a drop down menu to select the database that will be initialized. If only one database connection is available, this database will be the default one to be initialized.
4. A popup box will be displayed informing user the initialization status. Depending on the initialization result, one of the following scenarios will occur:
5. Initialization is successful.

You can choose to load the saved model from database. After that, a new work space will be added to the tree.

• Errors are detected in database initialization. The Tool will display an event log similar to a model validation report. It is strongly recommended you review each reported error or inconsistency (warning) and correct the model as needed.

After viewing the errors, user can choose to ignore the errors and continue, or correct the error and retry.

When seeing the message, contact database administrator to check database setup or to verify whether the data source configuration, especially the connection string, is set correctly.

Modelspace after Initialization

Modelspace is displayed in the Model Manager tree panel, which can be enabled via global context menu, as illustrated below.

After Modelspace is successfully initialized, two versions are automatically added to the Modelspace.

• Base version: This is the foundation of all future versions. Base version will remain intact during the life cycle of the model.
• Draft version: The default editable version derived from the Base Version. Its named is auto-generated as “Draft_2(Base)”, where “2” means the 2^nd version in the Modelspace, and “(Base)” represents a child of Base version. Draft version conveniently provides user a starting point to begin modeling tasks.

Tables of all four families are created in Model Database.

• Model management tables:

One record of ModelingSpace is inserted into the table with model specific information, such as owner, create time, profile, base model file name, etc.

Two version records are added.

• Base model table: contents of the full models are stored in the Base model tables.
• Incremental model table: remains empty after initialization.
• Pending change table: remains empty after initialization.

Validating the Initialized Modelspace

After the database is initialized, users can Load a selected version of model into workspace, as illustrated below.

Same as other models in work space, a model from Modelspace can be loaded into the Tool and validated.

Model saved in Modelspace after initialization should be identical to the “seed” model. This can be verified by running a model comparison between them.

If the model is successfully saved into the database, comparison between the model loaded from the Modelspace and the seed model shouldn’t report any difference.

To avoid confusion, it is recommended to unload the “seed” model from the tree view after Modelspace initialization.

Next Step

Once the Modelspace is initialized, users can now maintain the stored model by loading it into the workspace.

Limitations

In this release, The Modelspace can only initialized with one full model. It is expected the Tool will be extended in the future release to host multiple related model in one Modelspace. For example, users can host one EQ (the static network model) and multiple SV (the solutions) in a single Modelspace.

Need help? Contact cimspy_help@power-gem.com