B.Data Kernel Restart Procedures for WinCC Archive Configuration

Overview

B.Data is the Siemens SIMATIC WinCC option for long-term archiving, reporting, and analysis of process values. It runs as a multi-service Windows application that depends on a central kernel process coordinating acquisition, compression, calculation, and dispatch of measurement variables (MEVA) and key performance indicators (KPI). Whenever the underlying database configuration changes—new tags, modified KPI formulas, swapped protocol sources, archive group edits—the in-memory cache held by the kernel becomes inconsistent with the SQL backend. The required corrective action is a controlled kernel restart so the cache is rebuilt from the freshly committed configuration.

This reference consolidates the two supported restart paths (the Hardware node context menu and the command-line batch method), the rule for protocol module inputs (MEVA/KPI, not raw datapoints), the role of the B.Data Logging Viewer as a diagnostic console, and the integration boundary with WinCC OLE DB Provider (RT Professional) for downstream consumers.

Prerequisites and System Architecture

Before performing any kernel operation, confirm the following baseline:

• Operator/engineering workstation running WinCC V7.4 SP1 or later, or PCS 7 V9.0 SPx with B.Data option installed and licensed.
• SQL Server instance hosting the B.Data project database is online; verify with SELECT @@SERVERNAME, @@VERSION from SQL Management Studio against the B.Data database.
• B.Data project is loaded and the project folder (typically C:\BData\Projects\<ProjectName>) is accessible by the B.Data service account.
• User account performing the restart belongs to the local BDataUsers group and has db_datareader and db_datawriter on the project database.
• For OLE DB access, the WinCC OLE DB Provider must be installed; this is part of the WinCC RT Professional installation media.

B.Data Kernel Architecture

The B.Data runtime consists of three cooperating components:

The kernel loads its configuration exclusively at startup. Any modification made through the configuration editor (Hardware node, protocol definitions, KPI computations, archive groups, dispatchers) is committed to SQL but is not reflected in the running kernel until the cache is rebuilt by a Start/Restart cycle. This separation is what makes explicit restart mandatory after every change.

Restarting the Kernel via the Hardware Node

This is the canonical GUI procedure and is preferred when an interactive operator is at the engineering station.

1. Open the B.Data configuration project in the B.Data Configuration editor.
2. In the project tree, locate the Hardware node representing the runtime server.
3. Right-click the Hardware node and select Edit... from the context menu.
4. In the resulting dialog, click the Kernel button. This opens the Kernel Service Cockpit window.
5. In the cockpit, click Start/Restart. The kernel terminates the running instance and spawns a new one.
6. Observe the status indicator: it transitions from stopped to starting to running. The full cycle typically takes 10–45 seconds depending on database size.
7. Close the cockpit and the Hardware editor. The new configuration is now active.

Batch File Method for Kernel Restart

The batch method is preferred by automation engineers because it leaves a persistent console with status messages and can be called from scheduled tasks, RDP scripts, or remote maintenance shells. The recommended content for a desktop shortcut named kernel.bat:

@echo off
cd\
cd\BData\GUI
Kernel go
pause

Execution behavior:

• cd\ resets the working directory to the drive root; this prevents inheritance of a wrong drive letter from a UNC path or network share.
• cd\BData\GUI locates the Kernel.exe binary. If B.Data was installed to a non-default path, substitute the actual installation directory.
• Kernel go is the supported command-line directive to start or restart the kernel. Alternative directives include Kernel stop, Kernel status, and Kernel reload; consult the B.Data service manual for the full directive matrix.
• pause keeps the console open so the operator can read the return status and any warnings emitted by the kernel during initialization.

For multi-server installations, repeat the batch invocation on each B.Data server. Each server maintains its own kernel instance and its own cache; there is no cluster-wide restart broadcast.

Protocol Module Configuration: MEVA and KPI Inputs

A common source of "no value" or "no data" reports in B.Data is feeding a raw WinCC datapoint into a protocol module that expects a calculated variable. The protocol modules (used for things like shift reports, energy balancing, and standard-compliant logging) require a measurement variable as input.

When configuring a protocol module:

1. In the project tree, expand the target protocol (for example Standard Daily Report).
2. Open the variable assignment dialog.
3. Pick a variable of type MEVA or KPI from the selection list, not a raw datapoint.
4. Save the protocol definition, then perform a kernel restart as described in the previous sections.

If the selection list does not show any MEVA/KPI candidates, the corresponding measurement variable has not yet been defined in the Database node. Create the MEVA first (with archive group, compression method, and source datapoint), commit, restart the kernel, then return to the protocol definition.

Using the B.Data Logging Viewer for Diagnostics

The Logging Viewer is the first-line diagnostic tool when reports come back empty or acquisition appears stalled. It is accessed from the B.Data administration menu:

• Start → All Programs → Siemens Automation → B.Data → Administration → Logging Viewer

The viewer shows three live streams:

If a report returns no rows, filter the Logging Viewer on the report's protocol module name and the timestamp of the report period. Look for entries of type WARN or ERROR such as "Source variable not found", "Archive group offline", or "Calculation aborted: divide by zero". These messages pinpoint the exact cause faster than any report-side investigation.

Integrating WinCC Archive Access via OLE DB Provider

Downstream consumers (Excel reports, Power BI dashboards, custom .NET or Python analytics) can read B.Data and WinCC Runtime Professional archives directly through the WinCC OLE DB Provider. The provider exposes archive segments as OLE DB rowsets and supports both tag-value queries and compressed-value queries.

For Runtime Professional (WinCC RT Professional / TIA Portal V21), the access path is documented in the Siemens TIA Portal Help: Access to archive data via WinCC OLE DB Provider (RT Professional).

Key technical points when connecting B.Data-sourced data to OLE DB:

• The connection string uses provider WinCCOLEDBProvider.1 for the classic WinCC Runtime archive and the equivalent RT Professional connector for TIA-based projects.
• Query parameters require PACK (number of values), STARTIME and ENDTIME in ANSI date format, and the TAGNAME matching the B.Data MEVA name exactly (case-sensitive).
• For compressed archives, include MODE=COMPRESSED; for raw data, omit it.
• Authentication follows the WinCC user administration; the connecting user must have archive read rights assigned.

Example SQL query fragment against a B.Data-fed MEVA named Boiler1_Temperature:

SELECT * FROM OPENQUERY(WinCCArchive,
  'TAG:Boiler1_Temperature,''0000-01-01 00:00:00'',''9999-12-31 23:59:59''',
  'PACK:2')

Always validate that the kernel has completed its restart before issuing OLE DB queries; queries issued during the cache rebuild may return incomplete or stale result sets.

Troubleshooting Matrix

Verification After Kernel Restart

After every restart, run the following verification checklist before declaring the system ready:

1. In the Kernel Service Cockpit, confirm status indicator shows running and uptime reads as expected.
2. In the Logging Viewer (System tab), look for the line "Kernel ready, accepting requests".
3. Open a representative MEVA trend in the B.Data trend control or in WinCC Trend Control; verify new values arrive at the configured acquisition cycle.
4. Manually trigger a test report for a recent shift; confirm rows appear.
5. From a downstream consumer, issue a minimal OLE DB query (for example, last 10 values of one MEVA) and confirm the result set.

Best Practices for Stable Operation

• Make all related configuration changes in a single batch, then perform exactly one kernel restart. Multiple restarts in quick succession waste acquisition cycles and can mask configuration mistakes.
• Maintain a change log; record the timestamp, the operator, and the nature of every change that requires a restart. This makes regression analysis dramatically faster when reports later appear inconsistent.
• Schedule kernel restarts outside acquisition-critical periods whenever possible. For continuous processes with shift-based reporting, target the inter-shift boundary.
• Keep the Logging Viewer open on the engineering station during the first 10 minutes after every restart; early warnings are easier to act on than post-mortem analyses.
• Document the B.Data installation path in operational procedures. Custom installations to D:\Siemens\BData or similar non-default locations break the canonical batch file and are a common source of "nothing happens" troubleshooting tickets.

FAQ