CMS DCS: WinCC OA Installation Strategy Lorenzo Masetti Workshop on WinCC OA Upgrades 27th May 2016

Current CMS DCS overview Distributed system of 34 WinCC OA systems running on 28+28 DELL Blades Runs on Windows Server 2008 R2 Homogeneous environment: same software (WinCC OA, OPC Servers, etc.) installed with CMF in all the blades WinCC OA redundancy 68 WinCC OA projects on 56 DELL blades

Production deployment Sub-system developers/experts have no access to DCS computers Everything must be packaged as a JCOP component Components are read from SVN Production configuration is versioned and can be rebuilt if needed Possibility to patch a component if only panel/scripts/libraries are modified (no change in postInstalls, dplist) Installation Tool and Configuration DB System Information are critical CMS install library standardises and simplifies postInstall scripts: Add/stop/restart drivers and managers Target ConfigDB configurations to the system Defined in a custom XML file – only one line of code needed Hardware and logical views are stored in the ConfigDB No standard solution to store FSM trees CMS custom XML export/import for the FSM

Installation tool Configuration All the projects are configured to run in Central Management Mode System Configuration DB is the master all changes in the configuration db are applied to the production system New components installed Changes in the list of connected systems The installation agent is always running in our production systems Checks the consistency every 5 minutes How to push changes in the DB? Subdetector experts can update the version of their components (from cmsonline) To target a new component, the intervention of the central expert is required Using System Configuration DB WinCC OA interface

Consistency enforced The CMS deployment policy tries to ensure that all the changes are reflected in the System Configuration Database Changes are reproducible in case the system needs to be reinstalled. Expert “hacks” forbidden or minimized This was very important before the redundancy was introduced The only way to restore a failed pc was to reinstall the project in a new pc It is still important because this policy allows us to upgrade to a new WinCC OA version relatively quickly

Symbolic Link to Network File System Framework Path Policy All the projects in production share the same framework path (no local repository) All the components are installed in the same framework path All the projects in production must have the same version of common components (framework, CMS general components) The framework path must be changed when upgrading WinCC OA version Binaries are different It is then possible to have different versions targeted to different WinCC OA versions Framework paths are accessed via symbolic links Easy way to switch from filer to dfs in case of problems. [general] pvss_path = "C:\Siemens\Automation\WinCC_OA\3.11" proj_path = "C:\DCS\DCSRepository\FrameworkInstallation311" proj_path = "C:/DCS/WCCOAprojects/ServiceProject" Symbolic Link to Network File System

Script to install from scratch The installation tool is used to install a project from scratch the project must be created first (initial db, initial config files, registered as a service) Batch file CreateServiceProject.bat Connects to the System Configuration DB Using fwInstallation standard functions before the project is created (WCCOActrl –n) Retrieves all the information (system name, initial config file, system number, etc…) depending on the hostname Creates a default project with a predefined set of basic managers (data, event, redundancy, etc…) Starts the installation tool that finds an empty project and installs all the components in the proper order defined by dependencies Also handles the redundancy (it can copy the project from the peer if available)

Installation from Scratch Flowchart The System Configuration DB was extended with a function that produces the initial config file for the project Most of the installation work is done by the standard fwInstallation tool. The batch script is only used to create and register the project. Yes No

How to upgrade to 3.14

Procedure to upgrade to 3.14 Stop and backup the old system (both peers) Update the version in the System Configuration Database update fw_sys_stat_pvss_project set pvss_version = '3.14' where id=:1 Update the fw installation path in the database C:\DCS\DCSRepository\FrameworkInstallation311 -> C:\DCS\DCSRepository\FrameworkInstallation314 Untarget the old fw components and target the new ones (in principle the subdetectors components are not changed) Install WinCC OA 3.14 and update PATH to point to 3.14 Start the installation script It will automatically use WinCC OA 3.14 to recreate the project

Questions???