Introduction

The wizard, when running, makes the "explosion,” i.e., places data in the tables mentioned with the records appropriate to the specifications made.
Each customer or user may have databases with default prototypes appropriate to their needs and culture. To create these bases, the user must:

• Define the Templates of all bays using the naming rule and alarms of the user's installation;

• Define the behavior of generating alarms and events and choose the Alarm Groups that will be used in the project;

• Define the tables for the Historian, i.e., the Historian Tables.

Alarms

The Deploy Automatic Database Generation extension already defines a set of prototypes for group alarms. Of these names, one must choose those that meet customers' requirements. Probably, of the terms below, each client will use about a dozen.
Group Alarms already available are listed below. The identification of each AlarmGroup is relatively intuitive as to its functionality. When you run Deploy first, these groups are created, and if there is doubt about the functionality, one can better understand by looking at the complete set of fields in the registry.

Use Change condition
EVENTOS_BIP, EVENTOS_NOBIP
Use HI condition
HI_ACK_BIP, HI_ACK_NOBIP, HI_NOACK_BIP, HI_NOACK_NOBIP
Use HIHI condition
HIHI_ACK_BIP, HIHI_ACK_NOBIP, HIHI_NOACK_BIP, HIHI_NOACK_NOBIP
Use lo condition
LO_ACK_BIP, LO_ACK_NOBIP, LO_NOACK_BIP, LO_NOACK_NOBIP
Use LOLO condition
LOLO_ACK_BIP, LOLO_ACK_NOBIP, LOLO_NOACK_BIP, LOLO_NOACK_NOBIP
Use condition Equal or NotEqual
ACK_BIP ACK_NOBIP, NOACK_BIP, NOACK_NOBIP, NOMSG_BIP, NOMSG_NOBIP

Note: To choose Equal or NotEqual, specify along with the state (threshold) in comments.

Open

For each group alarm used in the Application, a category
corresponding with the prefix: ALARMGROUP_ followed by the name of the group alarm.
Example: ALARMGROUP_NOMSG_NOBIP

Open

See in the figure above (Run>Ditionaries) the categories created for AlarmGroups and also for Nodes (in Devices) and historian tables.
If alarm items records for each tag are created, it will be sufficient that in the tag record, in the case in its definition templates, this applies to the category.
Applying a category to an object is used in a hereditary way: that is, if it is applied to a hierarchically higher object, for example, in the template of a TRAFO, all tags defined in this template will also have the same category. The categories assigned directly in the tags (sheets) are also considered cumulatively. In other words, the tag (lowest-level object, or sheet) has set itself all categories (one OR of them) assigned to the top-level objects.

Points on Devices

It would help if you manually created the channels and Nodes according to the characteristics of the protocols used in the application. This parameterization should be done according to the IEDs the project will communicate.
For each existing node for which you want to do the automated generation of records in the POINTS table, the user must define a category with the prefix NODE_ followed by the node name. For example, for the nodes defined in the figures below (Edit>Devices), categories should be created:

• NODE_IEC8705104A and NODE_DNPSEL_MA

These categories should be assigned to all point tags handled by these communication nodes.
Typically, when you have templates that define higher-level objects, such as a Feeder, or a Trafo, where all monitored and controlled points come through a single communication node, assigning the node category to these objects makes the task much easier accessible.

Historic

You must create Categories for all historian tables necessary for the implementation. For example, you can reference three historian tables as follows:

• H1M - Saves records every minute;

• H5M - Saves records every five minutes;

• HVA - Saves records whenever the variable has its value changed;

For each historian table referenced, you should create a corresponding category with the prefix HIST_ the name of the historian table. In the HIST_H1M, HIST_H5M and HIST_HVA.
How many historian tables are necessary, without naming restrictions, and with any rescue parameterization, but there must be a category HIST_ + name of the historian table.
In the figure below (EDIT > TAGS) tables ANA and DIG were created. The categories to be made by the user must be HIST_ANA and HIST_DIG.
If you prefer the, user makes the reference and, the tables are automatically created by the application Deploy.
For each of the tags, you want to have your values and states written in each of these history tables, you must apply the Categories Corresponding. Again, remember that the work will be simplified if you apply the categories to higher-level objects. This facility will result directly from how the templates are structured in modeling the real objects.

Category Assignment

As shown above, alarm groups, templates, channels, nodes, historian tables, dictionaries (Localization, enumeration and categories) and the Symbol Library associated with user culture will be pre-created in the standard client project.
In the process of creating the records in the tables, they must be assigned to the tags in the tables objects and templates the categories for each of these tables.
Once the category assignments are made, the creation of the records in the tables is guaranteed, but the records will be created with some important fields left blank to be filled in later.
Additional ease available in the app Deploy, and ́ the possibility of specifying in advance the contents for the most used and important attributes of these records. This is done by using the comments , available in the objects and templates. In these columns, for each tag, you can specify through a text with keywords the contents to be used in the generation of records. See in "Additional attributes", details about this procedure.
The desired predefined categories must be assigned to tags (sheets) in the various templates, as shown in the figure below. Note that the categories enforced for higher-level objects defined with User Types (Templates) are inherited by the lower levels in the instantiated objects.
See the figure below how to enforce a category on an object. Click on the column Categories in (Edit>Tags>Objects), and the list of existing categories appears. You can choose one or more for the same object by clicking on the boxes to the left of each category. In the column Categories, the text is with the set of names of Categories separated by point and commin.

Here are the following examples:

1. In the figure above, the category NODE_IEC8705104A category defines the node of communication with the circuit is chosen for object A1 (feeder of type SEL_351A). In this template (type) are defined all the measurement tags and status that you want to read in this IED.

2. If the AMP tag of a BAY template needs to create a LO-type AlarmItem that requires recognition and beeps, this tag must have associated the ALARMGROUP_LO_ACK_BIP;

3. If for the same tag you want your values to be saved in the history in table H2, you must also have the HIST_H2;

4. If this tag has an address in the field and belongs to a DNP1 name, it must also have the NODE_DNP1

5. Each of the categories of different assigned types will be used by the Base Automatic Generation application, for the selection of tags that will be used in creating matching records in the respective tables.

Once all the templates are created, the categorizations of the tags of each template are categorized, filled in the desired comments fields, the next step will be to create an object to instantiate the desired template. Example: To create a trafo 1 from a TRAFO name template:

Type=TRAFO
Level must also be filled in.

1. If deemed appropriate, other Categories and set comments to these higher-level objects. At these higher levels it is convenient to assign categories of the type of communication NODes.

Additional attributes

For the specification of previously defined contents, to be used in the important attributes existing in the records to be created in the tables by the Deploy, is available the ease of use of the fields comment in the tables objects and templates.
For each attribute considered, in each of the tables, key words were created, which are mostly the names of the columns themselves. In each tag, or top-level object, you can type in the comments, texts formed with these key words and the contents you want. The app Deploy will use these contents in generating the related records in the AlarmItems, Points and Historian.
The figure below shows the use of the comments in a template. The following items present the attributes (columns) considered, the key words for each table, and a brief description of usage.

Alarm Items

The following table shows the key words of the columns used.

Example:

In the field comment of the A2 tag. KV. C would have been placed

Priority=1;LO=12; Alm_DeadBand=1.5

In the field comment of the A2 tag. KV.B. would have been placed

Priority=1;HI=20.5;LO=12

See the figure below for columns filled with these key words:

See the figure below examples of AlarmItems generated using the keys BIT and MSG.

Points

The following table shows the key words of the columns used.

Examples:

• In the field comment object A2. AMP (which has a Phases subtype) would have been placed

ADDRESS=A1:201; ACCESSTYPE=Read; SCALING=Equation;Div=100

• In the following example, the Address and Node Name Prefixes were used on objects that instantiate templates. See the comment field, see that if you need a tab like the underscore or point, they should be specified in the comment.

• See how it turned out after the generation in POINTS. (AddressPrefix). In the case of IEC61850, the logical device name would be SE12M1.

• In this template ALIM_DISJ had tags for reading by IEC 61850 protocol. The addresses placed on the tags were without the Lodical device, which was used with NodePrefix.

• And then the Points with the prefixing of the nodes ( NodePrefix):

Historian tables

The following table shows the key words of the columns used.

Example

In the field comment tr1 object would have been placed
HIST_DEADBAND=2.5;DEVIATION=3.5

Running Deploy

To automatically generate the project (explode), the Deploy extension must be run that will search for all objects that have not been created and create them.

Go to Run>Extensions

• Choose the symbol Deploy;

• When calling this extension a window appears for the execution tracking.

• You can choose by marking in the comics what types of tasks you want to perform in this call.

• Click the button Create, and track the creation of each of the tables and their records being executed. In the text box inside the window will appear each of the items being created, so that you can check the progress of the execution.

Checking whether or not the object has been created is done automatically by the Deploy that checks whether an element with the same name already exists and, if positive, does not recreate it a second time.
The records will be created for the following tables:

• Tags/Historian

• Device/Points

• Alarm/Items

Observations:

1. In devices / points are created all inputs and outputs associated with the nodes. You must complete the table with the addresses and AccessTypes. Export from ActionNET to a spreadsheet, copy the addresses of an Excel spreadsheet of addresses made by the client, and import it back into ActionNET.

2. In the Alarms table and in the definition of templates the names and acronyms are very important because they are part of the client culture. Limits for HI, LO, HIHI, and LOLO alarms must be placed on items manually.

3. If for some reason you want to recreate the Historian table, you must remove all items already created and, in the project directory, remove the file with the name of the same project and suffix _DeployHistorian_HandledTags.xml sorry.