Page Comparison

Anchor_Toc467408968_Toc467408968 Anchor_Toc467409569_Toc467409569 Anchor_Toc467410415_Toc467410415 Anchor_Toc467411625_Toc467411625 Anchor_Toc467432677_Toc467432677 Anchor_Toc467434575_Toc467434575 Anchor_Toc467439719_Toc467439719 Anchor_Toc467439921_Toc467439921 Anchor_Toc467440678_Toc467440678 Anchor_Toc467440956_Toc467440956 Anchor_Toc467443061_Toc467443061 Anchor_Toc467444629_Toc467444629 Anchor_Toc467445414_Toc467445414 Anchor_Toc467447238_Toc467447238 Anchor_Toc467447668_Toc467447668 Anchor_Toc467447761_Toc467447761 Anchor_Toc468014337_Toc468014337 Anchor_Toc468025228_Toc468025228 Anchor_Toc468033329_Toc468033329 Anchor_Toc468042091_Toc468042091 Anchor_Toc468042797_Toc468042797 Anchor_Toc468049457_Toc468049457 Anchor_Toc468052847_Toc468052847 Anchor_Toc468052958_Toc468052958 Anchor_Toc468053511_Toc468053511 Anchor_Toc468053624_Toc468053624 Anchor_Toc468053739_Toc468053739 Anchor_Toc468053854_Toc468053854 Anchor_Toc468053970_Toc468053970 Anchor_Toc468054598_Toc468054598 Anchor_Toc468641584_Toc468641584 Anchor_Toc468654465_Toc468654465 Anchor_Toc468654642_Toc468654642 Anchor_Toc468654803_Toc468654803 Anchor_Toc468688821_Toc468688821 Anchor_Toc469000581_Toc469000581 Anchor_Toc469000740_Toc469000740 Anchor_Toc469012964_Toc469012964 Anchor_Toc469013126_Toc469013126 Anchor_Toc469013291_Toc469013291 Anchor_Toc469013454_Toc469013454 Anchor_Toc469013621_Toc469013621 Anchor_Toc469014525_Toc469014525 Anchor_Toc469014688_Toc469014688 Anchor_Toc469038952_Toc469038952 Anchor_Toc469041754_Toc469041754 Anchor_Toc469041902_Toc469041902 Anchor_Toc469042057_Toc469042057 Anchor_Toc469044757_Toc469044757 Anchor_Toc469044904_Toc469044904Ideally, each site would have a Development, Test, and Production Environment. Although we don't see it often, ideally each environment would be isolated on its own subnet or Virtual Machine LANs so that most servers could not connect to each other. The one exception is the Process Historian, which may be used as the source historian for all three environments simultaneously. Anchor_Toc469044905_Toc469044905

Development

A Development environment should be created if the site anticipates a lot of new development or new configuration work being anticipated. This could be considered a trial & error until success environment. Some might refer to it as a "sandbox" where there is a fair amount of freedom for experimentation or simulated training. Ideally, new development or configuration is taken to a stage where there is confidence that it "should work" and has reached the testing stage for the Production environment. Regarding infrastructure, it is important that most applications that are likely to be configured or further developed be installed. The server topology, however, does not have to match the Production environment. Where there are cost savings available due to merging servers or realistically reducing CPU/RAM "horsepower," these should be taken advantage of.

A Test environment is required for most MES environments. It should mimic the Production infrastructure as much as possible: Server Topology, Server configuration (Operating System, CPUs, RAM), Server application installation base (Application Server, SQL Server, Visualization Server, Process Historian). Often effectively mimicking the OPC layer is not feasible or possible so this is often not part of the testing environment. A workstation to test client installs will also be required. If workstations are deployed by using something similar to a Citrix environment, then a Test Citrix server may also be required.
The Test environment is used for:

1. Testing new Operating System updates

2. Testing new application hotfixes or SIMS

3. Testing newly developed or created configurations (ideally developed/created first in the development environment).

4. Training, if a separate training or development environment is not available.

1. If there are Operating System or Application upgrades to be performed at the Company's Site they must be performed in all three environments. If all three environments are installed, then they would first be applied to the Development, Test, and Production environments in that order.

2. Refreshing an environment generally means backing up and restoring the SQL production database(s) to the Development and/or Test environment SQL server. This "refresh" involves many steps including some well thought out SQL scripts that convert the server names from the production environment to the server names in the Dev or Test environment as appropriate. It also turns off or deletes any references to the production environment that may allow a "leak" of data to that environment. Typically, a refresh takes around 3 – 4 hours to complete not including the time to backup and restore the database.

3. The site should establish a standard schedule for refreshing the Development and Test environments. A schedule might look like:

   1. Ad Hoc: Ad Hoc requests from various sources. A one-week notice is required to the database team (for backup and restoring DB), to the "refresh MES-IT team" (to allocate resources and to ensure that PA Services are turned off (connections to the database) prior to the database being restored), and to any Support/Project/Training, or Testing teams that may be working in that environment.

   2. Development Environment: Approximately every 6 months (or sooner via ad hoc requests)

   3. Test Environment: Approximately every 3 months (or sooner via ad hoc requests)Disaster