Phase 2 extends the virtualised renewable energy platform into a fully operational intelligent energy management system — integrating dynamic load demand modelling, adaptive energy routing, battery dispatch logic, real-time KPI computation, and a live WinCC Advanced HMI dashboard. All subsystems are orchestrated through structured SCL function blocks executing on a virtualised S7-1500 runtime under Siemens TIA Portal V19.
Phase 1 established the core simulation and energy generation architecture. Phase 2 transforms that static monitoring foundation into a responsive, decision-making system capable of dynamic energy routing — evaluating real-time solar generation, plant load demand, battery state of charge, and grid availability to autonomously determine the optimal energy distribution strategy on every PLC scan cycle.
The primary deliverable is a fully operational SCADA HMI screen running in WinCC Advanced Runtime, displaying live plant telemetry, animated energy flow indicators, renewable contribution tracking, and industrial-grade KPI metrics — consistent with the visualisation layer of a real solar utility installation.
| Component | Technology |
|---|---|
| PLC Platform | Siemens S7-1500 (CPU 1511-1 PN) |
| Engineering Environment | TIA Portal V19 |
| Simulation Runtime | Siemens PLCSIM V19 |
| Programming Language | SCL (Structured Control Language) |
| HMI / SCADA Platform | WinCC Advanced Runtime (V19) |
| HMI Hardware Target | TP700 Comfort Panel (virtualised) |
Phase 2 introduces three new functional layers above the Phase 1 energy core. Dynamic load demand feeds the energy router, which in turn drives real-time grid command resolution before efficiency metrics are computed — enforcing strict data dependency ordering within the PLC scan cycle.
Three new function blocks and one inline SCL network were added to the Main [OB1] execution sequence. Block ordering is critical — energy routing must resolve grid commands before the efficiency metrics block executes to avoid zero-value outputs caused by stale data.
Network 1 — FB_WeatherEngine [FB1 / DB6] — Phase 1 Network 2 — FB_SolarArray [FB2 / DB7] — Phase 1 Network 3 — FB_BatterySystem [FB3 / DB8] — Phase 1 Network 4 — FB_LoadDemand [FB5 / DB12] — Phase 2 ★ Network 5 — FB_EnergyRouter [FB6 / DB13] — Phase 2 ★ Network 6 — Grid SCL Resolution — Phase 2 ★ Network 7 — FB_EfficiencyMetrics [FB7/DB14] — Phase 2 ★
Simulates a variable plant consumption profile keyed to the simulated time-of-day, replicating realistic industrial load curves including peak demand periods. The block consumes DB_Weather.WeatherData.TimeOfDay and outputs a continuously varying Demand_kW value alongside a boolean PeakMode flag — allowing downstream routing logic to apply peak-demand prioritisation strategies.
TimeOfDay_In — sourced from DB_Weather.WeatherData.TimeOfDayDemand_kW_Out → DB_Load.LoadData.Demand_kWPeakMode_Out → DB_Load.LoadData.PeakModeDB_Load_Demand [DB12]The central decision-making block of the Phase 2 system. On every PLC scan, the router evaluates four live inputs — solar generation, plant demand, battery SOC, and peak mode status — and resolves the optimal energy routing strategy, issuing boolean command outputs that drive grid import, grid export, battery charge, and battery discharge operations. This single block replaces and supersedes the legacy FB_GridManager, consolidating all energy distribution authority into one deterministic control source.
Solar_kW_In — from DB_Energy.PowerData.Generated_kWDemand_kW_In — from DB_Load.LoadData.Demand_kWBatterySOC_In — from DB_Energy.BatteryData.SOCPeakMode_In — from DB_Load.LoadData.PeakModeChargeCmd_Out → DB_Energy.PowerData.ChargeCommandDischargeCmd_Out → DB_Energy.PowerData.DischargeCommandGridImportCmd_Out → DB_Energy.PowerData.GridImportCommandGridExportCmd_Out → DB_Energy.PowerData.GridExportCommandTranslates the boolean command outputs from FB_EnergyRouter into quantified power flow values. This inline SCL block reads the active grid commands and computes actual kilowatt values — import as the deficit between demand and generation, export as the surplus above demand. Executed immediately after the router and before the metrics block to guarantee that resolved values are available for efficiency calculations within the same scan cycle.
IF "DB_Energy".PowerData.GridImportCommand THEN
"DB_Energy".PowerData.GridImport_kW :=
"DB_Load".LoadData.Demand_kW -
"DB_Energy".PowerData.Generated_kW;
ELSE
"DB_Energy".PowerData.GridImport_kW := 0.0;
END_IF;
IF "DB_Energy".PowerData.GridExportCommand THEN
"DB_Energy".PowerData.GridExport_kW :=
"DB_Energy".PowerData.Generated_kW -
"DB_Load".LoadData.Demand_kW;
ELSE
"DB_Energy".PowerData.GridExport_kW := 0.0;
END_IF;
Computes four plant-wide performance indicators on every scan cycle, sourcing resolved power flow values from upstream blocks. Outputs are written to a dedicated DB_Metrics data block and bound directly to WinCC HMI display fields, providing operators with live renewable contribution percentages and grid dependency ratios consistent with industrial SCADA energy dashboards.
Solar_kW_In — from DB_Energy.PowerData.Generated_kWDemand_kW_In — from DB_Load.LoadData.Demand_kWGridImport_kW_In — from DB_Energy.PowerData.GridImport_kWRenewablePercent_Out → DB_Metrics.RenewablePercentGridDependency_Out → DB_Metrics.GridDependencySelfSufficiency_Out → DB_Metrics.SelfSufficiencyPlantEfficiency_Out → DB_Metrics.PlantEfficiencyA full operator overview screen was designed and deployed in WinCC Advanced Runtime, bound via HMI tag connections to the live PLC data blocks. The screen aggregates all critical plant parameters into a single operator view, modelled after industrial solar SCADA conventions.
Generated_kW numeric display with dynamic background colour indicating generation intensityGridImport_kW and GridExport_kWDB_Weather.WeatherDataDB_MetricsDB_Load.LoadData.Demand_kWDB_Energy.BatteryData.SOC with 0–100 scale mappingLive TIA Portal screenshots captured from the active PLCSIM runtime session with all Phase 2 networks compiled and loaded. All blocks confirmed green-online with zero compile errors.
Three operational states captured from the live WinCC Advanced Runtime session during PLCSIM execution. Each state demonstrates a distinct energy routing condition as the simulated day cycle progresses and solar irradiance varies.
All eight program blocks compiled to zero errors under TIA Portal V19 and loaded to the PLCSIM CPU 1511-1 PN virtual runtime. The WinCC Advanced HMI project was synchronised via the integrated HMI connection and launched in Runtime Advanced. All DB tag bindings confirmed active with live value updates visible across every HMI field during simulation.
Several non-trivial engineering challenges were encountered and systematically diagnosed during Phase 2 implementation.
Single-bit animation mode was unavailable for certain WinCC object types, preventing direct boolean-driven colour changes on the energy flow diagram.
Resolution: Animation properties reconfigured to range-based value mapping — values 0 and 1 used as discrete range boundaries, replicating bit-driven behaviour within WinCC's supported animation framework.
All four efficiency KPI outputs remained fixed at 0.0 during initial commissioning. Root cause: the inline grid command resolution SCL (Network 6) had been placed after FB_EfficiencyMetrics in the OB1 execution sequence. The metrics block was reading stale, unresolved grid import values from the previous scan cycle.
Resolution: Network ordering restructured — grid SCL resolution moved above FB_EfficiencyMetrics. This enforced correct data dependency sequencing within the PLC scan, ensuring all upstream values were fully resolved before KPI computation executed.
The legacy FB_GridManager [FB4] from Phase 1 continued to write GridImport_kW and GridExport_kW concurrently with the new FB_EnergyRouter routing commands, producing indeterminate and oscillating SCADA values as two independent control sources competed for the same process variables.
Resolution: FB_GridManager removed from the OB1 execution sequence entirely. FB_EnergyRouter designated as the sole authoritative control source for all grid interaction variables, restoring deterministic and consistent energy routing behaviour.
Multiple WinCC HMI tags failed to resolve at runtime. Causes included incorrect DB variable path references, PLC-to-HMI tag name mismatches, and UDT structure path errors in some tag definitions.
Resolution: Affected tags rebuilt manually — HMI tags rebound directly to DB-level variables with fully qualified path syntax. Tag connections validated in the WinCC tag editor and confirmed live in Runtime Advanced before commissioning sign-off.
WinCC generated compilation errors during Runtime launch related to invalid event handler references on auto-generated system screens.
Resolution: Invalid event references removed from the affected system screens. WinCC runtime compiled cleanly on subsequent build with no residual errors.
The zero-value metrics issue demonstrated that data dependency sequencing in OB1 is as architecturally significant as the function block logic itself. In any system where calculated values feed subsequent calculations within the same scan, block execution order must be explicitly designed — not assumed.
Allowing two control blocks to write the same process variable simultaneously produces non-deterministic, unstable SCADA behaviour. Industrial automation systems must enforce strict single-source ownership for every controlled variable — particularly for grid interaction and power flow values where conflicting commands have real operational consequences.
Each Phase 2 issue was isolated to a specific network or block within minutes, rather than requiring full-system analysis. The strict separation of concerns across weather, generation, storage, demand, routing, and metrics layers meant that each diagnosis affected one block — not a monolithic control program.
Multiple commissioning hours were consumed by incorrect HMI tag references rather than PLC logic errors. WinCC tag binding must be treated as a structured engineering activity — fully qualified DB paths, validated against the PLC data model, and tested independently of animation and screen logic.
This phase reinforced the architectural progression from monitoring → simulation → intelligent routing → metrics and diagnostics → operator visualisation. Each layer consumed verified outputs from the layer below it. That discipline is what allowed the system to scale from a static energy monitor into a responsive, decision-making plant management platform across two development phases.
Weather engine, solar generation, BESS, grid manager, PLCSIM virtual commissioning. Complete.
Dynamic load demand, intelligent energy routing, efficiency KPIs, WinCC Advanced SCADA HMI. Complete.
Inverter fault simulation, overtemperature alarms, grid instability events, alarm acknowledgment workflows, UDT_Alarm integration.
Energy historian, 24h accelerated playback, trend logging and SCADA reporting dashboards.
Wind turbine simulation, diesel generator backup logic, automatic transfer switching and source priority management.
Full plant state machines, PID thermal regulation, predictive energy optimisation, operational recipes.