SUMMARY

Cross-node encrypted SuiteLink requires both nodes to be joined to the same System Management Server (SMS) server. In some cases, even if SMS is properly configured, a system may encounter the following error and the encrypted SuiteLink connection will fail, even though a Troubleshooting Scan within the AVEVA Common Service Portal may return without errors:
[Multi-Line Message] - Encrypted SuiteLink connection cannot be established.
Problem: SuiteLink connection request was received from un-authorized node <CLIENTNODENAME>.
Possible Reason: Security configuration on node <CLIENTNODENAME> is incorrect.
Possible Solution(s):
1. Ensure the node designated to be the 'System Management Server' is available.
2. ***[IMPORTANT]*** Ensure your applications are using the same 'System Management Server'.
3. For each node, launch the Configurator Utility -> Select the Management Server -> Press Configure -> Verify that the workflow configured successfully (Green configured Icon)
4. For additional details, refer to the 'Security Configuration' section in the product documentation.

CAUSE

This issue can be caused by the suggested problems in the error itself; however, in this case, if the computer name contains lowercase characters, the above error and symptoms may be encountered.

In Platform Common Services (PCS) 7.0.1, the current implementation assumes the following:

1. Letters in the Windows hostname (or Computer Name, or NetBIOS name) must be all capital letters (numbers are permitted)
2. The hostname part of the FQDN (Fully Qualified Domain Name) must be the same as the short hostname

APPLIES TO

• Platform Common Services (PCS) v7.0.1
• Communication Drivers Pack (CDP) 2023
• Application Server 2023
• InTouch 2023
• Historian 2023

RESOLUTION

Rename the computer hostname with all capital letters (A-Z) and numbers (0-9), using a total of 15 or less characters and avoiding Unicode characters.

• All numeric is not a valid name.
• Hyphens and longer names are permitted, but this is not recommended, as not all software and systems support this.

This is considered a best practice, as computer names in certificates are case sensitive, but DNS names are not case sensitive. A hostname query against a computer with a lower-cased name can return an all-caps result, which will not be an exact match when compared to the name in that computer’s certificate due to the difference in casing.

SUMMARY

This Tech Note details the procedure to identify and clear APPCRASH events that appear in the Windows Event Viewer for System Platform components. This can impact any component of System Platform and look like the following:

• Windows Error Reporting: Event Name: APPCRASH P1: GDIWebServer.exe
• Windows Error Reporting: Event Name: APPCRASH P1: AELicServer.EXE
• Windows Error Reporting: Event Name: APPCRASH P1: aahIDAS.EXE
• Windows Error Reporting: Event Name: APPCRASH P1: aahStorage.exe

This issue is caused when AVEVA services that are running rely on other AVEVA services that have been stopped. For example, when performing a software install, such as a Service Pack or Patch upgrade,  “Stop Services” is selected to allow the installation to continue.  If some AVEVA services stay on “Running” with other AVEVA services on “Stopped”, the running services may generate the APPCRASH errors.

These APPCRASH events repeat in the same pattern along with other Windows related APPCRASH events. It is also worth noting that at times excessively large logs error reports can continue to report into Event Viewer because the log files failed to “report”, usually in instances where the machine is not connected to the internet. However, the projects/applications can still be developed and ran at runtime, data values continue to come in, alarms can be acknowledged, etc. The system continues to run as expected. Additionally, LogViewer in OCMC/SMC does not report any errors associated with the APPCRASH events.

APPLIES TO

• Application Server
• InTouch HMI
• Historian Server
• Historian Clients
• License Server/Manager

PROCEDURE

To correct the issue, perform a Disk Cleanup and clear the Windows Error Reporting Queue.

1. Open Windows Explorer.  Right-click on the C: drive and select Properties.

2. Under the General tab, select Disk Cleanup.

3. Check Windows error repots and feedback diagnostics, the click OK.

4. APPCRASH events should stop appearing in the Windows Event Viewer logs.

SUMMARY

It may become useful to test connectivity to a local or remote SQL Server to verify the connection, or credentials in use. This document was designed to explain the process of testing the SQL connection using a common, and non-software specific method.

APPLIES TO

• Microsoft SQL Server

PROCEDURE

1. The first thing to confirm is that you can see/edit file extensions. Open an instance of Windows File Explorer, click the “View” tab > Options > “Change Folder and Search Options”

2. When the “Folder Options” window opens, select the “View” tab. In the “Advanced settings” section take note of the “Hide extensions for known file types” option.  If it is checked, then un-check it, select “Apply” and then “OK.” If it is already unchecked, then simply select the “Cancel” button.

3. On a blank area of the desktop, right-click, hover over “New”, and select the “Text Document” Option

4. The new document will automatically be in rename mode. Name the document “test.udl” and then hit the “Enter” key on your keyboard.  You will get a prompt asking you to confirm the change to the file’s “type”. Click on the “Yes” button to proceed.

5. You can confirm that the change was successful by simply viewing the file icon. It should have changed to look like the following image.

6. Double-click on the new file. When it opens, select the “Provider” tab.
7. In the “Select the data you want to connect to:” list, select the “Microsoft OLE DB Provider for SQL Server” option and click “Next”.

8. You should now be back in the “Connection” tab. Enter the node name for the system with SQL Server that you want to try to connect to, or select it from the drop-down list (this can be local or remote). Then enter valid user credentials or choose Windows Integrated, and finally select the “Test Connection” button.
   NOTE: It is not necessary to select a specific database (item 3 in the “Connection” tab). Simply enter data for items 1 & 2, and then skip directly to the “Test Connection” button.

9. If the connection was successful, then you should receive a confirmation pop-up similar to the following:

SUMMARY

This Tech Note provides examples of how to derive different SQL Server dates such as the first day of the month, the first day of the week etc. These examples may become useful while developing Wonderware Historian reports (for instance: “average flow month to date”, “total yield this quarter” etc.).

The examples below will make use of the following Transact-SQL functions:

• GETDATE() -“ this function returns current SQL Server’s date and time
• DATEDIFF() -“ this function calculates the amount of time between two dates; it consumes the time interval as a parameter which can be expressed in hours, days, weeks, months, years etc.
• DATEADD() -“ this function calculates a date by taking an interval of time and adding it to a date, it consumes the time interval defined as provided above

Note: The last midnight can be returned using the following command:

SELECT DATEADD(day, DATEDIFF(day, 0, GETDATE()), 0)

Upcoming midnight

SELECT CONVERT(DATETIME, CONVERT(INT, GETDATE()))

Monday of the current week

SELECT DATEADD(week, DATEDIFF(week, 0, GETDATE()), 0)

If you don’t want Sunday to be the first day of the week, you need to use a different method. This example sets Monday as the first day of the week.

SET DATEFIRST 1
SELECT DATEADD(day, 1 – DATEPART(weekday, getdate()),
DATEADD(day, DATEDIFF(day, 0, GETDATE()), 0))

If you want to change the example above to calculate a different first day of the week you can adjust the SET DATEFIRST command above to the appropriate value (e.g. “SET DATEFIRST 3” for Wednesday).

Yesterday start

SELECT DATEADD(day, –1, DATEDIFF(day, 0, GETDATE()))

Section 2 – Month-Based Transact-SQL Examples

First day of the current month

SELECT DATEADD(month, DATEDIFF(month,0,GETDATE()), 0)

End of prior month

SELECT DATEADD(ms, –3, DATEADD(mm, DATEDIFF(mm, 0, GETDATE()), 0))

Last day of current month

SELECT DATEADD(ms, –3, DATEADD(mm, DATEDIFF(m, 0, GETDATE())+1, 0))

First Monday of the current month

SELECT DATEADD(wk, DATEDIFF(wk, 0, DATEADD(dd, 6
– DATEPART(day, GETDATE()), GETDATE())), 0)

Section 3 – Quarter-Based Transact-SQL Examples

First day of the current quarter

SELECT DATEADD(qq, DATEDIFF(qq, 0, GETDATE()), 0)

Last day of the current quarter

SELECT DATEADD(qq, DATEDIFF(qq, 0, GETDATE())+1, –1)

Section 4 – Year-Based Transact-SQL Examples

First day of the current year

SELECT DATEADD(year, DATEDIFF(year, 0, getdate()), 0)

Last day of the current year

SELECT DATEADD(ms, –3, DATEADD(yy, DATEDIFF(yy, 0, getdate())+1, 0))

Last day of prior prior year

SELECT DATEADD(ms, –3, DATEADD(yy, DATEDIFF(yy, 0, GETDATE()), 0))

NOTE: If you need to calculate dates relative to an arbitrary date different from today, you need to change the GETDATE() function call with appropriate reference to the arbitrary date. For example, if you wanted to calculate the Last day of the year from two years ago, you could write GETDATE()-365.

Section 5 – Using These Examples in Historian Client Query

To use these examples in Historian Client Query application, set Query type to “History values” and modify the columns, criteria, retrieval, and other settings to your liking. You do not need to modify the time settings because we will change these in the SQL code. After the settings have been modified, click the SQL tab in the Results pane to see the SQL query that matches your retrieval options.

The code in the screen shot has been placed below for your convenience:

SET NOCOUNT ON
DECLARE @StartDate DateTime
DECLARE @EndDate DateTime
SET @StartDate = DateAdd(mi,-5,GetDate())
SET @EndDate = GetDate()
SET NOCOUNT OFF
SELECT TagName, DateTime = convert(nvarchar, DateTime, 21), Value, vValue
FROM History
WHERE TagName IN (‘SysPerfCPUTotal’)
AND wwRetrievalMode = ‘Delta’
AND wwVersion = ‘Latest’
AND DateTime >= @StartDate
AND DateTime <= @EndDate

If we want to use the previous date examples, we can modify lines 4 and 5 according to what time we want to retrieve.

SET @StartDate = DateAdd(mi,-5,GetDate())
SET @EndDate = GetDate()

Changing the @StartDate and @EndDate variables yields the same results as changing the time settings in ActiveFactory. For example, if we want to get data ranging from last midnight until now, we would change the lines to:

SET @StartDate = CONVERT(datetime, FLOOR(CONVERT(float, GETDATE())))
SET @EndDate = GETDATE()

To get all data from last month, we would set the start date to the beginning of last month and the end date to the end of last month:

SET @StartDate = SELECT DATEADD(month, DATEDIFF(month, 0, GETDATE()) – 1, 0)
SET @EndDate = SELECT DATEADD(ms, –3, DATEADD(month, DATEDIFF(month, 0,
GETDATE()), 0))

SUMMARY

When working with AVEVA Historian and Remote IDAS, it is important to take time into serious consideration. With IDAS historical data storage there is a term called the “Real-Time Window“, which is a period of time behind and ahead of the AVEVA Historian system time, where values coming into the system are considered “valid” and will be stored properly.

With AVEVA Historian, the real-time window can be any value coming into the system between -30 seconds and +999 milliseconds. Time offset and discarded data can be a result of improper time synchronization. The purpose of this document is to help identify time issues between your AVEVA Historian and remote IDAS machines and correct them.

NOTE: This does not apply to MDAS storage. MDAS design is specific to late data. For the purposes of this document, we are using a local IDAS. In practice, these steps will actually apply to a Remote IDAS system (i.e. where the IDAS is not installed on the same node as Historian).

PROCEDURE

1. You’ll first need to identify the problem topic. You can do this using the wwTagKey parameter from the error messages. In our case this is 242.We can determine this by running a query against the Runtime database (DB). First, open up SQL Server Management Studio and connect to Historian, then create a new query in the Runtime DB.

2. Make sure you are running the query against the “Runtime” database, and then enter a query similar to the query below. When finished with the query select “Execute“.

SELECT Tag.Tagname, Topic.Name Topic, Topic.TopicKey

FROM Tag

INNER JOIN Topic

ON Tag.TopicKey = Topic.TopicKey

WHERE Tag.wwTagKey = <wwTagKey parameter from Step 1 above>

3. In the results, take note of the Topic.

4. Open the SMC Historian Configuration, and then navigate to the IDAS. Locate the topic in question and take note of the node name for the topic.

5. Now that we have identified the computer name for the Topic in question, we can start the process of synchronizing the time between the IDAS node and the Historian node.

Note: ALL steps from this point forward will be configured on the remote IDAS system.

Begin by navigating to the directory where you want to create the batch file. When ready, create a new text document.

6. Open a text editor like Microsoft Notepad. Enter the following script:

@echo off
net time \\HistorianNodeName /set /yes
exit

When finished, save and close the editor. Make sure to use the proper HistorianNodeName when you implement this script.

7. Right-click on the newly created script file and select “Properties“.

8. In the first editable text field change the file extension from “.txt” to “.bat“. This will change the text file into a batch file. When finished click the “OK” button.Note: In order to see the .txt extension, the “File Name Extensions” checkbox must be enabled in the View à Show/Hide settings in Windows File Explorer.

9. A prompt will appear letting you know that changing the extension of a file may cause the file to become “unusable”. Select “Yes“.

10. To verify that the change was successful you can simply observe the file’s icon, as displayed below.

11. Now open the “Control Panel“, and then open “Administrative Tools” and select “Task Scheduler”.

12. In Task Scheduler, select the “Create Basic Task…” option.

13. Name your task and provide a description if desired and click Next.

14. Selected your desired trigger – in this example we choose “Daily”, then click next.

15. Configure additional time details related to your chosen time trigger and click next.

16. Choose the “Start a program” option and click next.

17. Navigate to the batch file location using the “Browse” button, or manually enter the file path to the batch file. Click next once this is selected.

18. Review the details of your task. You can also select the “Open the properties for this task when I click Finish” checkbox to apply even more detailed task properties (e.g. stopping the task if it runs for too long of a time frame, only run the task if the system is idle, etc.). Otherwise, click “Finish” to complete the setup.

19. If desired, when finished you may right-click on the scheduled task and select “Run” to implement the changes immediately.

SUMMARY

It may become necessary for a developer to create an IDAS in AVEVA Historian that views many data points without having an InTouch HMI application to import tags from. This document provides the procedure necessary to utilize the Import Tags feature of AVEVA Historian without an existing AVEVA InTouch application, as well as how to use the AVEVA Historian Server database export/import utility for archiving or troubleshooting.

APPLIES TO

• AVEVA Historian – all versions

PROCEDURE

1. Create a new IDAS and applicable Topic through the System Management Console. Once you have created your IDAS and Topic information, create a new tag by right-clicking on your Topic and selecting New <TagType> Tag, where <TagType> is either Analog, Discrete, Event, or String.

NOTE: One tag will be created for every “type” of tag you need.  For instance, if you need 1,000 analogs, 500 discretes, and 70 strings, then here you would simply create 1 analog, 1 discrete, and 1 string.

2. Once you have created your tag you should be able to view it in the right-hand pane and make any changes necessary before proceeding.

3. The next step in the process is to Commit Pending Changes, so that the AVEVA Historian Server database can be properly updated with the new information. Navigate to Action->Commit Pending Changes and click Commit button.

4. Click the OK button to continue.

5. Now we need to export the Historian Server database. To complete this action, navigate to: Start -> AVEVA Historian -> Database configuration export and Import.
   Select the Export from Historian to a text file radio button from the Welcome screen and click Next.

6. In the Connect screen enter valid SQL Server or Windows authentication credentials, along with the directory where you wish the exported text file to save to.

 NOTE: Make sure that the Export all objects checkbox is checked.

Click Next.

7. If you have previously exported a copy of your Historian Server database to the desired directory with the same name, then the following message will be displayed. If not, then proceed to Step 8. If so, then click the OK button to continue.

8. The last screen before the action is completed is the Confirm screen.  There is nothing to configure here, yet it does give one last opportunity to go back to a previous step before the export is created. Click Next.

9. Once the export file is successfully created click the Finish button to complete the export process.

10. Open the export file in Microsoft Office Excel.

11. Locate the newly created tag for your IDAS, and then insert as many lines as needed to add the rest of your tags by right-clicking on the cell below and selecting Insert.

 NOTE: Data in the export file is grouped by type. If you need to add discrete tags, then you will need to add them to the :(DiscreteTag) section, for strings it is the :(StringTag) section and so on. Column A contains section names.

12. Copy the entire row with the tag created in the System Management Console, and then proceed by pasting it into the new blank rows created in the preceding step.

13. Modify the name after pasting the original to avoid duplicate tagnames. Here you can also specify different parameters for the copied tags (such as min/max EU).

14. When finished close Microsoft Excel. You will receive a message asking if you would like to save your changes. Click Yes to proceed. Choose to overwrite the existing file when saving.

15. Begin the import process. Navigate to: Start -> AVEVA Historian -> Database configuration export and Import. Select the Import from a text file to a Historian. Click Next to proceed.

16. Enter valid SQL Server or Windows authentication credentials, along with the directory where the text file containing the database is located. Click Next.

17. Click Next in the Confirm screen to continue.

18. Once the import has been successfully accomplished the Status screen will have an informational dialog box stating that the Import succeeded. Click the Finish.

19. Make sure you Commit Pending Changes.

20. Once the pending changes have been committed you should be able to view all of your new tags contained within your Topic.

SUMMARY

The AVEVA Historian includes two features that allow performance statistics to be collected and distributed to network clients. The System Driver module performs the task of collecting Historian performance statistics and the Historian IO Server allows clients to connect via Suitelink to acquire real-time data. Using these two features we can acquire Historian performance statistics to clients such as AVEVA Application Server for real-time monitoring and alarming.

APPLIES TO:

• Historian Server
• Application Server

Procedure

1. First, we must know the node name or IP address of our historian. In this example, our historian is called ‘DESKTOP_QFEFKPQ’. With this information we can now configure a $DDESuitlinkClient DI (device integration) object to reference this data source.
2. From the Application Server’s IDE (Integrated Development Environment), create a new $DDESuitelinkClient DI object by right-clicking on the $DDESuitelinkClient template in the template toolbox under the Device Integration Folder.
3. Select New -> Instance. Then drag this object from the ‘Unassigned Host‘ and place it on an appropriate AppEngine. In this example we will rename this object to ‘Historian_Performance‘ (right-click on the object and select Rename).
4. Double-click this object to open its configuration. Configure the object as shown in the screen-shots below:

5. Once we have configured a $DDESuitelinkClient DI object to reference data from the Historian, we can now configure another object to monitor and alarm on specific performance statistics. In this example we will be monitoring the Historian for CPU Utilization which indicate real-time processor load. To do this, create a new instance of the $UserDefined object and assign to the appropriate area. In this example we will call this object ‘Historian_Performance_Collector‘. Configure the object as shown below. Save and check this object in when completed:

6. Last step here is to deploy both objects that we have created. Deploy them both, and then check Object Viewer to confirm that data is being collected from the Historian:

This object attribute can now be used within the galaxy to monitor the CPU utilization of the historian.

7. Below are some other important performance monitoring items that are available in InSQL. A complete list of InSQL performance tags can be located in the InSQL Books Online under the topic ‘System Tags‘.

Error Count Tags

• SysCritErrCnt – number of critical errors
• SysErrErrCnt – number of non-fatal errors

Storage Space Tags

• SysSpaceMain – space left in the circular storage path
• SysSpaceAlt – space left in the alternate storage path

I/O Statistics Tags

• SysPerfDataAcq<N>CPU – CPU load for the specific IDAS denoted by <N>
• SysPerfRetrievalCPU – CPU load for the client retrieval subsystem
• SysPerfStorageCPU –“ CPU load for the storage subsystem

SUMMARY

This AVEVA Historian includes two features that allow performance statistics to be collected and distributed to network clients. The System Driver module performs the task of collecting Historian performance statistics and the Historian IOServer allows clients to connect via Suitelink to acquire real-time data. Using these two features we can acquire Historian performance statistics to clients such as InTouch for real-time monitoring and alarming.

APPLIES TO:

• Historian Server, all versions
• InTouch HMI, all versions

PROCEDURE

1. First, we must know the node name or IP address of the Historian. In this example our Historian is called “DESKTOP-QFEFKPQ”. With this information we can configure an Access Name in InTouch to reference this data source. The configuration details vary depending on what version of Historian is being used. To create a new Access Name in InTouch, click on the Special drop-down menu and select Access Names. Click on the Add button.

2. Once we have configured an Access Name to reference data from the Historian we can now configure tags in InTouch to monitor and alarm on specific performance statistics. In this example we will be monitoring the historian for “Fatal errors” which indicate a complete failure. To configure this tag, open the Tagname Dictionary and create a new I/O integer tag. Configure the tag as shown below:

Save this tag, and it can now be used to monitor fatal errors in the Historian. Also, if any fatal errors occur, InTouch will alarm to notify operators that there has been a failure. Here is another example that will allow us to monitor real time processor utilization:

Below are some other important performance monitoring items that are available in Historian:

Error Count Tags

• SysCritErrCnt – number of critical errors
• SysErrErrCnt – number of non-fatal errors

Storage Space Tags

• SysSpaceMain – space left in the circular storage path
• SysSpaceAlt – space left in the alternate storage path

I/O Statistics Tags

• SysPerfDataAcq<N>CPU – CPU load for the specific IDAS denoted by <N>
• SysPerfRetrievalCPU – CPU load for the client retrieval subsystem
• SysPerfStorageCPU – CPU load for the storage subsystem

SUMMARY

When experiencing problems connecting to an AVEVA Historian Server from an AVEVA Historian Client such as Trend, there are several steps that can be used to troubleshoot the problem. This tech note details the correct steps to take to initiate communication. Assume that there is a running Historian Server on your network which is able to accept client connections from other client nodes.

APPLIES TO:

• AVEVA Historian Server – all versions
• AVEVA Historian Client  – all versions

PROCEDURE

1. First, we must confirm basic network connectivity by using the ping command (which can be launched by going to Start button -> Run -> typing cmd -> then in the command window typing ping. You must know the node name or IP address of the Historian Server computer. Make sure that if you are pinging by node name that the IP address resolved is correct.

2. Next, we need to make sure that there aren’t any devices or software that could be blocking communication on specific TCP ports. If there are hardware firewalls or routers on the network, try bypassing them to see if the connection succeeds. Also, check for firewall software installed on the Windows OS, such as the Windows Firewall. The OS Configuration Utility will add the necessary exceptions to the Windows Firewall (but not other 3rd party firewall software). The OS Configuration Utility can be applied by installing a recent patch to AVEVA software.  If you’re not sure these exceptions have been added to the Windows Firewall and cannot download the OS Configuration Utility, the Windows Firewall can be temporarily deactivated manually by a local Administrator. Double-click the Windows Firewall in your Windows Control Panel, and turn it off:

3. If at this point there are still problem connecting to Historian Server, we need to check on the SQL client settings. First, we need to make sure the correct protocols are enabled. Click on Start -> Run type “cliconfg” in the Open: dialog and click on OK. This will start the SQL Server Client Network Utility. Make sure that TCP/IP is enabled and the default port under “Properties” is set to 1433:

Next, select the “Alias” tab and make sure that any configured aliases are correct. Specifically, make sure that the connection parameters reference the correct node name or IP address. Also, make sure the alias(es) are configured to use port 1433:

At this point we have confirmed network connectivity along with SQL client related networking options. If you are still having problems connecting it may be caused by other network or operating system related issues. Please contact Industrial Software Solutions Support at support@industrial-software.com for further assistance.

SUMMARY

This Tech Note details the procedure to backup history blocks of Historian Server. A history block is self-contained, containing all of the information necessary to retrieve data for the period represented by the history block. The default duration of a history block is one day and the minimum allowed duration is one hour. Historian Server automatically creates a new history block at system startup, at scheduled block changeover times, at request, or in response to certain dynamic configuration actions.

NOTE: Configuration data and event history are not stored in the history blocks; they are stored in the Runtime database file.

There are four types of storage locations for history blocks:

• Circular – this is the main storage location and it has to be one of the local hard drives
• Alternate – this is an overflow buffer
• Buffer – this is a read-only storage location
• Permanent – this is a storage location with Historian Server may write data but will never remove data

NOTE: History blocks may be automatically deleted to make room for new history blocks. Whether or not the blocks are deleted is determined by the minimum threshold and the maximum size and/or age specified for the storage location. If an alternate storage location exists, the older blocks will be removed there instead of being deleted. The alternate storage location functions exactly like the circular storage location. However, when the blocks exceed the set limits (minimum threshold, maximum size, or maximum age), the oldest blocks will be deleted from disk.

Recommended Historian Server Configuration

We recommend installing Historian Server on a computer that contains two physical hard drives:

• System drive (usually C: drive)
• Data drive (drive with a separate letter assigned, e.g. D:, E:)

Below is a sample storage architecture:

• Drive C (capacity: usually 10-20 GB)
  • Windows Operating System is installed under C:\Windows
  • Microsoft SQL Server program files are installed under C:\Program Files\Microsoft SQL Server
  • AVEVA Historian Server program files installed under C:\Prgoram Files\Historian
• Drive D (capacity: usually 100 GB or more)
  • Historian Runtime and Holding SQL databases installed for instance under D:\Historian\DB
  • Historian History Blocks installed for instance under D:\Historian\Data

Preferably both drivers should have RAID 1 (mirroring) or RAID 5 (stripping with mirroring) architecture. The configuration listed above can be achieved by specifying appropriate locations during the Historian Server installation.

Elements That Need to be Backed Up

Elements that will be included into our backup procedure are comprised of:

• Two SQL Server databases added by the AVEVA Historian Server installation program to MS SQL Server:
  • Runtime – stores configuration, event, and summary data (database file name is Run90Dat.mdf, its associated log file is Run90log.ldf)
  • Holding – used to temporarily store tag definition during InTouch tag import (database file name is Holding90Dat.mdf, its associated log file is Holding90log.ldf)
• SQL Server’s master database (it’s a database that stores information such as user login account information, security settings, server specific configuration information, etc.)
• Historian History Blocks – these are special folders and files that contain all the information necessary to retrieve data for the period represented by the history block and store it to hard disk. Circular storage is used for the main historical data storage.

We recommend a 2 step backup procedure:

• Step 1 – a local disk-to-disk backup procedure copies SQL Server databases and history blocks to a dedicated backup holding location
• Step 2 – backup software backs up the holding location to tape or to a network storage location

NOTE: We do not recommend using enterprise class backup software (such as Veritas Backup Exec and similar) to directly backup Historian Server databases and/or history blocks over the network. Such software may forcibly remove file locks prior to copying files which in the case of Historian Server may lead to fatal runtime errors.

Applies to

• AVEVA Historian Server

PROCEDURE

NOTE: The procedure described below applies to Historian Servers systems based on SQL Server. The circular storage location is used for the main historical data storage. A block of historical plant data is saved as a single sub-directory in the circular storage directory.

One of the methods for creating backups of Historian History Blocks is running VBScript (short for Visual Basic Scripting Edition) file.

VBScript is an Active Scripting language interpreted via Microsoft’s Windows Script Host. The language’s syntax reflects its pedigree as a variation of Microsoft’s Visual Basic programming language. When VBScript source code is contained in stand-alone file, it has the extension .vbs.

In our example, the file that contains VBScript code is the key to automated backup procedure (copying history blocks to a different location) and the “Scheduled Tasks” tool available in Windows will help run the procedure according to schedule.

NOTE: VBScript may not be the best way to copy large amounts of data over the network. Therefore this procedure assumes the VBScript would copy history blocks to a local backup holding location (disk-to-disk backup) and then a dedicated backup software (such as Windows Backup or Veritas Backup Exec) would copy the holding location to a tape or network storage.

1. Determine location of Historian history blocks (by default it’s C:\Historian\Data\Circular, in our recommended architecture it’s assumed to be C:\Historian\Data\Circular)

2. Create a local folder that will store backup copies of history blocks (in our example in C:\Historian_Backups\HistoryBlocks)

3. Open Notepad, type or copy and paste the code shown below:

Set FSO = CreateObject(“Scripting.FileSystemObject”)
Set SourceFolder = FSO.GetFolder(“C:\Historian\Data\Circular”)

‘specify the target folder in the next line
TargetFolderName = “D:\Historian_Backup\HistoryBlocks”

‘comment: 1st pass – find the name of the current (most recent) folder based on DateCreated attribute

For Each MyFolder In SourceFolder.SubFolders
  If MyFolder.DateCreated > LatestTimeStamp Then
    LatestFolderName = MyFolder.Name
    LatestTimeStamp = MyFolder.DateCreated
  End If
Next

‘comment: 2nd pass – copy all folders but the most recent one

i = 0
For Each MyFolder In SourceFolder.SubFolders
  If MyFolder.Name <> LatestFolderName Then
    On Error Resume Next
    FSO.CopyFolder MyFolder.Path, TargetFolderName & “\” & MyFolder.Name, True
  If Err.Number <> 0 Then
    MsgBox “Error: ‘” & Err.Description & “‘ while copying ‘” & MyFolder.Name & “‘”, 48, “Copy Historian History Blocks”
  Else
    i = i + 1
  End If
    On Error Goto 0
  End If
Next

MsgBox i & ” history blocks copied at ” & Now, 64, “Copy Historian History Blocks”

In the code above the current history block is excluded from the backup procedure. It will be included when Historian adds new history block with the most current creation date.

NOTE: It is not recommended to copy the current history block because files contained in that history block may not be properly closed by Historian Server.

4. Save the file as HistorianHistBlocksBackup.vbs in “My Documents” folder (the file needs to be saved with .vbs extension to work as a script)

5. Next open All Programs > Accessories > System Tools > Scheduled Tasks tool

6. Start the wizard and click “Browse” button. Go to the location where the script file is located (My Documents > HistorianHistBlocksBackup.vbs) and open it.

8. Review backups of history blocks by going to the location specified in batch file (in our example: D:\Historian_Backup\HistoryBlocks).

NOTE: It is advantageous to periodically test the validity of the backups. It is in your best interest to randomly select databases to restore onto test servers to ensure the restore functionality works properly and is meeting your expectations. The more frequently restoration testing is conducted, the better you will prepared for a real recovery.