Change log of version 2.2.14.6

Upgrade information from installations earlier then WinCC OA 3.18 / vimaccOA 2.2.10.26 > IPC protocols / ConfigNG

Based on the project experiences over the last decade, the internal runtime database of vimaccOA (named “vimacc Config”) has been general re-engineered for better runtime performance and system stability – also results in an overall improvement of the redundancy features of vimaccOA.

Reworking the IPC protocols of the “vimacc Config” harms, first time ever, the compatible with earlier versions of vimaccOA - NOT the compatible with any version of WinCC OA. Because of this any upgrade of distributed vimaccOA installations, from versions earlier then 2.2.10.26, needs additional plannings to keep operations without any general downtime. Please contact the WinCC OA VIDEO experts for further information and support (keyword “vimacc ConfigNG”).

Upgrade information from installations earlier then WinCC OA 3.20 P01 / vimaccOA 2.2.14.1 > Config Heap Improvement

Caused by the rework of the IPC protocols of the “vimacc Config” (see “ConfigNG” above) the heap memory usage of any vimacc processes increased significantly. With the release 2.2.14.1 of vimacc there has been performant several improvements regarding this topic. As a result of this, the format of some data structures changed from UTF-16 to UTF-8, which results in a incompatibility between a new Config Client (any vimacc process) and an old Config Server (AccVimaccConfig, AccVimaccSlave & AccVimaccConfigProxy).

To avoid any system downtime during an update it’s absolutely crucial to update the Config Servers first, before updating Config Clients. The update should be performed as follows:

  1. vimacc Config Server: hosts actively running AccVimaccConfig
  2. vimacc Config Proxy or Config Slaves: hosts actively running AccVimaccConfigSlave, AccVimaccConfigProxy
  3. hosts running other vimacc processes, like AccVimaccDisplay

Please contact the WinCC OA VIDEO experts for further information and support.

Additional information regarding feature “Stream cloning”

The feature of “Stream cloning” (introduced in vimaccOA 2.2.10.30) needs an update of the internal feature lists in vimaccOA. Please contact support for further guidance for activation of this feature.

New Features (compared to vimaccOA 2.2.10.36)

  • Layout Sensitive Bandwidth Management - When configuring special “quality tags” (like low, medium, high) to several streams of a camera, the vimacc Workstation and DisplayServer are automatically switching the streams based on the given grid layout. This allows reduction of network bandwidth and CPU load for decoding, if in a layout many streams are viewed, so that the high quality (e.g. Full-HD) are not needed to be displayed. The quality tags are handled per video dialog within a grid, based on the dialog size, based on the following rules:
    • 1 dialog = "high"
    • 2-6 dialogs = "medium,high"
    • >6 dialogs = "low,medium"
    • >12 dialogs = "low"
    • Spots always (like big dialog in the 11+1 grid) = "medium,high"
  • Privacy Zone editing - As the VIDEO AddOn supports the generation of privacy zones on the client side (VideoEWO, vimacc Workstation & DisplayServer) during visualization of video streams since 3.19, it’s new with 3.20 also supporting the configuration of these zone in a graphical way.
  • Overlays: SVG editor - Since 3.19 the VIDEO AddOn supports the visualization freestyle overlays, based on SVGs, during the display of video streams. New with WinCC OA 3.20 there has been added a graphical SVG editor, for the configuration of the overlays.
  • PlaybackProxy - When using network segmentation, e.g. for separation of Video Clients from Recording Servers, the PlaybackProxy helps to reduce the list of open ports between network segments, relaying the connections. Please consult the WinCC OA VIDEO experts for further information and support.
  • Update of Crypto Tokens to 3072 Bit - The generation of crypto tokens for IPC communication and stream encryption has been enhanced to 3072 Bit. These only harms fresh installations without any existing keys. If you plan to switch crypto tokens in a current installation, please consult the WinCC OA VIDEO experts for further information and support.
  • Enhanced features in vimacc Workstations - Several enhanced features have been enabled for the vimacc Workstation, like
    • access to Scenarios, Sequences, Bookmarks & Protections tabs
    • generating stream snapshots as PNG, JPG or PDF reports for single or all opened video stream
    • image display settings (like brightness, saturation, etc.)
    • video analytics of recorded video streams (AI based possible, with consulting)
    • export of playbacks

New Features (compared to vimaccOA 2.2.14.1)

  • Support for AUX commands (Bosch RCPP) Streaming Interface supports now AUX command for RCPP devices (Bosch Cameras), adding functionality to set an aux ON or OFF, with additional parameter "value=1" (ON) or "value=0" (OFF). Example for wiper: cmd=auxiliary;aux=105;value=1;

Changelog (compared to vimaccOA 2.2.14.1)

  • General:
    • Fixed the AccVimaccSecurityWizard call in RPMs for Oracle Linux to ensure encryption keys (vimacc_keys.pem) are correctly generated during installation.
  • WinCC OA Components:
    • Update of used QT-Version for libraries to QT 6.5.7
    • VideoManager: Fixed an issue where sequences were not available in redundancy scenarios for the vimacc Config.
    • VideoManager: Resolved issues that caused scenario configurations to be missing in vimacc Workstation.
  • vimacc-Core:
    • General refinements to the codebase for improved product support.
    • Fix of ONVIF implementation regarding dispatching of events, that have no tt:Source tag. This effects for example the LIDAR devices of "Blickfeld".
    • Improved startup performance of vimacc Workstation by reducing code complexity from unused feature implementations.
    • Resolved an issue with the "Layout Sensitive Bandwidth Management" feature where switching streams displayed the full camera name, including its path, instead of a truncated name. This occurred despite the VideoPanelOptions/useTruncatedStreamNames=true setting in AccVimaccWorkstation.conf.
    • Updated the setup process to support reading values for the command-line parameters "-IntfCount" and "-ServerCount" from the registry:
      • HKEY_LOCAL_MACHINE\SOFTWARE\Accellence\vimacc\General\InterfaceCount (String)
      • HKEY_LOCAL_MACHINE\SOFTWARE\Accellence\vimacc\General\ServerCount (String)
        • When using these command-line parameters, their values are automatically stored in the registry for future use (e.g. when installing an update).
    • Fixed an issue in the "Show Meta Information" dialog of vimacc Workstation where the count for "camera(s) in maintenance" was incorrect.
    • Enhanced the visual design of the "Show Meta Information" and "Camera Information Overview" dialogs in vimacc Workstation, particularly for cameras in the "in maintenance" state.
    • Implemented several enhancements to the "Layout-Sensitive Bandwidth Management" feature, improving its functionality and performance.
      • For a seamless upgrade strategy, the pausing of decoding for hidden video dialogs is now disabled by default. To enable this feature, set the “VideoPanelOptions/stopDecoderIfPlayerNotVisible=true” in the configuration files for vimacc Workstation and/or vimacc Display.
    • Fixing several critical issues regarding AccVimaccInterface, AccVimaccInterfaceProxy and AccVimaccServer, which resulting in unstable streamings from interfaces to clients and unreliable behavior regarding the provisioning of timeline information – mostly seen on wide area networks.
    • This especially harms any Display-Dist architecture and usage of the Stream Cloning features.
    • Fixing possible memory leaks in certificate handling for SSL connections.
    • Updated the KDEC protocol implementation to support addresses up to 999, as specified in the document "KDec_300_7.71980_BA_DE.pdf" (Version 3.3 for KDec-300 Version 2.x & 3.x). This extends compatibility beyond the previous limitation of 0x20, which was designed for legacy hardware with 5-bit addressing ranges.
    • Improved the handling of network operations to ensure smoother and more reliable performance by moving certain processes to a dedicated network component, reducing the risk of unexpected behavior. Enhanced the stability of network settings adjustments, ensuring compatibility with system requirements and best practices. (Windows only)
    • Resolved an issue where encoder errors were displayed continuously due to a flawed check preventing proper decryption setup.
    • Improved data processing efficiency in the system to enhance overall performance.