Resolving Out of Memory Errors and Query Timeouts in SIMATIC Information Server RDL Reports

In SIMATIC Information Server (2014 SP2 / 2020), custom RDL reports generated via Microsoft Report Builder that crash with Out of Memory exceptions or query timeouts when extending query time ranges (e.g., beyond 3 days) fail because the report executes unaggregated SQL/OLE-DB queries directly against runtime WinCC OS Servers. To resolve this, deploy SIMATIC Process Historian (PH) to serve pre-aggregated historical datasets, optimize RDL SQL queries by applying server-side filtering (filtering on 'Area', 'Priority', and 'DateTime' at the database level rather than client-side tablix expressions), and increase memory limits in the Information Server administrative console.

Executive Summary

SIMATIC Information Server (IS) provides web-based reporting, automated compliance dashboards, and plant analytics for SIMATIC PCS 7. Engineers frequently develop custom report templates (RDL files) using Microsoft Report Builder (such as customizing the standard alarm statistics template 64906050_Message_Statistics_PROJ_IS_PH to filter by plant area or alarm priority). While these custom reports execute smoothly over short sample intervals (1 to 3 days), expanding the date range to weekly or monthly intervals triggers fatal errors: the report generation halts with OutOfMemoryException, SQL query timeout pop-ups, or blank output pages.

This failure is caused by an architectural mismatch in data retrieval. When Information Server connects directly to active WinCC OS Servers instead of a central Process Historian, all message records must be extracted via the WinCC OLE-DB Provider. If custom RDL reports pull entire unindexed alarm tables into memory and rely on client-side Report Builder expressions to filter areas, the report server heap is exhausted. This guide details the data extraction mechanics, query optimization techniques, and architectural requirements needed to achieve high-performance reporting over long time horizons.

Architecture and Fundamental Mechanics

The Information Server reporting pipeline processes data across three distinct computational tiers:

Data Source Retrieval Mechanics (OS Server vs Process Historian):
- When Information Server connects directly to a WinCC OS Server, queries pass through the WinCCOLEDBProvider.
- WinCC OS Server databases are optimized for cyclic runtime logging and operator screen updates, not multi-month analytical queries. Querying millions of alarm records directly from an active OS Server degrades runtime performance and imposes strict buffer limits.
- Conversely, SIMATIC Process Historian (PH) utilizes Microsoft SQL Server Enterprise with specialized column-store and time-series indexing. PH pre-aggregates message statistics, enabling fast query execution over months or years.
Server-Side vs Client-Side Filtering in RDL Templates:
- Default Siemens report templates often retrieve a broad dataset and use Microsoft Report Definition Language (RDL) Tablix filters to hide unwanted rows in the visual presentation layer.
- When an engineer adds filtering parameters (such as 'Area' or 'Priority') only within the RDL Tablix properties, SQL Server still transmits every single message row across the network into the Information Server memory buffer.
- For multi-day or monthly queries involving hundreds of thousands of process alarms, the IIS Worker Process (w3wp.exe) or SQL Server Reporting Services (ReportingServicesService.exe) exceeds allocated RAM, throwing a fatal System.OutOfMemoryException.
Memory Configuration and Query Execution Limits:
- Information Server enforces execution limits in its administrative web portal to protect system stability.
- Default timeout thresholds (typically 30 to 60 seconds) abort complex queries before the database engine completes table joins.

Step-by-Step Implementation Procedure

Follow these steps to optimize custom RDL reports and eliminate Out of Memory exceptions in Information Server:

Implement Server-Side SQL Filtering in Microsoft Report Builder:
- Open the custom RDL template file in Microsoft Report Builder.
- In the Report Data pane on the left, expand 'Datasets' and right-click the primary message dataset > select 'Dataset Properties'.
- Click the 'Query' tab.
- Modify the SQL query command text to filter at the database level rather than in the report body:
- Incorporate @Area, @Priority, and @DateTime directly into the SQL WHERE clause:
  sql WHERE (DateTime >= @FromDate AND DateTime <= @ToDate) AND (AreaName IN (@Area) OR @Area IS NULL) AND (Priority >= @MinPriority)
- Remove redundant client-side filters from the 'Filters' tab of the Dataset Properties and Tablix Properties.
Limit Query Column Projections:
- In the SQL SELECT statement, remove all unused columns (e.g., internal system flags, unused text fields, auxiliary binary values).
- Request only the explicit fields required for the report layout (DateTime, MsgNumber, MsgText, AreaName, Priority, State).
Pre-Aggregate Statistics for Extended Date Ranges:
- For reports spanning weeks or months, avoid querying raw individual messages (msdb/messages).
- Utilize SQL aggregation functions (COUNT(*), GROUP BY AreaName, Priority) in the dataset query so that SQL Server transmits only summary numbers to Information Server rather than millions of discrete rows.
Deploy and Target SIMATIC Process Historian (Recommended Architecture):
- In plants generating high alarm volumes, install SIMATIC Process Historian (PH).
- In the Information Server Web Administration portal, configure Process Historian as the primary data source.
- Process Historian's dedicated indexing eliminates memory starvation during long-duration queries.
Adjust Execution Timeout and Memory Limits in Information Server:
- Open the Information Server Web Application as Administrator.
- Navigate to 'Administration > System Settings > Reporting'.
- Increase 'Database Query Timeout' from 60 to 300 seconds if querying large archives.
- Under 'Report Limits', verify maximum row limits and adjust memory thresholds to accommodate plant reporting requirements.
Upload and Test the Optimized Template:
- Save the modified RDL file in Report Builder.
- In the Information Server web portal, navigate to 'Templates > Upload' and overwrite the existing template.
- Execute a test report covering a 30-day time range.

Verification

In Information Server, configure a report execution with a 30-day date range and specific plant area filters.
Click 'Generate Report': verify that the report generates cleanly without Out of Memory pop-ups or gateway timeout errors.
Open Windows Task Manager on the Information Server host: verify that memory utilization of ReportingServicesService.exe remains stable within normal operating boundaries.
Confirm that the generated PDF or Excel report accurately displays alarm frequency counts and filtered area distributions.

Limitations and Operational Precautions

Directly querying active WinCC OS Servers for long-term historical analytics can degrade operator screen responsiveness and tag acquisition; always route multi-month queries to SIMATIC Process Historian. Custom RDL files modified in Microsoft Report Builder must maintain schema compatibility with the specific version of SQL Server Reporting Services (SSRS) bundled with Information Server. Software packages and client access licenses should be verified through an authorized Siemens distributor or the Siemens Industry Mall.

Engineer FAQ

Why did the default template work for a month, but the edited template crashed after 3 days?

The default template may have utilized pre-aggregated views or optimized server queries, whereas the custom edits introduced client-side tablix filtering that forced the server to load millions of raw records into RAM.

What is the maximum time range supported when querying an OS Server directly?

Typically 1 to 3 days, depending on alarm frequency. Extended time horizons require SIMATIC Process Historian.

What tool is used to edit Information Server RDL templates?

Microsoft Report Builder (or Visual Studio SQL Server Data Tools matching the bundled SSRS version).

How does server-side filtering resolve Out of Memory errors?

Server-side filtering applies WHERE clauses inside the database engine, returning only matching rows across the network and reducing memory consumption by up to 99%.