Section 3 – ArchestrA System Management Console Interface 2-25

Section 3 – ArchestrA System Management Console Interface

Section Objective
Introduce and explain the ArchestrA System Management Console Interface Elements

This section introduces and explains the ArchestrA System Management Console (SMC) Interface
Elements.

The Historian leverages the functionality of the ArchestrA System Management Console (SMC) by
making all areas within the Historian available to the administrator.
ArchestrA System Management Console does not perform administrative functions, but hosts
tools that do. The primary type of tool you can add to a console is called a snap-in. Other items
that you can add include ActiveX controls, links to Web pages, folders, taskpad views, and tasks.
There are two general ways to use SMC:
z in user mode, working with existing MMC consoles to administer a system
z in author mode, creating new consoles or modifying existing MMC consoles

Wonderware System Platform Course - Part 2

2-26 Module 2 – Historian Configuration

The installation program of the Historian automatically creates a shortcut on the desktop:

a. Double-click the shortcut icon.

The ArchestrA System Management Console appears (see the following figure).
The ArchestrA System Management Console Tree View pane (left-side) is divided into two
main areas: The Management Console and the Configuration Editor. Other options that may
display are the Log viewer, Application Server managers, and so on.
z The Management Console: This area is where the server “housekeeping” takes place.
From this area, you can monitor all communications, add and delete servers and groups,
access History Block information.
z The Configuration Editor: This area is where tag import, I/O servers, IDAS, Storage
information, and the Public and Private Groups are administered.
The following figure shows the Status icon highlighted. The Historian has not yet been started.

Wonderware Training
 Section 3 – ArchestrA System Management Console Interface 2-27

Management Console
a. Within the console root, expand IndustrialSQL Server Historians, IndustrialSQL Server
Group and the Server icons.
b. Expand the Management Console icon.
c. Highlight the Status icon. Within the Item, Module and Time/Message panes, you should see
current information about your server status.
This pane includes all system information in real-time.
d. Highlight the License status line within the Item pane:

The status message should be Valid.

Note: If the License Status message is not Valid, the Historian will log only system tags. No
other tags will be logged.

Wonderware System Platform Course - Part 2

2-28 Module 2 – Historian Configuration

Configuration Editor
e. Expand the Configuration Editor icon.
f. Expand any of the main icons in the Tree View pane.
This area contains a browser-like display of all system information.

Wonderware Training
 Section 3 – ArchestrA System Management Console Interface 2-29

g. Expand the System Configuration folder and click the Parameters icon.
Storage and Headroom settings are configured from within this pane, and are discussed in
detail later in this manual.

h. Expand the Storage folder.

Wonderware System Platform Course - Part 2

2-30 Module 2 – Historian Configuration

Storage properties are stored within this folder.

Several different storage locations are available. Notice all four types have similar configurable
properties: Path, Deletion Threshold, Maximum size, and Age threshold.
Circular: Local storage location for historical data storage. When the free space on the disk
containing the circular storage location drops below a minimum threshold or the data is of a
specified age, the oldest data is deleted out of this storage location and replaced with new data.
Instead of data being deleted from the circular storage location, it can be moved into the alternate
storage location, if that location is defined.
Alternate: When circular data is scheduled for deletion, the storage subsystem will start moving
these history blocks to one or more alternate locations, if defined. Alternate storage locations are
numbered. A block of data moves sequentially through the alternate locations until it is finally
moved to the end of the last alternate location space, at which point the data is deleted from the
system.
Buffer: Used for temporary purposes, such as retrieval from a data archive. Data stored in the
buffer storage location can be accessed and viewed along with the data stored in the circular
storage location.
Permanent: Permanent storage locations are used to store critical data (for example, reactor
trips) that must not be overwritten. The storage subsystem will never attempt to delete data in this
location. Data in a permanent storage location can be accessed and viewed along with the data
stored in the circular storage location.

Wonderware Training
 Section 4 – System Configuration 2-31

Section 4 – System Configuration

Section Objectives
z Introduce and explain the Historian System Configuration
z Introduce Dynamic Configuration of the Historian parameters

This section introduces and explains the Historian System Configuration. It also introduces
Dynamic Configuration of the Historian parameters.

Overview
Configuration data is information about elements that make up the Historian system, such as tag
definitions, I/O Server definitions, storage locations for historical data files, and so on.
Configuration data is relatively static; that is, it is not constantly being changed as the result of
plant operation.
The configuration subsystem is responsible for handling and storing configuration data. When the
Historian is installed, all configuration information are defined automatically.
Configuration data is stored in Microsoft SQL Server tables within the Runtime database. If
InTouch is handling your I/O, you can easily import much of this information from existing InTouch
applications.
System Configuration for Manual Data is performed from within the ArchestrA System
Management Console’s Configuration Editor.
Bulk modifications and Historian system migrations can be performed using the Historian
Database Export/Import Utility.
The system can be configured at any time with no interruption in the acquisition, storage, and
retrieval of unaffected tags. Configuration data can be stored with a complete revision history.

Dynamic Configuration
The Historian supports dynamic configuration. In other words, tags and other objects in the
Historian database can be modified while the system is running.
The Historian detects and applies the modifications to its internal runtime state, when the
modifications are authorized by the user, without requiring the system to be restarted. In addition,
clients do not suffer interruptions due to configuration changes.
The dynamic configuration feature in the Historian caters for all possible database modifications
that affect the runtime operation of the system.
The dynamic configuration subsystem is designed to ensure that no loss of data occurs for tags
that are not affected by the modifications being applied. However, tags that require a change in
data acquisition configuration will obviously lose data during the reconfiguration.
For some types of configuration modifications, the system automatically creates a new history
block.
In all but one case, the system continues to run uninterrupted. The single exception that requires a
restart of the system is when you change the main historization path in the system, a parameter
that is rarely modified after installation.

Wonderware System Platform Course - Part 2

2-32 Module 2 – Historian Configuration

Dynamic configuration is usually a two-step process:

z First, you modify one or more objects in the database, using the ArchestrA System
Management Console, Transact-SQL statements, or the database modification tool of
your choice.
z Then, after making all of the modifications, you must commit the changes, which triggers
the dynamic configuration process in the server.

System Change Scenarios

Different types of dynamic changes to the database affect the system in different ways. A
summary of typical changes and their effect on the system follows.

Modifying System Parameters

Modification to system parameters usually takes effect immediately (a new history block is not
created).
Exceptions:
z Adding headroom for one or more tag types (requires a new history block).
z Changes to the AutoStart parameter (takes effect after the next full shutdown of the
system).

Modifying Storage Locations

Modifying the circular storage location requires a shutdown and restart of the Historian. Changes
to the other storage locations take effect immediately.

System Change Effects

Modifications to the tag database that changes the database footprint on the disk may result in
creation of a new history block.
If only data acquisition or retrieval characteristics of a tag are modified, the changes take effect
without requiring the system to create a new history block. Any change to the data source for the
tag (for example, modifying the item name, topic name or I/O Server name of the tag) results in a
short gap in data for the tag. This is because the system disconnects from the old data source and
connects to the new data source.

Adding, Deleting, and Modifying Tags

Adding one or more tags to the system generally results in creation of a new history block, unless
sufficient headroom is available for that particular tag type. In this case a new block is not required.
If the headroom is exceeded, a new block is created and the headroom is replenished to the
amount specified in the SystemParameter table.
Deleting one or more tags takes effect immediately.
Certain modifications to tags result in a new history block. Those modifications include:
z Changing the integer size.
z Changing the raw type.
z Changing strings tags from fixed length to variable length or vice-versa.
z Changing storage type from Not stored to Stored.

Wonderware Training
 Section 4 – System Configuration 2-33

z Changing a string tag from ASCII to Unicode or vice-versa,

z Changing tag acquisition type from IDAS to Manual or vice-versa.
Headroom capability enables the user to define "space" storage to be readily available to the
system. In other words, settings are changed in order to add a few tags fairly quickly and with
no wait or delay when creating a new history block.
For example, when importing tags, the system merely checks the number of new tags against
the amount of headroom available and on that basis decides whether a new history block will
be created after the commit operation.
At the start of each new history block, however, the system will replenish the amount of
headroom to the setting specified by the user. If the user specified headroom for 100 discrete
tags and imports an application with 40 discrete tags (nothing else), the import happens
without a new block being created, but the system consumes 40 of the discrete headroom
"slots."
For the remainder of the duration of that block, the headroom remains at 60. Assuming no new
discrete tags are added, at the next block changeover (whether it is a scheduled block
changeover, or a block forced by the user), the discrete headroom internally will reset to 100.
Headroom settings should not be used to keep space "just in case" 10,000 tags will be added.
Memory and hard disk space is impacted.
Tag count validation for licensing purposes does not apply to pre-allocated tag memory; the tag
count is verified only when the tag definitions are committed.

Committing Changes
Committing database changes is the action that makes the Historian aware of changes in the
Runtime database. When the user modifies the Runtime database (using the Configuration Editor,
Query Analyzer, etc.) while the Historian is running, Historian is unaware of the changes until the
user commits the changes.
When the commit operation occurs, the Historian reads the modified info from the database to
keep in memory, and reconfigures the runtime components like IDAS, storage etc.
Modifications made to the database are done in a transactional fashion.
You can commit changes to the configuration of the system as often as needed. You can also
commit changes in batches or individually. There is no limit on the number of changes that may be
committed to the database.
Committing configuration changes typically takes effect within 10 seconds under maximum data
throughput conditions.

Cases in Which Configuration Changes will NOT be Committed

If the system is not running, or storage has not been started, any commit will be ignored, and the
contents of the ConfigStatusPending table will be cleaned up.
When the system is running, a commit will be disallowed:
z While a previous dynamic configuration is still in progress.
z While a new history block creation is in progress (initiated as a scheduled block
changeover, a dynamic configuration, or a user request). A block is deemed in progress
for five minutes after it has been created, and also ten minutes prior to the next scheduled
block changeover.
For each case, a message is displayed indicating that the commit was disallowed.

Wonderware System Platform Course - Part 2

2-34 Module 2 – Historian Configuration

– Intentionally left blank –

Wonderware Training