Professional Documents
Culture Documents
Wonderware System
Platform Installation
Guide
1/8/16
All rights reserved. No part of this documentation shall be reproduced, stored in a retrieval system, or
transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without the
prior written permission of Schneider Electric Software, LLC. No copyright or patent liability is assumed
with respect to the use of the information contained herein. Although every precaution has been taken in
the preparation of this documentation, the publisher and the author assume no responsibility for errors or
omissions. Neither is any liability assumed for damages resulting from the use of the information
contained herein.
The information in this documentation is subject to change without notice and does not represent a
commitment on the part of Schneider Electric Software, LLC. The software described in this
documentation is furnished under a license agreement. This software may be used or copied only in
accordance with such license agreement.
ArchestrA, Avantis, DYNSIM, EYESIM, Foxboro, Foxboro Evo, I/A Series, InBatch, InduSoft, IntelaTrac,
InTouch, PIPEPHASE, PRO/II, PROVISION, ROMeo, Schneider Electric, SIM4ME, SimCentral, SimSci,
Skelta, SmartGlance, Spiral Software, VISUAL FLARE, WindowMaker, WindowViewer, and
Wonderware are trademarks of Schneider Electric SE, its subsidiaries, and affiliated companies. An
extensive listing of Schneider Electric Software, LLC trademarks can be found at:
http://software.schneider-electric.com/legal/trademarks/. All other brands may be trademarks of their
respective owners.
3
Contents
Index..................................................... 179
Chapter 1
Note: You should not install the Galaxy Repository on a computer that
is used as a domain controller or an Active Directory server.
SQL
Product Based Selection Required
Runtime Client No
Remote System Platform Development Client No
System Platform Development Client Yes
System Platform Development Client without GR No
node (customized installation)
Historian Server Node Yes
Historian Client Node No
Information Portal No
All-In-One-Node Yes
All-In-One-Node without GR node and Historian No
Server (customized installation)
InTouch Access Anywhere Secure Gateway No
Wonderware Information Server 2014 R2 No
Licensing No
Note: If you are installing a small system (less than 25000 I/O), you
can use SQL Server Express instead of a standard version of SQL
Server. You can elect to install SQL Server Express as part of the
Wonderware System Platform installation process; you do not have to
install it separately.
For example if you need to install InTouch® with the default options,
then select a product-based installation.
Note: The Application Server installation will add the necessary SQL
Server privileges for SQL Server. For more information, see "SQL
Server Rights Requirements" on page 35.
4 Select the check boxes to indicate which products or roles you want
to install, and then click Next. The verify selection dialog box
appears.
If you select InTouch features, you need to select a language for the
InTouch installation. The localized InTouch versions are supported
only in the paired operating system. For example, the German
version of the InTouch HMI is only supported on the German
operating system.
7 Click Next. The End User License Agreement dialog box appears.
Note: See the Wonderware System Platform Readme for the complete
list of supported SQL Server versions.
Note: You need to configure the products only if you have installed
Wonderware Historian Server or Wonderware Information Server.
To configure products
1 In the complete installation dialog box, click Configure. The
Configurator dialog box appears. The following example shows
configuration for the Historian Server.
2 On the left pane, select the component and configure the details on
the right pane.
3 Click Configure. After the installation is complete, the system may
prompt you to restart. You can restart now or later.
Note: The installed programs may not function properly until you
restart the system.
Note: If you recreate the user account using the Change Network
Account utility, the Microsoft Windows security component on the
computer can take several minutes to update this information on the
ArchestrA Galaxy Repository node. Until that occurs, the ArchestrA
component may not function properly. Restarting the Galaxy Repository
node updates this information immediately.
Modifying an Installation
You can change the Wonderware System Platform components
installed on your computer. You can add new components or remove
the existing ones. You can modify any component of Wonderware
System Platform.
You must have the installation DVD inserted in the DVD-ROM drive
before you can modify a program.
To modify an installation
1 Click the Add or Remove Programs (or Uninstall or Change a
Program) option in Windows Control Panel.
3 Click the Modify option, and then click Next. The list of
Wonderware System Platform components appears.
4 Select or clear the components that you want to add or remove, and
then click Next. The verify change dialog box appears.
5 Click Modify. The selected components are added or removed and
the complete modification dialog box appears.
6 Click Finish.
Repairing an Installation
You can repair the installation of any component of the Wonderware
System Platform. You can repair missing or corrupt files, registry keys
or shortcuts. You can also reset the registry key to the default value.
Note: You must insert the installer DVD in the DVD-ROM drive before
you can repair a program.
To repair an installation
1 Click the Uninstall or Change a Program option in Windows
Control Panel. The list of software installed on your computer
appears.
2 Select the Wonderware System Platform component that you want
to repair, and then click the Uninstall/Change button. The Modify
Repair or Remove Installation dialog box appears.
3 Click the Repair option, and then click Next. The Confirm Repair
dialog box appears.
4 Click Repair. The complete repair dialog box appears.
5 Click Finish.
3 Click the Remove option, and then click Next. The confirmation
dialog box appears.
4 Click Uninstall. The component is uninstalled and the complete
uninstallation dialog box appears.
5 Click Finish.
Note: You can only upgrade the products that are already installed,
and you will not be able to install additional products during the
upgrade process.
Chapter 2
Application Server
Requirements and
Prerequisites
4 In the list of protocol names to the right, select and open TCP/IP
Properties.
6 Change the TCP Port number from 1433 to the desired number.
7 Click OK or Apply to commit the changes.
8 Reboot the GR node.
Chapter 3
For specific versions of the Application Server that you can upgrade to
version 2014 R2 SP1, see the Wonderware System Platform Readme
file.
Important: Ensure that you have installed the latest patch for your
existing version, wherever possible, before upgrading to the latest
version. Also, only systems that meet the minimum system
requirements, including operating system and SQL Server version, can
be upgraded.
Note: As long as the operating system and SQL requirements are met,
upgrade is supported. During software installation, operating system
upgrade is not supported.
6 Click the prerequisite whose status is "Not Met", and then click
Install Prerequisites. The general system prerequisites are
installed.
7 Click Next. Follow the prompts to complete the upgrade.
Important: An IDE node that has been upgraded to 2014 R2 SP1 will
not be able to connect to a GR node that has not been upgraded.
Conversely, an IDE node that has not been upgraded cannot connect to
a GR node that has been upgraded.
1 Upload Changes
run-time made at
changes run-time
now stored
in the
database.
3 Reboot Software is
when now at v2
prompted and P0
engines are
running
off-scan.
5 Optional: InTouch
Open and ViewApps
migrate now at v2.
InTouch
ViewApps
8 Reboot E1b is
when patched to
prompted. v2 and is
running
off-scan.
11 Reboot E1 is
when patched to
prompted v2 and is
running
off-scan.
12 Cascade E1 is No down-
deploy P1 deployed as time for
part of P1 objects on
deployment. E1b as E1b
continues to
E1 starts as
run as
standby and
active.
fully syncs
with active
engine.
Chapter 4
Chapter 5
Historian Server
Requirements and
Recommendations
Server Requirements
The minimum hardware and software requirements for the
Wonderware Historian are based on the tag count and the anticipated
data throughput rate. These requirements are divided into four levels,
which are outlined in this section.
The recommended memory configuration for SQL Server (32-bit) is to
clamp memory consumption to 50 percent of the amount of physical
memory installed on the server or 512 MB, whichever is larger. For
SQL Server Standard and Enterprise editions (32-bit), the
recommended physical memory configuration is 1 GB. The
recommended Windows virtual memory setting is twice the amount of
physical RAM installed on the server. For installation requirements
for SQL Server versions, see the Microsoft documentation.
You need to ensure that the memory that SQL Server reserves for the
Wonderware Historian is adequate for the expected load. Based on
your particular environment, you may need to adjust the SQL Server
MemToLeave allocation. For more information on MemToLeave, see
the Microsoft documentation.
You can install the Wonderware Historian on operating systems that
have the User Account Control (UAC) turned on.
If you are running the Wonderware Historian on a virtual server, the
historian must have an adequate CPU, adequate network memory,
and disk I/O resources at all times. Overloading the virtual server
leads to unpredictable behavior.
Operating Systems
Disk Space
A Level 1 server can handle a load of about 5,000 tags. For example,
2,600 analogs, 2,200 discretes, 300 strings, and 20 non-I/O Server
(manual) tags.
When replicating to Wonderware Online, each Level 1 server can
support up to 15,000 tags and 5,000 values per second.
A Level 2 server can handle a load of about 100,000 tags, with 50%
analog, 45% discrete, and 5% string tags. The requirements are:
• Processor:
• Minimum: P4 3.0 GHz dual CPU
• Recommended: quad-core CPU
• RAM:
• Minimum: 4 GB
• Recommended: 8 GB
• 1 Gbps network interface card (NIC)
Level 3 Server - Hardware
A Level 3 server can handle a load of 150,000 tags, with 50% analog,
45% discrete, and 5% string tags. The requirements are:
• Processor:
• Minimum: P4 2.7 GHz Xeon quad CPU
• Recommended: dual processor, quad-core CPUs
• RAM:
• Minimum: 6 GB
• Recommended: 12 GB
• 1 Gbps network interface card
Level 4 Server - Hardware
A Level 4 server can handle a load of 2,000,000 tags, with 50% analog,
45% discrete, and 5% string tags. The requirements are:
• Processor:
• Recommended: two quad-core CPUs
• RAM:
• Minimum: 24 GB
• Recommended: 48GB
• 1 Gbps network interface card
A performance report for different historian systems is provided in
"System Sizing Examples" on page 88.
Note: Historical plant data is not stored in the database files. This
type of data is stored in special files called history blocks.
Analog - Integer 8 34
Analog - Floating Point 8 34
Analog - Double 12 38
Discrete 5 31
String 5+AvgStringLength (5+AvgStringLength)+26
Analog Summary 37 63
The storage size is used for estimating the space required for storage.
The network transmission size is used for calculating the network
bandwidth required between HCAL and the historian.
If you enable compression on the AppEngine from which events are
originating, then the network size is reduced by approximately 80%.
For alarms and events, the network transmission size assumes that
the average name length for each of the alarm properties is 20
characters.
The following table provides some sizing examples.
Discrete Tags 5
Analog Tags (4 byte data) 8
String Tags (32 byte string) 37
Analog Summary (4 byte analog) 37
State Summary for Analog (for 10 states) 28 * 10 = 280
State Summary for Discrete (for 2 states) 20 * 2 = 40
State Summary for String (10 states and 32 byte string) (1 + 32) * 10 = 330
Performance Considerations
For a complete Wonderware Historian system, the following
components put a demand on memory.
• Internal historian subsystems, such as the Configuration
Manager, data acquisition, and data storage
• The associated Microsoft SQL Server
• The operating system
• Client access (data retrieval), which includes caching
When determining the amount of memory to purchase, remember that
adding more memory is the cheapest and easiest thing that you can do
to improve performance. Increasing the amount of memory reduces the
amount the server has to use virtual memory, thus lowering the load
on the storage subsystem. Even if you have a large amount of memory,
additional memory is used as additional disk cache, speeding up disk
access and therefore file service. Also, processes needed by the server
become faster because they are memory-resident.
A major factor in system performance is the amount of plant data you
anticipate storing in the system, including considerations about how
often that data is stored and retrieved. In general, the more you store,
the more often you store it, and the more you retrieve it, the slower the
system. The major storage factors affecting the performance of the
system are:
• Effective analog flow rate (analog updates per second).
• Period of online data storage required.
• Effective discrete variable flow rate.
• Number of concurrent end users required.
Server Loading
When a user connects to the Wonderware Historian with a client,
configuration information is immediately requested from the
historian. This information includes the tags that the server stores,
their descriptions, engineering units, and other tag data. SQL Server
reads this information from the database (stored on disk) and places it
in memory.
As the user selects time periods to trend, the historian reads data from
files located on the disk and prepares the results of the client's data
request to be transmitted back to the client. The ability of the server to
quickly handle subsequent requests for data from the same client and
others is dependent on the server's ability to keep as much information
in memory without having to again access data from the disk.
As a higher load is placed for memory, a higher load is placed on the
disk I/O system as the server has to use disk caching and read from
the data files.
The following table summarizes the loading for various systems.
IDAS Performance
An IDAS can acquire an unlimited number of real-time data values,
from an unlimited number of I/O Servers, each with an unlimited
number of topics. However, IDASs are subject to the following
limitations.
• The maximum sustained data throughput for any single IDAS is
30,000 items per second for real-time data. For late or old data, the
maximum throughput is 9,000 items per second. The total
combined throughput (real-time data plus late or old data) cannot
exceed 30,000 items per second. For higher-volume applications,
you can set up multiple IDASs to serve a single storage subsystem.
• The size of any data value is limited to 64,000 bytes.
• The maximum number of tags supported by any single IDAS is
30,000.
Tiered Historians
If you are installing a tiered historian, tier-1 nodes use the same basic
configuration for the number and types of tags and data collection
rates.
The tier 1 configuration should be “delta” data collected and stored:
• 12,000 analog tags every 2 seconds
• 2,900 discrete tags every 2 seconds
• 100 32-character string tags every 30 seconds
For the analog and discrete tags, the averages and value state
aggregates are:
• 6000 tags with an hourly calculation performed at the top of each
hour
• 6000 tags with 1-minute calculations performed at the top of each
minute
plus
• 1500 tags replicated (not aggregated) in tier 2
• 1500 tags stored only in tier 1 (no aggregates or replication)
Networking Recommendations
The Wonderware Historian is a highly configurable package that can
be set up in many different ways depending on your needs.
The historian can use any protocol currently supported by Microsoft
SQL Server 2012. You can use the default Microsoft SQL Server 2012
protocol (named pipes) with TCP/IP. TCP/IP is required if SuiteLink™
is used.
Do not use the historian computer as a domain controller.
It is highly recommended that you run the historian on a dedicated
computer. For example, running the historian on a mail server or an
Internet server may impact performance.
Generally, it is recommended that you split the process and IS
networks to ensure that the process network does not become
overloaded. The following illustration shows one possible network
architecture where the historian is the link between the process
network and the business LAN/WAN:
Note: All tags to be stored in historian are on "advise" all the time.
This may cause heavy load conditions on the process network. Before
you install the historian, investigate the possible load impact of
installing the historian on your network.
Client Access
All clients should connect to the Wonderware Historian using the
default Microsoft SQL Server connection. Usually, this means using
the name of the computer on which the historian is running as the
server name when logging on.
To change the default network protocol used by Microsoft SQL Server
to something other than named pipes, configure the client network
access using the SQL Server Client Network Utility. For more
information, see your Microsoft SQL Server documentation.
Licensing
Use the Invensys License Manager to manage licenses and associated
feature lines.
The historian allows functionality based on the presence of a valid
license file and/or feature lines. The historian checks that:
• A valid license file exists at the expected location on disk.
• One or more feature lines relevant to the product is contained in
the license file. A feature line defines specific behavior that is
allowed for the product. Typically, feature lines are bundled
together according to predefined licensing schemes.
If a valid license file cannot be found, or if the file does not contain the
appropriate feature lines, the historian is considered to be unlicensed.
If unlicensed, the historian starts up and runs for an unlimited period
of time. Data is stored for all tags, but you can only retrieve, replicate,
or advise only those tags that are licensed.
The historian reads the license file and appropriately updates the
system behavior when:
• The historian starts.
• You commit changes to the system using the System Management
Console.
• You refresh the license information using the System Management
Console.
Unless noted, all aspects of historian licensing are dynamic. That is,
you can make licensing changes during run time, and the system runs
uninterrupted.
The following main feature lines are available:
• Historian_Tagcount Feature Line
• Historian_ServerOS Feature Line
The following optional feature lines are available:
If this license is locked to a hardware key and you have removed the
key from the historian computer, then the displayed values are limited
to the last seven days, while all rows corresponding to timestamps
prior to the last seven days are displayed with NULL values and a
QualityDetail of 33. If a lengthy retrieval operation is in progress, it is
allowed to be finished.
As soon as you reattach the hardware key, the historian reacquires the
license and switches back to licensed mode.
Note that the Historian_HistoryDuration feature line is used to
enforce some of other feature lines to be acquired all the time after
their successful acquisition after a startup or reconfiguration.
Tag Information
Tag count (total) = 5,187
Analog tags = 2,607
Discrete tags = 2,285
String tags = 295
Manual tags = 17
Update rate of +/- 5,000 updates/second
Remote IDAS
None.
Event Information
• 3 snapshot events, each having:
• 1 analog snapshot
• 1 discrete snapshot
• 1 string snapshot
• 2 summary events, each having:
• 1 AVG calculation (1 tag every 8 hours)
• 1 MAX calculation (1 tag every 8 hours)
• 1 MIN calculation (1 tag every 8 hours)
• 1 SUM calculation (1 tag every 8 hours)
• 1 SQL insert every 4 hours
• 2 SQL multi-point updates every hour
Query Load
For the following seven queries, each are occurring at different times
in the hour:
• 1 query (trend):
• live mode - 1 second update
• 1-hour duration
• 10 tags (7 analogs, 3 discretes)
• 1 query: 1-hour range / hour (1 tag)
• 4 queries: 15-minute range / hour (1 tag)
• 1 query: 24-hour report every 24 hours (25 to 30 tags)
Performance Results
Category Value
Tag Information
Tag count (total) = 63,000
Analog tags = 39,359
Discrete tags = 19,734
String tags = 295
Manual tags = 5,057
Update rate of +/- 30,000 updates/second
Remote IDAS
One remote IDAS:
• P4 1.7 GHz
• 1 GB RAM
• 34,000 tags via the remote IDAS and the rest via the local IDAS
Note: Because this configuration was used for performance and stress
testing, the remote IDAS tag count is more than the recommended
30,000 maximum.
Event Information
• 3 snapshot events, each having:
• 1 analog snapshot
• 1 discrete snapshot
• 1 string snapshot
• 2 summary events, each having:
• 1 AVG calculation (1 tag every 8 hours)
Query Load
For the following seven queries, each are occurring at different times
in the hour:
• 1 query (trend):
• live mode - 1 second update
• 1- hour duration
• 10 tags (7 analogs, 3 discretes)
• 1 query: 1-hour range / hour (1 tag)
• 4 queries: 15-minute range / hour (1 tag)
• 1 query: 24-hour report every 24 hours (25 to 30 tags)
Performance Results
Category Value
Tag Information
Tag count (total) = 133,941
Analog tags = 73,600
Discrete tags = 53,560
String tags = 6920
Update rate of +/- 50,000 updates/second
MDAS
In the total tag count, 4009 tags originated from Wonderware
Application Server.
Remote IDAS
Two remote IDASs:
• Remote IDAS 1: P4 1.9 GHz, 1 GB RAM
• Remote IDAS 2: P4 2.5 GHz, 512 MB RAM
44,370 tags via the remote IDAS 1
45,584 tags via the remote IDAS 2
44,383 tags via the local IDAS
Note: Because this configuration was used for performance and stress
testing, the remote IDAS tag counts are more than the recommended
30,000 maximum.
Event Information
• 3 snapshot events, each having:
• 1 analog snapshot
• 1 discrete snapshot
• 1 string snapshot
• 2 summary events, each having:
• 1 AVG calculation (1 tag every 8 hours)
• 1 MAX calculation (1 tag every 8 hours)
• 1 MIN calculation (1 tag every 8 hours)
• 1 SUM calculation (1 tag every 8 hours)
• 1 SQL insert every 4 hours
• 2 SQL multi-point updates:
• 1 every 15 minutes
• 1 every 30 minutes
Query Load
For the following seven queries, each are occurring at different times
in the hour:
• 1 query (trend):
• live mode - 1 second update
• 15-minute duration
• 15 tags (10 analogs, 5 discretes)
• 1 query: 1-hour range / hour (1 tag)
• 4 queries: 15-minute range / hour (1 tag)
• 1 query: 24-hour report every 24 hours (25 to 30 tags)
Performance Results
Category Value
Tag Information
Tag count (total) = 2,000,000
Analog tags = 1,000,000
Discrete tags = 900,000
String tags = 100,000
Update rate of +/- 150,000 updates/second
Query Load
The following query is occurring at different times in the hour:
• 1 query (trend):
• live mode - 1 second update
• 15-minute duration
• 500 tags (250 analogs, 225 discretes, 25 strings)
Performance Results
Category Value
The 400 Kbps data transfer limit reflects a typical data transfer speed
between remote locations over the Internet. The data transfer from
each tier-1 historian to a tier-2 historian is assumed to be through a
dedicated 400 Kbps connection; multiple tier-1 historians do not share
the same 400 Kbps connection. It is assumed that the 400 Kbps is a
bandwidth that can be fully used.
Loading Information
Assume that the total tag count on the tier-1 historian is 15,000.
The tier-1 historian receives 15,000 tags from I/O Servers of the
following types and data rates:
• 12,000 4-byte analog delta tags changing every 2 seconds: (10,000
always fitting the real-time window and 2,000 falling outside of the
real-time window being 50 minutes late).
• 2,800 1-byte discrete delta tags changing every 2 seconds
• 200 variable-length string delta tags of 32-character length
changing every 30-seconds
The tier-2 historian stores the following:
• 6,000 tags with hourly analog summary calculations performed at
the top of each hour (using 6,000 4-byte analog tags as tier-1 tags)
• Another 6,000 tags with 1-minute analog summary calculations
performed at the top of each minute (using 6,000 4-byte analog
tags as tier-1 tags)
• 1,500 tags replicated (as simple replication) to tier-2 (using 1,400
1-byte discrete tags and 100 variable-length string delta tags as
tier-1 tags)
• Another 1,500 tags only stored on tier-1 (using 1,400 1-byte
discrete tags and 100 variable-length string delta tags as tier-1
tags)
Category Value
Latency Results
Category Value
100-Base T
Tier-1 Historians
(standard configurations)
• 4 GB RAM
• Disk I/O subsystem of a 60MB/s throughput, 16 ms access time.
• 100/1000Base-T network card
Loading Information
Assume that the total tag count on the tier-1 historian is 15,000.
The tier-1 historian receives 15,000 tags from I/O Servers of the
following types and data rates:
• 12,000 4-byte analog delta tags changing every 2 seconds: (10,000
always fitting the real-time window and 2,000 falling outside of the
real-time window being 50 minutes late).
• 2,800 1-byte discrete delta tags changing every 2 seconds
• 200 variable-length string delta tags of 32-character length
changing every 30-seconds
The tier-2 historian stores the following:
• 6,000 tags with hourly analog summary calculations performed at
the top of each hour (using 6,000 4-byte analog tags as tier-1 tags)
• Another 6,000 tags with 1-minute analog summary calculations
performed at the top of each minute (using 6,000 4-byte analog
tags as tier-1 tags)
• 1,500 tags replicated (as simple replication) to tier-2 (using 1,400
1-byte discrete tags and 100 variable-length string delta tags as
tier-1 tags)
• Another 1,500 tags only stored on tier-1 (using 1,400 1-byte
discrete tags and 100 variable-length string delta tags as tier-1
tags)
Category Value
Latency Results
Category Value
Tier-2 Historian
56 Kbps
Tier-1 Historian
(modem configuration)
Loading Information
In the tier-1 historian modem configuration, the tier-1 historian
receives 3,000 tags from I/O Servers of the following types with
average update rate 300 items per second:
• 1,500 4-byte analog delta tags (1,400 always fitting the real-time
window and 100 falling outside of the real-time window being 50
minutes late)
• 1,350 1-byte discrete delta tags
• 150 variable-length string delta tags of 32 bytes each
Category Value
Latency Results
Category Value
Chapter 6
Feature Description
The Legend box shows the status indicators. The status indicators
are:
• Error - Indicates that an error occurred during
configuration.
Data Path
Click the ellipsis button to specify a different directory for the
historian history blocks.
Make sure that you have a sufficient amount of available space on
the drive you specify, because the plant data will be stored
primarily in the path you specify in the Data Path box, which is
used for history blocks. The SQL Server database files typically
take less disk space.
Existing Database Conflict
If the database is created for the first time, then this option is not
available. When re-configuration is done, then the Drop and
Create New Database option is available. If you select this check
box, then the existing database is dropped and a new database is
created. If this check box is cleared, then the database would not
be dropped, but will be configured for changes, if any.
4 In the Alarms & Events Storage area, configure how you want to
store alarm and events.
Important: If you want to later change this setting after the Historian
is running, you must first shut down and disable the historian using the
Management Console. After making the change, you can then restart
and enable the historian.
Traditional
By default, alarms and events are stored in the A2ALMDB SQL
Server database. This works well for smaller applications. Alarm
and event data stored in the A2ALMDB database can be retrieved
using SQL queries. You can also use SQL Server tools, such as
Reporting Services, to query alarm and event history.
High-speed
If you have larger storage needs for alarms and events, you can
select this option to store alarm and event data to the history
blocks. Storing alarms and events in history blocks provides the
following advantages:
• You can manage the data using simple operations such as
moving, copying, or deleting folders, instead of using database
management software.
• You no longer need to purge to sustain storage.
• Significantly higher storage rates are achieved.
• The capacity for alarm and event storage is only limited by disk
space, not by insertion rate.
If you select this option, you will not be able to query alarm and
event history from SQL queries, but alarm and event data stored
in history blocks can be retrieved using the Open Data Protocol
(OData), the ArchestrA AlarmClient control 2014 R2 or later, or
the Historian SDK 2014 R2 or later.
10 After the system finishes running the SQL scripts, the Historian
node and Historian Server node are shown with a green status
indicator if the database is successfully configured.
11 Click All Messages to see all the configuration messages.
12 Click Close to exit the Configurator.
Antivirus Software
After installing the Wonderware Historian, configure your antivirus
software to prevent archive files from being scanned. Also, antivirus
software should not scan files in certain folders. For a list of folder
exclusions, see the Wonderware System Platform Readme file.
If you are upgrading from Application Server 3.5 or earlier, you should
upgrade the Wonderware Historian server first if it is located on a
separate node or the AppEngines will remain in store-and-forward
mode after the Application Server upgrade until you upgrade the
Historian. If you do not upgrade Application Server to the latest
version, the Application Server engines will remain fully functional;
however, they will not be able to take advantage of any new historian
capabilities.
If you are upgrading from Wonderware System Platform 2014 and are
using the Wonderware Historian for alarm and events (instead of
Alarm DB Logger), then you should also upgrade the Historian server
first. Otherwise, the alarm and event history for an AppEngine
upgraded to 2014 R2 SP1 will be collected as store-and-forward data
until you upgrade the Historian server. Note that there are no such
limitations for process history when upgrading from ArchestrA System
Platform 2012 R2 or Wonderware System Platform 2014.
If you have been using replication, when upgrading historian nodes,
upgrade the tier-2 historian node first and then the tier-1 historian
node. A tier-1 node running Wonderware Historian 2014 R2 SP1
cannot replicate to a tier-2 node running Wonderware Historian 2014
or earlier.
Chapter 7
Historian Client
Requirements
Desktop Applications
The Wonderware Historian Client software includes the following
stand-alone applications:
Note: The SQL Server locale language must be the same as the
operating system locale language.
Chapter 8
Note: In some cases, depending upon the operating system and the
prerequisite, you may have to restart the system after the prerequisites
are installed. In such cases, the setup automatically continues after the
restart.
Chapter 9
Information Server
Requirements and
Recommendations
Software Requirements
You must install the following software on the web server computer
before installing Wonderware Information Server. For details
regarding the specific versions of required and supported software
prerequisites, see the Readme file.
• Microsoft Internet Information Services (IIS). For more
information, see "Guidelines for Installing IIS and ASP.NET" on
page 134.
• ASP.NET. For more information, see "Guidelines for Installing IIS
and ASP.NET" on page 134.
• Microsoft SQL Server. For more information, see "Guidelines for
Installing Microsoft SQL Server" on page 130. ArchestrA Reports
are not supported on SQL Server 2008 or SQL Server 2012 Express
Edition.
You may need to install the following additional software on the web
server computer depending on the Wonderware Information Server
features you install:
• To install the ArchestrA Reports feature, you must install and
configure Microsoft SQL Server Reporting Services on the same
node as Wonderware Information Server. For more information,
see "Guidelines for Installing Microsoft Reporting Services" on
page 140.
• To use ActiveFactory Reporting, you must install Microsoft Excel.
For all software, apply the latest patches.
In addition, client users must be members of the same Windows
domain, or a trusted domain, as the web server.
You must install an ArchestrA Bootstrap on the Wonderware
Information Server portal computer to support any process graphic
that uses an ArchestrA reference to get data.
• ASP.NET
• ISAPI Extensions
• ISAPI Filters
11 After you enable the required features, start the World Wide
Publishing service if you want to install the default configuration
of Reporting Services. Otherwise, the SQL Server Setup program
only installs Reporting Services and does not configure Reporting
Services.
2 In the Role Services section, click Add Role Services. The Add
Role Services wizard appears.
2 In the System Service section, make sure that the World Wide
Web Publishing Service is running.
5 Select the server on which you want to install these roles and
features and then click Next.
6 Select the Web Server (IIS) check box and expand the IIS role to
view the underlying role services.
13 After you enable the required features, start the World Wide
Publishing service if you want to install the default configuration
of Reporting Services. Otherwise, the SQL Server Setup program
only installs Reporting Services and does not configure Reporting
Services.
3 Make sure that the following components are configured with the
defaults and no errors occur:
• Service Account
• Web Service URL
• Database
• Report Manager URL
4 Click Exit.
Chapter 10
Information Server
Installation and
Configuration
Installable Features
You can select from the following features during the Wonderware
Information Server install:
• Information Server. Required. Consists of core Wonderware
Information Server system, which manages security, licensing,
data sources, process graphics, factory alarms, customizing the
portal, access panels, and Table Weaver contents.
• ActiveFactory Reporting. Allows you to generate reports from
published Historian Client workbooks and trends using data from
the Wonderware Historian.
• ArchestrA Reporting. Provides infrastructure and tools that
extend SQL Server Reporting Services to better support report
development and deployment.
• Sample Content. Includes sample configurations and reports to
show the system’s capabilities and accelerate application
development. The sample content includes a process graphics
demo, a SmartSymbol display, content unit samples, and
ArchestrA report samples. You must configure valid alarm and
Wonderware Historian data sources to use the sample content.
• Information Model. Required. Retrieves and relates data from
external systems. You can then use the OverView client to view
the data in a grid or trend format.
Installation Pre-Requisites
The installation program checks for the following basic system
pre-requisites:
• One of the required operating systems. For more information, see
the Readme file.
• IIS is installed. For more information, including which roles and
features are required for each supported operating system, see
"Guidelines for Installing IIS and ASP.NET" on page 134.
• Upgrade does not support Wonderware Information Server 4.0 SP1
and prior release versions.
All other product pre-requisites are part of configuration and are not
checked during the Wonderware Information Server install. For
example, the installation does not check for:
• Microsoft Excel, if you select the ActiveFactory Reporting Website
feature during installation.
• SQL Server Reporting Services, if you select the ArchestrA
Reporting feature during installation.
• Enables WebDAV.
3 In the Virtual Folder Name box, type the virtual folder name. The
virtual folder name is the address you enter in Internet Explorer to
access Wonderware Information Server. The virtual folder name is
not case-sensitive, can be any characters other than /,*,?, and \.
The maximum length is 240 characters. For example, if you
specified MyInfoServer, run-time users would type
http:\\<computername>\MyInfoServer to access Wonderware
Information Server.
4 In the Database Configuration area, specify the SQL Server host
on which you want to create the Wonderware Information Server
database that is used to store administration and configuration
information. Do the following:
a In the Server box, type the name of the SQL Server host.
If you are using a non-default instance of SQL Express, specify
the name in the following format:
<SQLServerName>\<InstanceName>
6 Select Identity.
7 Make sure The interactive user is selected.
8 Click Apply and then OK to accept the changes.
• Creates the ArchestrA Reports folder under the root of the SQL
Server Reporting Services web site.
• Deploys sample history and alarm reports.
Before you can use the Information Model, the configuration for the
model must be defined in the Model schema tables in the SuiteVoyager
database. An application developer must create the model. For more
information, see the Wonderware Information Model Configuration
Guide.
You can also populate the model tables by importing sample content.
The Information Model uses the ArchestrA Data Adapter service to get
data from the following sources:
• Wonderware Historian
• Microsoft SQL Server
• Oracle
• OSI PI OLE DB
• Text (CSV) files
An instance of a data adapter can be created for each external data
repository. A data adapter is a component that can communicate with
the particular type of data repository. When you configure a data
source, you must provide a user account that has security privileges to
access the data source.
If you want to connect to an OSIsoft PI Server (OLE DB), Oracle, or a
text file data repository, you must install connectivity software on the
Information Server portal node so that the ArchestrA Data Adapter
service can communicate with the data source. For the required
versions of the connectivity software, see the Wonderware System
Platform Readme file.
The data sources that are listed in the Data Sources window will
depend on what is defined in the model.
If no data sources are available, be sure that you have imported a
model and that the model includes data sources.
2 In the Data Sources window, select a data source. The connection
options that appear will vary depending on the data source
selected.
3 Configure the connection details and then click Apply.
The connection string resulting from the configuration is encrypted
and stored in the ModelStore.DataSourceAttributes table.
4 Click Close.
Appendix A
Note that the full filespec of the response file (filename plus location of
file) must be included. For example:
Running setup with the /MINGUI switch will cause setup to install
without any input from the end user, but it will display the progress of
the installation on screen.
Running setup with the /? switch will display the silent installation
command-line help.
A good approach for testing is to first run the setup.exe in GUI mode
on a typical computer and confirm that no incompatibities exist that
would stop the installation, then cancel and run by command line.
4 From the command line, type the install command and provide the
path and filename of the response file you want to use.
Example: D:\setup.exe /silent c:\Documents\DevNode.txt.
In this example, the setup.exe file is in the root directory of the
DVD, and the development node response file is on the local C:
drive in the specified directory.
5 Press Enter to start the specified installation.
Appendix B
CD-Application 250 MB
Server
• Bulk Import 11 MB
Utility
• External 0.2 MB
• Framework 355 MB
• Redist 50 MB
• UserDocs 29 MB
CD-Gateway 37 MB
CD-Historian 104 MB
CD-Historian 221 MB
Clients
CD-IntouchFrench 312 MB
CD-IntouchGerman 316 MB
CD-Intouch 330 MB
Japanese
CD-Intouch 314 MB
SChinese
CD-Language 102 MB
Assistant
CD-Licensing 18 MB
CD-Server 30 MB
CD-WIS 543 MB
External 4 MB
Important: You may be able to further reduce the size of the installation
source by removing the DOTNET folder (298 MB) from Redist. The DOTNET
folder contains two subfolders: 4.5.2 and 3.5SP1. The 4.5.2 subfolder can
be safely removed if .NET version 4.5.1 or higher is already installed on the
target system. .NET 3.5SP1 is required for SQL Server. Beginning with
Windows 8.1 and Windows Server 2012 R2, the required minimum versions
of the .NET framework are included as OS features. However, you may need
to enable .NET 3.5SP1 (or .NET 3.5.1) through the Windows Features
Control Panel.
• MDAC 5 MB
• MSI4.5 6 MB
• PreReqInstaller <0.01 MB
• Safenet 8 MB
• VC10SP1 18 MB
• VC90SP1 4 MB
• VC2012U4 13 MB
ResponseFiles <0.1 MB
Support 0.2 MB
UpgradeSupport 38 MB
Caution: .NET 3.5SP1 or .NET 3.5.1 is required for SQL Server and is
an operating system component. However, you may need to enable it
through the Windows Features Control Panel.
Note: If you are installing Historian and the CD-Intouch has been
deleted, you will not be able to purge the A2ALMDB alarm database and
an error will be generated (does not apply if you are using block-based
history). However, the installation will complete successfully.
Important: You must copy the entire DVD. The root directory from
the DVD and all files in it must be in place and completely intact.
2 Navigate to the location where you copied the DVD. Delete the
files, components and language folders that you do not need.
Now you are ready to install or upgrade the product(s) using either
of the methods described below.
Index
hardware requirements 45
ArchestrA Bootstrap 127
Numerics ArchestrA Change Network Account
16 Pen Trend 18 utility 26
ArchestrA reporting, configuring 156
A ArchestrA user account
A2ALMDB database requirements for use with Application
Server 14
disk space 70
updating with ArchestrA Change Network
aaAdministrators group 35 Account utility 26
aaConfigSQL 35 ASBService 35
aaGalaxyOwner user account 35 ASBSolution 35
acquisition ASP.NET
loading 77 installing 134
ActiveEvent
installing 105 B
ActiveFactory reporting, configuring 152 Bootstrap
ActiveX and .NET Controls upgrading 44
aaHistClientQuery 119 upgrading with Galaxy Repository 44
aaHistClientTrend 119 upgrading with IDE 44
alarm data source upgrading with IDE and Galaxy
defining 158 Repository 44
antivirus software 112 building block controls
Application Server aaHistClientTagPicker 119
ArchestrA user account requirements 14 aaHistClientTimeRangePicker 119
L O
LAN 79 operating system requirements 127
language packs 142, 165 operating system, upgrading 45
Legacy Mode 36 operating systems
legacy mode 35 licensing 83
legacy software 41 non-English 87
License Viewer 106 Oracle
licensing 55 Intelligence data adapters 160
about 81 OSI PI
feature lines Intelligence data adapters 160
data modification 85
history duration 85 P
operating system 83 performance 76
remote IDAS 84 examples 88
replication server 86 IDASs 78
tag count 82 physical memory 64
loading Port
Wonderware Historian 77 SQL Server 39
process graphics 125
M process network 79
Management Console 105 product license 32, 167
Manufacturing Execution Module 87 installing 167
memory products
requirements 64, 76 configuring 25
Microsoft Client Utilities 104 protocols 81
Microsoft SQL recommendations 79
Intelligence data adapters 160
Microsoft SQL Server R
installation 104 RAID 69
Microsoft Windows Server 2003 129 repair
Microsoft Windows Server 2008 129 installation 28
Microsoft Windows Server 2008 R2 130 repairing 122
modify Wonderware Historian 112